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

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:

• First, we should take a cue from Amazon and be more deliberate and thoughtful about how we design systems that rely on services and ensure we understand the implications on performance of divvying up duties across too many little services.
• Second, we should remember that monoliths are a viable application architecture choice. There is a reason that 60% of an enterprise app portfolio is comprised of applications based on “traditional” architecture, and 16% of organizations have no plans to retire them.

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.