Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Distributed apps without the Microservices

Distributed apps without the Microservices

The last time you moved, you had that box. You haven’t opened it in years. You still haven’t opened it but you carry it around with you like a treasured keepsake. Unfortunately, we moved to the cloud the same way. We brought all of our habits, practices, and patterns without considering which may be strengths or weaknesses.

In this session, we'll take a critical look at our app architectures already in the cloud. Microservices are the "obvious" solution but we need to answer some key questions first: Do we really know what's happening in our systems? Do we have a single point of information, control, and truth? Towards that goal, we'll dive into core concepts like Distributed Logging, Federated Identity, and Rate Limiting to have and control our system.

Keith Casey

August 01, 2024
Tweet

More Decks by Keith Casey

Other Decks in Technology

Transcript

  1. Agenda - Intro - What are Design Patterns? - Rethinking

    for the Cloud - Distributed Logging - Federated Identity - Rate Limiting - Next Steps
  2. 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?
  3. 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
  4. 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 & configurations - Complete control over the stack The New(ish) World - DevOps and Build pipelines - Microservices - Distributed systems - Ephemeral systems - Scalable, unpredictable architecture - Predictable configurations - Minimal control for developers Why they break down
  5. 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
  6. 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 flippin’ clue why.” ~ Sun Tzu Some Wisdom
  7. 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
  8. 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
  9. What problem do we have? We have things all over

    the place Something breaks and we need to figure it out Different systems running on different architectures in different places with different timestamps
  10. - 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
  11. 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
  12. What problem do we have? What’s a user? Where’s the

    user? Who is the user? How do we remove the user?
  13. Have one view of the user, (normalization) one point of

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

    and grant/remove access (provision/deprovision) Goal
  15. - 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)
  16. What problem do we have? databases web app workers service1

    service2 Things are growing Maybe predictably, maybe not We have bottlenecks in our system
  17. 1. Crash 2. Auto-scale a. Sell your kidney 3. Filter

    Traffic a. Goto 1 Current State web app
  18. Add instances Scaling strategy: - Round Robin - % traffic

    load This assumes you can deploy identical nodes Scaling: Horizontal load balancer web app web app web app
  19. Now what? databases load balancer web app web app web

    app databases databases $$$ $$$ $$$ $$$ $$$ $$$
  20. 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
  21. - Design Patterns - complex ideas in simple repeatable explanations

    - Rethinking for the Cloud - our constraints have changed - Federated Logging - figure 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
  22. 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
  23. 62 62 62 Where can I learn more? - Microsoft’s

    Azure Architecture Center - PHP: Design Patterns on LinkedIn - webhooks.fyi