MicroServices

Microservices Architecture

Microservices architecture allows to avoid monolith application for large system. It provide loose coupling between collaborating processes which running independently in different environments with tight cohesion.

• Loose Coupling– Application build from collaboration services or processes, so any process change without effecting another processes.
• Tight Cohesion-An individual service or process that deals with a single view of data.

Definitions for Microservices : 

Small autonomous services that work together – Sam Newman

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 – James Lewis and Martin Fowler

• Clients – Different users from various devices send requests.
• Identity Providers – Authenticates user or clients identities and issues security tokens.
• API Gateway – Handles client requests.
• Static Content – Houses all the content of the system.
• Management –  Balances services on nodes and identifies failures.
• Service Discovery – A guide to find the route of communication between microservices.
• Content Delivery Networks – Distributed network of proxy servers and their data centers.
• Remote Service – Enables the remote access information that resides on a network of IT devices.

Pros and cons of Microservice Architecture

Pros of Microservice Architecture	Cons of Microservice Architecture
Freedom to use different technologies	Increases troubleshooting challenges
Each microservices focuses on single capability	Increases delay due to remote calls
Supports individual deployable units	Increased efforts for configuration and other operations
Allow frequent software releases	Difficult to maintain transaction safety
Ensures security of each service	Tough to track data across various boundaries
Mulitple services are parallelly developed and deployed	Difficult to code between services

Difference between Monolithic, SOA and Microservices Architecture?

• Monolithic Architecture is similar to a big container wherein all the software components of an application are assembled together and tightly packaged.
• A Service-Oriented Architecture is a collection of services which communicate with each other. The communication can involve either simple data passing or it could involve two or more services coordinating some activity.
• Microservice Architecture is an architectural style that structures an application as a collection of small autonomous services, modeled around a business domain.

Rest and Microservices

REST

Though you can implement microservices in multiple ways, REST over HTTP is a way to implement Microservices. REST is also used in other applications such as web apps, API design, and MVC applications to serve business data.

Microservices

Microservices is an architecture wherein all the components of the system are put into individual components, which can be built, deployed, and scaled individually. There are certain principles and best practices of Microservices that help in building a resilient application.

In a nutshell, you can say that REST is a medium to build Microservices.

Different types of Tests for Microservices?

While working with microservices, testing becomes quite complex as there are multiple microservices working together. So, tests are divided into different levels.

• At the bottom level, we have technology-facing tests like- unit tests and performance tests. These are completely automated.
• At the middle level, we have tests for exploratory testing like the stress tests and usability tests.
• At the top level, we have acceptance tests that are few in number. These acceptance tests help stakeholders in understanding and verifying software features.

End to End Microservices Testing?

End-to-end testing validates each and every process in the workflow is functioning properly. This ensures that the system works together as a whole and satisfies all requirements.

In layman terms, you can say that end to end testing is a kind of tests where everything is tested after a particular period.

What is the use of Container in Microservices?

Containers are a good way to manage microservice based application to develop and deploy them individually. You can encapsulate your microservice in a container image along with its dependencies, which then can be used to roll on-demand instances of microservice without any additional efforts required.

Microservices Benefits

• Smaller code base is easy to maintain.
• Easy to scale as individual component.
• Technology diversity i.e. we can mix libraries, databases, frameworks etc.
• Fault isolation i.e. a process failure should not bring whole system down.
• Better support for smaller and parallel team.
• Independent deployment
• Deployment time reduce

Microservices Challenges

While developing a number of smaller components might look easy, there are a number of inherent complexities that are associated with microservices architectures.

Lets look at some of the challenges:

