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
Top Related