SlideShare a Scribd company logo

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

•
•
WSO2
WSO2

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

Related slideshows

API Microservices with Node.js and Docker
API Microservices with Node.js and DockerAPI Microservices with Node.js and Docker
API Microservices with Node.js and Docker
 
RethinkConn 2022!
RethinkConn 2022!RethinkConn 2022!
RethinkConn 2022!
 
We are Net3 Technology
We are Net3 TechnologyWe are Net3 Technology
We are Net3 Technology
 
1 of 47
Download to read offline
Cloud-Native Middleware: Domain Driven Design, Cell Based Architecture, Service Mesh, and more Lakmal Warusawithana Senior Director Cloud Architecture WSO2
Software Design and Modularity
● 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
Domain-driven design (DDD)
● 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
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
● 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
From Domain-Driven Design to Cloud-Native Deployment
Key Challenges in Transitioning from Domain-Driven Design to Cloud-Native Deployment 9
● Map bounded contexts into the deployment concepts Key Challenges in Transitioning from Domain-Driven Design to Cloud-Native Deployment 10
● Map bounded contexts into the deployment concepts ● Autonomous team operations Key Challenges in Transitioning from Domain-Driven Design to Cloud-Native Deployment 11
● 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
● 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
● 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
● 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
● 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
● 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
● 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
By combining the right architecture with cloud-native middleware, these challenges can be effectively overcome.
Reference Architecture
Reference Architecture 21 https://github.com/wso2/reference-architecture/blob/master/platformless.md
Cell-based architecture (CBA)
● 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
Cell-based architecture (CBA) 24
Cloud-Native Middleware
● 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
Cloud-Native Landscape 27
Reference Implementation (Choreo)
● 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 DDD and Dev time Deployment and Runtime Domain Foo S1 S2 Domain Bar S1 S2 S3
Key Vault 31 DDD and Dev time Project Foo Project Bar S2 S1 Domain Foo S1 S2 Domain Bar S1 S2 S3 S2 S3 S1 Deployment and Runtime Buildpacks Docker Registry Deployment Services Namespaces HPA ConfigMaps
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 S3 S1 Deployment and Runtime Buildpacks Deployment Services Namespaces HPA ConfigMaps Docker Registry Key Vault
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 AA Authn & Authz Deployment and Runtime Dev time Buildpacks Deployment Services Namespaces HPA ConfigMaps Docker Registry Key Vault
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 E Encrypted AA AA API GW AA Authn & Authz AA Deployment and Runtime Dev time Buildpacks Deployment Services Namespaces HPA ConfigMaps Docker Registry Key Vault
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 E Encrypted AA AA X L3/L4 Access Deny X L3/L4 Access Deny L3/L4 Access Deny API GW AA Authn & Authz AA Deployment and Runtime Dev time Buildpacks Deployment Services Namespaces HPA ConfigMaps Docker Registry Key Vault
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 E Encrypted AA AA X L3/L4 Access Deny X L3/L4 Access Deny L3/L4 Access Deny API GW AA Authn & Authz AA Deployment and Runtime Dev time Buildpacks Deployment Services Namespaces HPA ConfigMaps Docker Registry Key Vault
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 E Encrypted AA AA X L3/L4 Access Deny X L3/L4 Access Deny L3/L4 Access Deny API GW AA Authn & Authz AA Logs Logs Deployment and Runtime Dev time Buildpacks Deployment Services Namespaces HPA ConfigMaps Docker Registry Key Vault
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 E Encrypted AA AA X L3/L4 Access Deny X L3/L4 Access Deny L3/L4 Access Deny API GW AA Authn & Authz AA Logs Logs Metrics Metrics Deployment and Runtime Dev time Buildpacks Deployment Services Namespaces HPA ConfigMaps Docker Registry Key Vault
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 E Encrypted AA AA X L3/L4 Access Deny X L3/L4 Access Deny L3/L4 Access Deny API GW AA Authn & Authz AA Logs Logs Metrics Retry if 503 Deployment and Runtime Dev time Service Mesh Metrics Buildpacks Deployment Services Namespaces HPA ConfigMaps Docker Registry Key Vault
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 E Encrypted AA AA X L3/L4 Access Deny X L3/L4 Access Deny L3/L4 Access Deny API GW AA Authn & Authz AA Logs Logs Metrics Retry if 503 No request: scale to zero Deployment and Runtime Dev time Service Mesh Scale to zero Metrics Buildpacks Deployment Services Namespaces HPA ConfigMaps Docker Registry Key Vault
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 E Encrypted AA AA X L3/L4 Access Deny X L3/L4 Access Deny L3/L4 Access Deny API GW AA Authn & Authz AA Logs Logs Metrics Retry if 503 No request: scale to zero Deployment and Runtime Zero Trust Principals Service Mesh Scale to zero Metrics Buildpacks Deployment Services Namespaces HPA ConfigMaps Docker Registry Key Vault
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 E Encrypted AA AA X L3/L4 Access Deny X L3/L4 Access Deny L3/L4 Access Deny API GW AA Authn & Authz AA Logs Logs Metrics Retry if 503 No request: scale to zero Deployment and Runtime Revisit Challengers Service Mesh Scale to zero Metrics Buildpacks Deployment Services Namespaces HPA ConfigMaps Docker Registry Key Vault
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.
Platformless
● 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
Question Time! 46
Thank You!

More Related Content

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
  • 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.
  • 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
  • 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
  • 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 S3 S1 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 S3 S1 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 AA Authn & Authz Deployment and Runtime Dev 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 E Encrypted AA AA API GW AA Authn & Authz AA Deployment and Runtime Dev 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 E Encrypted AA AA X L3/L4 Access Deny X L3/L4 Access Deny L3/L4 Access Deny API GW AA Authn & Authz AA Deployment and Runtime Dev 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 E Encrypted AA AA X L3/L4 Access Deny X L3/L4 Access Deny L3/L4 Access Deny API GW AA Authn & Authz AA Deployment and Runtime Dev 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 E Encrypted AA AA X L3/L4 Access Deny X L3/L4 Access Deny L3/L4 Access Deny API GW AA Authn & Authz AA Logs Logs Deployment and Runtime Dev 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 E Encrypted AA AA X L3/L4 Access Deny X L3/L4 Access Deny L3/L4 Access Deny API GW AA Authn & Authz AA Logs Logs Metrics Metrics Deployment and Runtime Dev 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 E Encrypted AA AA X L3/L4 Access Deny X L3/L4 Access Deny L3/L4 Access Deny API GW AA Authn & Authz AA Logs Logs Metrics Retry if 503 Deployment and Runtime Dev 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 E Encrypted AA AA X L3/L4 Access Deny X L3/L4 Access Deny L3/L4 Access Deny API GW AA Authn & Authz AA Logs Logs Metrics Retry if 503 No request: scale to zero Deployment and Runtime Dev 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 E Encrypted AA AA X L3/L4 Access Deny X L3/L4 Access Deny L3/L4 Access Deny API GW AA Authn & Authz AA Logs Logs Metrics Retry if 503 No request: scale to zero Deployment and Runtime Zero 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 E Encrypted AA AA X L3/L4 Access Deny X L3/L4 Access Deny L3/L4 Access Deny API GW AA Authn & Authz AA Logs Logs Metrics Retry if 503 No request: scale to zero Deployment and Runtime Revisit 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.
  • 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