Serverless vs. Microservices vs. Monoliths: Why Every CEO Should Focus on Results, Not Labels
Andrew Tahvildary
CTO | Tech & Strategy Advisor | Scaling Engineering Teams for Growth, IPOs & M&A | Startup Mentor/Advisor
An article by the Amazon Prime Video team about how they optimized their infrastructure spend and software design process stirred up a bit of a storm a few days back. To recap, the post summarized how the team opted to move away from buzzier, newer technology architectures — serverless and microservices — back to an old style of building applications called monoliths. The controversy was over why Amazon, a company that has strongly promoted serverless and microservices, would so publicly talk about a failure in using these paradigms that a team was forced to move back to an older paradigm.
For the non-technical, a primer on these three terms might be useful. A monolithic architecture is an approach where the entire application is built as a single, self-contained unit. All of the application components are tightly coupled, and the application typically runs on a single server. Microservices architecture, on the other hand, is an approach where the application is divided into small, independent services that communicate with each other over a network. Each microservice is responsible for a specific task or function and can be developed, deployed, and scaled independently of the other services. Serverless architecture is a type of cloud computing where the cloud provider manages the infrastructure and automatically scales the resources based on the application's needs. Instead of managing servers, the developer focuses on writing code for individual functions, which are triggered by events or requests.?
Jim Barksdale, the former CEO of Netscape, famously said there are two ways to make money in technology — bundling and unbundling. First, you bundle. Then you unbundle. The same path is true in software design. You either have one or a few big applications that do many things. Or you have a large number of smaller applications that split up the job and communicate to coordinate the formation of the end product. You can even have a mixture of the two. But what you don’t need is a bunch of buzzwords because either way of building an application can work just fine — as long as your team follows good design principles and puts in place the right systems to maintain and update your applications.?
In fact, the approach that the Amazon team took — of prototyping with serverless, then moving to what appeared to be a larger microservices design that could be confused with a monolith,-- is actually quite by the book, according to a useful blog by Adrian Cockcroft, who should know such things.?
领英推è
The bottom line? CEOs and CTOs should focus on metrics that matter — infrastructure costs, how quickly you ship code, customer satisfaction and retention, engineering team size compared to comparable applications, and more. Yes, Amazon uses monoliths among its applications. It probably also uses microservices in many places and successfully. There will always be another buzzword for what’s next. Ignore the buzzwords. Follow the money.?