• Quick Setup needed : You cannot spend a month setting up each microservice. You should be able to create microservices quickly.
• Automation : Because there are a number of smaller components instead of a monolith, you need to automate everything – Builds, Deployment, Monitoring etc.
• Visibility : You now have a number of smaller components to deploy and maintain. Maybe 100 or maybe 1000 components. You should be able to monitor and identify problems automatically. You need great visibility around all the components.
• Bounded Context : Deciding the boundaries of a microservice is not an easy task. Bounded Contexts from Domain Driven Design is a good starting point. Your understanding of the domain evolves over a period of time. You need to ensure that the microservice boundaries evolve.
• Configuration Management : You need to maintain configurations for hundreds of components across environments. You would need a Configuration Management solution
• Dynamic Scale Up and Scale Down : The advantages of microservices will only be realized if your applications can scaled up and down easily in the cloud.
• Pack of Cards : If a microservice at the bottom of the call chain fails, it can have knock on effects on all other microservices. Microservices should be fault tolerant by Design.
• Debugging : When there is a problem that needs investigation, you might need to look into multiple services across different components. Centralized Logging and Dashboards are essential to make it easy to debug problems.
• Consistency : You cannot have a wide range of tools solving the same problem. While it is important to foster innovation, it is also important to have some decentralized governance around the languages, platforms, technology and tools used for implementing/deploying/monitoring microservices.

Solutions to Challenges with Microservice Architecture

Spring Boot

Enable building production ready applications quickly

Provide non-functional features

• embedded servers (easy deployment with containers)
• metrics (monitoring)
• health checks (monitoring)
• externalized configuration

Spring Cloud

Spring Cloud definition from Spring :

Spring Cloud provides tools for developers to quickly build some of the common patterns in distributed systems (e.g. configuration management, service discovery, circuit breakers, intelligent routing, micro-proxy, control bus, one-time tokens, global locks, leadership election, distributed sessions, cluster state). Coordination of distributed systems leads to boiler plate patterns, and using Spring Cloud developers can quickly stand up services and applications that implement those patterns. They will work well in any distributed environment, including the developer’s own laptop, bare metal data centres, and managed platforms such as Cloud Foundry.

Click here for article that explains Spring Cloud.

 

Spring Cloud provides solutions to cloud enable your microservices. It leverages and builds on top of some of the Cloud solutions opensourced by Netflix (Netflix OSS).

• It is building blocks for Cloud and Microservices
• It provides microservices infrastructure like provide use services such as Service Discovery, Configuration server and Monitoring.
• It provides several other open source projects like Netflix OSS.
• It provides PaaS like Cloud Foundry, AWS and Heroku.
• It uses Spring Boot style starters

Important Spring Cloud Modules

Dynamic Scale Up and Down. Using a combination of

• Naming Server (Eureka)
• Ribbon (Client Side Load Balancing)
• Feign (Easier REST Clients)

Visibility and Monitoring with

• Zipkin Distributed Tracing
• Netflix API Gateway

Configuration Management with

• Spring Cloud Config Server

Fault Tolerance with

Hystrix

Few Main Projects with Spring Cloud :

Spring Cloud Config :

Centralized external configuration management backed by a git repository. The configuration resources map directly to Spring `Environment` but could be used by non-Spring applications if desired.

Spring Cloud Netflix

Integration with various Netflix OSS components (Eureka, Hystrix, Zuul, Archaius, etc.).

Spring Cloud Bus

An event bus for linking services and service instances together with distributed messaging. Useful for propagating state changes across a cluster (e.g. config change events).

Spring Cloud Sleuth

Distributed tracing for Spring Cloud applications, compatible with Zipkin, HTrace and log-based (e.g. ELK) tracing.

Spring Cloud Config :

Spring Cloud Config provides server and client-side support for externalized configuration in a distributed system. With the Config Server you have a central place to manage external properties for applications across all environments. As an application moves through the deployment pipeline from dev to test and into production you can manage the configuration between those environments and be certain that applications have everything they need to run when they migrate. The default implementation of the server storage backend uses git so it easily supports labelled versions of configuration environments, as well as being accessible to a wide range of tooling for managing the content. It is easy to add alternative implementations and plug them in with Spring configuration.

As an example we have properties such as minimum and maximum that differ from env to env . Added to the complexity we can have any variable instances of microservices on differnent envs – 1 instance of microservice A on Dev , 2 instances running on Test, 4 instances running on Prod. In other to maintain central external properties we use spring cloud config.

