Image: spainter_vfx, Getty Images/iStockphoto

As usual, Kelsey Hightower is probably right. In early 2020, Hightower suggested that “monoliths are the future.” The problem, he pointed out, is that developers haven’t been building microservices so much as building distributed monolithic applications: “Now you went from writing bad code to building bad infrastructure that you deploy the bad code on top of.” It’s garbage code (and microservices sprawl) all the way down.

So is 2021 the year of the monolith? Definitely maybe.

SEE: Microservices: The foundation of tomorrow’s enterprise applications (ZDNet/TechRepublic special feature) | Download the free PDF version (TechRepublic)

Solving and creating problems

But first, let’s remember why microservices have been such a boon to computing. First, microservices allow disparate teams to collaborate on the same system without necessarily using the same tools (database, language, etc.). It also makes it easier to build highly scalable applications, because instead of having to scale one monolithic application, teams could break up these applications into smaller services, scaling each independently. As a bonus, each microservice would maintain state, unshackling the need of the associated application to run on a single machine.

All good, right?

Not quite. According to Temporal’s Ryland Goldstein, “The first issue people noticed when they switched to microservices was that they had suddenly become responsible for a lot of different types of servers and databases.” Such infrastructure issues have been solved, in part, by the introduction of Kubernetes and serverless offerings, but it has left the lingering issue of bad code. (See Hightower’s point above: Bad code on bad infrastructure.) Companies like Temporal aim to offer microservices orchestration platforms that allow developers to focus on business logic while leaving management of the microservices infrastructure to Temporal, an interesting approach that could help. (Of course, Hacker News has lots of opinions on this.)

But there’s a more fundamental question to answer, and it goes back to the heart of Hightower’s argument: Do you really need microservices?

SEE: Prepare for serverless computing (ZDNet/TechRepublic special feature) | Download the free PDF version (TechRepublic)

Back to the future of monoliths

This is not simply a matter for smaller teams to consider, as the esteemed Martin Fowler has posited: “While [microservices] is a useful architecture—many, indeed most, situations would do better with a monolith.”

Why? Fowler suggested (at least) three reasons. First, distributed systems are harder to program, since remote calls are slow and are always at risk of failure. Second, maintaining strong consistency is difficult for a distributed system, which leaves everyone to figure out how to manage eventual consistency. And, finally, most companies lack the mature operations team capable of managing many services, most of which will be redeployed regularly.

SEE: Research: Microservices bring faster application delivery and greater flexibility to enterprise (TechRepublic Premium)

Adding to this, Lyft engineering lead Matt Klein has offered another key difficulty introduced by microservices: “The other major shift that comes with microservice development is the emergence of the network as an unstable substrate that cannot be avoided. Every developer must ultimately deal with networking problems, both in terms of transport and in terms of the vastly more complex tooling required for debugging.” (Of course, Klein would be the first to argue for a microservices-based approach, given he developed Envoy precisely to aid Lyft’s shift away from a monolithic-based approach.)

But this could be a long way of saying that a new development and deployment paradigm won’t save developers from bad habits. Shaun Gehring, senior product engineering lead at Comcast Cable, gets at this when he argued, “Your implementation success will depend on the amount of planning you put in.”

In other words, asking if monoliths (or microservices) are the future is the wrong question. It’s really a question of an individual company/developer team, and what they’re prepared to put into the application/infrastructure. Garbage in, garbage out, and that is true for both microservices and monoliths.

Disclosure: I work for AWS, but the views expressed herein are mine.

Also see