$30 off During Our Annual Pro Sale. View Details »

Monolith to Microservices: A small teams journey

Dale Humby
December 09, 2018

Monolith to Microservices: A small teams journey

At Nomanini we built our first payments platform on Google Cloud when it was still only App Engine. As our product grew we built an ever-more-complex monolith. As our start-up pivoted we needed more flexibility, and wanted to experiment with newer technologies. With only three developers we made the bold decision to migrate our platform from an App Engine monolith to microservices running on Docker and Kubernetes. In this frank discussion I talk about the reasons why we made this move, the pitfalls we experienced, the benefits of the move, and why we love Kubernetes on Google Cloud.

Video: https://youtu.be/1sLg689YZtg

Dale Humby

December 09, 2018
Tweet

More Decks by Dale Humby

Other Decks in Technology

Transcript

  1. Dale Humby, Nomanini
    @dalehumby
    South Africa
    Monolith to Microservices
    A small teams journey

    View Slide

  2. View Slide

  3. Affordable access to payments
    for everyone, everywhere

    View Slide

  4. View Slide

  5. View Slide

  6. $ 250+
    $ 200
    $ 150+
    < $ 40
    2011 2018
    Cost of Android phones has radically decreased
    We could not
    scale hardware

    View Slide

  7. Phone + Printer ≃ $ 100

    View Slide

  8. View Slide

  9. Monolith
    to
    Microservices
    Location
    South Africa

    View Slide

  10. tl;dr
    Monolith
    Microservices

    View Slide

  11. Monolith
    Business
    Logic
    View
    layer
    Front end
    developers
    Back end
    developers
    DBA
    Feature development

    View Slide

  12. Monolith
    Pro
    ● Simplicity
    ● Consistency
    ● Ease of cross boundary
    refactoring
    Con
    ● With Trunk based dev: Blocked sync 6
    devs
    ● Single language
    ● Package entire project and deploy,
    even if small change
    ● Scale by deploying entire project
    (heavy weight VMs)

    View Slide

  13. Microservices
    API
    Business Logic
    Full stack
    team
    Feature development
    Manages
    State
    Stateless

    View Slide

  14. Microservices
    Pro
    ● Scale out independently
    ● Experimentation
    ● Cognitive load
    ● Fast, independent release cycle
    ● Seperate teams
    Con
    ● Comms: Typically TCP/IP (http, graphql,
    rpc) instead of IPC
    ● Debug
    ○ Async
    ○ Architecture complex, messaging
    ○ Trace across services
    ○ Visibility in to status
    ● Dependency: large refactors,
    backward compat overhead,
    scheduling across teams
    ● Infrastructure: Duplication of
    monitoring, CI/CD pipelines

    View Slide

  15. Monolith and Microservices
    Initially easy
    Exponentially harder
    Steep
    learning
    curve
    Pays off over time

    View Slide

  16. CI/CD Maturity Model
    Continuous
    Integration
    Continuous
    Delivery
    Continuous
    Deployment
    Manual
    everything

    View Slide

  17. CI/CD Maturity Model
    Continuous
    Integration
    Continuous
    Delivery
    Continuous
    Deployment
    Manual
    everything
    Automated tests
    Build artifacts

    View Slide

  18. CI/CD Maturity Model
    Continuous
    Integration
    Continuous
    Delivery
    Continuous
    Deployment
    Manual
    everything
    Automated tests
    Build artifacts
    Always deployable
    Readiness feedback
    Push-button deploy
    DevOps culture

    View Slide

  19. CI/CD Maturity Model
    Continuous
    Integration
    Continuous
    Delivery
    Continuous
    Deployment
    Manual
    everything
    Automated tests
    Build artifacts
    Always deployable
    Readiness feedback
    Push-button deploy
    DevOps culture
    Auto deploy to prod
    Monitor, Alerting
    Canary releases

    View Slide

  20. How do I start?

    View Slide

  21. How do I start?

    View Slide

  22. How do I start?

    View Slide

  23. How big should
    microservices be?
    ● 2 pizza team
    ● Hold in head
    ● Bounded contexts
    ● Rewrite in 2 weeks
    ● 12 people, 1 service
    ● 6 people, 6 services
    ● Does 1 thing well
    ● As small as possible, and no smaller
    ● Independently replaceable, deployable,
    upgradable
    ● Heterogeneous tech

    View Slide

  24. Too Big
    ● Painful deployment
    ● Hard to change
    ● “Why does this depend on something
    I’ve never heard of?”
    ● Large teams
    ● 2-3 integration technologies (RPC,
    REST, Database)

    View Slide

  25. Too Big
    ● Painful deployment
    ● Hard to change
    ● “Why does this depend on something
    I’ve never heard of?”
    ● Large teams
    ● 2-3 integration technologies (RPC,
    REST, Database)
    How to fix?
    ● Find the seams
    ● Coupling, split on dependencies
    ● Functional decomposition, data
    partition
    ● Split, add API service

    View Slide

  26. Too small
    ● Integration issues
    ● Inconvenient coupling, especially in
    deployments
    ● Exposes representations, instead of
    behaviour

    View Slide

  27. Too small
    ● Integration issues
    ● Inconvenient coupling, especially in
    deployments
    ● Exposes representations, instead of
    behaviour
    How to fix?
    ● Redraw domain boundaries
    ● Combine services
    ● Hide CRUD, add business oriented events
    ● Service aggregator/orchestrator in front

    View Slide

  28. Just right
    But first...
    ● Mature DevOps
    ● No siloed teams

    View Slide

  29. Just right
    But first...
    ● Mature DevOps
    ● No siloed teams
    Business domain
    ● High cohesion
    ● Low coupling
    ● Single responsibility

    View Slide

  30. Just right
    But first...
    ● Mature DevOps
    ● No siloed teams
    Business domain Organisational
    culture
    ● High cohesion
    ● Low coupling
    ● Single responsibility

    View Slide

  31. "Organizations which design
    systems... are constrained to
    produce designs which are copies
    of the communication structures of
    these organizations."
    - Melvin Conway

    View Slide

  32. Google Cloud
    Platform
    Google Cloud Platform

    View Slide

  33. Continuum of services
    Most flexible
    Most responsibility
    More prescriptive, opinionated
    Just works

    View Slide

  34. Cloud
    Functions
    App Engine
    Kubernetes Engine
    Google Compute Engine

    View Slide

  35. Cloud
    Functions
    App Engine
    Kubernetes Engine
    Google Compute Engine

    View Slide

  36. Cloud
    Functions
    App Engine
    Kubernetes Engine
    Google Compute Engine

    View Slide

  37. Developed as only practical way to
    manage Google-scale compute
    Everything at Google runs in a
    container
    Containers at Google
    37
    Launch over 2 Billion
    containers per week.

    View Slide

  38. Kubernetes

    View Slide

  39. Kubernetes
    {...}

    View Slide

  40. Kubernetes
    {...}

    View Slide

  41. Kubernetes
    {...} Microservice

    View Slide

  42. Kubernetes
    Microservice
    Proxy

    View Slide

  43. Kubernetes
    Microservice
    Proxy

    View Slide

  44. Kubernetes
    Microservice
    Proxy
    Pod

    View Slide

  45. Kubernetes
    Microservice
    Proxy
    Pod
    Node

    View Slide

  46. Kubernetes
    Node
    Pod

    View Slide

  47. Kubernetes
    Node
    Microservice
    Pod

    View Slide

  48. Kubernetes
    Node
    Microservice
    Proxy
    Pod

    View Slide

  49. Kubernetes
    Node
    Microservice
    Proxy
    Pod
    Microservice
    Proxy
    Pod

    View Slide

  50. Kubernetes
    Node 1
    µS 1
    µS 1 µS 4
    µS 3
    Node 2
    µS 1
    µS 3
    µS 2
    Node 3
    µs 1
    µs 1 µS 2

    View Slide

  51. Kubernetes in Single Zone
    Node 1
    µS 1
    µS 1 µS 4
    µS 3
    Node 2
    µS 1
    µS 3
    µS 2
    Node 3
    µS 1
    µS 1 µS 2

    View Slide

  52. Kubernetes in High Availability
    Node 1
    µS 1
    µS 1 µS 4
    µS 3
    Node 2
    µS 1
    µS 3
    µS 2
    Node 3
    µS 1
    µS 1 µS 2

    View Slide

  53. Node 3
    Kubernetes in High Availability
    Node 1
    µS 1
    µS 1
    µS 3
    µS 1
    µS 3
    µS 2
    µS 1
    µS 1 µS 2
    µS 4

    View Slide

  54. Node 3
    Kubernetes in High Availability
    Node 1
    µS 1
    µS 1
    µS 3
    µS 1
    µS 3
    µS 2
    µS 1
    µS 1 µS 2

    View Slide

  55. Node 3
    Kubernetes in High Availability
    Node 1
    µS 1
    µS 1
    µS 3
    µS 1
    µS 3
    µS 4
    µS 1
    µS 1 µS 2
    µS 2

    View Slide

  56. Node 3
    Kubernetes
    + Preemptible VM’s
    = 70% cost saving
    Node 1
    µS 1
    µS 1
    µS 3 µS 3
    µS 1
    µS 1 µS 2
    µS 2

    View Slide

  57. Cloud
    Functions
    App Engine
    Kubernetes Engine
    Google Compute Engine

    View Slide

  58. Best practices
    ● Auto-scaling
    ● Async, Eventual consistency
    ● Timeouts, Circuit breakers to fail fast
    ● Bulk-heads
    ● Avoiding Cascading failures

    View Slide

  59. Cloud
    Functions
    App Engine
    Kubernetes Engine
    Google Compute Engine

    View Slide

  60. Firebase
    Cloud Functions

    View Slide

  61. Monolith
    or
    Microservices
    ????
    Location
    South Africa

    View Slide

  62. CI
    time
    knowledge
    Learning curve
    Automation, testing

    View Slide

  63. CI
    CD
    time
    knowledge
    Learning curve
    Always ready to release
    Automation, testing

    View Slide

  64. CI
    CD
    Microservices
    time
    knowledge
    Learning curve
    Kubernetes: Control plane
    Always ready to release
    Automation, testing

    View Slide

  65. CI
    CD
    Microservices
    Visibility
    time
    knowledge
    Learning curve
    Kubernetes: Control plane
    Istio: Microservice mesh
    Always ready to release
    Automation, testing

    View Slide

  66. Google Cloud
    Platform
    Lessons learnt

    View Slide

  67. Google Cloud
    Platform
    Lessons learnt
    Monolith
    ● Increasingly difficult as team, product complexity scale
    ● Not easy to change to another tech stack (DB’s, language, libraries)

    View Slide

  68. Google Cloud
    Platform
    Lessons learnt
    Monolith
    ● Increasingly difficult as team, product complexity scale
    ● Not easy to change to another tech stack (DB’s, language, libraries)
    Microservices
    ● Went too small: CRUD services… now consolidating
    ● Really needed a strong CI/CD culture, even then challenging
    ● Refactoring while live : Changing engine while aeroplane is flying
    ● Distributed systems are challenging
    ● Kubernetes ecosystem good, big learning curves, need larger team

    View Slide

  69. Google Cloud
    Platform
    Lessons learnt
    Monolith
    ● Increasingly difficult as team, product complexity scale
    ● Not easy to change to another tech stack (DB’s, language, libraries)
    Microservices
    ● Went too small: CRUD services… now consolidating
    ● Really needed a strong CI/CD culture, even then challenging
    ● Refactoring while live : Changing engine while aeroplane is flying
    ● Distributed systems are challenging
    ● Kubernetes ecosystem good, big learning curves, need larger team
    Not removing complexity – Just moving it

    View Slide

  70. GDE
    Thank you
    [email protected]

    View Slide

  71. Q&A
    South Africa

    View Slide