Dependencies : 

For setting up server we need dependency “Config Server” (start.spring.io)

For setting up clients (Microservices)  we need to add dependency “ConfigClient” (start.spring.io)

Feign Client : 

Feign is a declarative web service client. It makes writing web service clients easier. With microservice architecture , there will be a need to invoke multiple microservices internally from a microservice. Feign makes it really easier to configure and as usual helps developers focusing on writing the business logic instead of working on boiler plate.

It also provides integration which is client side load balancing .

Ribbon :

Ribbon helps us distribute load across multiple instances of microservices.

Naming Server:

Ribbon helps us distributing the load across multiple instances of Micro services. If we were just configuring the URLs(static running instances of service http:localhost:8080 , http:localhost:8081) using ribbon but in the real world think about this – If new instances were created dynamically or downsizing the load (removing instances).. We can’t configure the application properties that results in frequent restarts to configure the URLs and it defeats the purpose of dynamically scaling up and down.

Naming server solves this problem and it revolves around Service Registration and Service Discovery 

Service Registration : 

Service Registration is the concept by which all the instances of Microservices will tell the Naming server – ” Hi – I am available to serve ”

Service Discovery means clients that were trying to invoke other Microservice will know about all the running  instances of the Microservice. Naming Server knows all the details of the running instances because of Registration.

API Gateways :

In Microservices architecture there will be 100’s of microservices but there are common features such as every call needs to be authenticated and so on.. Api Gateways intercepts all incoming calls to microservices and following are the few features ..

a. Authentication, authorization and security
b. Rate Limits – For a specific client , we need to allow only X number of calls per hour..
c. Fault Tolerance – If service is not up -should be able to provide default fault response to the client .
d. Service Aggregation – If a service is dependent on 10 different Micro services , it can instead aggregate all the 10 Micro services so that just one call is made by the client and response is given back after aggregating all the calls.

Zuul API Gateway is a popular Gateway tool and Netlfix provides it ..

To configure Zuul APIGateway , we need to follow below 3 steps .

1. Create a component for it . (Create a project and add dependency Zuul )
2. What should it do when it intercepts ? Eg.Logging . Have the implementation logic.
3. Make sure that all important requests get routed via API gateway.

Distributed Tracing :

In a microservice architecture with tons of services around , we may be interested in knowing on what happened to a request. If one of the microservice is down or naming server is down or Gateway server is down – we need to know exactly where request failed. There comes the need of centralized location to store the logs .

There are numbers of solutions to address the distributed tracing ..

1. Elastic Log search with kibana
2. Zipkins Distributed Tracing .

Spring Cloud Sleuth : Spring Cloud Sleuth helps to assign unique ID to every request. It is very useful if we have a unique request ID propagating across multiple layers ( different microservices , gateways etc)

Rabbit MQ : Messaging Queue that helps in storing request to database..

Here with the help of Zipkins we can come to know the logs for a specific request and it helps us analyzing the issue.

Zipkin UI is really helpful and we can see the request trace ..

Spring Cloud Bus :

Spring Cloud Bus uses lightweight message broker to link distributed system nodes. The primary usage is to broadcast configuration changes or other management information. We can think about it as a distributed Actuator.

From the below diagram, lets assume that 2 instances of Limit Services are running and we have a scenario where we changed the values of properties related to the service in GIT . For the changes to be reflected, the URLS needs to be refreshed . In a practical micro service world with tons of services , it is practically impossible to refresh each instance and instead Spring Cloud Bus solves this problem by configuring one URL and it takes care of refreshing all the instances of the service.

Popular tools used are Kafka , Rabbit MQ

Hystrix:

Fault tolerance of microservices is an important concept . We should always think what happens when a call to microservice fail ? (May be for variety of reasons such as data base down or application code issue or any issue). Hystrix helps with fault tolerance and we can define a fall back method incase of any exceptions.