Monolith to Microservices – Our Journey

February 2014• 2 Presentation Layers:

• Customer Services Backend• Simple Marketing Website

• Single Backend API

• Hosting:• 3 apps on Heroku

• 1 engineer

• c. £80 / day in transactions

API

MySQL(Heroku addon)

Customer services

Marketing site

March 2014• 4 Presentation Layers:

• Customer Services Backend• Online Booking Website• Hotel Booking Interface• Therapist Mobile Website

• Single Backend API

• Hosting:• 5 apps on Heroku

• 1 engineer

• c. £250 / day in transactions

API

MySQL(Heroku addon)

Neo4J(Heroku addon)

Customer services

Online booking

Hotel booking

Therapist site

December 2014• More Presentation Layers:

• Customer Services Backend• Online Booking Website• Hotel Booking Interface• Therapist Responsive Website• Therapist Mobile Apps• Consumer iOS App• Consumer Android App• Hotel Group Login Interface

• Ever-growing Monolithic Backend API

• Hosting:• 8 apps on Heroku

Starting to get expensive…

• 2 engineers

• Over £1.5k / day in transactions

Customer services

Online booking

API

MySQL(Heroku addon)

Hotel booking

Therapist site

Neo4J(Heroku addon)

redis(Heroku addon)

Hotel groups

Consumer iOS

Consumer Android

Therapist Android

Therapist iOS

Native appsRabbitM

Q (EC2)

Time for a new architecture…

Monoliths

Pros• Simple ops tasks (deployment,

scaling)

• Very fast development

• Single tech stack (easy to understand)

Cons• Harder to add new features with

stability confidence

• Overwhelming to develop

• Long build +test times

• Long term commitment to tech stack

• Larger instance sizes

Microservices

Pros• Tiny applications = tiny build + test

time

• Pick and choose stack for each case + easy to rewrite a service

• More efficient scaling

• Independent deploy processes

• Prevent faults in one service affecting entire platform

Cons• More applications to deploy

• Inter-service communication has to be dealt with

• Harder to aggregate logs and trace across systems

• Not necessary for a simple codebase / platform

Where to host?

• Practically zero learning curve

• Expensive to run at large scale

• No access to OS / VM

• Git-push deploys can cause issues when bugs arise (CI / build pipeline)

• Super configurable networking layer (security!)

• Easy to go ‘back to OS’ for trickier setups

• Attractive startup programme

• Great services infrastructure (RDS / EC etc)

More applications to deploy

• Problem:– More applications means more ops work to do to deploy

and scale efficiently

• Solution:– Containerize your apps (stop thinking about instances)– Automate your deployment, uptime management and

scaling

Empire (PAAS)

emp deploy user/repository:tagDeployments

emp set VARIABLE=value -a app-nameEnvironment Variables

emp scale web=3:CPU:RAM -a app-nameScaling

emp ps -a app-nameProcess State

emp rollback v21 -a app-nameFast Release Rollback

github.com/remind101/empire

Inter-service communication

• Problem– Maintaining knowledge of traditional REST API endpoints

& DNS names can grow out of control with lots of services involved

• Solution– Use a centralised service bus (e.g. RabbitMQ)

RabbitMQ Service BusServer application

Client application

npmjs.com/package/rabbitr

Logs and tracing through multiple layers

• Problem– You need to view logs for all your applications– Nested requests can become difficult to trace

• Solution– Use a standardised logging & tracing solution that can link

requests through multiple application levels

FlightControl

FlightControl

github.com/urbanmassage/flight-control

Now

Customer services

Online booking

MySQL(RDS)

Hotel booking

Therapist site

redis(ElastiCache)

Hotel groups

Consumer iOS

Consumer Android

Therapist Android

Therapist iOS

RabbitMQ Cluster on EC2

Therapist API gateway Customer + Hotel API gateway

Microservice A

NodeJS

MySQL(RDS)

redis(ElastiCache)

Microservice BNodeJS

Microservice CPHP

MySQL(RDS)

redis(ElastiCache)

Microservice D

NodeJS

Postgres(RDS)

Microservice ENodeJS

And more…S3

@gileze33

@JackCKTang

@MassageApp