Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Monolith to Microservices

Monolith to Microservices

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

forLoop

June 28, 2016
Tweet

More Decks by forLoop

Other Decks in Programming

Transcript

  1. 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
  2. ❖ Where We Started ❖ Identify Bounded Contexts ❖ Splitting

    Frontend and Backend ❖ API Gateway ❖ Split The Monolith ❖ Scaling Microservices Agenda
  3. 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
  4. 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
  5. 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
  6. 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 ... ...
  7. 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)
  8. Split The Monolith Monolithic Schema User Mgmt Code Monolithic Schema

    User Service User Schema Monolithic Backend Monolithic Backend
  9. 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