Tweet
Tweet

Slide 1

Slide 1 text

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

Slide 2

Slide 2 text

LOVE \ YOUR \ MONOLITH (dutch php conference 2022)

Slide 3

Slide 3 text

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

Slide 4

Slide 4 text

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

Slide 5

Slide 5 text

5 Why though? 5

Slide 6

Slide 6 text

Software evolution is MESSY 6

Slide 7

Slide 7 text

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

Slide 8

Slide 8 text

SOFTWARE DEVELOPMENT PROCESS 8

Slide 9

Slide 9 text

SOFTWARE DEVELOPMENT PROCESS 9

Slide 10

Slide 10 text

SOFTWARE DEVELOPMENT PROCESS 10

Slide 11

Slide 11 text

11 The result? MONOLITHS!

Slide 12

Slide 12 text

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

Slide 13

Slide 13 text

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

Slide 14

Slide 14 text

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

Slide 15

Slide 15 text

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

Slide 16

Slide 16 text

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

Slide 17

Slide 17 text

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

Slide 18

Slide 18 text

“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

Slide 19

Slide 19 text

… therefore … 19

Slide 20

Slide 20 text

“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

Slide 21

Slide 21 text

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

Slide 22

Slide 22 text

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

Slide 23

Slide 23 text

No content

Slide 24

Slide 24 text

No content

Slide 25

Slide 25 text

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

Slide 26

Slide 26 text

No content

Slide 27

Slide 27 text

27

Slide 28

Slide 28 text

No content

Slide 29

Slide 29 text

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

Slide 30

Slide 30 text

30

Slide 31

Slide 31 text

APIs can be INTERNAL 31

Slide 32

Slide 32 text

No content

Slide 33

Slide 33 text

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

Slide 34

Slide 34 text

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

Slide 35

Slide 35 text

No content

Slide 36

Slide 36 text

No content

Slide 37

Slide 37 text

No content

Slide 38

Slide 38 text

No content

Slide 39

Slide 39 text

Authentication subdomain Orders subdomain DOMAIN DRIVEN DESIGN

Slide 40

Slide 40 text

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

Slide 41

Slide 41 text

▰ 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

Slide 42

Slide 42 text

▰ 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

Slide 43

Slide 43 text

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

Slide 44

Slide 44 text

Remember this one? 44

Slide 45

Slide 45 text

SOFTWARE DEVELOPMENT PROCESS 45

Slide 46

Slide 46 text

MICROSERVICE ARCHITECTURE 46

Slide 47

Slide 47 text

47

Slide 48

Slide 48 text

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

Slide 49

Slide 49 text

49 WHAT IS “WEB SCALE”?

Slide 50

Slide 50 text

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

Slide 51

Slide 51 text

51 IDENTIFY ASYNCHRONOUS BOUNDARIES

Slide 52

Slide 52 text

52 MULTI-ANGLE MONOLITH Queue Monolith Service Job runner

Slide 53

Slide 53 text

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

Slide 54

Slide 54 text

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

Slide 55

Slide 55 text

▰ 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

Slide 56

Slide 56 text

▰ 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

Slide 57

Slide 57 text

57

Slide 58

Slide 58 text

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

Slide 59

Slide 59 text

59

Slide 60

Slide 60 text

60

Slide 61

Slide 61 text

61

Slide 62

Slide 62 text

62

Slide 63

Slide 63 text

… write it yourself 63 (at least some times)

Slide 64

Slide 64 text

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

Slide 65

Slide 65 text

THAT DESIGN BIT 65

Slide 66

Slide 66 text

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

Slide 67

Slide 67 text

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

Slide 68

Slide 68 text

… it depends 68 (but probably not)

Slide 69

Slide 69 text

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

Slide 70

Slide 70 text

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

Slide 71

Slide 71 text

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