Monoliths to Microservices — Scale Changes Everything

September 27, 2018 | Kristin Brennan

It was a dark and stormy night last week in Austin when engineering leaders from Under Armour, BigCommerce, and Indeed delivered lightning talks about their microservices nightmares. While the specific details across the three companies differed, there were some common themes about the pains and lessons learned from operating microservices at scale.

Complexity is inevitable

One common theme across all presenters was that microservices are inherently complex and if their creation and deployment aren’t properly controlled, a proliferation of multiple languages and redundant tools makes things much harder. In some cases, this heterogeneous environment is the product of acquisitions where each team selected different tools and created their services in different languages. In other cases, it’s the result of newly autonomous engineering teams operating like it’s the Wild West; picking whatever technologies they want and duplicating functionality.

One of the speakers shared that when he joined his organization, microservices were being written in seven different languages. This meant that when a developer built something, another developer had to build six different client libraries for it — which was completely unmanageable. Architecture decisions were influenced by the communication limitations across services. The more services they added, the more complex things became, which led to greater inconsistencies. The recent Global Microservices Trends report also found this to be true: 56% of respondents stated that each additional service increased the overall complexity.

Corral and control what you can

A platform engineering team can serve a critical function in simplifying complexity by corralling and controlling technology choices. Each of the speakers discussed the value of introducing limited choices for the tools that developers use and the languages in which they write services. But, platform engineering teams also need to embrace a little bit of chaos and offer a few options in their development approaches. Dictating a singular approach can lead to “religious” arguments where nobody wins. To operate effectively, teams must introduce some standards for things like deployment policies, tools, and the languages that developers use to write the services. When platform engineering teams introduce these limited options, they’re on the hook for ensuring that the tools and languages they select are awesome. And the people who are on call — the ones who are awakened in the middle of the night when something breaks — should select the infrastructure.

Living and dying by managing complexity

Platform engineering teams live and die by being able to manage the complexity of modern distributed systems. Teams need to take a hard look at the problems they’re trying to solve and pick the best pieces of technology and apply them. The role of platform engineering should be to make it easier for other engineers to focus on building customer value. As one of the speakers stated, “If the engineering organization isn’t chomping at the bit to use what the platform team has built, then something is wrong.”

Scale changes everything

The lesson learned by each of the three presenters was “scale changes everything.” As each of the organizations began their initial efforts of adopting microservices and shrinking their monoliths, they had to change their processes and technology. The old ways of doing things, like tapping someone on the shoulder to deploy, no longer worked.

As each of them contemplated the massive growth they expected in the number of services over the coming two years (one projected as many as 10,000 new services), they wondered if the new processes would continue to work with that kind of scale? Would the system explode in unforeseen ways?

The parting advice from our speakers: equip your teams with tools, such as service meshes, that let you scale sublinearly. Look for solutions built specifically to handle the scale and complexity of modern distributed systems such as [x]PM. And, enable teams to self-serve as much as possible, so no team becomes a bottleneck.

Want to learn more about microservices and avoid nightmares? Stay informed.

Originally published at lightstep.com on September 27, 2018.