Architecture & Design

An Introduction to Microservice Based Architecture Through Story– Part 2

By  | 

The Bump In the Roadway

In general the transition to a microservice architecture had shown advantageous for the company. Gemma had actually effectively architected a solution that broke the site into 3 distinct issue domains; the accounts service, the store service and the comic-book audience service.The Decrease of Downtime After 3 months in production the comic

book company had seen an end to any downtime thanks, in part, to their green-blue release method. There disappeared cases of a”big bang”implementation going live and consequently passing away, reducing the whole site.With green-blue releases, Gemma and her group had the ability to deploy new versions of their systems along with their existing, steady releases and carry out a multitude of various tests such as canary tests to guarantee that when they made the last switch over, everything was working nominally.The Troubles with Releases As Gemma and her team moved to a microservice based approach, they discovered that the amount of time they spent doing deployments increased.They were no longer performing

“one”release of their monolithic application, they were releasing anywhere from 2 to 6 different services every time they performed a release. This included both the new green-blue instances of each of their 3 services.This clearly wasn’t ideal, exactly what they had acquired in regards to less downtime and more resistant architecture, they had lost in terms of developer performance. Being a little group, if one designer was being dragged into 4 hours worth of deployments every 3 days then it actually begins to hurt group productivity.The Increase of Kubernetes After hitting this stumbling block, Gemma was required to research study further and discover a method they could automate releases in such a way that they could reclaim this lost time and focus more on delivering essential service worth.

This is when she discovered Kubernetes. She took a look at Kubernetes: Up and Running and began getting herself experienceded in

the art of using Kubernetes.What Kubernetes essentially enabled her and her team to do was define their entire system as code. Running this on top of AWS’s new managed Kubernetes service this permitted them to conserve a great deal of time with regards to handling their overall estate.The only provide this raised was that the group needed a long time to find out the ins and outs of the managed Kubernetes service and the underlying Kubernetes innovation.

With the amount of time this would save further down the line, Gemma saw no problem with this. AWS’s EKS– Handled Kubernetes Service The Loss of

Traceability Another somewhat bothersome issue that arose when transferring to a microservice based architecture was

the loss of traceability with regards to exactly what went wrong.As the variety of services in any application grows, having the ability to trace demands across the numerous microservices constructing that application ends up being troublesome.If something was to fail within one of the services, how might they trace it through all the subsequent systems it calls easily?Initially a lot of time was lost using inefficient

debugging systems. Every time an engineer was contacted at the weekend due to an issue they would loathe coming online and attempting to debug exactly what had gone on. Any concern faced took a minimum of an hour to debug, even in the circumstances where it was a non-issue. The Response to Traceability: Zipkin Gemma relied on a system called Zipkin which is based upon the ideas from Google’s own tracing system, Dapper. Zipkin basically provides you a really in-depth tracing of all interservice calls and essentially allowed Gemma and her group to trace through any and all problems faced within their services.Again more time had to be sunk into learning this new tool and guaranteeing all the developers in her group were comfy with successfully debugging utilizing the tool.However, once they were familiar with Zipkin they were able to make use of these quite awesome looking call traces.< p data-image-id=1 * 8DYgaRRXZmw9AmHZCRhjCw.png data-width=2670 data-height =1208 data-action=zoom data-action-value= 1 * 8DYgaRRXZmw9AmHZCRhjCw. png > Zipkin traces typically appear like this 3 Months Later On– The Conclusion 6 months after moving towards a microservice based architecture the group had seen enormous improvements in terms of the speed at which they had the ability to make changes.They had seen enormous improvements in regards to resiliency and consumer experience was greatly improved. They were able to rapidly deploy changes and improvements

that users loved and overall the company was able to control

the online comic book market.The group spent a lot of time

learning the more recent technologies but the time financial investment made at first paid real dividends in the end.

Source

https://hackernoon.com/an-introduction-to-microservice-based-architecture-through-story-part-2-dacceaff9a13

Language »