Microservices Architecture vs Monolithic Architecture
Blog: The Tibco Blog
Why is microservices architecture so popular these days and how did we arrive at such a distributed architecture? To understand where we are today, let’s look at how software architecture used to be. Let’s go to a time when we relied on a software architecture that we refer to as ‘monolithic’.
Monolithic Architectures
At that time, applications used to be comprised of a single block of code even though it could consist of millions of lines. The description ‘single block’ is a bit misleading as the code was organized into files, functions, and processes.
As time went on, more organized and intuitive styles like object-oriented programming and classes came into popularity.
Even though the monolithic application was broken into many parts for organization and simplicity, at the core it was always still one single entity. This led to the nickname of “monolithic architecture” derived from the term monolith which is a structure built from a single piece of rock. The monolithic application is one large piece of software with many interdependencies among its parts.
This monolithic architecture had many problems. The first issue was it had long development cycles that don’t work in today’s fast-paced world. The process used was called Waterfall – where all tasks were performed in a linear fashion, with a staggered sequence of milestones. From the development perspective, there were many interdependent parts, and if any one part was changed, the entire application had to be rebuilt. If there were parts of the monolithic application that were reusable in other (separate) applications, then you had to manually copy and paste the code into the other applications, or you had to create libraries that were either statically or dynamically linked into the respective applications.
From the operations perspective, this monolithic architecture could not respond well to events. It essentially ran from start to finish, simply collecting events along the way. It could not actually respond to those events as they occurred. Therefore, reacting in real-time to events was nearly impossible with a monolithic architecture, a crucial need of today’s software. Client/server architecture alleviated this issue somewhat, but since there was no fundamental change to the architecture, it still did not scale very well.
Modern Cloud Architectures – the microservices approach
In modern cloud architectures, applications need to be elastic, scale to millions of users, and respond promptly to millions of events. The best way to satisfy these requirements is to distribute the functionality in the code and also in the running of the application. This is what eventually led to what we today call microservices architecture.
Microservices are self-contained compute functions each of which performs a single task. A software architecture that is built using microservices as the individual functional units and a communication protocol for them to interact is called a microservices architecture.
Microservices architecture is actually an evolution of an older architecture called Service Oriented Architecture (SOA).
In SOA, application functionality is broken down into disparate individual functions that run separately and communicate with each other via messages. This allows: (a) functionality to be turned on as and when required (elasticity), (b) replication of instances of the same function to run simultaneously and service users as they grow in number (scale), and (c) the application to respond to requests immediately as they come in (event-driven).
Microservices vs. SOA Architecture
Unfortunately, the implementations of SOA in the real world did not quite live up to the promises it made. That’s how microservices architecture came into popularity. It actually improved on the issues found in SOA implementations. In fact, the main differences between microservices and SOA are:
- Microservices typically communicate with each other via RESTful APIs instead of the centralized Enterprise Service Bus (ESB) concept of SOA. While ESBs could be designed to be fail-safe, many implementations turned out to be a single point of failure.
- Each microservice has its own independent data store. Similar microservices may share data stores, but that increases the interdependence between those that share the data store. In general, the architecture calls for a separate data store for each microservice.
- There is a strong emphasis on lightweight functionality in the microservices architecture, which is missing in SOA. Thus, SOA implementations are often larger and more complex making them harder to change, scale, build, and deploy.
- In microservices architecture, the services are all deployed and managed independently of each other via automated methods. This happened primarily because of the rise of DevOps practices around the same time as the shift to microservices occurred. It is not necessarily the case with SOA implementations.
- Microservices do not need to be started and left on — their instances can be stopped when not required and created anew — this is essential for elasticity in the cloud.
Microservices architecture is used by many enterprises that scale massively to millions of events – such as Netflix, eBay, Amazon, and Uber.
Microservices – the answer to all your problems?
This does not mean that microservices architecture has solved all problems. There is a lot of complexity in this architecture which needs to be managed very carefully. In a microservice architecture, every component communicates independently with the other parts. It is a much more complicated method of communication than the ESB and requires a rigorous method of service discovery and management of the messaging. You can manage it via service meshes, but again, that now adds an additional layer that is required to successfully run your microservices.
Application design now requires much more effort to partition the application effectively and prevent duplication of effort. Quality assurance for microservices architecture is also very complex, matching the complexity of the architecture.
So, microservices are not necessarily for everyone. But that is a topic for another day.
Leave a Comment
You must be logged in to post a comment.
