Part Two : Microservices by Example #microservices

Microservices is an architectural style, which is an approach to develop a single application as a suit of small services, each running in its own process and communicating with light weight mechanism, often a HTTP resource API. – Martin Fowler 

Though this is technically correct, this is an abstract definition to what it means to build Microserivces.

In extreme reaction to our experiences with Monolithic application, this is how we would like to lay out the differentiator of a Microservice.

• Separation of Concerns
• Modulatory
• Encapsulation : Ability to encapsulate your data structures behind something that you don’t have to deal with and coordinate.
• Scalability
• Horizontally Scaling
• Workload partitioning : In a distribute system you can take your work , beak it out into small components , which makes it more manageable.
• Virtualization and Elasticity
• Automation Operation
• On Demand Provisioning

Let’s have a second look at the Monolith connected application:

You have an app talking to a service layer and service layer is connected to a Data Store. In the service layer you have multiple services that executes a business logic and caters to the request coming from the App.

Now if you App has gained popularity and more subscribers are subscribing to you App, all of a sudden your Backend is starting to have some scaling problem, then you figured out it is the Data Store that is slow. Hence you go ahead and shared your Database.

Then your App becomes more popular , no now it is no more a Data base problem you now have to scale the instances of you application

Well there is limitation and cost to this kind of scaling. Hence if you worried about scaling , why not build the application to scale the individual services that is required to scale , rather than replicating the entire application suite of services.

Hence here is where Microservices architecture helps us to build our application with each microservice being agnostic to the other microservices changes and scale your components individually.

This is how we will remodel the service layer in the above architecture to make it more agile and easy to scale.

Now you have the flexibility to scale just one service which is seeing a huge traffic.

What has worked really well by Microsrevice Architecture ?

• Easier to scale based on real-world bottlenecks.

You can identify the bottlenecks in your services and replicate there and fix them there instead of doing massive re writes or actually come up with a plan to make the changes to fix that issue.

• Easier to Test

Test surface is way smaller each one of these microservices they don’t do as much as a big monolithic application, hence they are way easier to test. Developers can test them locally, this is awesome, because developer don’t have to push their code every time to a development environment to test their changes. 

• Easier to Deploy

They are smaller they deploy really fast.

• Easier to monitor

They are easy to monitor because they are doing less, it make it way easy to monitor those instances.

• Can be versioned independently

Some of the application run on embedded devices, the embedded devices manufacturers they really don’t care once they have sold their hardware to the user. They have taken the ownership of their product, so they are not going to maintain your hardware and not responsible to update it. There is no real values for the producer to update them. So at the time of sale the hardware is wired to call a particular version of an API, if the API goes down then the hardware will not work anymore. Now people who bought the hardware are going to be angry with the Producer of the hardware, they are in fact going to be angry with the service provider of that hardware to which the API belongs to.

So it is better for the service provider to create a new version of that API and host it as an individual service in a different server, which means each version of the API is independently deployed on its own server, hence any new version of API deployment is not going to effect the old versions of that API. Up until the hardware stop calling the old API, that is when that old Version of API can be decommissioned.  

• Less susceptible to large failures

Big services fail big and small services fail small. In the microservices world we are expecting a service to make multiple calls to other microservices to render some information. In this case if any one of them fails, all you are going to get impacted is just that particular information, without bringing down the entire application.

What has not worked really well by Microsrevice Architecture ?

• Harder to monitor

Now with microservice we have thousands for instances running on multiple servers, even though the service area of these services are small, they are just way too many of them running on multiple instances so that is a challenge.

• Need Good Documentation/Discovery tools

You need to have a good documentation or Discovery tools now ever important than before. Because you are looking at lot of small services which can provide value to a developer who is trying to render them to build a problem solving application. However a developer need a good reference of all the services that are available for him to render.

• Create Increased latency

The common issue we hear about is the amount of latency we have been observing since we adopted to microservices architecture. What is happening is instead of us calling a single process or multi proc service which goes and collects all the data and returns it, instead we are calling lot of services and again those services are calling other services, this way the latency grows through each one of these calls. The benefit that we seemed to actually working this way, means that we have to figure out better way to handle latency in these calls.

One of the thing we can do to overcome these latencies, can be learned from the solution provided from Netflix. Where we can switch to this view aggregation service.

Today an App will make call to dozens of microservices and then kind of assemble all the data it has obtained from these calls, there are instance where it gets few data that is not even needed and give out the desired output to the user. In this case switching to view aggregation model, running them via these services that are basically one per platform per view, so this view aggregator goes and aggregates the data by calling different services and return exactly the data that is required to be returned to the client.

This significantly reduced the processing burden on the App interfacing with the client. App became more responsive. What we have done here is we have kept connection between the services short within the network, which has contribute to an improvement in latency time and this also reduced the traffic to the client.

Enablers for Microservices :

• Reusable Service Template :

Service Template enable the developer to quickly create a service without reinventing the setup process and common configurations. We can have multiple flavors of Service templates that might serve particular protocol or implementation.

• Continues Delivery with Automated Continues Integration and Continues Deployment Pipelines

Automated CI/CD pipelines, help the development team to automate full life cycle automation and manage ops activity with their own squads, instead of relying on the Ops teams to assist them with their rapid deployment and aids in Devops culture. This enables High application availability Geo-Redundant and Multi-Tenant Security. Automated policy based scaling and Consistent administration.