Name Megalith Platform Monolith Platform Macro SOA Platform Meso Application Platform Microservice Platform Nanoservice Platform

Description

Humongous singlecodebase resulting in asingle application

Large single codebaseresulting in a singleapplication

Classical SOA applications, andplatforms consisting of loosely-coupled large services (potentiallya series of interconnectedmonoliths)

Meso' or middle-sized servicesinterconnected to form a singleapplication or platform. Essentially amonolith and microservice hybrid

Cloud native' loosely-coupledsmall services focused aroundDDD-inspired 'boundedcontexts'

Extremely small single-purpose (primarily reactive)services

Motivations

These systems typicallyresult from theimplementation of aninitial intensively plannedcomplex application,which has evolved in ahaphazard fashion overmany years of success inthe market

Monolithic applicationsinitially allow rapidapplication development,and early features areadded easily and quickly.When the applicationcodebase is small thesystem is easy tounderstand, change anddeploy

Macrolithic systems generallyresult from organisations withclearly defined logical groupingsof business activity (i.e. riskanalysis, billing, accountmanagement). There is oftenintegration within the platform ofmultiple disparate systems,potentially acquired via mergerand acquisition activity

Meso systems emerge fromorganisations migrating away frommonolith, or adding new functionalityto existing applications via externallyhosted smaller applications

Microservice systems promotethe single responsibilityprinciple, and are potentiallyeasier to understand andmaintain even as theapplication grows in size andcomplexity. They can alsoenable decreased time tomarket (changes are isolated),and enable flexible scalability

Platforms such as AWSLambda are allowingapplications to be developedthat are ideal for responding tosimple event-driven systemswith dynamic workloads. Thiscan be thought of as anextension to the 'blackboard'architectural model, althoughstate is stored externally

Challenges

Near impossible tounderstand, maintain andmodify.

Difficult to understand,maintain and evolve

Difficult to reason about system-level behaviour. The platformsonto which these systems aredeployed are typically controlledby a vendor, and there may belarge licensing costs. Changetypically involves a lot oforganisation-level coordination.

These systems often contain thechallenges of both the monolithic andmicroservice architectures. It can alsobe difficult to extract functionality fromthe monolith, and there will bechanges required in development anddeployment practices and tooling.Potentially two separate skillsetsrequired.

Complexity pushed fromapplications to deploymentand runtime orchestration.Multiple services also requireresilient discovery andcommunication mechanisms.Services must be explicitlydesigned to allow flexiblescalability and fault-tolerance

Due to the asynchronous andreactive nature of theseplatforms, they often displayemergent behaviour that canbe difficult to debug at thesystem level

Typical Codebase Age 10 years + 5 years + 5+ years 2 - 5 years + New New

Languages Single Single Multiple Multiple Polyglot Polyglot (currently limited)

KLOC Per Artifact 1000's 100's 10's 10 - 1's 1's 0.1's

Code-levelModularisation

Ball of mud Ball of mud, potentially withsome componentization

(packages, namespaces,JARs, DLLs etc)

Typically componentized at theplatform level, but individual

service code may be less wellorganized and implemented

according to, or coupled with,vendor APIs

Hybrid of monolith and microserviceplatforms

Highly-componentised Extreme componentization

Typical Code Coupling High High High - Medium High - Low Low Extremely Low

Typical Code Cohesion Low Low - Medium Medium - High Medium - High High Extremely High

Typical Inter-applicationCommunication

In-process In-process Out-of-process via heavyweightprotocols and middleware, e.g.

WS-*, SOAP, XML, ESB (TIBCO,Oracle Service Bus)

Out-of-process with a combination oflightweight middleware and protocols,e.g. ESB (Mule ESB, Fuse, WS02),

HTTP, AMQP

Out-of-process, typically usinglightweight protocols e.g.

HTTP, Protocol Buffers, JSON,AMQP

Out-of-process, typically usinglightweight protocols e.g.

HTTP, Protocol Buffers, JSON,AMQP

State

Application typicallystateful. Long-lived state

typically persistedexternally typically

following ACID principles

Application typically stateful,with sticky sessions. Long-

lived state persistedexternally using ACID

principles. Caching usedextensively at the edge, and

throughout stack

Combination of (sticky) statefuland stateless services. Long-livedstate typically persisted externally

Hybrid of monolithic and microserviceplatform

Services typically stateless,with data persisted externally,

often eventually consistent.Extensive use of caching

None

Data Stores Single, external Multiple, external Multiple 'enterprise' data storesand middlewareCombination of monolith and

microserviceMultiple, integrated with

individual servicesSingle, external

Data Store TypeRDBMS, flat file RDBMS, search indexes

(e.g. Solr, ElasticSearch)RDBMS, search indexes, data

grids (e.g Coherence, Infinispan)Combination of monolith and

microserviceRDBMS, search indexes,

NoSQL, lightweight data grids(e.g. Hazelcast)

NoSQL

Microservice Maturity Model Proposal - Daniel Bryant (@danielbryantuk)

Name Megalith Platform Monolith Platform Macro SOA Platform Meso Application Platform Microservice Platform Nanoservice PlatformApplication Runtime

LongevityEternal Long-lived Long-lived Combination of long and short lived

(depending on application)Transient Ephemeral

Scalability

Vertical Initially vertical, and thenhorizontal via cloning /

clustering and loadbalancing. Vertical scaling is

typically not on-demand

Vertical and horizontal, dependingon service and vendor offerings

Combination of monolith andmicroservice

Horizontal service-specificcloning / clustering (typically

on-demand)

Horizontal (on-demand)

Deployment PlatformsBespoke Bespoke Typically vendor-specific

'Enterprise' platformsCombination of monolith and

