Monolithic vs. Microservices Architecture: Microservices are Out, Monoliths are Back

Lori MacVittie 缩略图
Lori MacVittie
Published May 16, 2023

Everybody calm down. Take a deep breath, and then we’ll walk slowly into the middle of the microservices versus monoliths war raging on the Internet. 

The Scoop:

Amazon recently published a case study documenting their decision to ditch microservices and embrace monoliths, citing a 90% reduction in costs. That case study caused the Internet to blow up with commentary and sarcastic tweets as microservices were thrown into the technical boxing ring with monoliths. 

The Reality:

For those of you who feel like you’re suffering a bad case of technical déjà vu, you aren’t wrong. This is the same situation service-oriented architecture (SOA) found itself in circa 2009 when Anne Thomas Manes declared its death. The link goes to a commentary by David Linthicum on Manes’ post because the original appears to have been eaten by the Internet.

Now, Manes was being hyperbolic and somewhat sarcastic because, as we well know, service-oriented architecture didn’t die. It was resurrected fairly quickly as microservices, and by the lamentation of the Internet, designers still haven’t learned how big a role “the network” plays in performance.

SOA ‘died’ for two reasons:

  1. Competing, bloated XML-based standards that made architectures overly complex. No one remembers WSDL, SOAP, and UDDI fondly. No one.
  2. The laws of physics and interoperability standards restrict the exchange of network packets to the speed of light and to 1500 bytes.

We might have overcome the first challenge but the second? The only answer to the second has been and continues to be a delicate balance between granularity of service design with a good understanding of the time it takes to transfer data between services.

Transferring data is not free. It takes time. There’s no such thing as “zero cost” when it comes to communications between services. There’s the time it takes to put a packet on the wire, then transfer it, then take it off the packet, and ultimately process it. And don’t forget that transport communications take time, too. Opening sockets and accepting requests is not free, either, and neither is the time it takes to serialize and deserialize payloads into something the service can process.

Now, multiply that total cost by the number of services you’re trying to use.

The more granular you design your system, the more time it takes to process a request. In other words, the total time to process a request is dependent on the number of services that request must pass through.

Greater granularity? Longer processing time. More services? Greater congestion on the network, which ultimately increases time to process as network cards and devices try to put packets in order and demand retransmission.

So, like SOA, microservices can and will suffer from design patterns that rely on too much granularity.

Amazon chose a monolith to replace its microservices. That means for their use case, a monolithic architecture was the best option. Does that mean microservices are dead?

No. Instead, we should take away two key points:

Application architectures are neither good nor bad, nor are they appropriate for every use case. Organizations need to step back and consider carefully what it is they’re trying to achieve and which architecture might best serve that need instead of choosing the most “modern” architecture because, well, it’s in vogue.

When we say the future is hybrid IT, we mean more than just a mix of multi-cloud and on-premises deployments. We also mean that the enterprise app portfolio will remain hybrid—a mix of traditional and modern—for the foreseeable future. That’s why the F5 portfolio continues to support all applications whether on-premises or in the public cloud—or both.