Microservices at scale: A complexity management issue

by Jeremy

The benefits of microservices have been touted for years. Their popularity is apparent when you consider the explosion in the use of technologies, such as Kubernetes, over the last few years. Based on the number of successful implementations, popularity seems to be deserved. 

For example, according to a 2020 survey by O’Reilly, 92% of respondents reported some success with microservices, with 54% describing their experience as “mostly successful” and under 10% describing a “complete success.”


But building and managing all of these smaller units containing code adds a lot of complexity to the equation, and it’s essential to get it right to achieve those successes. Developers can create as many of these microservices as they need, but it’s necessary to have good management over those, especially as the number of microservices increases. 

According to Mike Tria, head of platform engineering at Atlassian, there are two schools of thought to managing microservices’ proliferation. One idea is to keep the number of microservices to a minimum so developers don’t have to consider scale and security.

“Every time they’re spinning up a new microservice, they try to keep them small,” Tria said. “That works fine for a limited number of use cases and specific domains because what will happen is those microservices will become large. As they say, you’ll end up with a distributed monolith.”

The other option is to let developers spin up microservices whenever they want, which requires some additional considerations, according to Tria. Incorporating automation into the process is the key to ensuring this can be done successfully. 

“If every time you’re building some new microservice, you have to think about all of those concerns about security, where you’re going to host it, what’s the IAM user and role that you need access to, what other services can it talk to—If developers need to figure all that stuff out every time, then you’re going to have a real scaling challenge. So the key is automating those capabilities away, making it such that you could spin up microservices without having to do all of those things,” said Tria.

According to Tria, the main benefits of automation are scalability, reliability, and speed. Automation allows scale because new microservices can be created without burdening developers. Second, reliability is encapsulated in each microservice, which means the whole system becomes more reliable. Finally, skill and speed are gained because each team can build microservices at their own pace. 

Atlassian built their tool for managing microservices, but Tria recommends starting small with some off-the-shelf tools. This will enable you to get to know your microservices and figure out your needs, rather than predicting your needs and buying some expensive solution that might have features you don’t need or is missing parts you do. 

“It’s way too easy with microservices to overdo it right at the start,” Tria said. “Honestly, I think that’s the mistake more companies make getting started. They go too heavy on microservices, and right at the start, they throw too much on the compute layer, too much service mesh, Kubernetes, proxy, etc. People go too, too far. And so what happens is they get bogged down in the process, in bureaucracy, in too much configuration when people want to build features fast.”

Related Posts