Microservices

Microservices

Martin Fowler defines Microservices as a subset of Service Oriented Architecture (SOA). In SOA, the services can be of any size. In a microservice, the service performs a single function. Micro means small. A microservices architecture consists of a collection of small, autonomous services. Each service is self-contained and should implement a single business capability. Each microservice can communicate synchronously or asynchronously.

Advantages of Microservices

·       Independent deployments. You can update a service without redeploying the entire application, and roll back or roll forward an update if something goes wrong. Bug fixes and feature releases are more manageable and less risky.

·       Independent development. A single development team can build, test, and deploy a service. The result is continuous innovation and a faster release cadence.

·       Small, focused teams. Teams can focus on one service. The smaller scope of each service makes the code base easier to understand, and it's easier for new team members to ramp up.

·       Fault isolation. If a service goes down, it won't take out the entire application. However, that doesn't mean you get resiliency for free. You still need to follow resiliency best practices and design patterns.

·       Mixed technology stacks. Teams can pick the technology that best fits their service.

·       Granular scaling. Services can be scaled independently. At the same time, the higher density of services per VM means that VM resources are fully utilized. Using placement constraints, a services can be matched to a VM profile (high CPU, high memory, and so on).

API Gateway. The API gateway is the entry point for clients. Clients don't call services directly. Instead, they call the API gateway, which forwards the call to the appropriate services on the back end. The API gateway might aggregate the responses from several services and return the aggregated response.

The advantages of using an API gateway include:

·       It decouples clients from services. Services can be versioned or refactored without needing to update all of the clients.

·       Services can use messaging protocols that are not web friendly, such as AMQP.

·       The API Gateway can perform other cross-cutting functions such as authentication, logging, SSL termination, and load balancing.

Features of Microservices

1. Decoupling

2. Componentization

3. Business capabilities

4. Autonomy

5. Continuous Delivery

6. Responsibility

7. Decentralized Governance

8. Agility

Characteristics of Microservices

·       In a microservices architecture, services are small, independent, and loosely coupled.

·       Each service is a separate codebase, which can be managed by a small development team.

·       Services can be deployed independently. A team can update an existing service without rebuilding and redeploying the entire application.

·       Services are responsible for persisting their own data or external state. This differs from the traditional model, where a separate data layer handles data persistence.

·       Services communicate with each other by using well-defined APIs. Internal implementation details of each service are hidden from other services.

·       Services don't need to share the same technology stack, libraries, or frameworks.

·       The services can be invoked both synchronously and asynchronously.

SOA vs. MSA comparison

SOA (Service Oriented Architecture)	MSA (MicroServices Architecture)
SOA is coarse-grained.	MSA is fine-grained. Often behavior & data are encapsulated. Adheres to the Single Responsibility Principle (SRP).
SOA focuses more on re-usability. SOA has higher coupling, where services depend on other services to function.	MSA focuses more on low coupling & high cohesion. It also emphasizes onautonomy, where services can be individually developed, deployed, scaled & monitored to provide business value on its own with both behavior & data. Lower coupling allows the service to operate independently and high cohesion increases it’s ability to add value on its own.

Some of the Challenges with Microservice Architecture

·       Complexity. A microservices application has more moving parts than the equivalent monolithic application. Each service is simpler, but the entire system as a whole is more complex.

·       Development and test. Developing against service dependencies requires a different approach. Existing tools are not necessarily designed to work with service dependencies. Refactoring across service boundaries can be difficult. It is also challenging to test service dependencies, especially when the application is evolving quickly.

·       Lack of governance. The decentralized approach to building microservices has advantages, but it can also lead to problems. You may end up with so many different languages and frameworks that the application becomes hard to maintain. It may be useful to put some project-wide standards in place, without overly restricting teams' flexibility. This especially applies to cross-cutting functionality such as logging.

·       Network congestion and latency. The use of many small, granular services can result in more interservice communication. Also, if the chain of service dependencies gets too long (service A calls B, which calls C then it calls D...), the additional latency can become a problem. You will need to design APIs carefully. Avoid overly chatty APIs, think about serialization formats, and look for places to use asynchronous communication patterns.

·       Data integrity. With each microservice responsible for its own data persistence. As a result, data consistency can be a challenge. Embrace eventual consistency where possible.

·       Management. To be successful with microservices requires a mature DevOps culture. Correlated logging across services can be challenging. Typically, logging must correlate multiple service calls for a single user operation.

·       Versioning. Updates to a service must not break services that depend on it. Multiple services could be updated at any given time, so without careful design, you might have problems with backward or forward compatibility.

·       Skillset. Microservices are highly distributed systems. Carefully evaluate whether the team has the skills and experience to be successful.

·       Debugging

·       Monitoring

Microservice Pros and Cons

Microservices are not a silver bullet, and by implementing them you will expose communication, teamwork, and other problems that may have been previously implicit but are now forced out into the open. But API Gateways in Microservices can greatly reduce build and QA time and effort.
One common issue involves sharing schema/validation logic across services.  What A requires in order to consider some data valid doesn’t always apply to B, if B has different needs.  The best recommendation is to apply versioning and distribute schema in shared libraries.  Changes to libraries then become discussions between teams.  Also, with strong versioning comes dependencies, which can cause more overhead.  The best practice to overcome this is planning around backwards compatibility, and accepting regression tests from external services/teams.  These prompt you to have a conversation before you disrupt someone else’s business process, not after.

Pros

·       Microservice architecture gives developers the freedom to independently develop and deploy services

·       A microservice can be developed by a fairly small team

·       Code for different services can be written in different languages.

·       Easy integration and automatic deployment, using open-source continuous integration tools such as Jenkins, Hudson, etc.

·       Easy to understand and modify for developers, thus can help a new team member become productive quickly

·       The developers can make use of the latest technologies

·       The code is organized around business capabilities

·       Starts the web container more quickly, so the deployment is also faster

·       When change is required in a certain part of the application, only the related service can be modified and redeployed—no need to modify and redeploy the entire application

·       Better fault isolation: if one microservice fails, the other will continue to work.

·       Easy to scale and integrate with third-party services

·       No long-term commitment to technology stack

Cons

·       Due to distributed deployment, testing can become complicated and tedious

·       Increasing number of services can result in information barriers

·       The architecture brings additional complexity as the developers have to mitigate fault tolerance, network latency, and deal with a variety of message formats as well as load balancing

·       Being a distributed system, it can result in duplication of effort

·       When number of services increases, integration and managing whole products can become complicated

·       In addition to several complexities of monolithic architecture, the developers have to deal with the additional complexity of a distributed system

·       Developers have to put additional effort into implementing the mechanism of communication between the services

·       Handling use cases that span more than one service without using distributed transactions is not only tough but also requires communication and cooperation between different teams

·       The architecture usually results in increased memory consumption

·       Partitioning the application into microservices is very much an art

Best practices to design Microservices

1. Separate data store for each microservices

2. Keep code at a similar level of maturity

3. Separate build for each microservices

4. Deploy into containers

5. Treat servers as stateless

6. Use service registry

**follow 12 factor app development