Love Your Monolith

What do you think of your monolith? It's a system built over maybe
many years, possibly by many developers, but it seems to cause so many
issues - unexpected bugs, difficulty testing, a challenge to train new
developers on. Should you tear it down and rebuild with microservices?
What would you lose?

The monolith has come in for criticism, some of it deserved, in
recent years. Microservices are heralded as the solution to many
problems we face with monolithic applications. This talk will explore
the reasons underpinning these architecture decisions, and examine if we
can apply these principles to evolve our monolithic applications. We'll
learn about coupling, pros & cons of different approaches, and
explore real world examples to see how thinking well about architecture
choices can benefit us. We'll even see how monoliths and microservices
can work together - is there a best of both worlds?

Transcript

1. 1
   HELLO#!
   :Mike Lehan \
   software engineer \
   cto sturents \
   skydiver \
   follow @m1ke \
   joind.in/talk/1832a
   1
   

   View Slide

2. LOVE \
   YOUR \
   MONOLITH
   (dutch php conference 2022)
   

   View Slide

3. WE’LL LEARN
   ▰ How monoliths are perceived
   (in comparison to microservices)
   ▰ What principles guide our architecture decisions
   ▰ Which microservice practices hint at better principles
   ▰ How to get “microservice” advantages in your monolith
   3
   

   View Slide

4. THE MONOLITH
   ▰ Variety of meanings, but generally implies
   large/singular codebase for an application
   ▰ Many “off the shelf” applications (e.g. Drupal,
   Magento) promote a monolithic approach
   ▰ Some arguments as to how “modular” a system can
   be before it stops being monolithic
   ▰ Considered more “traditional”
   4
   

   View Slide

5. 5
   Why though?
   5
   

   View Slide

6. Software evolution is
   MESSY
   6
   

   View Slide

7. 7
   It’s rare to START a
   project with a clear
   idea of what we are
   doing - or at least,
   where we are going
   7
   

   View Slide

8. SOFTWARE DEVELOPMENT PROCESS
   8
   

   View Slide

9. SOFTWARE DEVELOPMENT PROCESS
   9
   

   View Slide

10. SOFTWARE DEVELOPMENT PROCESS
    10
    

    View Slide

11. 11
    The result?
    MONOLITHS!
    

    View Slide

12. MICROSERVICES
    ▰ A form of service-oriented architecture (SOA)
    ▰ Involves decoupled systems with a protocol handling
    communication between them
    ▰ Intended to allow splitting systems by “business
    domain”, and to decentralise component parts
    ▰ Term evolved around mid-2000s though there is no
    canonical definition
    12
    

    View Slide

13. COMMON COMPARISONS
    13
    Monolith Microservices
    Heavy coupling Decoupled
    Centralized Decentralized
    One server Network/containers
    Single point of failure Resistant to failures
    One programming language Multiple languages (possibly)
    Hard to maintain Easier to maintain
    

    View Slide

14. “That’s just, like, your
    opinion, man
    14
    the dude: 1998
    

    View Slide

15. … can we do it
    without the FUD?
    (fear, uncertainty, doubt)
    15
    

    View Slide

16. WHAT DO WE WANT?
    16
    Monolith Microservices
    Heavy coupling Decoupled
    Centralized Decentralized
    One server Network/containers
    Single point of failure Resistant to failures
    One programming language Multiple languages (possibly)
    Hard to maintain Easier to maintain
    LOGICAL
    STABLE
    FLEXIBLE
    

    View Slide

17. WHAT DO WE WANT?
    Flexible
    We want to build
    systems that can
    evolve, that grow with
    their teams. We care
    about innovation, being
    able to use new tools
    and experiment
    Logical
    We want systems that
    are easy to reason
    about, whose internal
    structure matches that
    of our businesses
    Stable
    We want options of where
    we host, how we provision
    & test, plus resilience to
    failures at levels we can’t
    control - machines &
    networks
    17
    

    View Slide

18. “Your choice of architecture
    has less impact on the
    operation of a system than
    the principles you follow
    because of that choice
    18
    me: 2022
    

    View Slide

19. … therefore …
    19
    

    View Slide

20. “The reason why we would choose
    a specific approach should be
    driven by our preferred principles
    (rather than the other way round)
    20
    also me: 2022
    

    View Slide

21. what microservices teach us about
    LOGICAL systems
    ▰ Split separate business functions into separate
    systems to decentralise services
    ▰ Services have specific sets of clear interactions via
    API with one another
    ▰ Unrelated code lives in different codebases which
    reduces coupling
    21
    

    View Slide

22. general principles for
    LOGICAL systems
    ▰ Split separate business functions into separate
    systems to decentralise services
    ▰ Services have specific sets of clear interactions via
    API with one another
    ▰ Unrelated code lives in different codebases which
    reduces coupling
    22
    

    View Slide

23. View Slide

24. View Slide

25. 25
    Store
    Orders
    Auth
    Payment
    Emailer
    Web
    API
    API
    API
    API
    Web
    API
    

    View Slide

26. View Slide

27. View Slide

28. View Slide

29. ▰ Build good APIs
    ▰ S O L I D
    ▰ Use code quality & static analysis tools
    ▰ Domain driven design (DDD)
    29
    techniques for
    LOGICAL systems
    

    View Slide

30. View Slide

31. APIs can be INTERNAL
    31
    

    View Slide

32. View Slide

33. 33
    Store
    Orders
    Auth
    Payment
    Emailer
    Web
    Function
    Function
    Web
    Function
    Function
    Function
    

    View Slide