microservice platformsIaaS, PaaS (private or public),or container cluster manager

(e.g. Mesos, Kubernetes)

PaaS e.g. AWS Lambda

Deployment FabricBare metal in a private

data centerBare metal or virtualizeddata center, or public /

private cloud

Bare metal in a vendor manageddata center or private/public cloud

Bare metal or virtualized data center,or public / private cloud

Public / private cloud with VMsor container-ready OS

Bespoke, typically supportingLXC / containers 'under the

hood'

Deployment Artifacts Single large artifact Single large artifact Multiple medium-large artifacts Typically one / several large artifacts,and multiple smaller artifactsLarge number of small artifacts Large number of tiny artifacts

DeploymentOrchestration

Manual Manual with potentiallysome scripting, or

automated build pipelineimplemented via CI tooling

(Jenkins, MS TFS) incombination with releasetrains code deployments

Tooling typically provided byvendor platform

Semi-automated orchestration withmultiple build pipelines (typically a

hybrid of monolith and microserviceplatform approaches)

Automated build pipelinesimplemented via CI tooling

(Jenkins, MS TFS). Additionaltooling may be required to

automate deployments (e.g.Netflix's Asgard)

Complexity varies dependingon number of services and

vendor platform

Infrastructure Mutability Snowflakes, with serverstreated as sacred petsServers treated as pets Bespoke hardware configuration Move towards immutable

infrastructureImmutable 'Phoenix' servers or

immutable containersN/A (no access to underlying

infrastructure)

InfrastructureProvisioning

Hand-crafted Hand-crafted, or potentially'automated sysadmin'approach (CFEngine,

Puppet etc)

Customised vendor-specificprovisioning, which may only

expose a deployment containersuch as application server

Provide 'automated sysadmin'including 'frying' of environments with

tools such as Chef, Puppet or Salt

Highly automated, withenvironments typically 'baked'

with tools such as Packer.i,Aminator or Docker

None required. Deploymentartifact is typically uploaded viaAPI / SDK to pre-provisioned

platform

Application ConfigurationManual Manual, potentially some

automation via generatedconfig files

Semi-automated Semi-automated Automated, typically providedvia external service such as

Zookeeper, Consul, etcd

Automated (at build time)

Inter-platform ServiceDiscovery

None required None required Provided as part of the platform Manual, or semi-automated (viaconfig files)

Provided by external servicewithin the platform (e.g.

ZooKeeper, Consul, etcd)

Automated (at build time)

Routing

Typically none, asmegaliths are typicallyonly scaled vertically

Ingress traffic is typicallyhardware load-balanced to

cluster of applicationinstances. Internal

communication typically viacentral load-balancer

Provided as part of the platform Combination of software load-balancers (HAProxy etc) and P2P.MQ used for async communication

Typically P2P, or via serviceendpoints (via DNS etc). MQbroker provides routing for

async or event-drivencommunicaiton

Typically events are sent toplatform API or MQ broker,

which handles routing

Observability /Monitoring

Single artifact to monitor.OS monitored at hardware

level

Artifacts and instancesmonitored at cluster level,

typically via tooling such asNagios, Graphite andbespoke applications

Provided as part of the platform Hybrid of monolithic and microservicemonitoring

Services monitored individuallyby external centralised

applications e.g. Logstash,Nagios, Reimann, Graphite

Platform monitoring via vendorPaaS console

Dev ToolingTerminal for remote

access to code, and (iflucky) IDE

IDE IDE, potentially with vendor-specific plugins

IDE, external service virtualisation(enabling testing against QA servers),

and scripted local serviceorchestration

IDE, service virtualisation (e.g.VCR, mountebank), localservice orchestration (e.g.

Ansible, Fig)

IDE (limited)

Microservice Maturity Model Proposal - Daniel Bryant (@danielbryantuk)

Name Megalith Platform Monolith Platform Macro SOA Platform Meso Application Platform Microservice Platform Nanoservice Platform

Ops Tooling

Shell scripts, quick witsand lots of coffee

Shell scripts, with someautomated provisioning

tools such as Puppet, Chefand Salt

Shell scripts and vendor-specificinstalls and tooling

Provisioning and config management,such as Chef, Puppet, and Ansible

Provisioning and configmanagement with tooling such

as Puppet or Ansible, andPaaS vendor-specific APIs /

SDKs. Potentially toolingaround Docker or another

container-based OS (CoreOS,Project Atomic etc) ecosystem

None required

Testing

Witchcraft and voodoo Manual testing, and (iflucky) unit tests and

monolithic integratation testsuite

Typically manual via QA andStaging environments. Some

localised automated testing forcomponents/services

Automated testing. QA and Stagingenvironments allow manual validation

Extensive automated testing atcomponent level. Automatedcanary deployments (capable

of rollback) and syntheticmonitoring in production

Synthetic monitoring inproduction

Iteration Cycle

Yearly Quarterly - weekly (althoughcompanies such as Flickr,

Google and Etsy havepioneered multiple daily

releases)

Monthly - weekly Monthly - daily Within minutes Within seconds

Delivery Model Big bang Big bang (some continuousintegration)Coordinated Big Bang via vendor

toolingContinuous integration, potentially

with continuous deliveryContinuous delivery Continuous delivery

ExamplesLarge 'enterprise' systems,

such as insurance andfinancial software

Lots of companies (probablyyours)

Typical modern 'enterprise'organisation, e.g. finance,

insurance and travel

Lots of companies attempting toinnovate (e.g Groupon, Sage)

Typical 'Cloud-native' orDevOps unicorn organisationse.g. Netflix, Amazon, Twitter

Amazon

Microservice Maturity Model Proposal - Daniel Bryant (@danielbryantuk)