Microservice Maturity Model Proposal - Daniel Bryant (@danielbryantuk)
Name
Description
Motivations
Megalith Platform
Humongous single
codebase resulting in a
single application
Monolith Platform
Large single codebase
resulting in a single
application
These systems typically
result from the
implementation of an
initial intensively planned
complex application,
which has evolved in a
haphazard fashion over
many years of success in
the market
Monolithic applications
initially allow rapid
application development,
and early features are
added easily and quickly.
When the application
codebase is small the
system is easy to
understand, change and
deploy
Near impossible to
Difficult to understand,
understand, maintain and maintain and evolve
modify.
KLOC Per Artifact
Platforms such as AWS
Lambda are allowing
applications to be developed
that are ideal for responding to
simple event-driven systems
with dynamic workloads. This
can be thought of as an
extension to the 'blackboard'
architectural model, although
state is stored externally
Due to the asynchronous and
reactive nature of these
platforms, they often display
emergent behaviour that can
be difficult to debug at the
system level
Polyglot
Polyglot (currently limited)
5+ years
Single
Multiple
Multiple
New
1000's
100's
10's
10 - 1's
1's
0.1's
Ball of mud
Ball of mud, potentially with
some componentization
(packages, namespaces,
JARs, DLLs etc)
Hybrid of monolith and microservice
platforms
Highly-componentised
Extreme componentization
High - Low
Low
Extremely Low
Medium - High
High
Extremely High
High
High
Typical Code Cohesion
Low
Low - Medium
Medium - High
In-process
In-process
Data Store Type
Microservice systems promote
the single responsibility
principle, and are potentially
easier to understand and
maintain even as the
application grows in size and
complexity. They can also
enable decreased time to
market (changes are isolated),
and enable flexible scalability
Complexity pushed from
applications to deployment
and runtime orchestration.
Multiple services also require
resilient discovery and
communication mechanisms.
Services must be explicitly
designed to allow flexible
scalability and fault-tolerance
New
5 years +
Typical Code Coupling
Data Stores
Meso systems emerge from
organisations migrating away from
monolith, or adding new functionality
to existing applications via externally
hosted smaller applications
Single
Code-level
Modularisation
State
Microservice Platform
Nanoservice Platform
Cloud native' loosely-coupled Extremely small singlesmall services focused around purpose (primarily reactive)
DDD-inspired 'bounded
services
contexts'
10 years +
Typically componentized at the
platform level, but individual
service code may be less well
organized and implemented
according to, or coupled with,
vendor APIs
High - Medium
Typical Inter-application
Communication
Meso Application Platform
Meso' or middle-sized services
interconnected to form a single
application or platform. Essentially a
monolith and microservice hybrid
These systems often contain the
challenges of both the monolithic and
microservice architectures. It can also
be difficult to extract functionality from
the monolith, and there will be
changes required in development and
deployment practices and tooling.
Potentially two separate skillsets
required.
2 - 5 years +
Challenges
Typical Codebase Age
Languages
Macro SOA Platform
Classical SOA applications, and
platforms consisting of looselycoupled large services (potentially
a series of interconnected
monoliths)
Macrolithic systems generally
result from organisations with
clearly defined logical groupings
of business activity (i.e. risk
analysis, billing, account
management). There is often
integration within the platform of
multiple disparate systems,
potentially acquired via merger
and acquisition activity
Difficult to reason about systemlevel behaviour. The platforms
onto which these systems are
deployed are typically controlled
by a vendor, and there may be
large licensing costs. Change
typically involves a lot of
organisation-level coordination.
Out-of-process via heavyweight
protocols and middleware, e.g.
WS-*, SOAP, XML, ESB (TIBCO,
Oracle Service Bus)
Application typically
Application typically stateful, Combination of (sticky) stateful
stateful. Long-lived state with sticky sessions. Long- and stateless services. Long-lived
typically persisted
lived state persisted
state typically persisted externally
externally typically
externally using ACID
following ACID principles principles. Caching used
extensively at the edge, and
throughout stack
Single, external
Multiple, external
Multiple 'enterprise' data stores
and middleware
RDBMS, flat file
RDBMS, search indexes
RDBMS, search indexes, data
(e.g. Solr, ElasticSearch) grids (e.g Coherence, Infinispan)
Out-of-process with a combination of Out-of-process, typically using Out-of-process, typically using
lightweight middleware and protocols,
lightweight protocols e.g.
lightweight protocols e.g.
e.g. ESB (Mule ESB, Fuse, WS02), HTTP, Protocol Buffers, JSON, HTTP, Protocol Buffers, JSON,
HTTP, AMQP
AMQP
AMQP
Hybrid of monolithic and microservice Services typically stateless,
None
platform
with data persisted externally,
often eventually consistent.
Extensive use of caching
Combination of monolith and
microservice
Combination of monolith and
microservice
Multiple, integrated with
individual services
RDBMS, search indexes,
NoSQL, lightweight data grids
(e.g. Hazelcast)
Single, external
NoSQL
Microservice Maturity Model Proposal - Daniel Bryant (@danielbryantuk)
Name
Application Runtime
Longevity
Megalith Platform
Eternal
Vertical
Scalability
Bespoke
Monolith Platform
Long-lived
Macro SOA Platform
Long-lived
Initially vertical, and then Vertical and horizontal, depending
horizontal via cloning /
on service and vendor offerings
clustering and load
balancing. Vertical scaling is
typically not on-demand
Bespoke
Typically vendor-specific
'Enterprise' platforms
Meso Application Platform
Combination of long and short lived
(depending on application)
Microservice Platform
Transient
Nanoservice Platform
Ephemeral
Combination of monolith and
microservice
Horizontal service-specific
cloning / clustering (typically
on-demand)
Horizontal (on-demand)
IaaS, PaaS (private or public),
PaaS e.g. AWS Lambda
or container cluster manager
(e.g. Mesos, Kubernetes)
Bare metal in a private
Bare metal or virtualized Bare metal in a vendor managed Bare metal or virtualized data center, Public / private cloud with VMs Bespoke, typically supporting
data center
data center, or public /
data center or private/public cloud
or public / private cloud
or container-ready OS
LXC / containers 'under the
Deployment Fabric
private cloud
hood'
Single large artifact
Single large artifact
Multiple medium-large artifacts Typically one / several large artifacts, Large number of small artifacts Large number of tiny artifacts
Deployment Artifacts
and multiple smaller artifacts
Manual
Manual with potentially
Tooling typically provided by
Semi-automated orchestration with
Automated build pipelines
Complexity varies depending
some scripting, or
vendor platform
multiple build pipelines (typically a
implemented via CI tooling
on number of services and
automated build pipeline
hybrid of monolith and microservice (Jenkins, MS TFS). Additional
vendor platform
Deployment
implemented via CI tooling
platform approaches)
tooling may be required to
Orchestration
(Jenkins, MS TFS) in
automate deployments (e.g.
combination with release
Netflix's Asgard)
trains code deployments
with servers
Servers treated as pets
Bespoke hardware configuration
Move towards immutable
Immutable 'Phoenix' servers or N/A (no access to underlying
Infrastructure Mutability Snowflakes,
treated as sacred pets
infrastructure
immutable containers
infrastructure)
Hand-crafted
Hand-crafted, or potentially
Customised vendor-specific
Provide 'automated sysadmin'
Highly automated, with
None required. Deployment
Infrastructure
'automated sysadmin'
provisioning, which may only
including 'frying' of environments with environments typically 'baked' artifact is typically uploaded via
approach (CFEngine,
expose a deployment container
tools such as Chef, Puppet or Salt
with tools such as Packer.i,
API / SDK to pre-provisioned
Provisioning
Puppet etc)
such as application server
Aminator or Docker
platform
Manual
Manual, potentially some
Semi-automated
Semi-automated
Automated, typically provided
Automated (at build time)
automation via generated
via external service such as
Application Configuration
config files
Zookeeper, Consul, etcd
None required
None required
Provided as part of the platform
Manual, or semi-automated (via
Provided by external service
Automated (at build time)
Inter-platform Service
config files)
within the platform (e.g.
Discovery
ZooKeeper, Consul, etcd)
Typically none, as
Ingress traffic is typically
Provided as part of the platform
Combination of software loadTypically P2P, or via service
Typically events are sent to
megaliths are typically hardware load-balanced to
balancers (HAProxy etc) and P2P.
endpoints (via DNS etc). MQ
platform API or MQ broker,
only scaled vertically
cluster of application
MQ used for async communication
broker provides routing for
which handles routing
Routing
instances. Internal
async or event-driven
communication typically via
communicaiton
central load-balancer
Single artifact to monitor.
Artifacts and instances
Provided as part of the platform Hybrid of monolithic and microservice Services monitored individually Platform monitoring via vendor
OS monitored at hardware monitored at cluster level,
monitoring
by external centralised
PaaS console
Observability /
level
typically via tooling such as
applications e.g. Logstash,
Monitoring
Nagios, Graphite and
Nagios, Reimann, Graphite
bespoke applications
Terminal for remote
IDE
IDE, potentially with vendorIDE, external service virtualisation IDE, service virtualisation (e.g.
IDE (limited)
access to code, and (if
specific plugins
(enabling testing against QA servers),
VCR, mountebank), local
Dev Tooling
lucky) IDE
and scripted local service
service orchestration (e.g.
orchestration
Ansible, Fig)
Deployment Platforms
Combination of monolith and
microservice platforms
Microservice Maturity Model Proposal - Daniel Bryant (@danielbryantuk)
Name
Ops Tooling
Testing
Iteration Cycle
Delivery Model
Examples
Megalith Platform
Shell scripts, quick wits
and lots of coffee
Monolith Platform
Macro SOA Platform
Meso Application Platform
Microservice Platform
Shell scripts, with some
Shell scripts and vendor-specific Provisioning and config management,
Provisioning and config
automated provisioning
installs and tooling
such as Chef, Puppet, and Ansible management with tooling such
tools such as Puppet, Chef
as Puppet or Ansible, and
and Salt
PaaS vendor-specific APIs /
SDKs. Potentially tooling
around Docker or another
container-based OS (CoreOS,
Project Atomic etc) ecosystem
Witchcraft and voodoo
Manual testing, and (if
Typically manual via QA and
Automated testing. QA and Staging Extensive automated testing at
lucky) unit tests and
Staging environments. Some
environments allow manual validation component level. Automated
monolithic integratation test localised automated testing for
canary deployments (capable
suite
components/services
of rollback) and synthetic
monitoring in production
Yearly
Quarterly - weekly (although
Monthly - weekly
Monthly - daily
Within minutes
companies such as Flickr,
Google and Etsy have
pioneered multiple daily
releases)
Big bang
Big bang (some continuous Coordinated Big Bang via vendor Continuous integration, potentially
Continuous delivery
integration)
tooling
with continuous delivery
Large 'enterprise' systems, Lots of companies (probably
Typical modern 'enterprise'
Lots of companies attempting to
Typical 'Cloud-native' or
such as insurance and
yours)
organisation, e.g. finance,
innovate (e.g Groupon, Sage)
DevOps unicorn organisations
financial software
insurance and travel
e.g. Netflix, Amazon, Twitter
Nanoservice Platform
None required
Synthetic monitoring in
production
Within seconds
Continuous delivery
Amazon
