I’ve been chatting to various people for quite some time about how there isn’t an agreed maturity model for the current trend to implement microservice architectures, and so I though I would have a go at creating one (quick link to PDF: Microservice Maturity Model Proposal).
I’m in no way suggesting this first draft is complete or definitive, but I hope it may stimulate the conversation around this topic. I’m sure some people will argue that a maturity or classification model isn’t necessary, but I believe it is a fun exercise, and it does enable us to explore (and discuss) what we think are requirements for a microservice implementation.
I’ve proposed six classifications of application architectural styles:
- Megalith Platform
- Humongous single codebase resulting in a single application
- Monolith Platform
- Large single codebase resulting in a single application
- Macro SOA Platform
- Classical SOA applications, and platforms consisting of loosely-coupled large services (potentially a series of interconnected monoliths)
- Meso Application Platform
- ‘Meso’ or middle-sized services interconnected to form a single application or platform. Essentially a monolith and microservice hybrid
- Microservice Platform
- ‘Cloud native’ loosely-coupled small services focused around DDD-inspired ‘bounded contexts’
- Nanoservice Platform
- Extremely small single-purpose (primarily reactive) services
I’ve then attempted for each classification to write about things such as, motivations, challenges, architecture, code modularisation, state data stores, deployment, associated infrastructure, tooling and delivery models.
The full proposal can be found in the following PDF ‘Microservice Maturity Model Proposal – Daniel Bryant (@danielbryantuk)‘
Please do let me know what you think – I’m keen to see whether this model could be useful, and also explore how it could be developed.