Often when designing a new architecture for a solution to a business problem, the term Microservices are thrown into the mix. But are Microservices always the right approach to a new problem?
What exactly is a Microservice?
Well, a Microservice is one part or service of an overall business solution that is isolated, separately deployable and independent of all other services in the overall solution. It is small, lightweight and simple, has smart end-points and is built using the right tool for the job.
Sounds pretty awesome right? We are reducing the size of an application down into smaller more manageable services. So, when is it not the right time to apply this!? I’m glad you asked!
Let’s assume you are an agile dev (who isn’t these days) and are tasked with building that fancy new Greenfield application. But the thing about Agile is; you are not always going to know your domain upfront, especially if it’s Greenfield. It will be about getting an application into a user facing environment as quickly as possible so we can gain feedback on the value we are providing so we can gradually evolve the existing application to gain more of that value. But being able to apply a Microservice architecture to your application architecture will require you understanding the domain upfront, so you can isolate all the boundaries into separate independent solutions that service the overall domain. The better approach would be to build out your application with all its layers into one solution. If you feel that application is growing too large and becoming something of a monolith further down the application evolution timeline, you could then consider a Microservice architecture. But this is only when the application domain has been fully fleshed out, then you could start to break out all the layers into independentservices. This can be done by applying patterns like the strangler pattern while discovering the seams in your application or using branching by abstraction.
Sometimes it’s not as easy as saying; let’s build this using a Microservices architecture. The right culture has to be considered. You need to understand Conway’s Law and how/if it applies to your organisational communication structure. This structure can be a major influence in how applications are architected. Ideally, an inverse of Conway’s Law should be applied, to create cross-functional teams. Here, skill-sets should range to cover all concerns of aMicroservice architecture, such as DB, services, security and ops etc. Without this cross-functionality from the off, coupling of teams creates dependencies on the availability of people from the other team to complete some work, so you will only be as fast as your slowest dependency. You will need to understand and use the last responsibility moment principle to make sure you know your requirements and constraints upfront before making a commitment.
A lot of us development folk create an emotional attachment with the software we write, but we need to design for failure and build in resilience. We need to build for substitutability and portability, or in other words, we need to be prepared for the service being removed and replaced quickly in some cases. Because, although it’s great that we can isolate a lot of concerns, what can happen is that we are taking the pain of managing the problem of a large monolith and pushing that problem to the infrastructure and integration overhead. Having many Microservices can introduce potential network latency issues and more applications to monitor in terms of uptime and metrics. Perhaps in the future, Docker could lend itself perfectly to this problem. Here you could stand-up a VM and have one Docker process running a service talking to another Docker process running a MySql DB, with only the process running the service exposing itself to the public. All managed using Compose. This way management of the Microservice architecture is only limited to management of the VM. And if you need to dispose and replace of a service you can do so easily by substituting the process in the VM. There are some caveats that may need to be ironed out before Docker becomes a possibility to an approach to Microservices. Things like security with sharing the kernel and user mapping inside and out of the process.
To summarise, Microservices are no silver bullet. This architecture pattern is not for you if you are building a Greenfield application in an agile environment. It requires a certain level of maturity and understanding of the overall domain. It’s when you have that domain that you can start to break things up and apply a Microservices architecture. Microservices can only really be built once the application is released to your users and adding value.
Thanks for reading and keep building awesome.
Until next time!
Ian B
P.S. You can also find me on Twitter: @ianaldo21
Ian Barry 