It was inevitable! With such euphoria greeting the concept of microservice architecture in 2014, it was only a matter of time before the trough of disillusionment swallowed the hype. What started with blogs like “What are microservices?” and “Reducing technical debt with microservices,” peaked with articles like “Can microservices save U.S. Retailers?” and “Why microservices are the foundation to a digital future,” has now come crashing down with pieces like “Goodbye microservices” and “Monoliths are the future.” Where did it all go wrong?
Examining these recent blogs reveals some specific criticisms. In “Goodbye microservices,” Alexandra Noonan recounts Segment’s microservices journey. Initially, Segment adopted microservices to optimize their message distribution by removing a single queue bottleneck in their architecture. Although this yielded good results at the start, a number of consequential design decisions (e.g. moving to multiple repos) led to “exploding defect rates,” “plummeting velocity,” and a feeling they had become “mired in complexity.” Segment has subsequently reverted to a monolithic architecture. In “Monoliths are the future,” Kelsey Hightower identifies a pattern he has observed whereby organizations move to microservices in the hopes a new approach will correct the structure of their haphazard monoliths. The result is a poorly-structured microservice architecture that amplifies the monolith’s issues without providing any of the claimed benefits of microservices. Are these stories an indictment of microservice architecture?
Conceptually, no. However, they do reflect a trend of organizations jumping on the bandwagon because of some new hype. Nothing attracts a crowd like a crowd, as the song goes. In my 2016 piece for InfoWorld — Learn from SOA: 5 lessons for the microservices era — I outlined how this tendency derailed the service-oriented architecture movement. If you don’t have a destination in mind, it makes it easier to jump off one bandwagon and wait for the next. Interestingly, the Segment blog even outlines the generalized benefits of microservice architecture — ”improved modularity, reduced testing burden, better functional composition, environmental isolation, and development team autonomy” — and then articulates a completely different goal in adopting microservices (runtime optimization). If you don’t know why you’re doing something, or the reason you want to do something doesn’t match with why it should be done, maybe it isn’t the best approach after all.
The goal of microservice architecture
Architecture in any field — not just in software — is about design within a complex domain where perspectives and priorities conflict. Architectural decisions should be guided by the question, “for what am I optimizing?” As a generalized approach, microservice architecture was never intended to optimize for initial speed of delivery, nor was it intended to optimize for runtime performance. Rather, the goal of microservice architecture is to optimize the structure of software systems for changeability over time while scaling up. There can be benefits to aggregate delivery speed and operational resilience, but the broader context is system evolvability. Microservice architecture does not — or should not — pretend to eliminate complexity. Microservice architecture embraces complexity. Although known as a style of software architecture, microservices have always been about more than the software.
The Lewis and Fowler bliki post — that popularized the term “microservices” — focused very little on the technical details of this new architectural approach. Instead, they defined the common characteristics and patterns they had observed in organizations implementing these small, network-bounded application components. This makes sense when you examine the reasons these organizations adopted a microservice architecture. For many, such as SoundCloud, it was about scaling the delivery and operations of an increasingly complex software system. To achieve that goal, SoundCloud adopted Agile software development methods, continuous delivery, and a DevOps culture. Microservices was the architecture that matched their adjustments in these other areas. Such early adopters understood that software systems, the organizations that build and support them, and the methodologies they use are actually one interconnected sociotechnical system. To address their scalability needs, they had to analyze each of these sociotechnical dimensions. It is no coincidence that the popularity of Conway’s Law, an axiom asserting the inextricable link between systems and the organizations that create them, has been renewed in conjunction with the microservices movement. In a recent Twitter thread, Mel Conway stated that one cannot effectively design a system without considering the broader systems that contain it. A microservice architecture was never going to enable high changeability at scale on its own.
Beyond microservices
Although many of the most well-known implementers of microservices — such as Amazon and Netflix — come from the post-web world, organizations of every size and vintage are feeling the impact of software change momentum colliding with the inertia of their system complexity. Established enterprises that have run their core operations on aging applications feel these effects most keenly. We wrote the book Microservice Architecture to deconstruct the approach, highlight its intended benefits, and show how enterprises could apply it in their context to deal most effectively with the complexity of their growing landscape of interconnected software components. Organizations who try out microservices and don’t get the results they want should not be surprised. Confronting expansive complexity resulting from generations of software legacy is a difficult task. And even if the architecture is done well, there could be other sociotechnical barriers that hinder the benefits. As Bridget Kromhout articulated so well, “containers will not fix your broken culture.” Neither will reverting to a monolithic architecture, or migrating to a serverless approach, or wrapping everything in GraphQL. At least not on their own.
I am still bullish about the principles of microservice architecture. As I outlined in my InfoWorld piece, I see microservices as a proven approach to dealing with software complexity based on its empirical roots, as well as its holistic nature. There are amazing resources out there from wise practitioners like Chris Richardson and Sam Newman to help find practical ways to apply it. Darrin Solomon’s blog series on adopting microservices is particularly useful for enterprises undergoing digital transformation. Nonetheless, I have been in the industry long enough to know that buzzwords come and go, technologies rise and fall just as quickly, but the stubborn problems we’re grappling with never seem to go away. In fact, as we add more and more layers to our software systems and reap the business benefits that come with new applications and features, we compound the systemic inertia by introducing more complexity. So we know that we will still need to deal with complexity at scale long after the term “microservices” has been retired.
As we exit the microservices era and enter whatever comes next, let’s not fool ourselves into thinking there is some new fad — microserver-less mesh — that will be the silver bullet we’ve been waiting for. Let’s extract the techniques and principles from microservice architecture that help us deal with complexity at scale and incorporate them into our future approaches. In part two of this blog series, I will examine those attributes in more detail.
MuleSoft’s Way of the API workshop shows organizations how to apply to most effective principles of microservice architecture in an enterprise context. Find out more about MuleSoft’s API Program Workshops.
