WSO2CON 2024 - Cloud Native Middleware: Domain-Driven Design, Cell-Based Architecture, Service Mesh, and More

WSO2CON 2024 - Cloud Native Middleware: Domain-Driven Design, Cell-Based Architecture, Service Mesh, and More

1. Cloud-Native Middleware:
Domain Driven Design, Cell Based
Architecture, Service Mesh, and
more
Lakmal Warusawithana
Senior Director Cloud Architecture
WSO2

2. Software Design and Modularity

3. ●Modularity, a fundamental principle in software design, plays a crucial role
in making software manageable and maintainable.

●It involves breaking down a system into smaller, manageable, and
interchangeable components or modules. Each module is designed to
execute one specific aspect of the desired functionality and interacts with
other modules through well-defined interfaces.

Modularity
3

4. Domain-driven design (DDD)

5. ●Domain-Driven Design (DDD) is a methodology for software design that
involves creating detailed models to capture the business requirements of
a specific domain. These models form the conceptual basis for software
development.

●DDD helps us build a microservice architecture by splitting a big system
into smaller, independent parts. We figure out what each part does and
how they connect to each other.

Domain-driven design (DDD)
5

6. Domain-Driven Design for microservices
6
●Strategic phase: identify the Bounded Contexts and map them out in a
context map




●Tactical phase: model each Bounded Context according to the business
rules of the subdomain.

●DDD is iterative and adaptive.
Analyze Domain
Define Bounded
Contexts
Identify
Microservices

7. ●Domain-Driven Design: Tackling Complexity in the Heart of Software by
Eric Evans
●Implementing Domain-Driven Design by Vaughn Vernon
●Domain-Driven Design Distilled by Vaughn Vernon
Learn more about Domain-Driven Design
7

8. From Domain-Driven Design to
Cloud-Native Deployment

9. Key Challenges in Transitioning from Domain-Driven Design to
Cloud-Native Deployment
9

10. ●Map bounded contexts into the deployment concepts

Key Challenges in Transitioning from Domain-Driven Design to
Cloud-Native Deployment
10

11. ●Map bounded contexts into the deployment concepts
●Autonomous team operations

Key Challenges in Transitioning from Domain-Driven Design to
Cloud-Native Deployment
11

12. ●Map bounded contexts into the deployment concepts
●Autonomous team operations
●Dependency management
Key Challenges in Transitioning from Domain-Driven Design to
Cloud-Native Deployment
12

13. ●Map bounded contexts into the deployment concepts
●Autonomous team operations
●Dependency management
●Service discovery and governance
Key Challenges in Transitioning from Domain-Driven Design to
Cloud-Native Deployment
13

14. ●Map bounded contexts into the deployment concepts
●Autonomous team operations
●Dependency management
●Service discovery and governance
●Complexity in scaling and resiliency
Key Challenges in Transitioning from Domain-Driven Design to
Cloud-Native Deployment
14

15. ●Map bounded contexts into the deployment concepts
●Autonomous team operations
●Dependency management
●Service discovery and governance
●Complexity in scaling and resiliency
●Infrastructure automation and frequence release management
Key Challenges in Transitioning from Domain-Driven Design to
Cloud-Native Deployment
15

16. ●Map bounded contexts into the deployment concepts
●Autonomous team operations
●Dependency management
●Service discovery and governance
●Complexity in scaling and resiliency
●Infrastructure automation and frequence release management
●Security implications
Key Challenges in Transitioning from Domain-Driven Design to
Cloud-Native Deployment
16

17. ●Map bounded contexts into the deployment concepts
●Autonomous team operations
●Dependency management
●Service discovery and governance
●Complexity in scaling and resiliency
●Infrastructure automation and frequence release management
●Security implications
●Observability and monitoring

Key Challenges in Transitioning from Domain-Driven Design to
Cloud-Native Deployment
17