34. ▰ Single responsibility
    ▰ Open/closed
    ▰ Liskov substitution
    ▰ Interface segregation
    ▰ Dependency inversion
    34
    

    View Slide

35. View Slide

36. View Slide

37. View Slide

38. View Slide

39. Authentication
    subdomain
    Orders
    subdomain
    DOMAIN DRIVEN DESIGN
    

    View Slide

40. Authentication
    context
    DOMAIN DRIVEN DESIGN
    Authentication
    subdomain
    Orders
    subdomain
    Orders
    context
    Payments
    context
    

    View Slide

41. ▰ Scale systems independently according to use
    ▰ Balance system load by splitting workloads between
    services
    ▰ Multiple services leads to use of infrastructure as code
    ▰ Independent services provide opportunity for
    experimentation
    41
    what microservices teach us about
    STABLE systems
    

    View Slide

42. ▰ Scale systems independently according to use
    ▰ Balance system load by splitting workloads between
    services
    ▰ Multiple services leads to use of infrastructure as code
    ▰ Independent services provide opportunity for
    experimentation
    42
    general principles for
    STABLE systems
    

    View Slide

43. 43
    Store
    (vercel)
    Orders
    (k8s)
    Auth
    (Auth0) Payment
    (k8s)
    Emailer
    (Lambda)
    HTTPS
    HTTP
    Batch
    Queue
    gRPC
    HTTPS
    Queue
    

    View Slide

44. Remember this one?
    44
    

    View Slide

45. SOFTWARE DEVELOPMENT PROCESS
    45
    

    View Slide

46. MICROSERVICE ARCHITECTURE
    46
    

    View Slide

47. View Slide

48. ▰ Comprehensible > Scalable
    ▰ Asynchronous boundaries
    ▰ Infrastructure as code
    ▰ Satellite services
    48
    techniques for
    STABLE systems
    

    View Slide

49. 49
    WHAT IS “WEB SCALE”?
    

    View Slide

50. 50
    WHAT IS “WEB SCALE”?
    Focus on:
    ▰ Separate data storage and application serving
    ▰ Big database servers can be better than fancy tech
    ▰ Async boundaries & job queues
    

    View Slide

51. 51
    IDENTIFY ASYNCHRONOUS BOUNDARIES
    

    View Slide

52. 52
    MULTI-ANGLE MONOLITH
    Queue
    Monolith
    Service
    Job runner
    

    View Slide

53. 53
    INFRASTRUCTURE AS CODE (IaC)
    Tools just as useful in a monolith…
    ▰ Terraform - define cloud resources
    ▰ Packer - build machine images
    ▰ docker-compose - map coupled service interactions
    

    View Slide

54. 54
    Monolith
    Emailer
    SATELLITE
    SERVICES
    Analytics
    ▰ Asynchronous
    ▰ Prototyping
    ▰ Secondary concerns
    ▰ Cross-cutting
    

    View Slide

55. ▰ Smaller services encourage fewer dependencies
    ▰ Mapping service responsibilities and interactions places
    a focus on system design
    ▰ Contracts between teams and services require clear
    understanding of a system
    ▰ Tests must branch beyond unit tests, focussing on
    acceptance & integration testing
    55
    what microservices teach us about
    FLEXIBLE systems
    

    View Slide

56. ▰ Smaller services encourage fewer dependencies
    ▰ Mapping service responsibilities and interactions places a
    focus on system design
    ▰ Tests must branch beyond unit tests, focussing on
    acceptance & integration testing
    56
    general principles for
    FLEXIBLE systems
    

    View Slide

57. View Slide

58. ▰ Utilising established languages & tooling
    ▰ Reduce the number of 3rd party dependencies
    ▰ Planning our systems better
    ▰ Testing & code quality
    58
    techniques for
    FLEXIBLE systems
    

    View Slide

59. View Slide

60. View Slide

61. View Slide

62. View Slide

63. … write it yourself
    63
    (at least some times)
    

    View Slide

64. INTERNAL DEPENDENCIES
    ▰ Common pattern to share internal dependencies: e.g.
    helper functions, business logic, database representations
    ▰ This causes the same problem in reverse - we have to
    coordinate upgrades of internal dependencies OR risk
    teams being unable to share code
    64
    

    View Slide

65. THAT DESIGN BIT
    65
    

    View Slide

66. BEYOND UNIT TESTING
    ▰ Integration & acceptance testing as standard
    Use Codeception - codeception.com
    BDD-style acceptance tests
    Integrations with popular frameworks
    66
    

    View Slide

67. “We’re already on
    microservices, should we go
    back?
    67
    you: just now (maybe)
    

    View Slide

68. … it depends
    68
    (but probably not)
    

    View Slide

69. ASK YOURSELF
    ▰ Do you know why you’re using microservices?
    ▰ Are you confident that the specific challenges of your
    business are best solved by microservices?
    ▰ Is the microservice implementation causing more
    problems than it has solved for you?
    ▰ Can you spot cases where you’d benefit significantly from
    using a “loved monolith” approach?
    69
    

    View Slide

70. IN CONCLUSION (like the previous slide, but for everyone)
    ▰ Principles should inform practice
    ▰ Choose your principles - what matters most to your
    software?
    ▰ The benefits and advantages attributed to microservices
    can often be implemented in a monolith
    ▰ Rebuilding is generally more expensive than improving,
    even if the improvements require paradigm changes
    70
    

    View Slide

71. 71
    THANKS#!
    questions: ask ->
    ▰ twitter @M1ke \
    ▰ slack #og-aws \
    ▰ joind.in/talk/1832a
    Code snippets by carbon.now.sh
    Presentation template by SlidesCarnival
    

    View Slide