Microservices, although not exactly a novel concept or practice, have been redefining software development in a lot of ways. Microservices have the potential to replace monolithic applications and are more aligned to the changing business needs of enterprises. A typical monolithic application is a self-contained software application in which all component parts are tightly interconnected with one another. If any components are impacted for any reason, the entire application is impacted. For example, a change in one component may necessitate a full system regression and a full deployment. Monolithic applications are viewed as inflexible systems and enterprises expend a lot of resources to maintain such applications. Microservices, on the other hand, are proving to be more agile and flexible. They are small, independent and reusable services which can be modified and independently deployed. This allows enterprises to save a lot of investments. Although it cannot be said that microservices are being universally used, there are some encouraging case studies already. (For more on technology trends, see Autonomic Systems and Elevating Humans from Being Middleware.)

What Are Microservices?

Microservices is an architectural style of developing a single software application with a combination of small, independent services. The idea is to be able to work or modify each service in an isolated manner so that, unlike in the case of monolithic applications, the whole software application is not impacted because of the update. Each service has its own processes and communicates in a lightweight mechanism – often with the help of an HTTP resource web service.

To understand the features of microservice architecture, it may be relevant to compare it with monolithic software systems. The following table provides the main differences between monolithic and microservices software systems.





Puts all functionalities in a single process.

Puts individual functionalities into separate services.


Replicates the monolith in multiple servers.

Distributes the services across services and replicates whenever needed.

Why It's Gaining Popularity

The microservices way of developing and managing software applications is more aligned to changing business needs, and that is the most important reason enterprises are gradually embracing it. In a challenging and dynamic business scenario, businesses need to quickly respond to changing needs, but monolithic software systems do not allow them to do so. Microservices are more agile and responsive to changing situations. The main reasons for microservices' popularity include:

  • Microservices applications allow fault isolation. Whenever there is an issue, the isolated, independent nature of the services allow separation from the main software and assessment. The software application remains unaffected while the fault is being fixed.
  • Enterprises do not need to commit for a long term to a particular technology stack because they can replace it with another one that fulfills their needs.
  • Since the services are isolated and independent, it is easy to gain knowledge and start working.

What Are the Architectural Components?

The architectural components of a microservice architecture can also be called its defining characteristics. The main components of the architecture are described below.

Simple Request Processing Architecture

Unlike complex systems such as the enterprise service bus (ESB) that employs advanced systems for performing tasks such as message routing, choreography and applying business rules, the microservice architecture processes a request in a simple manner: It accepts requests, processes them and generates a response.

Decentralization and Flexibility

Microservice architecture allows enterprises to add independent services from anywhere regardless of the language or program used to develop those services. This allows the software developers to choose the most suitable services according to their needs.

Robust Issue Management

Since the architecture may comprise several disparate services that interact with one another constantly, there will always be a possibility of issues. In such cases, the problematic service can be isolated from the whole software system and fixed or replaced while the software system continues to operate smoothly.

How It Works

Microservice architecture works on the basis of its principles which can be applied across software applications, regardless of technology or platform. The way microservices work is described below:

Build It and Run It

It kind of follows Amazon’s philosophy of “build it and run it.” Software applications are built and it is assumed that the development team is responsible even after the software has been delivered. This is unlike in the case of software projects where the development team is dismantled after the software is delivered and responsibility is handed over to the maintenance team. In this case, the development team takes full responsibility even after the software is delivered.

Componentizing Software into Services

While the microservice architecture can work like the monolithic software system does – calling libraries – it provides a unique feature. Libraries are components that are linked to a program which is called with the help of in-memory function calls. But microservices use services that are out-of-process components that communicate with the software with the help of elements such as web services or a remote procedure call.

How Is It Different from SOA?

Service-oriented architecture (SOA) is an architecture based on services or RESTful web services which perform various functions – for example, displaying system status, creating users and updating user data. SOA allows software developers to build, call and expose services and orchestrate the services to provide a solution. Just like in microservices, services in SOA are all independent, loosely-coupled services. While both SOA and microservice architecture share common principles in componentizing a software application in the form of services, they are not the same. The main differences between SOA and microservice architecture are described below. (To learn more about SOA, read BPM and SOA: How They Drive Business.)

Communication Mechanism

While SOA allows you to develop services in diverse technology stacks and deploy them to develop a software application, it also requires each service to communicate using a common communication mechanism. However, in the case of microservice architecture, there is no such requirement. Services can be deployed and operated independently.

Impact of Communication Failure

In SOA, the enterprise service bus is used for communication across all services deployed. In the case of a failure of the ESB, the communication between services can break down. Obviously, there is total dependence on the ESB. In the case of microservices, each service can be differently built, and in case of a fault or bug, only that particular service is affected and not the others.

Size and Scope

Each service in a microservice architecture tends to be significantly smaller than that in an SOA architecture. Microservices are independently deployable services, while an SOA can be a part of a monolith application or small deployable services.

Some Examples of Microservices

Many prominent organizations have been leaving the monolithic system for microservice architecture, including Netflix, eBay, Amazon, the UK Government Digital Service, Twitter, PayPal, Soundcloud, The Guardian and many more.

Netflix has been using microservices in SOA architecture with great success. It receives more than one billion calls every day through APIs from more than 800 diverse kinds of devices and then makes five additional calls to the backend service.

EBay has moved to microservices as well with their core application comprising several smaller, autonomous applications. Each small application executes the business logic for different business areas of the application.


It is obvious that microservices are highly favored because they are more aligned to changing business scenarios. However, it needs to be kept in mind that putting together so many diverse services to fulfill a single objective is no cakewalk. Enterprises will still have to manage clear, timely communication in the system, which can be a challenge. Also, managing teams or people who have knowledge of managing so many diverse services can be a challenge. All things considered, microservice architecture still seems a much better option than monolithic architecture.