18. ●Map bounded contexts into the deployment concepts
●Autonomous team operations
●Dependency management
●Service discovery and governance
●Complexity in scaling and resiliency
●Infrastructure automation and frequence release management
●Security implications
●Observability and monitoring
●Infrastructure/cloud cost
Key Challenges in Transitioning from Domain-Driven Design to
Cloud-Native Deployment
18

19. By combining the right architecture
with cloud-native middleware, these
challenges can be effectively
overcome.

20. Reference Architecture

21. Reference Architecture
21
https://github.com/wso2/reference-architecture/blob/master/platformless.md

22. Cell-based architecture (CBA)

23. ●A Decentralized Reference Architecture for Cloud-native Applications by
Asanka Abeysinghe, CTO @WSO2 and Paul Fremantle, founder CTO
@WSO2
●Cell-based Architecture (CBA) and Domain-Driven Design (DDD) align well
together.
●CBA is an approach for modularizing a group of related capabilities from
(part of) a domain into a network cell and managing access to them
through well-defined gateways.
Cell-based architecture (CBA)
23
https://github.com/wso2/reference-architecture/blob/master/reference-architecture-cell-based.md

24. Cell-based architecture (CBA)
24

25. Cloud-Native Middleware

26. ●Cloud-native middleware is a software or set of software tools that
provide common services and capabilities to applications beyond those
offered by the underlying cloud infrastructure.
●It is designed to support scalability, resilience, maintainability, and
observability in cloud-native environments.
●This middleware integrates seamlessly with cloud services and caters to
the dynamic nature of cloud-native applications, enabling them to
communicate efficiently, scale, and adapt to changing demands without
compromising performance or security.
●Additionally, it includes features for monitoring and observing application
behavior, which is crucial for troubleshooting and optimizing performance.
Cloud-Native Middleware
26

27. Cloud-Native Landscape
27

28. Reference Implementation
(Choreo)

29. ●Github
●Github Runners
●Docker
●Trivy Scanner
●Buildpacks
●Kubernetes
●Key Vault
●API Gateway
●eBPF
●Cilium Service Mesh
Cloud-Native Middleware used in Choreo Implementation
29
●Cilium CNI
●Wireguard
●Hubble
●Envoy
●Prometheus
●Opensearch
●FluentBit
●Keda

30. 30
DDD and Dev time Deployment and Runtime
Domain Foo
S1
S2
Domain Bar
S1
S2
S3

31. Key Vault
31
DDD and Dev time
Project Foo Project Bar
S2
S1
Domain Foo
S1
S2
Domain Bar
S1
S2
S3
S2
S3S1
Deployment and Runtime
Buildpacks
Docker Registry
Deployment
Services
Namespaces
HPA
ConfigMaps

32. 32
Dev time
Project Foo Project Bar
S2
S1
Foo
●S1 need to expose to
public
●S1−>S2
Bar
●S2 need to expose to
public
●S2−>S3


Cross Domain
●Foo/S2−>Bar/S1
●Service Discovery


Security
●Authentication and
Authorization
●All network call need to
be encrypted
●Allow only defined
network communication
and deny all others.

S2
S3S1
Deployment and Runtime
Buildpacks
Deployment
Services
Namespaces
HPA
ConfigMaps
Docker Registry
Key Vault

33. 33
Project Foo Project Bar
S2
S1
S1
S2
S3
Foo
●S1 need to expose to
public
●S1−>S2
Bar
●S2 need to expose to
public
●S2−>S3


Cross Domain
●Foo/S2−>Bar/S1
●Service Discovery


Security
●Authentication and
Authorization
●All network call need to
be encrypted
●Allow only defined
network communication
and deny all others.

API GW
API GW
API GW
API GW
AA AA
AA
AAAuthn & Authz
Deployment and RuntimeDev time
Buildpacks
Deployment
Services
Namespaces
HPA
ConfigMaps
Docker Registry
Key Vault

