1992 (C-64) • IHK Applied Computer Science/Max-Planck Society (-2007) • Systems Engineer Dell (-2015) • Engineer and Research VMware Office of the CTO (-2022) • Product Manager AWS EventBridge (2022-) • Self-taught Developer (Golang) • Public Speaking and Blogging (@embano1 www.mgasch.com) • ! and "
Control Plane API Server etcd Controller Manager Scheduler … Access REST API SDKs Web UI kubectl Workers Kubelet Kubelet Kubelet Pod Pod Pod Availability Scalability Resiliency Security Flow Control Extensibility Observability Durability Consistency Deployment Versioning Responsiveness Programming Model Open Source Recovery Communication
Solution to a Problem in a Context” • Applicable in lots of different Situations • Patterns are Solutions • Why as well as how • Code Examples Defini&on Patterns Source: https://martinfowler.com/articles/writingPatterns.html
Architecture Commands Events • Requests (intent) to do something • Named in the impera)ve, e.g. “CREATE” • Can be rejected • Higher coupling between sender and owner • Typically used in synchronous 1-to-1 request/response communicaEon • Something that has happened (a fact) • Named in past tense, e.g. “CREATED” • Cannot (semantically) be rejected by receiver • Lowest coupling between sender and owner • Asynchronous 1-to-many communication, e.g. publish/subscribe
API Server CREATE apiVersion: extensions/v1beta1 kind: ReplicaSet spec: replicas: 2 CREATE Pod ReplicaSet CREATED ReplicaSet Controller BIND Pod Pod CREATED Scheduler Kubelet Pod BOUND UPDATE Pod (“running”) Time Command Event
(assume) Order • Single Responsible Principle • Decoupling via event-driven Messaging • No central Coordinator A different Mindset Writing Controllers Autonomous Processes Concurrency & Asynchrony
• In-memory Cache via Reconciliation • Eventual consistent by Design • Don’t rely on (assume) Order • Single Responsible Principle • Decoupling via event-driven Messaging • No central Coordinator A different Mindset Writing Controllers Autonomous Processes Concurrency & Asynchrony Stateless over Stateful
(wall) Clock • Anticipate Effects on the Rest of the System • API server (etcd) is the Source of Truth* • In-memory Cache via Reconciliation • Eventual consistent by Design • Don’t rely on (assume) Order • Single Responsible Principle • Decoupling via event-driven Messaging • No central Coordinator A different Mindset Writing Controllers Autonomous Processes Concurrency & Asynchrony Stateless over Stateful Defensive Programming
Things will go wrong (crash) • No shared (wall) Clock • Anticipate Effects on the Rest of the System • API server (etcd) is the Source of Truth* • In-memory Cache via Reconciliation • Eventual consistent by Design • Don’t rely on (assume) Order • Single Responsible Principle • Decoupling via event-driven Messaging • No central Coordinator A different Mindset Writing Controllers Autonomous Processes Concurrency & Asynchrony Stateless over Stateful Side Effects Defensive Programming
changes to the specific values on the server. It's difficult for clients to structure their logic if they need to poll the server conbnuously to look for changes. If clients open too many connecbons to the server for watching changes, it can overwhelm the server. Problem State Watch Pattern
their interest with the server for specific state changes. The server nobfies the interested clients when state changes happen. The client maintains a Single Socket Channel with the server. The server sends state change nobficabons on this channel. Solution State Watch Pattern
miss Events e.g., during Downtime? • How to handle duplicate Events, such as when re-LISTING due to transient Network Errors? • How to reconcile Changes on external Resources that don’t support a WATCH mechanism? Considera&ons State Watch Pa-ern !
Distributed System • Building and operabng Distributed Systems is hard • Pagerns decompose complex Problems into understandable and reusable Solubons Recap 1/2
Loops provide Boundaries • Choreography and event-driven Integrabon unlock Extensibility and Autonomy • At the Cost of added Developer Complexity (Asynchrony and Eventual Consistency) • Consistent (replicated) Core, State Watch and Versioned Values for Durability, Availability, Scalability, and Consistency Recap 2/2