Why microservices?

With the advent of Kubernetes, the term Microservices has become the latest trend in software architectural styles. However, are many engineering teams really taking a clear step back and asking the fundamental question: Do we need Microservices?

Remember SOA?

I remember during my early days of software engineering the term SOA (Service Oriented Architecture) was the next big thing in the enterprise software space. Numerous blogs, articles were written that this architectural style was the way forward. Terms such as Enterprise service bus, Service discovery, XML Web services were the common parlance in enterprise architecture circles. Unfortunately the enterprise nature of this approach never made the mark!

Keep it simple

One of the lessons that is always pertinent in software architecture is keeping it simple. Don’t build abstractions which themselves cause the solution to be hard to comprehend by the software engineers building the solution!

A journey to Microservices

Accelerate to the present day and now everyone wants to use Microservices.

My first real project working with Microservices was three years ago. It was very interesting project and there was a lot to learn. The project involved stateful and stateless microservices and involved many interactions between services to pull and push data as part of simple and complex workflows.

To sum up the stack at the time was (there was a lot more):

• Dotnet core
• Cosmos DB
• Azure Service Fabric
• Blob storage
• Azure DevOps for CI/CD

I won’t go into the detail depths about Service Fabric it’s very Microsoft specific. Find out more about it:

https://docs.microsoft.com/en-us/azure/service-fabric/service-fabric-overview

Lessons learnt

During the project the whole team was invested in developing a high quality software that met all the customers functional and non-functional requirements. This meant developers, testers, product owners were all invested in building in quality from the beginning. The key learnings from that project included the following:

• CI/CD is fundamental to building your microservices independently from one other
• Understand your business domains and how they can be decomposed
• Distributed tracing and correlation is fundamental to debugging and troubleshooting
• Building ephemeral environments for your software is a given
• Robust end to end acceptance testing
• All the developers should be encouraged to build infrastructure as code, think about observability, resilience and transient failures, and automate tasks for the platform and improve their knowledge of all the component parts

So developing platforms for Microservices is a team, collaborative effort and also a shift in traditional modes of developing monoliths or even n-tiered applications.

Which path?

Sam Newman is his book Monoliths to Microservices makes a very pertinent point about thinking about the outcome and benefit the software brings. If the outcome is not clear, and the benefits not articulated your engineering team are venturing into murky waters!

To sum up in my opinion the main properties of a successful Microservice endeavour are the following criteria:

• Independant deployability. A single Microservice can be independently deployed.
• Serves a clearly defined business capability. A classic example is a Product catalog service in Ecommerce.
• By striving for the previous two points a team can minimise the blast surface of changes to each service!!
• Understand the operational complexity tradeoff. Your troubleshooting and debugging is going to be more difficult, so invest in distributed tracing and monitoring!!!

Making the choice not the tech

A engineering team who thinks about the business domain, the benefits and outcomes of adopting a software Microservice architectural style will have a much better path to a team who mistakenly follow what they perceive to be the latest trend!!

Not all software projects have to evolve into Microservices!!