Monolith to Microservices

Brice of Andela presented their experience moving from Monolith to Microservices Architecture at the first forLoop Abuja conference.

Transcript

1. Monolith To Microservices The Journey of a 1,000 Spartans!! 25TH JUNE 2016 Brice Nkengsa
2. Who am I?
3. 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
4. ❖ Where We Started ❖ Identify Bounded Contexts ❖ Splitting Frontend and Backend ❖ API Gateway ❖ Split The Monolith ❖ Scaling Microservices Agenda
5. Where We Started
6. 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
7. Identify Bounded Contexts
8. 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
9. Splitting Frontend And Backend
10. Splitting Frontend And Backend Frontend Backend DB Heroku App Web Dyno Frontend Backend DB API
11. API Gateway
12. 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
13. 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 ... ...
14. Split The Monolith
15. 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)
16. Split The Monolith Monolithic Schema User Mgmt Code Monolithic Schema User Service User Schema Monolithic Backend Monolithic Backend
17. Scaling Microservices
18. 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
19. Where Do We Go From Here? Serverless!
20. THANK YOU