Slide 1

Slide 1 text

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

Slide 2

Slide 2 text

Who am I?

Slide 3

Slide 3 text

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

Slide 4

Slide 4 text

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

Slide 5

Slide 5 text

Where We Started

Slide 6

Slide 6 text

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

Slide 7

Slide 7 text

Identify Bounded Contexts

Slide 8

Slide 8 text

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

Slide 9

Slide 9 text

Splitting Frontend And Backend

Slide 10

Slide 10 text

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

Slide 11

Slide 11 text

API Gateway

Slide 12

Slide 12 text

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

Slide 13

Slide 13 text

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 ... ...

Slide 14

Slide 14 text

Split The Monolith

Slide 15

Slide 15 text

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)

Slide 16

Slide 16 text

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

Slide 17

Slide 17 text

Scaling Microservices

Slide 18

Slide 18 text

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

Slide 19

Slide 19 text

Where Do We Go From Here? Serverless!

Slide 20

Slide 20 text

THANK YOU