In this first part I will introduce the concept of microservices, what they are and the role they play. Then I’ll talk about the issues they try to solve and an advised process of breaking down an existing codebase.
In part 2 (coming soon) I will introduce Russ Mile’s life-preserver diagram and talk about the role Event Sourcing can play in a microservice architecture. I will also talk about how we want our microservices to talk to each other.
In part 3 (coming less soon than part 2) I’ll talk about stressing our systems to expose weaknesses before they occur naturally and the benefits of microservices beyond architecture and deployments.
A few weeks ago I attended Russ Miles’ Microservice Workshop at Skills Matter here in London. The course covered the benefits of adopting a microservice-centric architecture as a means of achieving anti-fragility in systems. Anti-fragile systems are open to and embrace change. Anti-fragile systems grow out of being pushed to their limits of resiliency by stressing them under their weaknesses.
Disclaimer: I had no experience with microservices before this workshop and my current experience since has been implementing a test system comprised of microservices. I have also advised within my team at work how this type of architecture could be adopted.
There are lots of vague definitions of a Microservice. Others a very specific. On the course Russ listed these factors of an application which fits being a microservice:
What we don’t value in a microservice is reuse. Reuse often involves sharing code, libraries, responsibilities, etc.
If two microservices reuse parts of each other they are no longer:
Russ Miles is an advocate of the usage of microservices. He has a lot of experience in the field and has consulted for the likes of Netflix and us here at Sky. His talks about anti-fragility explain that the adoption of microservices are but one step towards building resilient systems, which are open to and even embrace change. He explains that Event Sourcing and stress testing are two other key elements to achieve this.
In my limited experience and from Russ’ advice, adopting a microservice architecture is a big undertaking. It also leads to changes beyond just the software, which I’ll talk about in part 3.
If the issue can be solved by building a better monolith. Then this might be the way to go. Microservices solve problems such as the division of responsibility between teams. If each team is responsible for a part of a whole system and they create microservices which communicate with other across the teams, then each team is loosely coupled from the rest. They can deploy independently, test independently and change independently.
Russ was not the first to advise me to focus on simplicity over everything else when writing software. Simplicity results in code which speaks for itself and software which is intuitive to work with.
Russ defines three steps to achieving simplicity:
Easy on paper (or on blog). Like me you’re likely thinking that this sounds simple at first, but as soon as you start applying it to an existing codebase you have in min+d, maybe a monolith, things get complicated quick.
My suggestion would be to work in stages. Take one area to organise, reduce and encapsulate. Let’s imagine a scenario where the encapsulation fits being a microservice, it meets our criteria defined earlier in What is a microservice?. It is loosely coupled from the rest of the codebase, the encapsulation has a single responsibility and we aim to achieve an openness to change by making it a microservice and continuing to treat it as such.
With a microservice as a product of our steps to extract a common set of functionality, we have a piece of the puzzle, that is, building an anti-fragile system or set of systems. We can run this microservice alongside everything else, which is yet to be organised, reduced and encapsulated into a form that fits it.
This first step is a learning process. Issues such as the resiliency of the microservice and openness to change will present themselves with time.
In the next post I’ll be talking about how our microservices interact with the rest of our architecture, including databases and external third-parties.