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 TrendsGlobal 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 LightstepLightstep. 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.Stay informed.
September 26, 2018
4 min read
About the author
Kristin BrennanRead moreRead more
Explore more articles
Monoliths to Microservices: The Journey to Cloud NativeJason Bloomberg | Sep 14, 2022
The path from earlier-generation monolithic architectures to today’s cloud native computing was a bumpy one. From REST-based SOA to microservices architectures to today’s hybrid cloud native architectures, we’ve learned many lessons along the way.Learn moreLearn more
Migrating to Microservices: Worst PracticesJames Burns | Apr 28, 2020
The reality is that most migrations bog down quickly. This worst practices guide will tell you how you too can end up with a distributed monolith at the end of a multi-year long slog.Learn moreLearn more
Thinking about Migrating to Microservices? Here’s Where to StartTalia Moyal | Mar 24, 2020
Migrating to microservices is not an easy decision, and one that shouldn’t be taken lightly. To get a head start, here are the two main questions that should be answered before migrating to microservices.Learn moreLearn more
Lightstep sounds like a lovely idea
Monitoring and observability for the world’s most reliable systems