Welcome to

Evaluate Expression

Home / Microservices / Microservices and their place in software architecture – part 1

Microservices and their place in software architecture – part 1

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.

What is a Microservice?

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:

  • Loosely coupled: We can change the internal workings of this app (this microservice), without affecting other apps which interact with it. Provided the contracts between them are not broken.
  • Single responsibility: The app (the microservice) can be independently deployed and independently run. An app might not provide much benefit when running on its own, but at least it can be tested on its own.
  • Open to change: We do not fear changing the app. Adapting it to the real world.

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:

  • Loosely Coupled: Changing one may result in updating the other with the same change, if it affects the shared code, library etc.
  • Single Responsibility: Changing reused code may result in many microservices having to be redeployed. It is fair to say that only one copy of the shared code needs the update, but if the change is beneficial to many or it is a bug fix, all affected microservices will have to be redeployed.
  • Open to change: To avoid the first two problems of reuse, change may be resisted within a microservice to prevent many updates and redeploys. The app is no longer open to change.

Who’s this Russ?

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.

What is the issue we are trying to solve?

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.

Molding microservices

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:

  1. Organise – Gather together the functionality that works together. The code which is cohesive.
  2. Reduce – Simplify what you’ve organised together into its simplest representation and form.
  3. Encapsulate – Present this reduced and organised piece of functionality as a whole. Be it a microservice, a module, a service or whatever term best describes your final product. Now repeat.

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.

Leave a Reply

Your email address will not be published. Required fields are marked *

Thanks for reading!

>> <<