Download to read offline
Uploaded byWSO2
WSO2Con 2025 - Architecting Cloud-Native Applications
As enterprises modernise their technology stacks, designing platform-agnostic, scalable, and well-governed cloud-native architectures is essential for long-term success. This lab session will explore how to apply the platformless concept to build cloud-native applications that offer flexibility, portability, and resilience across diverse cloud environments. Through guided discussions and real-world insights, we will examine key architectural patterns, including microservices, API gateways, and Kubernetes orchestration, while addressing critical aspects such as scalability, governance, and operational efficiency. Join us to exchange ideas, refine best practices, and explore strategies for architecting cloud-native applications that are future-proof, scalable, and effectively governed.
More Related Content
Similar to WSO2Con 2025 - Architecting Cloud-Native Applications
![[Roundtable] Choreo - The AI-Native Internal Developer Platform as a Service](https://cdn.slidesharecdn.com/ss_thumbnails/choreo-deck-250328074645-511dded7-thumbnail.jpg?width=640&height=640&fit=bounds)
WSO2Con 2025 - Architecting Cloud-Native Applications
- 1. Architecting Cloud-Native Applications Chathura Kulasinghe SeniorLead - Solutions Engineer WSO2 Chintana Wilamuna VP Solutions Architecture WSO2
- 2. ● Application architecturepatterns - monolith/distributed/microservices ● Developing and managing microservices ● Cloud-native application architecture ● Brownfield/Greenfield app transformation to microservices ● Analyzing architecture trade-offs ● Practical cloud-native app example with Choreo Agenda 2
- 3.
- 4. ● Monolithic ○ Layered ○Pipes and filters ○ Microkernel ● Distributed ○ Service Oriented (SOA) ○ Event-driven ○ Space based architecture ○ Microservices Architecture patterns 4
- 5. Architecture patterns >Monolithic > Layered 5 Pros Easy to get started for simple projects Separation of concerns Lower complexity and cost at the beginning Cons Harder to scale Deployments and modifications are complex and expensive HA and fault tolerance is harder Image - https://herbertograca.com/2017/08/03/layered-architecture/
- 6. Architecture patterns >Monolithic > Pipes and filters 6 Pros Easy and simple to get started Comparatively higher modularity Easy to reuse components Cons Harder to scale Deployments and modifications are complex and expensive HA and fault tolerance is harder
- 7. Architecture patterns >Monolithic > Microkernel 7 Image - https://www.oreilly.com/library/view/software-architecture-patterns/9781098134280/ch04.html Pros Flexibility in adding dynamic functionality through plugins Plugins can have their own DB / schema (decoupled data architecture) Reduced scope in testing, can be isolated to each plugin Cons The core is still a monolith, harder to scale Deployments and modifications are complex and expensive HA and fault tolerance is harder
- 8. Architecture patterns >Distributed > SOA 8 Pros One of the easiest and simplest distributed architecture models Functionality is isolated and can be dev., test, deploy separately Easy to scale Cons Typically a lot more complexity due to standards A lot more error conditions due to services over network hops Interdependent services can be hard to debug Image - https://en.wikipedia.org/wiki/Service-oriented_architecture
- 9. Architecture patterns >Distributed > Event-driven 9 Pros Asynchronous comms give higher perf. and overall responsiveness Higher flexibility and extensibility Higher reliability - guaranteed delivery patterns Cons Harder to test HA and scalability of brokers are not simple Handling dynamic events is complex Image - https://developer.confluent.io/patterns/event-stream/event-broker/
- 10. Architecture patterns >Distributed > Spaced based architecture 10 Pros Can scale to handle high performance More responsive - Reads/Writes driven off of a cache Decoupled components Cons Complex and difficult testing process Complicated architecture Higher costs to maintain a system with this high complexity Image - https://en.wikipedia.org/wiki/Space-based_architecture
- 11. Architecture patterns >Distributed > Microservices 11 Pros Often with bounded contexts, clear separation of concerns Data isolation Easy to scale Cons Testing and debugging is harder Integration points between services can become harder to manage Increased cost and communication overhead Image - https://microservices.io/patterns/microservices.html
- 12. Fundamentals of developingand managing microservices
- 13. Design Patterns forMicroservices 13 https://www.linkedin.com/pulse/microservices-design-patterns-pranav-kumar-dwivedi/
- 14.
- 15. Challenges in managingmicroservices 15 ● Packaging microservices - Containers ● Testing - A/B, Blue-Green, Canary ● Version management ● Configuration management ● Scaling ● Discovering services and endpoints ● Monitoring
- 16.
- 17. What is CloudNative? “Cloud-native architecture and technologies are an approach to designing, constructing, and operating workloads that are built in the cloud and take full advantage of the cloud computing model.” 17 Source: https://learn.microsoft.com/en-us/dotnet/architecture/cloud-native/definition https://wso2.com/choreo/resources/building-a-cloud-native-twelve-factor-app-on-choreo-just-write-the-code/
- 18. 18 Cloud Native ApplicationDesign Cloud-native architecture harnesses cloud benefits through key practices: ● Microservices: Splits apps into small services for flexible scaling and maintenance. ● Containers/Orchestration: Ensures consistent environments and automates operations with tools like Kubernetes. ● Immutable Infrastructure: Uses replaceable components for reliability, avoiding direct changes. ● Declarative APIs: Defines desired states, ensuring consistent application behavior. ● Stateless Design: Improves scalability and fault tolerance; stores state externally for better load management. Above practices enable resilient, scalable, and manageable cloud applications, optimizing deployment and operations.
- 19. What is acloud native application and what are the benefits? ● Cloud native apps are specifically designed and built to run on cloud computing platforms by using technologies that are optimized for the cloud environment. ● These apps gain benefits of the cloud including ⦿ Scalability: Ability to scale up and down as needed ⦿ Resiliency: Can continue to function event if individual components fail ⦿ Flexibility: Can be deployed in any environment and easily integrated with other services and apps ⦿ Faster time-to-market: Modular, containerized architecture makes it easier to develop, test, and deploy new features. ⦿ Cost-effective: You only have to pay for resources that you use 19
- 20. Typical brown fieldapp transformation Centralized Decentralized 20
- 21. Typical brown fieldapp transformation 21 Decentralized Centralized Cell Based Architecture - https://github.com/wso2/reference-architecture/blob/master/reference-architecture-cell-based.md
- 22.
- 23. A typical pathof a cloud native application ● They face several challenges along the way: ⦿ Challenge 1: Technology complexity ⦿ Challenge 2: Hard to find technical resources ⦿ Challenge 3: Slow to go-to-market ● The organization must now make a decision ⦿ Continue to build a platform on their own ⦿ Buy a ready made platform with all the tools they need 23
- 24.
- 25. ● Use case- Hotel Reservation System ○ Room reservation ○ Room search ○ Cancel reservation Application Architecture - Analyzing trade-offs 25
- 26. Analyzing trade-offs >Room reservation 26
- 27. Analyzing trade-offs >Room reservation 27
- 28. Trade off analysisat a granular level 28 ● REST vs GraphQL vs gRPC ● Choosing data storage options ○ MySQL, MongoDB, Cassandra ○ GCP - Bigtable, Datastore, Firestore, Spanner, AlloyDB ● Federated GraphQL API for all services of my enterprise
- 29. Still a lotof things left to think about as a architect/developer ● Endpoint management ● Secret management ● Endpoint/API credentials / authentication ● User authentication and authorization ● …
- 30. Tooling make lifeeasy … or does it? 30
- 31. Focusing on addingbusiness value
- 32. 32 ● Runtime architecture,CI/CD, DevOps, environments, SecOps, configuration management, version management, testing, observability, analytics, and SRE ● New features in development needs re-use of existing code/libs/APIs ● DevOps goes to Blue/Green, etc. ● Self-service and policy-driven ● Zero-trust environment Only digital natives have software manufacturing down to a science; all others are struggling. Develope r GitHub Digital Experience B2B Employee Consumer Customer Because manufacturing software in the cloud-native era is very hard You write code. You want to get it to the hands of the customer ASAP.
- 33. Enterprises should focuson engineering applications, not platforms 33
- 34.
- 35. Let’s build it(practical session)
- 36. Demo: Building HotelReservation System 36
- 37. “The Luxury Hotelwants to build a reservation system for the public website” Room Search: Users can find rooms by entering check-in and check-out dates and can apply filters based on the guest count. Room Reservation: With requires entering personal details (full name, contact number, email) Update Reservations: Users can change their booking dates Cancel Reservations: Offers an easy option for users to cancel their bookings at any time. Use case 37 Please refer to the instructions guide for more details. https://github.com/wso2con/2025-BCN-choreo-tutorial-1
- 38. UX 38 Customer “Gain Access toHotel Data” “Browse available rooms based on requirement or preferences criteria” “Reserve/Cancel/Rebook a room” “Receive confirmation(s) in email” Login, Smooth onboarding Experience. Search capability. Custom querying capabilities. Efficient & Fast. Modify records, provide controlled access to hotel data. Trigger notifications Frontend Application (UI) Backend for Frontend (API) Domain Services (APIs) System APIs, Triggers Systems of Record External Services Security
- 39. UX 39 Customer “Gain Access toHotel Data” “Browse available rooms based on requirement or preferences criteria” “Reserve/Cancel/Rebook a room” “Receive confirmation(s) in email” ReactJS (Frontend Application (UI)) GraphQL (Backend for Frontend (API)) SpringBoot Domain Services (APIs) Python ( Triggers) MySQL Database (Systems of Record) Azure Comm’ Services. Kafka (External Services) Asgardeo (Security) Our example: Login, Smooth onboarding Experience. Search capability. Custom querying capabilities. Efficient & Fast. Modify records, provide controlled access to hotel data. Trigger notifications
- 40. 40 Customer Organization = luxuryhotel GraphQL (Backendfor Frontend (API)) Project = HotelReservation MySQL Database (Systems of Record) Project Gateway ReactJS (Frontend Application (UI))
- 41. 41 Customer GraphQL (Backend for Frontend (API)) SpringBoot Domain/Experience API Project= HotelReservation MySQL Database (Systems of Record) Kafka (External Services) Project Gateway Organization = luxuryhotel ReactJS (Frontend Application (UI))
- 42. 42 Customer ReactJS (Frontend Application (UI)) GraphQL (Backend for Frontend(API)) SpringBoot Domain/Experience API Project = HotelReservation MySQL Database (Systems of Record) Kafka (External Services) Project Gateway Organization = luxuryhotel
- 43. 43 Customer ReactJS (Frontend Application (UI)) GraphQL (Backend for Frontend(API)) SpringBoot Domain/Experience API Project = HotelReservation dependency: Connection (Project-INTERNAL) dependency: Connection (Project-INTERNAL) MySQL Database (Systems of Record) Kafka (External Services) Project Gateway Organization = luxuryhotel
- 44. 44 Customer ReactJS (Frontend Application (UI)) GraphQL (Backend for Frontend(API)) SpringBoot Domain/Experience API Project = HotelReservation dependency: Connection (Project-INTERNAL) dependency: Connection (Project-INTERNAL) MySQL Database (Systems of Record) Python ( Triggers) Kafka (External Services) Azure Comm’ Services (External Services) Project Gateway Organization = luxuryhotel
- 45. 45 Customer ReactJS (Frontend Application (UI)) Identity Provider (Asgardeo- luxuryhotel) Client ID & Secret Callback (signed in) Route (sign in) GraphQL (Backend for Frontend (API)) SpringBoot Domain/Experience API Project = HotelReservation dependency: Connection (Project-INTERNAL) dependency: Connection (Project-INTERNAL) MySQL Database (Systems of Record) Python ( Triggers) Kafka (External Services) Azure Comm’ Services (External Services) Project Gateway Organization = luxuryhotel
- 46. 46 Customer Organization = luxuryhotel Customeraccount Standard Based Application Login Flow with SSO, Multifactor, Adaptive Authentication. Username/ Password, Social Login Client ID & Secret ReactJS (Frontend Application (UI)) Identity Provider (Asgardeo - luxuryhotel) Client ID & Secret Callback (signed in) Route (sign in)
- 47.
- 48.
- 49.
Editor's Notes
- #5 Twitter - Started out as a Ruby on Rails app Cloudflare - Started as a collection of stored procedures written on top of a PostgresDB
- #6 Synapse is a good example here
- #7 Carbon is a good example
- #8 Carbon is a good example
- #9 2 main methods - Broker method and event coordinator (BPEL)
- #10 2 main methods - Broker method and event coordinator (BPEL)
- #11 2 main methods - Broker method and event coordinator (BPEL)
- #13 Lakmal’s talk on how to go from DDD to cell
- #14 Lakmal’s talk on how to go from DDD to cell
- #17 Dynamic compute Pay per use
- #21 Can use strangler pattern here - Incrementally migrate feature by feature to microservices until ultimately ever feature is written/refactored as a microservice
- #23 Complexity: The infrastructure, products and tools needed to build cloud native app is complex Hard to find technical resources: Technically diverse teams of technical resources are needed to manage and maintain the infrastructure, products and tooling. Lack of visibility into developer team productivity / activities. Cognitive load, multiple clouds, high learning curve. Slow to go-to-market: Technology is constantly evolving. Teams are too slow to keep up with this while delivering apps at the speed of business initiatives, resulting in delayed or missed opportunities. These challenges defeat the purpose of moving to cloud native app development if you are trying to build these by yourselves.
- #25 There are no best practices, best practices depends on the use case Always it’s about trade-offs in the face of specific constraints and business requirements
- #26 Best practices doesn’t help much here
- #28 Depends on multiple factors What is the expected latency and performance requirements? What’s the expected reusability? Multiple mobile apps, web apps, services etc…
- #33 Enterprise IT's focus on platform maintenance overshadows application development, where real value lies A mindshare shift is needed: from platform-centric to application-centric, prioritizing innovation over infrastructure Such a shift reallocates people to drive business value, enabling tech roles to focus on delivering solutions, not just supporting systems.
- #40 <button onClick={() => {window.location.href="/auth/login?fidp=myfederatedidp"}}>Login</button> import Cookies from 'js-cookie'; // Read userinfo cookie value. const encodedUserInfo = Cookies.get('userinfo') // Decode the value. const userInfo = JSON.parse(atob(encodedUserInfo)) // Store the value in a preferred browser-based storage if needed. // Clear the cookie. Cookies.remove('userinfo', { path: <post-login-path> }) const response = await fetch('/auth/userinfo') <button onClick={async () => { window.location.href = `/auth/logout?session_hint=${Cookies.get('session_hint')}`; }}>Logout</button>`
- #41 <button onClick={() => {window.location.href="/auth/login?fidp=myfederatedidp"}}>Login</button> import Cookies from 'js-cookie'; // Read userinfo cookie value. const encodedUserInfo = Cookies.get('userinfo') // Decode the value. const userInfo = JSON.parse(atob(encodedUserInfo)) // Store the value in a preferred browser-based storage if needed. // Clear the cookie. Cookies.remove('userinfo', { path: <post-login-path> }) const response = await fetch('/auth/userinfo') <button onClick={async () => { window.location.href = `/auth/logout?session_hint=${Cookies.get('session_hint')}`; }}>Logout</button>`
- #42 <button onClick={() => {window.location.href="/auth/login?fidp=myfederatedidp"}}>Login</button> import Cookies from 'js-cookie'; // Read userinfo cookie value. const encodedUserInfo = Cookies.get('userinfo') // Decode the value. const userInfo = JSON.parse(atob(encodedUserInfo)) // Store the value in a preferred browser-based storage if needed. // Clear the cookie. Cookies.remove('userinfo', { path: <post-login-path> }) const response = await fetch('/auth/userinfo') <button onClick={async () => { window.location.href = `/auth/logout?session_hint=${Cookies.get('session_hint')}`; }}>Logout</button>`
- #43 <button onClick={() => {window.location.href="/auth/login?fidp=myfederatedidp"}}>Login</button> import Cookies from 'js-cookie'; // Read userinfo cookie value. const encodedUserInfo = Cookies.get('userinfo') // Decode the value. const userInfo = JSON.parse(atob(encodedUserInfo)) // Store the value in a preferred browser-based storage if needed. // Clear the cookie. Cookies.remove('userinfo', { path: <post-login-path> }) const response = await fetch('/auth/userinfo') <button onClick={async () => { window.location.href = `/auth/logout?session_hint=${Cookies.get('session_hint')}`; }}>Logout</button>`
- #44 <button onClick={() => {window.location.href="/auth/login?fidp=myfederatedidp"}}>Login</button> import Cookies from 'js-cookie'; // Read userinfo cookie value. const encodedUserInfo = Cookies.get('userinfo') // Decode the value. const userInfo = JSON.parse(atob(encodedUserInfo)) // Store the value in a preferred browser-based storage if needed. // Clear the cookie. Cookies.remove('userinfo', { path: <post-login-path> }) const response = await fetch('/auth/userinfo') <button onClick={async () => { window.location.href = `/auth/logout?session_hint=${Cookies.get('session_hint')}`; }}>Logout</button>`
- #45 <button onClick={() => {window.location.href="/auth/login?fidp=myfederatedidp"}}>Login</button> import Cookies from 'js-cookie'; // Read userinfo cookie value. const encodedUserInfo = Cookies.get('userinfo') // Decode the value. const userInfo = JSON.parse(atob(encodedUserInfo)) // Store the value in a preferred browser-based storage if needed. // Clear the cookie. Cookies.remove('userinfo', { path: <post-login-path> }) const response = await fetch('/auth/userinfo') <button onClick={async () => { window.location.href = `/auth/logout?session_hint=${Cookies.get('session_hint')}`; }}>Logout</button>`
- #46 <button onClick={() => {window.location.href="/auth/login?fidp=myfederatedidp"}}>Login</button> import Cookies from 'js-cookie'; // Read userinfo cookie value. const encodedUserInfo = Cookies.get('userinfo') // Decode the value. const userInfo = JSON.parse(atob(encodedUserInfo)) // Store the value in a preferred browser-based storage if needed. // Clear the cookie. Cookies.remove('userinfo', { path: <post-login-path> }) const response = await fetch('/auth/userinfo') <button onClick={async () => { window.location.href = `/auth/logout?session_hint=${Cookies.get('session_hint')}`; }}>Logout</button>`