At Container Solutions we often get asked what someone needs to do in order to be successful with microservices. This includes the technical challenges as well whether their culture and team structure is set up for success.
Here, we’d like to focus on the technical side, addressing the many elements that should be considered when designing and developing a microservices architecture.
In order to put these topics into context with each other and get a healthy discussion going, we at Container Solutions created a Microservices Architecture Maturity Matrix. It’s based on the Cloud Native Maturity Matrix we use to help companies map their current Cloud Native status and the gaps they might need to close in order to reach their goals. (The original Maturity Matrix is used in our Cloud Native Assessment, a three-day evaluation of your organisation’s current state.)
(If viewing on a mobile device, you can download a PDF of the Microservices Maturity Matrix here.)
Moving from a monolith to a microservice architecture is not easy. In our experience, it is a journey that requires a lot of considerations and trial and error. A Cloud Native transformation brings a lot of new technical implications that may change the way things are developed and maintained. It may open up the platform and services into new areas (for better or worse).
While almost all of the technologies mentioned in our Microservices Maturity Matrix can be applied to all different kinds of architectures, it is often a good idea to adopt some of these patterns in order to run microservices successfully.
But microservices aren’t only about technology. We need to make sure that a microservice architecture is a good idea for the organisation and its business goals. Often a company’s organisational and team structures need to be adjusted in order to facilitate a microservice architecture successfully.
Many Moving Parts
A microservice architecture affects many areas of the way an organisation operates. Many of these cannot be considered in isolation, such as the platform and scalability.
The creation of a microservice architecture is not only breaking down a business case or monolith into ‘smaller bites’, throw it in an orchestrator such as Kubernetes, and be done with it. The architectural changes alone create new complexity.
Observability, for example, is a big and important factor that needs to be considered in the very beginning; decisions that affect observability need to trickle through the entire design and creation process. With many services, databases, load-balancers, etc. involved, you will want to keep an eye on all of them. A traditional monolithic monitoring approach won’t help here (PDF version available too):
This is why, in our Microservices Maturity Matrix, we mapped seven categories to help you see exactly where your organisation stands in relation to greater microservice maturity.
The matrix is not a perfect representation of the real world. Many—or even most— organisations will not progress linearly from left to right. For some categories it may be more effective for a given organisation to remain towards the left of the matrix (for example, see the technologist Sam Newman's article on why you might not want to do microservices). We use the matrices as a way to start conversations about where an organisation is and what it might considering working on—not as a dogmatic assertion of progress or standing
Where can you find yourself in the Matrix?
To help you learn more, we offer a Microservices Evaluation, where we help you find the next steps in your microservice journey. Click below to learn more about all of our professional services packages.
Previous article
