The Shapes and Sizes of Cloud-Native Applications

The recent history of cloud-native development shows that applications have been designed and built with varying architectural styles and functional boundaries. This means that we can build cloud-native applications in various shapes and sizes. However, there doesn’t seem to be a single one-size-fits-all solution. So what shapes and sizes do we have, and for which purposes are they being applied?

After this session, attendees will be able to determine which architectural “shapes” they can use to build cloud-native applications “sized” to their projects. We will be covering concepts like monoliths, microservices, and… lasagna.

Transcript

1. The Shapes and Sizes of Cloud-Native Applications 26.09.2023
2. Edwin Derks • Principal Consultant with Team Rockstars IT • Loves solving complex, strategic IT challenges • Passionate about collecting and sharing knowledge • Adept with cloud-driven software development in general • Frequent Conference Speaker • Java Champion 26.09.2023
3. 26.09.2023 Shapes and Sizes of Cloud-Native Applications… What about it?
4. 26.09.2023 Burj Khalifa, Dubai • 828 meters tall • Concrete, steel and aluminium • Cost $ ~1.5 Billion Form Follows Function
5. 26.09.2023 my-application.war, Local Computer • 25MB • Bytecode • Cost $ …? Form Follows Function (?)
6. 26.09.2023 • We can determine the applications file size • We can determine how much resources the application consumes • We can determine how many features the application contains Both buildings and software are created with a certain architecture in mind. However… Software doesn’t have a physical form. Why do we care so much about its shape and size?
7. 26.09.2023 What kind of Shapes and Sizes of Cloud-Native Applications do we have?
8. 26.09.2023 Monolith Modulith Macrolith Microservice Nanoservice
9. 26.09.2023 Service Library Library Configuration Service View/Presentation Controller Model Data Access Persistence Ports & Adapters Domain Big Ball of Mud Lasagna Hexagonal
10. 26.09.2023 • Used for making architecture design and intentions clear What’s actually happening? Shapes • Describing amount of features • Describing internal complexity • Describing file size • Describing resource consumption Sizes
11. 26.09.2023 This is what happens in reality when discussing Shapes and Sizes
12. 26.09.2023
13. 26.09.2023
14. 26.09.2023
15. 26.09.2023 Y tho? What should we actually focus on?
16. 26.09.2023 The ideal shape follows the functional and technical purpose of the application, tuned to its environment Cloud-Native Capabilities 12-Factor Applications The result? More Shapes and Sizes!? Majestic Monolith Typical Microservice
17. 26.09.2023 What’s more important? Shape or Size? We want to build applications that fit perfectly cloud infrastructure; adhering to cloud-native principles Shape Size Developer Important Less Important Infrastructure Not Important Important
18. 26.09.2023 What are we looking for…? The perfect Shape for optimal Size
19. 26.09.2023 Never talk about these semantics again. They distract us from the actual reason we’re building software; delivering business value. We need the perfect Shape for development and the Ideal size for resource consumption. Let’s introduce the… My dream… Domain Service
20. 26.09.2023 Splitting up a Domain Service technically makes sense for: • Load division • Release cadence • Cognitive or technical complexity • …etc Flexible shape for optimal balance between functional boundary and technical solution Domain Service Important! The functional boundary doesn’t have to change. Domain Service Domain Service Domain Service Domain Service
21. 26.09.2023 How to design a Domain Service Domain Service What’s inside? More Hexagons ;)
22. 26.09.2023 The Domain Hexagon is the core of the Domain Service where business value resides Domain Only Business Objects live here! We can apply: - Multi-tenancy - CQRS and Event Sourcing patterns - Domain Driven Design (DDD) business objects - Domain Interfaces - Eventual Consistency (The Dark Side) Aggregate Entity Value
23. 26.09.2023 The Command Hexagon processes input from external sources Domain Input processing can include: - Input sanitizing - Input validation - Authorization checks - (A)synchronous response using various protocols like HTTP(S) and WebSocket - API documentation Aggregate Entity Value Command Input Data
24. 26.09.2023 The Query Hexagon provides data for external clients Domain Data querying can include: - Authorization checks - Reading view models built on events from the domain - Consuming a message stream with events from the domain directly Aggregate Entity Value Command Query Input Data View/Projection Data
25. 26.09.2023 The ACL Hexagon facilitates external communication Domain External calls include: - Calling down stream services - Sanitizing and/or translating the external data to the proper and desired Domain objects Aggregate Entity Value Command Query Input Data View/Projection Data ACL External Calls
26. 26.09.2023 The Repository Hexagon stores the Domain objects Domain Responsibilities include: - Reading and storing Domain objects persisted on a certain data store - Warding the validity, integrity and completeness as the source of truth of the Domain data Aggregate Entity Value Command Query Input Data View/Projection Data ACL External Calls Repository Persist Data
27. 26.09.2023 The Process Hexagon orchestrates processes that call methods on the Domain Domain Use cases include: - Orchestrating internal process instances - Solving Eventual Consistency - Data migrations - Data maintenance Aggregate Entity Value Command Query Input Data View/Projection Data ACL External Calls Repository Persist Data Process
28. 26.09.2023 The GUI Hexagon contains the view logic when packaged with Domain Service Domain - Can call the domain “directly” when applying Server Side Rendering (SSR) - Can call the Domain Service’s own exposed API’s, acting as any other external client Aggregate Entity Value Command Query Input Data View/Projection Data ACL External Calls Repository Persist Data Process GUI
29. 26.09.2023 Characteristics of the Domain Service Domain - Language Independent - Technology Independent - Infrastructure Independent Perfect fit for - Cloud-Native Principles (12-factor) - Domain Driven Design Java Implementation - Each “hexagon” in a separate package in the project’s package structure Aggregate Entity Value Command Query Input Data View/Projection Data ACL External Calls Repository Persist Data Process GUI
30. 26.09.2023 What do you need to do for optimal Shapes and Sizes of Cloud-Native Applications? • Apply Domain Driven Design to determine the business objects and functional boundaries of your Domain Services • Apply 12-Factor guidelines to apply Cloud-Native principles for your Domain Services when deploying on Cloud infrastructure Concluding
31. 26.09.2023 • Semantic discussions, it’s the context and purpose that matters • Shape (application architecture) is important for developers for understanding • Size (consumption of resources) is important for the infrastructure that is building and running the application • Hexagonal architecture complemented with DDD is the most flexible application architecture that fits almost any functional boundary • Hexagonal architecture is ideal for cloud-native principles and industry standard patterns for modern software development Regarding Shapes and Sizes of Cloud-Native Applications
32. 26.09.2023 12-factor Apps https://12factor.net/ Domain Driven Design https://martinfowler.com/bliki/DomainDrivenDesign.html Application Architecture https://www.martinfowler.com/ References
33. Edwin Derks Thank you, and please rate my session! LinkedIn • /in/edwin-derks/ Twitter • @edwinderks Mastodon • mastodon.social/@edwinderks 26.09.2023
34. Are there any Questions? 26.09.2023