Blog Posts Process Management

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.

monolithic architecture

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 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

Get the BPI Web Feed

Using the HTML code below, you can display this Business Process Incubator page content with the current filter and sorting inside your web site for FREE.

Copy/Paste this code in your website html code:

<iframe src="" frameborder="0" scrolling="auto" width="100%" height="700">

Customizing your BPI Web Feed

You can click on the Get the BPI Web Feed link on any of our page to create the best possible feed for your site. Here are a few tips to customize your BPI Web Feed.

Customizing the Content Filter
On any page, you can add filter criteria using the MORE FILTERS interface:

Customizing the Content Filter

Customizing the Content Sorting
Clicking on the sorting options will also change the way your BPI Web Feed will be ordered on your site:

Get the BPI Web Feed

Some integration examples