Distributed apps without the Microservices

Slide 1

Slide 1 text

Distributed Apps without the Microservices Product Manager [email protected]

Slide 2

Slide 2 text

Agenda - Intro - What are Design Patterns? - Rethinking for the Cloud - Distributed Logging - Federated Identity - Rate Limiting - Next Steps

Slide 3

Slide 3 text

Who am I?

Slide 4

Slide 4 text

Who am I?

Slide 5

Slide 5 text

Who am I?

Slide 6

Slide 6 text

What are Design Patterns?

Slide 7

Slide 7 text

7 7 7 A way to express a complex solution to a problem in a simple, repeatable way We do this in many areas - Goldilocks - Catch 22 - Kobayashi Maru What is a Design Pattern?

Slide 8

Slide 8 text

8 8 8 What are some familiar ones?

Slide 9

Slide 9 text

Types of Design Patterns Creational Structural Behavioral Scope Class Factory Adapter Interpreter Object Abstract Factory Adapter Chain of Responsibility Builder Bridge Command Prototype Composite Iterator Singleton Decorator Mediator Facade Observer Flyweight Strategy Proxy Visitor

Slide 10

Slide 10 text

10 10 10 The Old World - Direct access to systems - 3-tier architecture (presentation, app, data) - Simple request/response - Local request/response - Potentially single server - Predictable components & conﬁgurations - Complete control over the stack The New(ish) World - DevOps and Build pipelines - Microservices - Distributed systems - Ephemeral systems - Scalable, unpredictable architecture - Predictable conﬁgurations - Minimal control for developers Why they break down

Slide 11

Slide 11 text

Disclaimer: These are descriptive, not prescriptive.

Slide 12

Slide 12 text

Rethinking for the Cloud

Slide 13

Slide 13 text

13 13 13 Why are we talking about this? Ref: https://www.joelonsoftware.com/2002/11/11/the-law-of-leaky-abstractions/ Our systems are abstractions built on abstractions These abstractions gloss over the details These abstractions make SOME work easier These abstractions make SOME work harder Goal: Understand the boundaries and how/when we cross them

Slide 14

Slide 14 text

Goal: There are ALWAYS trade offs. You can’t avoid them, but you can choose them.

Slide 15

Slide 15 text

Our Reference Architecture databases web app workers service1 service2

Slide 16

Slide 16 text

16 16 16 “If you know the problem and know yourself, you need not fear the result of a hundred releases. If you know yourself but not the problem, for every release you will also suffer downtime. If you know neither the problem nor yourself, you will break everything and have no ﬂippin’ clue why.” ~ Sun Tzu Some Wisdom

Slide 17

Slide 17 text

17 17 17 - Service Discovery - Service Mesh - Sidecars - Mock Objects - Work Objects What’s out of bounds this time? Ref: https://speakerdeck.com/caseysoftware/lift-and-shift-cut-overs-and-other-bad-habits - Publisher/Subscriber - Circuit Breakers - Strangler - Promises

Slide 18

Slide 18 text

18 18 18 - Service Discovery - Service Mesh - Sidecars - Mock Objects - Work Objects What’s out of bounds this time? Ref: https://speakerdeck.com/caseysoftware/lift-and-shift-cut-overs-and-other-bad-habits - Publisher/Subscriber - Circuit Breakers - Strangler - Promises

Slide 19

Slide 19 text

Federated Logging

Slide 20

Slide 20 text

Current State databases web server workers service1 service2 logs logs logs logs logs

Slide 21

Slide 21 text

What problem do we have? We have things all over the place Something breaks and we need to ﬁgure it out Different systems running on different architectures in different places with different timestamps

Slide 22

Slide 22 text

What problem do we have? HOW DO WE DEBUG ANYTHING?

Slide 23

Slide 23 text

Current State databases web server workers service1 service2 logs logs logs logs logs

Slide 24

Slide 24 text

Understand what’s in the logs, how it got there, what is missing Goal

Slide 25

Slide 25 text

Desired State databases web server workers service1 service2 logging

Slide 26

Slide 26 text

Trade Offs

Slide 27

Slide 27 text

- A single source of truth - A single set of timestamps - A standard structure of data - Traceability - Lots of data What do we gain & lose? - A single point of failure - Timestamps that may be “off” - A data structure mismatch - Mutability - Paying for lots of data