34. 34
Project Foo Project Bar
S2
S1
S1
S2
S3
Foo
●S1 need to expose to
public
●S1−>S2
Bar
●S2 need to expose to
public
●S2−>S3


Cross Domain
●Foo/S2−>Bar/S1
●Service Discovery


Security
●Authentication and
Authorization
●All network call need to
be encrypted
●Allow only defined
network communication
and deny all others.

API GW
API GW
API GW
E
E
E
E
E
E
EEncrypted
AA AA
API GW
AAAuthn & Authz
AA
Deployment and RuntimeDev time
Buildpacks
Deployment
Services
Namespaces
HPA
ConfigMaps
Docker Registry
Key Vault

35. 35
Project Foo Project Bar
S2
S1
S1
S2
S3
Foo
●S1 need to expose to
public
●S1−>S2
Bar
●S2 need to expose to
public
●S2−>S3


Cross Domain
●Foo/S2−>Bar/S1
●Service Discovery


Security
●Authentication and
Authorization
●All network call need to
be encrypted
●Allow only defined
network
communication and
deny all others.

API GW
API GW
API GW
E
E
E
E
E
E
EEncrypted
AA AA
X
L3/L4
Access
Deny
X
L3/L4
Access
Deny
L3/L4 Access
Deny API GW
AAAuthn & Authz
AA
Deployment and RuntimeDev time
Buildpacks
Deployment
Services
Namespaces
HPA
ConfigMaps
Docker Registry
Key Vault

36. 36
Project Foo Project Bar
S2
S1
S1
S2
S3
Observability
●Logs: access, debugs
etc
●System metrics:
memory, cpu etc
●Runtime metrics:
network traces, request
counts, latency, errors
etc


Service Mesh
●Resiliency: retry, circuit
breaker etc

Serverless
●Scale to zero

API GW
API GW
API GW
E
E
E
E
E
E
EEncrypted
AA AA
X
L3/L4
Access
Deny
X
L3/L4
Access
Deny
L3/L4 Access
Deny API GW
AAAuthn & Authz
AA
Deployment and RuntimeDev time
Buildpacks
Deployment
Services
Namespaces
HPA
ConfigMaps
Docker Registry
Key Vault

37. 37
Project Foo Project Bar
S2
S1
S1
S2
S3
Observability
●Logs: access, debugs
etc
●System metrics:
memory, cpu etc
●Runtime metrics:
network traces, request
counts, latency, errors
etc


Service Mesh
●Resiliency: retry, circuit
breaker etc

Serverless
●Scale to zero

API GW
API GW
API GW
E
E
E
E
E
E
EEncrypted
AA AA
X
L3/L4
Access
Deny
X
L3/L4
Access
Deny
L3/L4 Access
Deny API GW
AAAuthn & Authz
AA
Logs
Logs
Deployment and RuntimeDev time
Buildpacks
Deployment
Services
Namespaces
HPA
ConfigMaps
Docker Registry
Key Vault

38. 38
Project Foo Project Bar
S2
S1
S1
S2
S3
Observability
●Logs: access, debugs
etc
●System metrics:
memory, cpu etc
●Runtime metrics:
network traces, request
counts, latency, errors
etc


Service Mesh
●Resiliency: retry, circuit
breaker etc

Serverless
●Scale to zero

API GW
API GW
API GW
E
E
E
E
E
E
EEncrypted
AA AA
X
L3/L4
Access
Deny
X
L3/L4
Access
Deny
L3/L4 Access
Deny API GW
AAAuthn & Authz
AA
Logs
Logs
Metrics
Metrics
Deployment and RuntimeDev time
Buildpacks
Deployment
Services
Namespaces
HPA
ConfigMaps
Docker Registry
Key Vault

39. 39
Project Foo Project Bar
S2
S1
S1
S2
S3
Observability
●Logs: access, debugs
etc
●System metrics:
memory, cpu etc
●Runtime metrics:
network traces, request
counts, latency, errors
etc


Service Mesh
●Resiliency: retry, circuit
breaker etc

