The hidden costs of microservices

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.

Cloud bills for microservices

The unexpectedly large cloud bill is almost a rite of passage for businesses that decide to embrace cloud adoption without taking the time to outline a strategy for doing so.

For microservices built on cloud platforms, the problem can be made worse.

There are two main causes of higher-than-expected bills for microservices architecture: first, scalability – a primary reason people choose microservices in the first place. However, when something can scale more or less limitlessly and with almost no friction – and you’re paying by use – it’s easy to use more than you planned.

The second reason microservices can cost more than expected is that inter-service calls require more data than similar calls would in a traditional architecture. The cost of transmitting data among multiple services can – and does – grow fast.

The good news here is that, just as with cloud architecture more generally, the costs of microservices can be managed with strategic planning.

For best results with microservices, do your homework

While I don’t think the buzz around microservices is unearned – the technology offers an exciting way to solve very real business problems – I would caution business leaders to be wary of the buzz itself. Any time a technology becomes trendy, there’s a risk that business leaders will want to use it for the sake of being on trend.

That can create more problems than it solves. In the case of microservices, those problems might include increased personnel demands, increased systems complexity, hampered ability to implement change, and higher-than-expected bills.

For best results with a microservices implementation, start with a clear problem that you hope the technology can solve. Work with experienced engineers and business strategists to develop a holistic vision of how microservices can work within your business to improve its operations and profitability. With a plan in place from the beginning, you’ll maximize your odds of success in the short and long term.