Modern Application Architectures Part — 2 (Microservice Architecture)
The Microservice Architecture (MSA) pattern builds an applications using small, autonomous, independently versioned and self-contained services. These services use well-defined interfaces and communicate with each other over standard and lightweight protocols.
A Microservice Architecture is particularly well-suited for large and/or complex software systems. In contrast with the monolithic architecture, an applications built using a micro service architecture handle complexity by splitting the application into smaller services that are easier to manage.
In Microservice Architecture, incoming requests are commonly handled by an API Gateway, which serves as the entry point to the system. It is an HTTP server that takes requests from clients and routes them to the appropriate service through its routing configuration.
Basicly Microservice architecture was emerged not as a solution for a problem, but as the result of the shortcomings and drawbacks of the traditional Service Oriented Architecture (SOA). Although Microservice architecture is a variation of the service-oriented-architecture, there are key differences between both of them.
There is no single definition for microservices. A consensus view has evolved over time in the industry. But there are a number of characteristics related to the microservice architecture. I will examine these characteristics in this post.
Small, Focused Services
The functionality of a microservice should be small in scope. Each microservice should follow the Unix philosophy that advocates for doing one thing and doing it well. Keeping the scope small for each service allows the complexity of the software to be better managed.
Applications with a microservice architecture are easier to understand and modify because every service has a focused responsibility. This allows the services to be developed faster.
A microservice can be developed by a small team. This allows organizations to easily split up work among multiple development teams. Each microservice can be worked on by a single team, independent of other microservices. Tasks for different microservices can be worked on in parallel.
Well Defined Service Interfaces
Microservices are treated like black boxes, hiding their complexity and implementation details from service consumers. This makes a well-defined interface, with clear entry and exit points, which is important to help facilitate microservices working together. Services interact with each other through their interfaces.
Interfaces need to be designed carefully and treated as a public API. One technique that is used is having multiple interfaces on the same service, or multiple versions of the same service, so as to not disrupt existing users of the code.
Autonomous and Independently Deployable Services
One of microservice’s goals is that teams can develop and deploy their services independently of others. An application using a microservice architecture consists of a system of autonomous services. The services should be loosely coupled, interacting through their well-defined interfaces and not dependent on the implementation of the service.
Autonomous services are independently deployable, making it easier to deploy them to production. A microservice architecture enables continuous deployment because it is easier to release updates to the services. If a change is made to a microservice, it can be deployed independently of the other microservices.
The autonomy of the services increases organizational agility. It allows organizations to quickly adapt to changing business requirements and take advantage of new business opportunities.
Independent Data Storage
One of the characteristics that support service autonomy is that each microservice can have its own data store. This helps services to be independent and loosely coupled to other services. A service’s data store can be altered without those changes affecting other services.
Designing each microservice to have its own data store may come in the form of a microservice having its own database, but that is not the only way to keep a microservice’s data storage private. If the data storage technology is a relational database management system (RDBMS), then in addition to the option of having a separate database server, data can be kept separate by designating certain tables to be owned by a particular service. Another option is to designate a schema that is to only be used by a single microservice.
Communicating With Lightweight Protocols
Microservices should communicate using well-known and lightweight message protocols. There is no rule dictating a particular protocol, and microservices can communicate synchronously or asynchronously. A common implementation for microservices is to have them expose HTTP endpoints that are invoked through REST API calls.
For synchronous communication, REST is one of the preferred protocols. It is common for REST to be used with JavaScript Object Notation (JSON). Service operations can accept and return data in the JSON format as it is a popular and lightweight data-interchange format.
Some applications may require asynchronous communication. A common messaging protocol used for asynchronous communication with microservices is Advanced Message Queueing Protocol (AMQP).
Another protocol that is popular with microservices is gRPC. It was designed by Google as an alternative to REST and other protocols. It is an open source protocol that was designed to be faster and more compact than other protocols used for distributed systems.
gRPC is built on protocol buffers, also known as protobufs, which is a way of serializing data that is language and platform neutral. This allows gRPC to efficiently connect polyglot services because it supports a variety of programming languages. The increased prevalence of containerized applications and microservices has made gRPC popular. Given modern workloads, gRPC is an attractive choice because it is a high-performance and lightweight protocol. gRPC is inherently efficient, but it is also based on HTTP/2. This yields additional benefits such as decreased latency and higher data compression.
The communication protocol that you select for your microservice architecture really depends on your requirements. There is no silver bullet answer that will apply to all situations.
Better Fault Isolation
A system built on a microservice architecture improves fault isolation. When one service goes down, other services can still operate normally, allowing other parts of the system to remain operational. This is in contrast to a monolithic application, where a fault can potentially bring down the entire system.
There are disadvantages of using a microservice architecture. The benefits of using a microservice architecture must outweigh the added complexity, so it is not the ideal solution for all types of applications.
Using multiple databases is another challenge in microservice architecture. It is common for a business transaction to update multiple entities, which will require the use of multiple microservices. With each one having its own database, this means that updates must take place in multiple databases. One way to handle this is through event-sourcing and having eventual consistency. Even if that is acceptable, implementation of event-sourcing is another added complexity.
As a distributed system, a microservice architecture introduces complexity simply not found in a monolithic application. When multiple services are working together in a distributed system and if something goes wrong, there is added complexity in figuring out what and where something failed. A service may not respond downstream and the system must be able to handle the disruption.
Decomposing a complex system into the right set of microservices can be difficult. It requires a knowledge of the domain and as the number of services increase, the management of those services becomes increasingly complex.
At the same time, you do not want the services of a system to be too coarse-grained, so that they are responsible for too much functionality. The last thing you want is a bunch of services that are tightly coupled, making it so that they have to be deployed together. If you are not careful, you will end up with a microservice architecture that is a monolith in disguise.
