The Death Of Microservices?
A blog from Amazon has been buzzing in the IT industry: A monolithic architecture produced superior performance compared to a serverless microservices approach. It reduced infrastructure cost by over 90% and increased scaling capabilities. In response, polemics abound denouncing microservices. So are microservices dead? Is it time to go back to the monolith?
To answer like an architect: It depends. This is the same problem we faced with structured programming on our Commodore 64s and COBOL mainframes and with the object-oriented design that followed. The problem lies not in microservices itself but in poor decisions about coupling and cohesion.* I believe the backlash is due to embracing microservices worst practices that fail to address those decisions.
Why Monoliths Suck
Let’s first understand why a monolith is bad. It’s not due to its size. Rather, it’s because the business design that you have today is different than what you had 15 years ago, when the monolith was first designed. This is because the monolith, once well aligned to your business, grew haphazardly over time. It’s because you embraced agile’s “make it up as you go” emergent architecture mistake. It’s because it has turned into a big ball of mud. If those sentences don’t describe your monolith, then your monolith doesn’t suck — it’s likely a good architecture; keep it for now.
Why Microservices Suck
If you think “microservices” means small services for the sake of small services, then, yes, it’s a terrible pattern that should be left to the ash heap of history. But that’s the wrong view. The name is a misnomer — a microservice can be quite large. It’d be better called a “component service” or “correctly sized service.”
The value is aligning the org structure and components of your applications with your business design while ensuring that the marginal benefit of decomposition outweighs the marginal cost of added complexity. That marginal cost/benefit concern seems to be the crux of the Amazon blog. (Though to be fair, the blog says the original design led to faster speed to market. That isn’t necessarily a mistake if you can pay down the debt, as Amazon clearly did.) If you’re able to effectively maintain your app with one team, even if it’s a large code base, it’s probably best to stick with the monolith. But if your app spans across multiple teams with massive and painful release coordination, “correctly sized services” may be the right move with consideration to the marginal costs and benefits.
Above all, replacing the big ball of mud with distributed little balls of mud will make things worse. You will soon face an unmigration project to restore the monolithic ball of mud. Sadly, organizations that pursue little balls of mud often blame microservices rather than their poor architectural decisions.
Focus On Outcomes, Not Trendy Buzzwords
Don’t just blithely follow trends without comprehension. Understand how an architecture adds value and its trade-offs. Know your desired business outcomes and how an architecture aligns (or doesn’t) to those outcomes. Be clear about how your IT org structure is aligned (or misaligned) with your business design, and employ a reverse Conway to make them aligned if necessary. Be frank about the limits of your organization’s competencies: Migrating to monoliths won’t, as Kelsey Hightower put it, “somehow find the engineering discipline we never had in the first place.” Most important of all, never forget: Employing microservices for microservices’ sake won’t make up for poor coupling and cohesion decisions.
Ultimately, architecture is about delivering business outcomes. Start with the desired outcomes before discussing technical design. Whether it’s microservices or a monolith, you must be able to articulate how the choice advances those business outcomes. To quote that original Amazon blog, “Microservices and serverless components are tools that do work at high scale, but whether to use them over monolith has to be made on a case-by-case basis.”
*For the hardcores out there: Software engineering has identified “loosely coupled and highly cohesive” components as an architectural ideal since the late 1960s. Balls of mud, whether small or large, are neither.