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:
- Competing, bloated XML-based standards that made architectures overly complex. No one remembers WSDL, SOAP, and UDDI fondly. No one.
- 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.
About the Author
Related Blog Posts
At the Intersection of Operational Data and Generative AI
Help your organization understand the impact of generative AI (GenAI) on its operational data practices, and learn how to better align GenAI technology adoption timelines with existing budgets, practices, and cultures.
Using AI for IT Automation Security
Learn how artificial intelligence and machine learning aid in mitigating cybersecurity threats to your IT automation processes.
The Commodification of Cloud
Public cloud is no longer the bright new shiny toy, but it paved the way for XaaS, Edge, and a new cycle of innovation.
Most Exciting Tech Trend in 2022: IT/OT Convergence
The line between operation and digital systems continues to blur as homes and businesses increase their reliance on connected devices, accelerating the convergence of IT and OT. While this trend of integration brings excitement, it also presents its own challenges and concerns to be considered.
Adaptive Applications are Data-Driven
There's a big difference between knowing something's wrong and knowing what to do about it. Only after monitoring the right elements can we discern the health of a user experience, deriving from the analysis of those measurements the relationships and patterns that can be inferred. Ultimately, the automation that will give rise to truly adaptive applications is based on measurements and our understanding of them.
Inserting App Services into Shifting App Architectures
Application architectures have evolved several times since the early days of computing, and it is no longer optimal to rely solely on a single, known data path to insert application services. Furthermore, because many of the emerging data paths are not as suitable for a proxy-based platform, we must look to the other potential points of insertion possible to scale and secure modern applications.