Introduction to Microservices
Itâs getting difficult for the companies to decide whether to invest money in Consumer-facing applications first or to invest in Enterprise solutions. This situation brings up new challenges and interesting ways of developing software that should focus on Agile development, Easy and Short Build deployments, Quick and small enhancements in Consumer-facing interfaces i.e. Web Application, Mobile Application and also enhance the enterprise software suite to meet the business needs. So to overcome these challenges we can think of using Microservice Architecture.
What is Microservices Architecture?
Microservices Architecture advises developing small, scalable, and loosely coupled services that can be deployed independently and also focus only on its functionality instead of taking care of the whole system at once. These small services are fully functional, independent work of units that are responsible for managing everything on their own i.e. Technology Stack, Development team, Development cycle, Development architecture, Build cycle, and deployment architecture. Later these services can be combined and consume other services to build up a large chain and provide the functionality of Enterprise software, the main benefit of this architecture style is to reduce the dependency on one large system and avoid a single point of failure, this also promotes quick development cycles as these services are a small unit of the solution and can be developed by a small team which will be responsible to manage all aspects of this service.
Microservices are an architectural and organizational approach to software development to speed up deployment cycles, foster innovation, and improve the maintainability and scalability of software applications. Therefore, the software is composed of small independent services that communicate over well-defined APIs and are owned by small self-contained teams.
How do we wire our services together?
Components in a monolithic system communicate through a simple method call, but components in a Microservice communicate over the network through REST or web services.
In monolithic systems, we can avoid issues of service wiring altogether and have each component create its own dependencies as it needs them. In reality, such close coupling between a component and its dependencies makes our system rigid, tight coupled and hampers testing efforts. It also makes release cycles long due to the changes in the dependencies and different timelines for different timelines impact the deployment of other components and make it mandatory to release the whole system as one unit.
If we decide to implement an application as a set of Microservices, we have wiring options similar to those we have for a monolith. We can hard-code or configure the addresses of our dependencies, tying our services together closely but it would need additional requirements of a configuration expert and bring more complexity. Alternatively, we can externalize the addresses of the services we depend on, and supply them at deploy time or run time. Here we can use the concept on Service registry which serves as the only point of information for the service available in the Microservices cloud and store information of the available services their IP addresses and ports, As these services could be deployed on a cloud platform and use concepts like auto-scaling, your services should not worry about the IP addresses and ports these will be managed by the service registry components and will serve as a service directory to look up the details of services, some tools which can act as Service registry are Apache Zookeeper, Spring Cloud and Netflixâs Eureka.
Characteristics of Microservices
Microservices architectures are not a completely new approach to software engineering, but rather itâs a collection and combination of various successful and proven concepts such as object-oriented methodologies, agile software development, service-oriented architectures, API-first design, and with focus on Continuous Delivery.
Here are some common and important characteristics:
Decentralized Data: Microservices architectures are distributed systems with decentralized data management. They donât rely on a unifying schema in a central database. Each Microservices has its own view on data models. Those systems are decentralized also in the way they are developed, deployed, managed, and operated. It makes it easier for teams to manage data and it also allows full control of data as itâs only managed by a specific service.
Independent Release Cycle: Various components in Microservices architecture can be changed, upgraded, or replaced independently and without affecting the functioning of other components. Similarly, the teams responsible for different Microservices are enabled to act independently from each other. It helps businesses to upgrade small changes in multiple services at a time to keep pace with the business requirements. It also helps businesses to bring new changes quickly to their end-users and take quick feedback from users.
Single Responsibility: every component is designed around a set of capabilities and with a focus on a specific domain. As soon as a component reaches a certain complexity, it might be a candidate to become its own Microservice. Microservices are designed based on the Single Responsibility concept which means one service is responsible for handling only one knowledge stream i.e. Authentication Service, Identity Management Service, Order Management Service, etc.
Heterogeneous: Microservices architectures donât follow a âone size fits allâ approach. Teams have the freedom to choose the best platform for their specific problems. As a consequence, Microservices architectures are usually heterogeneous with regard to operating systems, programming languages, data stores, and tools â an approach called polyglot persistence and programming.
Abstraction: individual components of Microservices are designed as a black box, i.e. they hide the details of their complexity from other components. Any communication between services happens via well-defined APIs. Generally, they avoid any kind of hidden communication that would impair the independence of the component such as shared libraries or data.
You build it, you run it: The Team responsible for building service is also responsible for operating and maintaining it in production â this principle is also known as DevOps. In addition to the benefit that teams can progress independently at their own pace, this also helps to bring developers into close contact with the actual users of their software and improves the understanding of the customersâ needs and expectations.
High Scalability and Availability
Breaking monolithic applications into small Microservices, the communication overhead increases because Microservices have to talk to each other. In many implementations, REST over HTTP is used as a communication protocol, which is pretty lightweight, but high volumes can cause issues. In some cases, it might make sense to think about consolidating services that send a lot of messages back and forth. For Microservices, it is quite common to use simple protocols like HTTP. Messages exchanged by services can be encoded in different ways, e.g. in a human-readable format like JSON or YAML or in an efficient binary format. HTTP is a synchronous protocol. The client sends a request and waits for a response. By using async IO, the current thread of the client does not have to wait for the response but can do different things. Modern generation frameworks are also available to suit this structure one can use Play Framework which provides all the basic requirements to develop REST APIs in a very easy way and also provides concepts like Akka Actors and Java Completion stage which are highly scalable and efficient mechanisms to handle the scalability. Also, this architecture is Cloud friendly and can be easily deployed on any of the popular cloud platforms like AWS or Windows Azure.
Microservices Architecture on AWS Cloud