Introducing Microservices

The Microservices architecture is, basically, service-oriented architecture done well. After years of working with Service-Oriented Architecture, software developers have realized what Service-Oriented Architecture should be like, and this is basically what Microservices architecture is--it's an evolution of the Service-Oriented Architecture.

Microservices are small, autonomous services that perform one function well while working with other services as well.

Microservices introduces a new set of additional design principles, which teach us how to size a service correctly. Previously, there was no guidance on how to size a service, and what to include in a service. The traditional Service-Oriented Architecture resulted in monolithic large services, and because of the size of the service, these services became inefficient to scale up.

Let's look into the advantages of using Microservices.

Lightweight yet scalable

Microservices provide services which are more efficiently scalable, flexible, and which can provide high performance in the areas where performance is required.

An application which is based on the Microservices architecture is, normally, an application which is powered by multiple Microservices, and each one of these provide a set of functions, or a set of related functions, to a specific part of the application. A Microservices architecture normally provides a set of related functions to applications, to client applications, and client services.

Microservices architecture also uses a lightweight communication mechanism between clients and services or between two or more services. The communication mechanism has to be lightweight and quick, because when a Microservices-architected system carries out a transaction, it is a distributed transaction which is completed by multiple services. Therefore, the services need to communicate to each other in a quick and efficient way over the network.

Technology agnostic

The application interface for a Microservice, or the way we communicate to a Microservice, also needs to be technology agnostic. It means the service needs to use an open communication protocol so that it does not dictate the technology that the client application needs to use. And by using open communication protocols, for example, like HTTP REST (JSON based), we could easily have a .NET client application which talks to a Java-based Microservice.

Independently changeable

Another key characteristic of a Microservice is that it is independently changeable. We can upgrade, enhance, or fix a specific Microservice without changing any of the clients or any of the other services within the system.

In the Microservices architecture, each microservice has its own data storage. By modifying one Microservice, we should then be able to deploy that change within the system independently without deploying anything else.

Sample Microservices architecture app

The preceding image depicts a high-level architecture diagram for a Microservices system. This is an example of a typical e-commerce system, and as you can see on the left-hand side, there's a shopping website running in the customer's browser, or it could be a mobile app using the API gateway.

The browser connects to the demo shopping website via the internet--the demo shopping website might be an ASP.NET MVC website running on IIS. All the processing required for all the interactions with the website is actually carried out by a number of Microservices which are running in the background.

Each Microservice has a single focus, or a single set of related functions, has its own data storage, and it's also independently changeable and deployable. So, for example, we could upgrade the Orders service without upgrading any other part of this system.

There might also be multiple instances for each type of Microservice. For example, if the Orders service is in demand, we might have several instances of the Orders service in order to satisfy the demand. And in order to direct a request from the shopping website to the correct instance of an order service, we have an API Gateway which manages and routes a request to the correct Microservice within the system.

So, in this example, when a customer places an order, the shopping website might use multiple services and multiple functions within those services in order to satisfy that transaction. And this is why, in the Microservices architecture, a transaction is normally a distributed transaction, because the transaction is actually satisfied by multiple pieces of software, that is, Microservices.