Slide 28

Slide 28 text

In the Wild

Slide 29

Slide 29 text

A way to corrupt/obfuscate details on the source A common pattern in security/intelligence operations where a “cutout” is used hide details Fun Sidebar: Cutouts Target Attacker Cutout

Slide 30

Slide 30 text

Federated Identity

Slide 31

Slide 31 text

Current State databases web app workers service1 service2

Slide 32

Slide 32 text

What problem do we have? What’s a user? Where’s the user? Who is the user? How do we remove the user?

Slide 33

Slide 33 text

Problem: Scope

Slide 34

Slide 34 text

Have one view of the user, one point of control and grant/remove access Goal

Slide 35

Slide 35 text

Have one view of the user, (normalization) one point of control (auth policies) and grant/remove access (provision/deprovision) Goal

Slide 36

Slide 36 text

Current State databases web app workers service1 service2

Slide 37

Slide 37 text

Current State: Open Standards

Slide 38

Slide 38 text

Have one view of the user, one point of control and grant/remove access (provision/deprovision) Goal

Slide 39

Slide 39 text

Desired State databases web app workers service1 service2 Identity Provider

Slide 40

Slide 40 text

Trade Offs

Slide 41

Slide 41 text

- A single view of the user - A single source of truth - A single set of authN policies - A single set of authZ policies - Open protocols (interop) What do we gain & lose? - A single point of failure - Vendor lock in - Everything must speak OIDC, SAML, etc - Latency (no longer local data)

Slide 42

Slide 42 text

In the Wild DIY

Slide 43

Slide 43 text

In the Wild DIY

Slide 44

Slide 44 text

Rate Limiting & Scaling

Slide 45

Slide 45 text

Current State databases web app workers service1 service2

Slide 46

Slide 46 text

What problem do we have? databases web app workers service1 service2 Things are growing Maybe predictably, maybe not We have bottlenecks in our system

Slide 47

Slide 47 text

Current State databases web app workers service1 service2

Slide 48

Slide 48 text

1. Crash 2. Auto-scale a. Sell your kidney 3. Filter Trafﬁc a. Goto 1 Current State web app

Slide 49

Slide 49 text

Provide access to the people and systems we need Goal

Slide 50

Slide 50 text

Desired State databases web app workers service1 service2

Slide 51

Slide 51 text

Desired State databases web app workers service1 service2 Web App Firewall/Proxy/Gateway

Slide 52

Slide 52 text

Scaling: Vertical web app

Slide 53

Slide 53 text

Scaling: Vertical web app

Slide 54

Slide 54 text

Add instances Scaling strategy: - Round Robin - % trafﬁc load This assumes you can deploy identical nodes Scaling: Horizontal load balancer web app web app web app

Slide 55

Slide 55 text

New Bottlenecks? databases load balancer web app web app web app

Slide 56

Slide 56 text

New Bottlenecks? databases load balancer web app web app web app databases databases

Slide 57

Slide 57 text

Now what? databases load balancer web app web app web app databases databases $$$ $$$ $$$ $$$ $$$ $$$

Slide 58

Slide 58 text

Btw: Circuit Breakers You may not want to scale - bad behavior - downstream problems - cost Ref: https://speakerdeck.com/caseysoftware/lift-and-shift-cut-overs-and-other-bad-habits

Slide 59

Slide 59 text

Wrap Up

Slide 60

Slide 60 text

- Design Patterns - complex ideas in simple repeatable explanations - Rethinking for the Cloud - our constraints have changed - Federated Logging - ﬁgure out who did what when - Federated Identity - have a single, consistent view of the user - Rate Limiting/Scaling - get control over your system and costs Recap

Slide 61

Slide 61 text

61 61 61 - Service Discovery - Service Mesh - Sidecars - Mock Objects - Work Objects Other Cloud Design Patterns Ref: https://speakerdeck.com/caseysoftware/lift-and-shift-cut-overs-and-other-bad-habits - Publisher/Subscriber - Circuit Breakers - Strangler - Promises

Slide 62

Slide 62 text

62 62 62 Where can I learn more? - Microsoft’s Azure Architecture Center - PHP: Design Patterns on LinkedIn - webhooks.fyi

Slide 63

Slide 63 text

Distributed Apps without the Microservices Product Manager [email protected]