Love Your Monolith - Longhorn 2025

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. curl -v "https://longhorn.php/love-your-monolith.json" * Trying 127.0.0.1:443... * TCP_NODELAY set * Connected to longhorn.php (127.0.0.1) port 443 (#0) * SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384 > GET /love-your-monolith.json HTTP/3 > user-agent: your-brain/1.0.1 * Connection state changed: waiting for audience
2. 2 #!/usr/bin/hi echo ‘Mike Lehan \ cto sturents.com \ aviator \ @m1ke@phpc.social \ joind.in/talk/5d2c3’ 2
3. LOVE \ YOUR \ MONOLITH (longhorn php 2025)
4. 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 4
5. 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” 5
6. 6 Why though? 6
7. Software evolution is MESSY 7
8. 8 It’s rare to START a project with a clear idea of what we are doing - or at least, where we are going 8
9. SOFTWARE DEVELOPMENT PROCESS 9
10. SOFTWARE DEVELOPMENT PROCESS 10
11. SOFTWARE DEVELOPMENT PROCESS 11
12. 12 The result? MONOLITHS!
13. MICROSERVICES ▰ 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 13
14. COMMON COMPARISONS 14 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
15. “That’s just, like, your opinion, man 15 the dude: 1998
16. … can we do it without the FUD? (fear, uncertainty, doubt) 16
17. WHAT DO WE WANT? 17 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
18. 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 18
19. “Understand the “why” first - the how will follow. Know your principles and let these guide how you architect your projects 19 me: 2025
20. WE WANT (systems which are): 20 LOGICAL STABLE FLEXIBLE
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 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
23. what’s wrong with coupling? 23
26. how do microservices decouple? 26
27. 27 Store Orders Auth Payment Emailer Web API API API API Web API
30. ▰ Domain driven design (DDD) ▰ Use code quality & static analysis tools ▰ Build good APIs ▰ S O L I D 30 techniques for LOGICAL systems
31. Authentication subdomain Orders subdomain DOMAIN DRIVEN DESIGN
32. Authentication context DOMAIN DRIVEN DESIGN Authentication subdomain Orders subdomain Orders context Payments context
38. APIs can be INTERNAL 38
41. 41 Store Orders Auth Payment Emailer Web Function Function Web Function Function Function
42. ▰ Single responsibility ▰ Open/closed ▰ Liskov substitution ▰ Interface segregation ▰ Dependency inversion 42
43. ▰ 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 43 what microservices teach us about STABLE systems
44. ▰ 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 44 general principles for STABLE systems
45. 45 Store (vercel) Orders (k8s) Auth (Auth0) Payment (k8s) Emailer (Lambda) HTTPS HTTP Batch Queue gRPC HTTPS Queue
46. Remember this one? 46
47. SOFTWARE DEVELOPMENT PROCESS 47
48. MICROSERVICE ARCHITECTURE 48
50. ▰ Comprehensible > Scalable ▰ Asynchronous boundaries ▰ Infrastructure as code ▰ Satellite services 50 techniques for STABLE systems
51. 51 WHAT IS “WEB SCALE”?
52. 52 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
53. 53 IDENTIFY ASYNCHRONOUS BOUNDARIES
54. 54 MULTI-ANGLE MONOLITH Queue Monolith Service Job runner
55. 55 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
56. 56 Monolith Emailer SATELLITE SERVICES Analytics ▰ Asynchronous ▰ Prototyping ▰ Secondary concerns ▰ Cross-cutting
57. ▰ 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 57 what microservices teach us about FLEXIBLE systems
58. ▰ 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 58 general principles for FLEXIBLE systems
60. ▰ Utilising established languages & tooling ▰ Reduce the number of 3rd party dependencies ▰ Planning our systems better ▰ Testing & code quality 60 techniques for FLEXIBLE systems
65. … write it yourself 65 (at least some times)
66. 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 66
67. THAT DESIGN BIT 67
68. BEYOND UNIT TESTING ▰ Integration & acceptance testing as standard Use Codeception - codeception.com BDD-style acceptance tests Integrations with popular frameworks 68
69. In conclusion 69
70. “We’re already on microservices, should we go back? 70 you: just now (maybe)
71. … it depends 71 (but probably not)
72. 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? 72
73. 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 73
74. 74 #!/usr/bin/thanks curl “https://longhorn.php/any-questions.json” | jq { “fediverse”: “@m1ke@phpc.social”, “feedback”: “joind.in/talk/5d2c3” } Code snippets by carbon.now.sh Presentation template by SlidesCarnival