Serverless
●Scale to zero

API GW
API GW
API GW
E
E
E
E
E
E
EEncrypted
AA AA
X
L3/L4
Access
Deny
X
L3/L4
Access
Deny
L3/L4 Access
Deny API GW
AAAuthn & Authz
AA
Logs
Logs
Metrics
Retry
if 503
Deployment and RuntimeDev time
Service Mesh
Metrics
Buildpacks
Deployment
Services
Namespaces
HPA
ConfigMaps
Docker Registry
Key Vault

40. 40
Project Foo Project Bar
S2
S1
S1
S2
S3
Observability
●Logs: access, debugs
etc
●System metrics:
memory, cpu etc
●Runtime metrics:
network traces, request
counts, latency, errors
etc


Service Mesh
●Resiliency: retry, circuit
breaker etc

Serverless
●Scale to zero

API GW
API GW
API GW
E
E
E
E
E
E
EEncrypted
AA AA
X
L3/L4
Access
Deny
X
L3/L4
Access
Deny
L3/L4 Access
Deny API GW
AAAuthn & Authz
AA
Logs
Logs
Metrics
Retry
if 503
No request:
scale to zero
Deployment and RuntimeDev time
Service Mesh
Scale to
zero
Metrics
Buildpacks
Deployment
Services
Namespaces
HPA
ConfigMaps
Docker Registry
Key Vault

41. 41
Project Foo Project Bar
S2
S1
S1
S2
S3
●Never Trust, Always
Verify
●Verify Explicitly
●Least Privilege Access
●Micro-Segmentation
●Layered Security
Controls and MFA
●Assume Breach
●End-to-End Encryption
●Full User and System
Visibility

API GW
API GW
API GW
E
E
E
E
E
E
EEncrypted
AA AA
X
L3/L4
Access
Deny
X
L3/L4
Access
Deny
L3/L4 Access
Deny API GW
AAAuthn & Authz
AA
Logs
Logs
Metrics
Retry
if 503
No request:
scale to zero
Deployment and RuntimeZero Trust Principals
Service Mesh
Scale to
zero
Metrics
Buildpacks
Deployment
Services
Namespaces
HPA
ConfigMaps
Docker Registry
Key Vault

42. 42
Project Foo Project Bar
S2
S1
S1
S2
S3
●Map bounded contexts
into the deployment
concepts
●Autonomous team
operations
●Dependency
management
●Service discovery and
governance
●Complexity in scaling
and resiliency
●Infrastructure
automation frequence
release management
●Security Implications
●Observability,
Monitoring and
Maintenance
●Infrastructure/cloud
cost

API GW
API GW
API GW
E
E
E
E
E
E
EEncrypted
AA AA
X
L3/L4
Access
Deny
X
L3/L4
Access
Deny
L3/L4 Access
Deny API GW
AAAuthn & Authz
AA
Logs
Logs
Metrics
Retry
if 503
No request:
scale to zero
Deployment and RuntimeRevisit Challengers
Service Mesh
Scale to
zero
Metrics
Buildpacks
Deployment
Services
Namespaces
HPA
ConfigMaps
Docker Registry
Key Vault

43. After building this platform, you'll
streamline the development process,
enhance productivity, and accelerate
time-to-market, all of which are
essential for business success.

44. Platformless

45. ●Platformless by Sanjiva, Paul and Asanka
●Cell-Based Architecture by Paul and Asanka
●Unlocking the Power of Programmable Data Planes in Kubernetes with
eBPF by Lakmal
●How We Implemented Zero Trust in Choreo by Lakmal
●Scaling Smart: Introducing Choreo’s Scale-to-Zero for Optimal Resource
Utilization by Lakmal
●Reference Architecture for a Cloud Native Digital Enterprise by Lakmal
●Reference Implementation for a Cloud Native Digital Enterprise by Lakmal
Read more…
45

46. Question Time!
46

47. Thank You!