Cloud Native Patterns Using AWS
1 like230 views
This document discusses cloud native patterns using AWS. It defines cloud native as architectures that take advantage of cloud capabilities to build scalable applications in dynamic environments. The document outlines characteristics of cloud native applications like being disposable, isolated, globally scalable, and developed by self-sufficient teams. It then describes foundation patterns like having one database per component, using event streaming, event sourcing, data lakes, and trilateral APIs. It also covers boundary patterns such as API gateways, CQRS, backend for frontends, and external service gateways. Finally, it discusses control patterns involving event collaboration and orchestration and provides examples of relevant AWS building blocks.
Cloud Native Patterns Using AWS
- 1. Cloud Native Patterns Using AWS Practical Examples
- 2. What means to be “Cloud Native” Cloud Native architectures take advantage of what Cloud has to offer empowering organisations to build and run scalable applications in modern, dynamic environments such as public, private, and hybrid clouds (CNCF Definition). $ > ”It means to be designed for the cloud from day one.”
- 3. Cloud Native characteristics - We should be able to create, destroy and recreate at any time (i.e. disposable infrastructure) - We should be able to deploy, update, replace and scale it individually (i.e. bounded isolated components) - We should be able to run it in multiples regions (i.e. scales globally) - It should be able easy to design, redesign or make experimentations (i.e. disposable architecture) - A single team should be able to architect, provision the infrastructure, implement and monitor a component (i.e. self-sufficient full-stack teams) - Deployments are decoupled from releases (i.e. it drives a cultural change)
- 4. Foundation patterns - FP - FP1: One Database per component - FP2: Event Streaming - FP3: Event Sourcing - FP4: Data Lake - FP5: Trilateral API
- 5. Boundary patterns - BP - BP1: API Gateway - BP2: Command Query Responsibility Segregation - BP3: Backend for Frontend - BP4: External Service Gateway
- 6. Control patterns - CP - CP1: Event collaboration - CP2: Event orchestration
- 7. AWS Building Blocks - Route 53 - API Gateway - AWS Lambda - RDS - Kinesis - S3 - Elastic Search - Elasticache - SNS
- 8. FP1: One Database per component • Database type matching the component’s needs (polyglot persistence) • Database is not shared between components • Change data capture (CDC) triggering intra- component processing • Some cloud DB offer cross-region replication
- 9. FP2: Event Streaming • Enable inter-component asynchronous message-driven communication • Multiples streams for different purposes: • Log stream • Back-office stream • Front-office stream
- 10. FP3: Event Sourcing • Changes in state of domain entities results in atomic immutable domain-event • We should be able to recreate the state from the event history • Upstream components don’t know/care about the downstream components. • Downstream components don’t know/care who/how the event was generated
- 11. FP4: Data Lake • All events are collected, stored and indexed in raw format • High durability supporting auditing, searching, replay, and analytics • All streamed event eventually run into the Data Lake
- 12. FP5: Trilateral API • Teams should document and publish the Trilateral API of each component • Any change must be backwards compatible • Tests must ensure no breaking changes • Pub/Sub streams for asynchronous inter- component communication • Command/query for synchronous communication with the external world
- 13. BP1: API Gateway • Exposes the component to the external world • Decouples business concerns from cross- cutting concerns like subscriptions, quotas, security, DDoS, DNS routing (treated by other components/services)
- 14. BP2: Command Query Responsibility Segregation • Command and queries have different requirements (cpu / memory / throughput) • Each component has it own database but it is blocked from generate join queries • CQRS consumes state change events from upstream components and maintain materialised views that support queries used within the component
- 15. BP3: Backend for Frontend • The Front-end is a product that can touches the backend • Dedicated self-sufficient backend components supports user-focused features • GraphQL to support multiple device formats in a single BFF • Teams have the full control over their feature across the full-stack
- 16. BP4: External Service Gateway • Integrates with external systems • Bridge between different systems or regions • Decouples business concerns from cross- cutting concerns like subscriptions, quotas, security, external service authentication,…)
- 17. CP1: Event collaboration • Domain events triggers downstream commands • A reactive chain of collaboration across multiples components
- 18. CP2: Event Orchestration • The inners of the event define the next step in the chain • Mediators can control how the collaboration between components going to work • It makes possible to build complex process rules like workflows
- 19. References
- 20. Thank you!