Goodbye Microservices, Hello Self-Contained Systems Simon Martinelli 

About Me • 30 years in software engineering • 25 years with Java • Self-employed since 2009 • Teaching at two Universities • Co-Lead JUG Berne, Switzerland 

The Evolution of Architecture 

Until 1999 

2000 - 2010 

2011 - Today 

Are Those the Same Thing? 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 Published in Communications of the ACM Volume 15 Issue 12, Dec. 1972 

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 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 

Modularity and Distribution 11 Distribution Modularity Modular monolith Monolithic big ball of mud Distributed big ball of mud Microservices 

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 

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 

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 

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 

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. 

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 

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. 

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 

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 

How to Integrate SCS? • Self-contained Systems should be integrated via their web interfaces to minimize coupling to other systems 

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 

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 

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 

Wholesale ERP Systems Modernization 

Wholesale Domain Model 

Systems Overview 

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 

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 

Strangler Fig 

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 

Thank you! • Web https://martinelli.ch • EMail [email protected] • X/Twitter simas_ch • Bluesky martinelli.ch