For the best microservices results, you need to do your homework. By Wayne Geils, AWS technology evangelist at ServerCentral Turing Group and Mike Hostetler, senior director of engineering at Cars.com
Microservices are hot right now. IT colleagues I talk with are excited about their potential, and thought leaders in various industries are speculating about their transformative power – and with good reason. Used effectively, microservices have the capacity to improve the flexibility and scalability of many software-based applications.
However, they’re not the right solution for every scenario. When they’re used without a strategic plan, they can end up costing a lot more than a company expects (in the same way that poorly planned cloud deployments can lead to outsized bills). Here, I’ll highlight some of the hidden costs microservices can add to a company’s IT program and offer some tips for evaluating whether they make sense in a given scenario.
Background: the four-week footer update
First, a quick anecdote: at Cars.com, we adopted microservices-based architecture to give us the ability to scale more easily and efficiently. It worked: we hit 50 million visits in August, and our microservices infrastructure helped us scale our servers to handle that growth.
There have been downsides, too. For example, we determined at one point that we needed to change something in our website’s footer, and because we had 17 microservices working together to run the front end of the site, all of them had to be updated to make the change. In the end, it took us a bit of time to make the update.
That was one of a few incidents that served as a wake-up call and spurred us to kick off a more detailed technology transformation project. We’re now moving away from microservices for much of our platform.
Hidden costs in time, tech, and people
Clearly, a timeline for a website footer update measured in anything more than seconds is too long. Worse, we didn’t anticipate the update taking as long as it did, which meant we had to bump other projects back to accommodate the tweak.
That incident was frustrating for us, but it was also symptomatic of a larger problem: improperly or inefficiently deployed microservices can slow a company’s velocity of change.
This is true partly because breaking a large application or service into several microservices inherently adds to its complexity, which means it takes longer to run integration tests and teams have to better coordinate their communication as they run those tests. All of this takes time.
These realities also mean that someone must be in charge of coordinating integration testing and inter-team communication, which means you either have to hire for that role or expand someone’s current duties. Microservices are a cultural and technical transformation.
Another role you’ll have to assign is the managing of microservices orchestration. If you’re using AWS, for example, there are three orchestration services you can use. But someone has to be in charge of choosing the right one and that it’s operating correctly.
And unlike on-prem architecture, which can be expected to remain stable, AWS has near-constant feature releases and updates, which means someone has to constantly work to optimise and maintain the stability of anything you build with microservices.