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.

Transcript

1. Distributed Apps without the Microservices Product Manager keith.casey@pangea.cloud
2. Agenda - Intro - What are Design Patterns? - Rethinking for the Cloud - Distributed Logging - Federated Identity - Rate Limiting - Next Steps
3. Who am I?
4. Who am I?
5. Who am I?
6. What are Design Patterns?
7. 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?
8. 8 8 8 What are some familiar ones?
9. 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
10. 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
11. Disclaimer: These are descriptive, not prescriptive.
12. Rethinking for the Cloud
13. 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
14. Goal: There are ALWAYS trade offs. You can’t avoid them, but you can choose them.
15. Our Reference Architecture databases web app workers service1 service2
16. 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
17. 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
18. 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
19. Federated Logging
20. Current State databases web server workers service1 service2 logs logs logs logs logs
21. 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
22. What problem do we have? HOW DO WE DEBUG ANYTHING?
23. Current State databases web server workers service1 service2 logs logs logs logs logs
24. Understand what’s in the logs, how it got there, what is missing Goal
25. Desired State databases web server workers service1 service2 logging
26. Trade Offs
27. - 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
28. In the Wild
29. 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
30. Federated Identity
31. Current State databases web app workers service1 service2
32. What problem do we have? What’s a user? Where’s the user? Who is the user? How do we remove the user?
33. Problem: Scope
34. Have one view of the user, one point of control and grant/remove access Goal
35. Have one view of the user, (normalization) one point of control (auth policies) and grant/remove access (provision/deprovision) Goal
36. Current State databases web app workers service1 service2
37. Current State: Open Standards
38. Have one view of the user, one point of control and grant/remove access (provision/deprovision) Goal
39. Desired State databases web app workers service1 service2 Identity Provider
40. Trade Offs
41. - 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)
42. In the Wild DIY
43. In the Wild DIY
44. Rate Limiting & Scaling
45. Current State databases web app workers service1 service2
46. What problem do we have? databases web app workers service1 service2 Things are growing Maybe predictably, maybe not We have bottlenecks in our system
47. Current State databases web app workers service1 service2
48. 1. Crash 2. Auto-scale a. Sell your kidney 3. Filter Traffic a. Goto 1 Current State web app
49. Provide access to the people and systems we need Goal
50. Desired State databases web app workers service1 service2
51. Desired State databases web app workers service1 service2 Web App Firewall/Proxy/Gateway
52. Scaling: Vertical web app
53. Scaling: Vertical web app
54. 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
55. New Bottlenecks? databases load balancer web app web app web app
56. New Bottlenecks? databases load balancer web app web app web app databases databases
57. Now what? databases load balancer web app web app web app databases databases $$$ $$$ $$$ $$$ $$$ $$$
58. 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
59. Wrap Up
60. - 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
61. 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
62. 62 62 62 Where can I learn more? - Microsoft’s Azure Architecture Center - PHP: Design Patterns on LinkedIn - webhooks.fyi
63. Distributed Apps without the Microservices Product Manager keith.casey@pangea.cloud