Head-to-head: Monolith vs. Microservices
Available Now • On-Demand
Microservices are a type of software architecture where the functionality of the application is broken up into smaller fragments to make it more resilient and scalable. We call these fragments “services”. Each service focuses only on a single functionality of the application and is isolated from the others, making each one of them independent. This means that your development teams can work separately on different services and avoid a complex orchestration between them.
These different services then communicate with each other through APIs or web services.
To better understand what microservices are and why they've become so popular, it's helpful to know where they came from. Here is a brief history.
Like a Phoenix, microservices were born in the ashes of their former incarnation: services. Two decades ago, architects conceived services, and today, microservices fulfill their original promise. Service-oriented architecture (aka SOA) promised the IT world something of a miracle cure for intractable monolithic applications.
Businesses were plagued by backlogs and political wrangling, while startups were building scalable products that ate away at market share. Businesses could break up their monoliths by creating mini-monoliths that house core business functionality.
A mini-monolith or, better yet, a “minilith” was created to promote agile practices, assign full product ownership to a horizontal team, and provide easy access to the service for whoever needed it. That's pretty impressive. What happened?
In this case, we're discussing a "hot tech trend," and almost all trends follow the fad pattern. Fads disappear because the professionals that initiated them have been practicing for years. However, amateurs galvanized by their success find it difficult to reproduce their success. A few talented individuals crafted their services with care, while the rest of the IT industry enviously admired those who made it look so easy.
Martin Fowler, one of the founders of agile, has stated that the majority of organizations do not migrate to true SOAs, rather they move complexity from one place to another, primarily to the enterprise service bus. The enterprise service bus (ESB) is a piece of middleware designed to handle communication between services and their consumers. Companies use ESBs in order to mitigate the difficulties associated with decoupling a business process from its monolithic parent company.
In the end, the result is a black-box solution that technically "works," but is hard to change, difficult to test, and impossible to manage. Martin Fowler decided to rename ESBs to a more appropriate initialism: Erroneous Spaghetti Boxes.
When describing something, have you ever found that your listener regurgitates a twisted, clearly misinterpreted version of what you just described? When in doubt, remember any conversation in which there was a noticeable amount of head nodding. That's it. Developers felt precisely the same way when the enterprise world ate up service-oriented architectures and spat out whatever it is that is being presented:
And in that social situation, one wishes to correct misunderstandings. Developers have done so by rephrasing their original point in the form of microservices. Microservices at their core provide the same benefits originally promised by services. Generally, they follow these conventions:
Several tech giants like Netflix, Amazon, and Uber have already adopted microservices due to the many benefits they promise. Those advantages include:
Unfortunately, like any other hot trend, microservices are not all roses. Here’s the catch.
You should be able to answer this question now that you are aware of all the pros and cons of microservices. As a final point for you, before you search for microservices tutorials, consider why you would like to develop a microservice architecture. You are probably on the wrong track if you respond, "because all the big ones do it.".
In this article, we outlined some of the benefits associated with microservices, and it is clear why such an architecture might be beneficial. Several teams can have independent continuous integration and continuous delivery (CI/CD) pipelines while capitalizing on different skills, vendors, and technologies.
However, it is crucial to recognize when it is worthwhile. As a result, most companies are not like Netflix, which has a large development staff with some of the best engineers in the world all dedicated to managing a single application. Typically, talent is scarce and difficult to find in the average enterprise; plus, they tend to be smaller and focus on a portfolio of applications that serve the business rather than a single product. Microservices may result in impossible situations if improperly utilized.
An understanding of the advantages and disadvantages of each approach is critical to making good decisions about your architecture.
To learn more about the different approaches and how to choose the right architecture for your development projects, I recommend the following resources: