Microservice Architecture Pattern for Architects

Origin of Microservices

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

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.

Monolithic Architecture

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.

• User Interface: handles all user events through HTML, client side library like jQuery or Angular, JSON.
• Business logic: is responsible to validate all business rules provided by user inputs, user events, and data passed to and the from database.
• Database Access: gives you simplified access to the database that is persistent storage of application data.

Disadvantages of Monolithic Architecture

• InterModule Dependency: Components of Monolithic Architecture are tightly coupled with each other resulting in multiple changes required if any other module changes.
• One component fails resulting entire system being down: If the business layer or DataAccess layer fails in responding entire system is going to be down.
• Large Codebase: as repetitive code increases to achieve required functionality, code becomes very large and becomes difficult to maintain.
• Complex Code Deployment: for minor change the entire application needs to be redeployed.

Service-oriented architecture

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.

Advantages of SOA

• Reusability: Services can be used by multiple clients. Order service can be used by the website or mobile app and also it can be consumed by back office application for fulfillment or reporting purpose.
• Scalability: Services can be easily scaled up to handle growing users, sessions, transactions.
• Upgradeability: As services are loosely coupled, it is easy to update service functionality and deploy code without affecting current client implementation.

Disadvantages of SOA

• Large upfront cost: Even though multiple teams can work on different services of same application simultaneously, its deployment is costly as you are deploying services as separate host.
• Complex Service Management: In Enterprise level applications huge data gets exchanged between client and services in a millisecond, this requires very complex service management and high bandwidth servers. This also makes it difficult to use asynchronous communication..
• Validation Overhead: whenever the service receives a request or sends a response to the client, validation of the input parameter happens that results in decreasing response time due to this overhead.

Understanding microservice architecture

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.

Advantages of Microservices Architecture

• Isolation

  As each service is independent of other services, Microservices comes with great use of isolation of each service. If one service is failed only that particular functionality will fail to work however your application might still work. This also isolates component-specific errors. This way developers can build and deploy services without the need to stop the entire app or redeploy the entire application. So in theory there will be doing downtime for your application due to code changes. Each service will have their own CRUD operations.

• Scalability

  As an application based on microservices is a group of small components, it's easier to scale up or scale down as per the requirement of a specific component. Independent functions can easily be extracted or moved for reuse in other services. As the workload grows with more data to process and increased user sessions additional microservices can easily deploy to handle specific component growth.

• Smaller code base

  Each service is small so it is easy to develop and deploy as a unit. This also helps to maintain and deploy code.

• Faster Project development

  Your team specific to components can change component code, test it, and deploy without affecting other teams. In turn, development and deployment will be faster with the separation of services. .

• Compatible With CI/CD, DevOps process and Agile

  Applications with Microservices Architecture are compatible With CI/CD and Agile and container methodologies. Each team can choose the process that works bests for the development and the deployment of application component. Tools like Docker and Kubernetes are used for this.

Amazon, Netflix are successful usecase of Microservices Architecture. Following is a diagram of Netflix Microservices Architecture.

Disadvantages of Microservices Architecture

1. Microservices are more expensive: Microservices requires more resources as each service is isolated and requires its own CPU time and runtime environment. You will require more tools, servers and APIs. More services means more resources. Handling multiple database, file operations, transactions will be difficult.
2. Communication between services is complex: As each service is an independent service, communication between multiple services becomes difficult. Eventually, remote calls in between services will increase resulting network latency. The better way to create a shared library to include all shared functionality throughout the application like users and their roles..
3. Global testing is difficult: As the application is spread across multiple services, global testing is difficult especially for the components which are dependent on other services.

Communication in Microservices

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.

Internal Communication in Microservices

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

1. HTTP communication

   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.

2. Message communication

   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.

3. Event-driven communication

   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.

SOA Vs Microservices

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.

• Service Deployment and Scalability

  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

  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.

• Heterogeneous interoperability

  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.

• Maintainable

  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.

Prerequisites of microservice

Deployment and QA

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.

A monitoring framework

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