Goodbye Microservices, Hello Self-Contained Systems

Microservices are a popular approach to building modern software, offering scalability and flexibility. But for many teams, they come with challenges like increased complexity, difficult debugging, and managing too many small services.

In this talk, we'll introduce an alternative: Self-Contained Systems (SCS). Unlike microservices, SCS allows each part of your application to operate independently with its UI, logic, and database, simplifying both development and deployment.

You'll learn why SCS can be a better fit for many projects, how it reduces the complexity of distributed systems, and when it makes sense to use this approach over microservices. We'll also dive into real-world examples that show you how to build self-contained systems using Java and Vaadin.

If you're ready to rethink your architecture and say goodbye to microservice headaches, this talk will show you the way!

Transcript

1. Goodbye Microservices, Hello Self-Contained Systems Simon Martinelli
2. About Me • 30 years in software engineering • 25 years with Java • Self-employed since 2009 • Teaching at two Universities • Co-Lead JUG Berne, Switzerland
3. The Evolution of Architecture
4. Until 1999
5. 2000 - 2010
6. 2011 - Today
7. Are Those the Same Thing? 7
8. 1972 The effectiveness of a modularization is dependent upon the criteria used in dividing the system into modules. On the criteria to be used in decomposing systems into modules - David L. Parnas Published in Communications of the ACM Volume 15 Issue 12, Dec. 1972
9. It’s All About Modularity Module A self-contained component of a system, often interchangeable, which has a well-defined interface to the other components. Source: https://en.wiktionary.org/wiki/module 9
10. Does The Size Matter? • The term MICRO is misleading • Scope matters • Bounded Contexts • Design for Maintenance • 3 to 10 developers per Microservice during project development • But how many developers will maintain the system? 10
11. Modularity and Distribution 11 Distribution Modularity Modular monolith Monolithic big ball of mud Distributed big ball of mud Microservices
12. Distributed Big Ball of Mud • If you can't build a modular monolith, what makes you think microservices are the answer? - Simon Brown 12 Customer Order Catalog
13. Distribution and Communication • First Law of Distributed Object Design: Don't distribute your objects - Martin Fowler 13 Synchronous Request 1 Response 1 Request 2 Response 2 Asynchronous Request 1 Response 1 Request 2 Response 2 Event based Event 1 Event 3 Event 2 Event 4
14. Beware of the N+1 Select Problem • Use Case: Select all orders of certain customers 1. 1 request to get all customers 2. n requests to get orders of customer 14 Customer Order Client 1 1 ... n
15. Distributed Architecture Patterns Backend A Database A Database B Backend D Database D Frontend A Frontend B Frontend C Backend B Backend C Self-Contained System Monolithic frontend Integration Database
16. Self-Contained Systems Architecture https://scs-architecture.org The content in this section is licensed under the Creative Commons attribution-sharealike 4.0 international license.
17. What are Self-Contained Systems? • An architectural approach that separates a larger system’s functionality into many independent, collaborating systems • Relays on the concept of Bounded Context from Domain Driven Design DDD • Introduced by INNOQ
18. The Way to SCS • If you cut a monolithic system along its very domains and wrap every domain in a separate, replaceable web application then that application can be referred to as a self- contained system SCS.
19. Characteristics • An SCS contains its own user interface, specific business logic, and separate data storage • It may contain an optional API • The business logic may comprise microservices designed to solve domain-specific problems
20. Data Storage • Every SCS brings its own data storage and with it redundant data depending on the context and domain • These redundancies are tolerable as long as the sovereignty of data by its owning system is not undermined
21. How to Integrate SCS? • Self-contained Systems should be integrated via their web interfaces to minimize coupling to other systems
22. Asynchronous for the Win! • To further minimize coupling to other systems, synchronous remote calls inside the business logic should be avoided • Instead, remote API calls should be handled asynchronously to minimize dependencies and prevent error cascades • This implies that, depending on the desired rate of updates, the data model’s consistency guarantees may be relaxed
23. SCS vs Microservices SCS Microservices Size and Scope Larger with UI Smaller without UI Independence Autonomous Dependent to implement a single use case Integration Style Avoiding direct API calls Synchronous API calls Team Structure Teams own a full vertical slice Coordination needed due to service dependencies User Interface Include their own UI Don't handle UI concerns Deployment Deployed independently May require orchestration
24. Advantages of SCS • Resilient • Improved through loosely coupled, replaceable systems. • Scalable • Systems can be individually scaled to serve varying demands. • Open to Integration • A system of systems consists of individually developed software and standard products. • Independent • Technical decisions can be made independently, such as programming language, frameworks, tooling, etc. • No more risky big bang releases • Migration can occur in small, manageable steps that minimize the risk of failure and lead to an evolutionary modernization
25. Wholesale ERP Systems Modernization
26. Wholesale Domain Model
27. Systems Overview
28. Micro vs Macro Architecture Aspect Micro Architecture Macro Architecture Scope SCS level System landscape Key concerns Local optimization Cross-system coherence Stakeholders Developers, technical teams Architects, leadership, platform engineers Design principles Low coupling, high cohesion Autonomy, scalability, interoperability Examples Design patterns, data access frameworks API standards, messaging formats, observability guidelines
29. Our Macro Architecture • User Interface • Common Design System with Components and Styles • Link database for navigation • Integration • Replication of read-only data based on database views • Orders over ActiveMQ • Technology • Vaadin UI framework • Spring Boot • Oracle DB • Apache Camel • SymmetricDS
30. Strangler Fig
31. Conclusion • SCS provide optimal modularity based on business boundaries • Team autonomy from UI to DB • Reduces runtime dependencies to a minimum • Simpler deployment and operations • Supports continuous modernization 31
32. Thank you! • Web https://martinelli.ch • EMail simon@martinelli.ch • X/Twitter simas_ch • Bluesky martinelli.ch