The Prime Video team published a story about collapsing a few microservices into a single service, and the internet piled in with opinions about returning to monoliths and SOA, mostly missing the point. Vogels stepped into the fray to defend the teams choices and push back on misconceptions about the distributed systems philosophy at Amazon, but it was perhaps too late to stem the tide of armchair architects.
Doomscrollers 😱: “It’s end of microservices and serverless era, a return to monoliths , SOA and mainframe is imminent!” FRP and Serverless 🌩️ : “The reports of my death are greatly exaggerated…”
Here are some real lessons and some valuable perspectives I took away from this little kerfuffle.
1. Optimization requires analysis. You cannot simply move your application to the latest, greatest SOA architecture, data mesh paradigm, or microservices framework and declare victory. Do you understand the bottlenecks in your application? Do you know if you are CPU, I/O, memory, or network bound? What are your performance characteristics under load — what parts of the system start backing up? What are tightly coupled processes that operate on the same data in sequence and what are loosely associated non-core functions that need to be evolved rapidly and independently? If you cannot answer these simple questions, you likely do not understand your current architecture well enough to refactor it, and you’re likely going to spend a lot of time solving problems you don’t have, migrating to frameworks you don’t need. Folks who cannot answer basic Big-O questions about an application should not be driving any replatforming efforts around it. You are more than likely to wind up with a macrolith (a nightmarish distributed monolith) and one of the originators of Kubernetes, Kelsey Hightower, has given us fair warning when he called out application teams that were “gonna break it [the monolith] up and somehow find the engineering discipline we never had in the first place… Now you went from writing bad code to building bad infrastructure”.
2. Speed to market and speed to develop does not always equate to long-term scalability and maintainability. You must actively balance your investments across these two critical pillars to build viable product. The paradigms that let you get out of the gate quickly with an MVP and the high developer productivity tooling that lets you ship to aggressive GTM schedules are invaluable but they are not a panacea. A federated application built on readily available cloud services can provide an invaluable advantage on day one but can become your Achilles heel as you look to scale, secure and distribute for global consumption. Adrian Cockcroft talks at length about this at length in his response to the Prime Video article and resulting furore. Whether you’re Amazon looking to collapse IO and network bottlenecks in a frame processing application, or Meta rethinking its GPU investments for LLM training, active rebalancing and reconsideration of the stack and technology mix for your finops and bizops context is both art and science.
3. Beware Cargo Cults. If your feed seems to awash in posts about a “return to monoliths” by folks who had barely taken the time to read the post from the Prime Video team, you’re not alone. The same sort of perfunctory analysis also seems to pervade the space of companies and consultants pushing kubernetes and or Serverless (KaoS), everything as a platform (EaaP), Anything as a Service (AaaS), or the next hot data mess. They, critically, seem to miss the respective revolutions in thinking around investing in shared platforms for managing complex distributed systems, building internal developer platforms to improve consistency and accelerate delivery, factoring out key concerns at each layer of the stack as reusable services, and using a domain-driven approach to structure and build efficiencies in enterprise data architectures. They also miss the caveats and up-front costs that come with each — whether it’s additional layers that need to be deployed to ensure security, observability, and traceability or investments in federated governance and management required to operate these topologies at scale.
Cloud native distributed systems paradigms are here to stay. The Prime Video folks have mistakenly labeled a properly factored highly coupled data intensive processing step a monolith — it’s at best a rocky outcropping in their distributed microservices forest. Here’s to a thoughtful approach to architecture and engineering!