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. Simon Martinelli Goodbye Microservices, Hello Self-Contained Systems
5. About Me • 30 years in Software Engineering • 25 years with Java • Self-employed since 2009 • Teaching at two Universities • Co-lead Berne, JUG Switzerland
6. Are These the Same Things?
7. 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 Communications of the ACM Volume 15 Issue 12, Dec. 1972
8. 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. Does 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. Modularity and Distribution Distribution Modularity Modular monolith Monolithic big ball of mud Distributed big ball of mud Microservices
11. Distributed Big Ball of Mud • If you can't build a modular monolith, what makes you think microservices are the answer? - Simon Brown Customer Order Catalog
12. Distribution and Communication • First Law of Distributed Object Design: Don't distribute your objects - Martin Fowler 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
13. Anti-Patterns Database B Backend D Database D Frontend B Frontend C Backend B Backend C Monolithic frontend Integration Database
14. 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.
15. • Cut the monolith along bounded contexts • Wrap each domain in its own web application • That application is a Self-contained System SCS The Way to SCS
16. Characteristics • An SCS contains its own user interface, specific business logic, and separate data storage • It may contain an optional API
17. Data Storage • Every SCS brings its own data storage, which may cause redundant data • Redundancy is tolerable as long as data sovereignty is preserved
18. How to Integrate SCS? • Self-contained Systems should be integrated via their web interfaces to minimize coupling to other systems
19. Asynchronous for the Win! • Synchronous remote calls inside business logic should be avoided • Asynchronous calls reduce dependencies and prevent error cascades • Consistency guarantees may be relaxed, depending on the required update rate
20. Advantages of SCS ✓ Resilient Loosely coupled, replaceable systems ↑ Scalable Individually scaled, even to zero ⇄ Open Custom and standard products side by side ★ Independent No big bang releases, evolutionary migration
21. • AI assistants are only as good as the context they see • With microservices • One feature lives in many repos • The full code may not fit in the context window • AI suggestions break other services • Humans still stitch it together AI Needs Context Context Window auth orders billing catalog cart users search payment ship invoice notify audit
22. • The full picture fits • UI, business logic, and data access live together • The whole context fits in the window • Changes stay inside the boundary • One team per SCS maps to one AI agent per SCS SCS: Right-Sized for AI Context Window UI Business Logic Data
23. Modernizing a Wholesale ERP System
24. Wholesale Domain
25. Systems Overview
26. • Data Integration • Replication of read-only data based on database views • Async through events • User Interface • Common Design System with Components and Styles • Link database for navigation Macro Architecture
27. Replication • Pull-based replication • Target system refreshes data • Good for data that does not change very often • Adds delay depending on refresh interval • Simple to implement Events • Push-based replication • Source system publishes changes • Good for frequently changing data • Near-real-time updates • Higher operational complexity Data Redundancy
28. Migration
29. Strangler Fig Pattern https://martinfowler.com/bliki/StranglerFigApplication.html
30. Conclusion • Optimal modularity based on business boundaries • Team autonomy from UI to DB • Reduced runtime dependencies to a minimum • Simpler Deployment and Operations • Supports continuous modernization
31. Thank you! • Web martinelli.ch • EMail simon@martinelli.ch • Bluesky @martinelli.ch • X/Twitter @simas_ch • LinkedIn https://linkedin.com/in/ simonmartinelli