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
2. LOVE \ YOUR \ MONOLITH (dutch php conference 2022)
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
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
5. 5 Why though? 5
6. Software evolution is MESSY 6
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
8. SOFTWARE DEVELOPMENT PROCESS 8
9. SOFTWARE DEVELOPMENT PROCESS 9
10. SOFTWARE DEVELOPMENT PROCESS 10
11. 11 The result? MONOLITHS!
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
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
14. “That’s just, like, your opinion, man 14 the dude: 1998
15. … can we do it without the FUD? (fear, uncertainty, doubt) 15
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
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
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
19. … therefore … 19
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
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
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
25. 25 Store Orders Auth Payment Emailer Web API API API API Web API
29. ▰ Build good APIs ▰ S O L I D ▰ Use code quality & static analysis tools ▰ Domain driven design (DDD) 29 techniques for LOGICAL systems
31. APIs can be INTERNAL 31
33. 33 Store Orders Auth Payment Emailer Web Function Function Web Function Function Function
34. ▰ Single responsibility ▰ Open/closed ▰ Liskov substitution ▰ Interface segregation ▰ Dependency inversion 34
39. Authentication subdomain Orders subdomain DOMAIN DRIVEN DESIGN
40. Authentication context DOMAIN DRIVEN DESIGN Authentication subdomain Orders subdomain Orders context Payments context
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
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
43. 43 Store (vercel) Orders (k8s) Auth (Auth0) Payment (k8s) Emailer (Lambda) HTTPS HTTP Batch Queue gRPC HTTPS Queue
44. Remember this one? 44
45. SOFTWARE DEVELOPMENT PROCESS 45
46. MICROSERVICE ARCHITECTURE 46
48. ▰ Comprehensible > Scalable ▰ Asynchronous boundaries ▰ Infrastructure as code ▰ Satellite services 48 techniques for STABLE systems
49. 49 WHAT IS “WEB SCALE”?
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
51. 51 IDENTIFY ASYNCHRONOUS BOUNDARIES
52. 52 MULTI-ANGLE MONOLITH Queue Monolith Service Job runner
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
54. 54 Monolith Emailer SATELLITE SERVICES Analytics ▰ Asynchronous ▰ Prototyping ▰ Secondary concerns ▰ Cross-cutting
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
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
58. ▰ Utilising established languages & tooling ▰ Reduce the number of 3rd party dependencies ▰ Planning our systems better ▰ Testing & code quality 58 techniques for FLEXIBLE systems
63. … write it yourself 63 (at least some times)
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
65. THAT DESIGN BIT 65
66. BEYOND UNIT TESTING ▰ Integration & acceptance testing as standard Use Codeception - codeception.com BDD-style acceptance tests Integrations with popular frameworks 66
67. “We’re already on microservices, should we go back? 67 you: just now (maybe)
68. … it depends 68 (but probably not)
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
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
71. 71 THANKS#! questions: ask -> ▰ twitter @M1ke \ ▰ slack #og-aws \ ▰ joind.in/talk/1832a Code snippets by carbon.now.sh Presentation template by SlidesCarnival