Monolith To Microservices The Journey of a 1,000 Spartans!! 25TH JUNE 2016 Brice Nkengsa

Who am I?

BRICE NKENGSA ❏ Leads Engineering @ Andela ❏ Software Craftsman ❏ Ex-BlackBerry, Ex-Pivotal Labs ❏ Cameroonian ❏ Amateur guitar player (For the gyal dem :D) TWITTER - @briceicle GITHUB - @andela-bnkengsa MEDIUM - @briceicle

❖ Where We Started ❖ Identify Bounded Contexts ❖ Splitting Frontend and Backend ❖ API Gateway ❖ Split The Monolith ❖ Scaling Microservices Agenda

Where We Started

Where We Started ❏ Multitude of isolated monolithic applications ❏ Each application built to meet a specific business need ❏ Assessing candidates to Andela Fellowship ❏ Tracking Fellow progress during the Fellowship ❏ Tracking Fellow skills, interests, specializations, career plans, travel, etc. ❏ Challenges ❏ Rigid architecture ❏ Lots of duplicated business capabilities across apps ❏ Growing complexity over time ❏ Long-term commitment to a tech stack ❏ Solution ❏ Microservices!! Frontend Backend DB Heroku App Web Dyno

Identify Bounded Contexts

Identify Bounded Contexts “Bounded Context is a central pattern in Domain-Driven Design. DDD deals with large models by dividing them into different Bounded Contexts and being explicit about their interrelationships” - Martin Fowler Bounded Context allows you to model the aspects of a problem without having to be concerned with other parts of the business. ❏ Identified all the independent business capabilities we needed ❏ Identified the relationship between each of them ❏ Documented all the bounded contexts

Splitting Frontend And Backend

Splitting Frontend And Backend Frontend Backend DB Heroku App Web Dyno Frontend Backend DB API

API Gateway

API Gateway ❏ Direct Client to Microservice communication is not ideal ❏ Many services needed to be invoked to serve one client request ❏ Services might use non web-friendly protocols (Thrift binary, protocol buffers) ❏ Dependency with client makes it hard to refactor client code ❏ API Gateway provides a single point of entry for all clients into the system

API Gateway API Gateway simply proxies all client requests to the monolithic backends...for now! Web Client 1 Backend DB API Gateway Web Client 2 Web Client n Backend DB Backend DB ... ...

Split The Monolith

Split The Monolith ❏ Refactored our backend to be more modular ❏ Incrementally split each monolithic backend by: ❏ Identifying parts of the codebase that formulate bounded contexts (i.e. modules) ❏ Identifying ways to split the database ❏ Which part of the code reads from and write to the database ❏ Inspecting database-level constraints (e.g. foreign key relationship)

Split The Monolith Monolithic Schema User Mgmt Code Monolithic Schema User Service User Schema Monolithic Backend Monolithic Backend

Scaling Microservices

Scaling Microservices Design considerations we made to help us scale ❏ Build for failure ❏ Circuit breakers, requests timeouts, caching (even if it’s for 5 seconds) ❏ Monitor Everything. No, but really...Everything! ❏ Application monitoring (e.g. newrelic) ❏ Error monitoring (e.g. bugsnag) ❏ Log aggregation (e.g. Elasticsearch, Logstash & Kibana) ❏ Automate everything ❏ Continuous integration & delivery ❏ Test everything ❏ Unit tests, Integration tests, Acceptance tests, tests, tests and more tests

Where Do We Go From Here? Serverless!

THANK YOU