This blogpost explains about advantages, disadvantages, internal service communication, SOA vs MSA, Prerequisites, and other aspects of Microservice Architecture that are required to define architecture your application with Microservices.
This also explains about Monolithic Architecture and Service Oriented Architecture, their advantages, and disadvantages.
The term Microservices was referred first time by James Lewis in a workshop for software architects in March 2012. In 2013-14 Microservices was well known term for Architects from large enterprises. In 2014 James Lewis and Martin Fowler described Microservices as:
A microservice architectural style is an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API. These services are built around business capabilities and independently deployable by fully automated deployment machinery. There is a bare minimum of centralized management of these services, which may be written in different programming languages and use different data storage technologies
Prior to Microservices Architectural Style, the monolithic architecture and Service Oriented Architecture(SOA) was widely used for large enterprise applications. The term monolithic architecture was borrowed from the Unix world and used for standalone programs whose functionality is not dependent on any other features.
In Monolithic Architecture, you will have different components for User Interface, Business Logic, Database Access in one application. Each component is dependent on the other.
To overcome issues from Monolithic Architecture, SOA was the better choice. The main difference between SOA and Monolithic Architecture is SOA services run on separate process whereas application with Monolithic Architecture runs on multiple processes resulting in better scalability.
The SOA oriented Enterprise Applications are designed as a collection of services. These services will be RESTFul Services or ASMX web service. Each service from SOA will have complete business functionality with required code and data integrations endpoints for example in eCommerce application OrderService will have features like placing orders, calculating order total considering product discount, reduce product available qty, process payment, etc.
The service interface provides loose coupling so that they can be consumed by clients with no or little knowledge of how the integration is implemented inside service. The services are exposed using SOAP(Simple object Access protocol) OR HTTP OR JSON. Services can be published to intranet or IIS so that client can find / consume them.
Microservice architecture is a trending software design pattern to develop a single application having a set of smaller services. This extends loosely coupled services that can be developed, deployed, and maintained independently. Each service is independent. Each service is responsible for the separate, individual tasks and can communicate with other services through simple APIs to achieve complex business functionality.
In monolithic applications, we have a single assembly containing a user interface, business rule logic, and data access layer. Every component of an application like Order, Product, Payment will be part of the same assembly.
With Microservices business components are segregated into individual services. Each individual is a smaller unit. There is no need to call Order service when Payment is processing or no need to use product service when inventory needs to update. All these services are independent of each other. Each service is responsible for its own execution.
The previous diagram shows how you can change an eCommerce application from a monolithic application to an application using microservices. Product Service, Payment Service, Order service are independent of each other, no service is aware of what others are doing. Each service can have a different technology stack depending on need. Here Products are stored on a cloud database, payment logs are stored on disk, and order data stored on-premises database. Also, each service can be hosted separately.
Amazon, Netflix are successful usecase of Microservices Architecture. Following is a diagram of Netflix Microservices Architecture.
You need to be very careful while selecting communication and message patterns, working with Microservices. If this is incorrectly used, the purpose of the advantages of Microservices will be compromised. Each service from the application should be simple and lightweight.
Choose synchronous or asynchronous calls wisely depending on if your client calls need to be blocked or not. Message formats like HTTP/s, JSON, XML, or Binary can be used.
Microservices based application is distributed is a distributed system executing multiple processes and services. Each service instance is a process. Services must interact with other internal services using inter-process communication protocol like HTTP, AMQP, TCP. For example in the eCommerce application, the Order service needs to interact with the User or Authorization service to find the validity of the customer before placing an order.
There are three different ways that you can use internal communication between services
HTTP communication can be synchronous or asynchronous. Synchronous HTTP communication creates coupling between two services which we do not want. The services involved communicating directly with each other with requests and responses.
A popular architectural style for request/response communication is REST. This approach is based on and tightly coupled to, the HTTP protocol, embracing HTTP verbs like getting, POST, and PUT. REST is the most commonly used architectural communication approach when creating services. You can implement REST services when you develop ASP.NET Core Web API services.
With Message-based communication, services are not involved directly for communication. Services push messages to the services that have subscribed for messages. This removes the complexity of associated sending and receiving messages associated through HTTP communication.
Services do not require to know how to talk with other services however every service should know about the service broker.
This is an asynchronous approach that removes the coupling between services. Message Broker is required where service will write its events to it. Consuming service does not need to know the details of the event as consuming service react to the triggering of the event not the message.
If you do not have a good understanding of both architecture you might think SOA and Microservices Architecture sounds similar, in both architectures each service has a specific responsibility to perform, unlike monolithic architecture. However, both architectures differ in the following way.
In SOA each team member should be aware of common messaging patterns between services, as SOA uses Enterprise service bus for communication. ESB can be a reason for the failure of the entire application. Scaling specific service is not possible unless ESB is capable to handle it.
In Microservices, each service is truly independent and services can be created and deployed independently unlike SOA. It is easier to develop a new version of service and deploy it without affecting others. Frequent deployment and scaling specific services is pretty much possible in Microservices.
Component Sharing is a main benefit of SOA. It has coupled components and its data as single unit with minimal dependencies. SOA relies on multiple requests and response through ESB to complete on business funtionality of application due to this systems built on SOA are slower than Microservice Architecture. Data storage shared among all services.
Microservices Architecture minimize direct component sharing. Point to point communication is a standard way. Required shared functionality can be achieved using NuGet packages. Each service will have a independent data storage.
Interoperability refers to the ability to consume services by clients developed in a different programming language than services. SOA promotes multiple heterogeneous protocols through its messaging middleware component. SOA uses AMQP, MSMQ, SOAP as primary remote access protocols..
Microservices architecture expects all clients should use the same remote access protocol as the service is using. MSA uses REST-based protocols, these are usually homogeneous.
SOA is bigger in size and the components involved perform more than one function so the application code base becomes difficult to maintain. SOAs are implemented as a complete subsystem..
Microservices are smaller components and each component is designed for only one purpose that makes it more maintainable than SOA. The prefix "micro" in microservices is referring to the granularity of each component.
The new version of service from microservice demands quick development, testing, and deployment of service. This requires infrastructure to test the updated version and deploy it to the production server. Test case execution and deployment can be achieved using the CI / CD. The development team might push changes to UAT / staging for testing more frequently, so testing these changes you need a QA team.
As the number of services and functionality of the entire application scales, you need a framework that can monitor the functionality and health of each system, cross-service communication and find any possible issues, and have an automated way to respond to these issues..