A summary of common Cloud Native design patterns using the AWS Build blocks.

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!