An Introduction to Microservice Based Architecture Through Story — Part 1

The drive towards Microservice based architecture these days seems to make sense for a lot of big, distributed applications. This style of architecture helps to improve things such as scalability and helps to reduce the complexity of the code that construct each of your microservices.

I’m going to attempt to highlight these issues with a bit of storytelling, bear with me as I am new to this style of writing.

A Developer’s Crusade

Gemma was a senior developer who had just joined a new company that sold online comic books. You could purchase new comic books through their store front or you could navigate to your collection and read them through your various digital devices. It had a suave frontend built in Angular that was very responsive and very popular.

Iron Man clearly tops the charts.

The software that managed all of the transactions, all of the account updates, all of the comic books was one big project written in Java that was becoming increasingly more painful to test and deploy. There were some issues in previous months that had resulted in all of the sites services going down. This invariably cost the company both money and reputation. Releases were also a manual process and issues constantly brought the site down briefly during their release window. Essentially, if something like a memory leak occurred, it would bring down the one and only instance of our system.

Another key thing was that the site could not handle massive spikes in traffic, every time a new Riri Williams comic came out the site came dangerously close to dying and on several occasions both Gemma and her team would get a call at 2am on a Saturday stating everything was down.

Management were getting increasingly worried that competitors would start to win over more and more of their customers as they became increasingly unhappy with this more and more frequent downtimes of the site. Obviously these issues had to be addressed quickly and effectively.

The Pitch

When Gemma joined the company, she knew about the trend of developers following a microservice based approach and she had been reading up on some of the basics. From her research she found that microservices could help to improve resiliency and allow her to make changes quicker to several parts of her application with less overall risk of the platform going down.

She pitched this concept to management and they agreed to let her manage this transition from a monolithic architecture to a series of microservices.

The Initial Design Stage

When it came to designing this new microservice architecture Gemma looked at following a domain driven design approach and started to break up her monolithic application.

She broke off the all accounts functionality into a domain, the store into it’s a domain and the comic book viewer into a domain.

One of the key benefits of this architecture would be that when Gemma makes a change to something within the accounts service it won’t cost the company a considerable amount of money by taking out the store service if things were to go wrong. Essentially by separating everything into services that had bounded context, she protected herself from having one key point of failure.

Development Stage

Once the main design of our new microservice based system was finished, the development stage was next. For the purpose of this story we are going to gloss over this slightly but overall refactoring our monolith into a series of microservices allowed Gemma to mix things up a bit in terms of language choice.

A core portion of the team was well versed in Python and decided to rewrite some of the services in Python in order to improve overall code readability. The store service stayed in Java due to performance worries but the developers in the team enjoyed going back to their roots and exploring their favourite language again and having both services communicate via REST API calls.

Overall this stage proved to be somewhat successful, the only issue was that no new functionality was being developed during the refactoring stage. Gemma highlighted this to management at the initial proposal but sold them on the thought that they would be able to deploy code faster with more stability after the rewrite was done.

Initial Deployment Strategy

After a few months of refactoring and rewriting the code it was prime time. When it comes to initial deployment of these refactored services it can get stressful, but you can take as much time as necessary before you make the switch. Gemma and her team deployed the services and performed a full battery of integration tests and once they were confident they moved these into their production environment. At this stage they performed a series of probing tests and started to migrate their website to use their newly deployed services whilst leaving the old ones still running.

By leaving their older services still running they had a decent rollback strategy should their new services struggle under production workloads.

Blue-Green + Canary Deployments

With their previous monolith it was necessary to have a small period of downtime between taking down an older version and starting the newer version. Gemma realised she could eradicate any downtime by utilizing blue-green deployments.

She decided to run 2 or more instances of each service across multiple regions and front this with a load balancer. When she wishes to deploy a newer version of her system she could bring one of the instances down, deploy the updated version and perform a full battery of integration tests before re-adding this to the load balancer and allowing traffic to flow through it. She could then iteratively work through the remaining instances until all of the older versions have been replaced.

Final Results

3 months after the switch to a microservice based architecture Gemma and co saw reduced downtime, improved resiliency and the team were able to start iteratively making changes faster and with greater confidence.

This was not all sunshine and buttercups though, with this improved resiliency and increase number of services, the complexity of deploying the entire estate increased. As did the complexity of tracing issues through the system.

Conclusion

Hopefully this story-telling method was able to convery some of the main advantages of a microservice based approach, this was a little new to me so I’d appreciate feedback!

In the next article we’ll be following on how Gemma and co were able to combat against the increased complexity of managing their multiple services and tracing issues across their estate.