Traditional style application architecture coupled all their functionality tightly into one service. This caused a lot of difficulty in implementing new features as long downtime would be required which reduced the possibilities to update the application. Scaling such applications is expensive because we have to scale the entire application even if a single particular service receives a lot of traffic. Additionally, it is not dependent on the technology stack, each service can be built on different domains if required.

Why Microservices?

The cloud-like (Amazon and Azure) has brought about a sea change in the way we design, design and deliver our applications. Help faster deployments, improve uptime, scale on-demand, and reduce time to market. So here comes the Microservices-based application; the goal is to create smaller isolated services that can be deployed and scaled independently of each other.

Who Adopted Microservices?

There are many organizations using Microservices for their products and services. A few of them are given below:

• Microsoft
• Comcast Cable
• Uber
• Netflix
• Amazon
• eBay
• Sound Cloud
• Karma
• Gilt

Microservices Principles

• Services Modelling: It breaks down business requirements into services. Each service will focus on one thing and its associated logic and can easily migrate and scale independently to the next level. You can scale just the functional area that needs more processing power or network bandwidth to support demand, rather than scaling out other areas of the application.
• DevOps and CI/CD: With the increase of small but multiple deployment units, testing, deploying and monitoring each service separately will be over-head. It needs to be managed through automated CI-CD.
• Encapsulation: It should be architected in such a way that it won’t expose internal, technical and business implementations. No need to look into the whole architecture for updates.
• Fast Development (Decentralization): Fast application development & delivery, usually with different teams focusing on different microservices having their own database.
• Deploy Independently: To experience the entire advantages of the structure, microservices ought to be independently deployable. If you’re failing to do so, take a look at any coupling and resolve it.
• Failure Impact: The impact of a failure is less compared to the monolithic type as it will only affect those particular services and they’re associated while other services can keep running. It should handle such scenarios when the dependent is unresponsive or slow.
• Highly Observable: The services should collect as much information to analyse what is happening within each of them like log events and stats.

Monolithic vs. SOA vs. Microservices

Monolithic architectures are the handiest form as it is having only one layer that bundles collectively all the software features, and is hosted together. It is used by many small and mid-sized companies. For scaling, we need to duplicate the whole application including all the features of other machines which increases the cost and maintenance. Also, the failure of one feature will affect the whole system making it unreliable.

Service-Oriented Architecture (SOA) breaks down into smaller components as services consist of some tasks. This type of architecture allowed us to horizontally scale each service, and also more flexibility and performance at the cost of increasing the complexity of the architecture compared to the monolithic. Each service can be written in different languages and the communication between them can be done with the help of a middleware

Microservices is an upgraded interpretation of SOA where those features are further broken down into tasks position services making it a fine-granulated armature. SOA has a central system where each service is controlled by a central middleware. On the negative, microservices is a decentralized governing system where factors talk directly to each other and can be written in different programming languages and communicate without

the help of any broker. Stylish is to make rest microservices.

Microservices Architecture

An architectural style that structures an application as a collection of small self-contained processes, modelled around a business capability called service. They don’t share the data structure and will be communicating through APIs. The components are divided into a separate module and sharing information with the help of API interface. Each microservices is responsible for its own data model and meta-data.

Source:https://docs.microsoft.com

Each small service with loosely coupled capability can be developed and deployed independently by a small team as each service is having its own codebase. Data and state persistence should be taken with each service as it lacks a separate data layer to handle it. The services only communicate with well-defined APIs following encapsulation. Each service can use a different technology stack, language, libraries or frameworks.

• Management: The Management take care of the placement of services on nodes, checking for failures, rebalancing services across nodes in case of any failures.
• Service Discovery: Maintains proper documentation for a list of services where each service is located and deployed with endpoints.
• API Gateway: The entry point for clients, then it decides to forward requests to relevant services.

Advantages of Microservices

• Services can be written in different programming languages and can be accessed by using any framework.
• Independently develop, deploy, redeploy, version and scale component services in seconds without compromising the integrity of an application
• Minimal time-out upgrades.
• Services can be of from different infrastructure & platforms.
• Monitor & health diagnostics for each service.
• Reliable and self-healing
• Supports continuous integration and continuous delivery.
• Easy to transfer knowledge to the new team member.
• Easy to integrate with third parties.

Disadvantages of Microservices

• The additional complexity for implementation of an inter-process communication mechanism between services.
• Formal documentation must be required.
• Writing automated tests involving multiple services is challenging under a dedicated test environment.
• Automation is required to manage multiple instances of different types of services in production.
• Managing multiple databases and their transactions are difficult.
• Inter-process calls are slow.
• Debugging for a system will become difficult.
• Complexity in DevOps.
• Production monitoring cost is higher.