Microservices are not inherently bad. But they are not a one-size-fits-all solution either. In fact, for many business applications, they can introduce unnecessary complexity. In this post, I want to show you an alternative architecture style: Self-contained Systems (SCS), an approach that has helped us successfully modernize large enterprise systems with less pain, fewer dependencies, and better resilience.
A Quick Look Back
The history of enterprise software architecture has gone through several waves:
- Pre 2000s: The “Wild West” of software development, often mainframes and COBOL in large enterprises.
- 2000 – 2010: The rise of monoliths, especially in Java with J2EE (now Jakarta EE) and later Spring Framework, leading to many successful greenfield projects.
- Post 2010: Inspired by Netflix, microservices became the buzzword, often misunderstood and misapplied.
Microservices emerged from the needs of massive-scale platforms like Netflix. But unless you’re building for millions of concurrent users, that level of architectural complexity might not be necessary or even manageable.
The Problem Isn’t Monoliths, It’s the “Big Ball of Mud”
When people criticize monoliths, what they mean is the big ball of mud, a system that’s evolved without clear boundaries, strong modularity, or maintainable structure.
But not all monoliths are bad. Like architect Jean Nouvel’s monolith filled with beautiful art, a well-structured monolith can be elegant. The key is modularity.
As early as 1972, David Parnas emphasized the value of modularity. And this remains true today regardless of whether you’re building monoliths, microservices, or anything in between.
The Myth of “Micro”
The name “microservices” is misleading. At Netflix, microservices are fairly large. The real idea is to divide your system into independent, well-defined components, often aligned with bounded contexts from Domain-Driven Design (DDD).
But in practice, many companies go too small, too fast. I’ve seen teams of 3 trying to maintain 20 microservices, dealing with fragile inter-service communication, cascading failures, and deployment headaches. Too many services without the resources to maintain them leads to more complexity, not less.
Modularity vs. Distribution
Here’s the key insight:
- Modularity is about structure.
- Distribution is about deployment.
You can build a modular monolith, a well-structured, single-deployment application with clean boundaries. You can also build a distributed big ball of mud, a nightmare to maintain.
Distribution adds complexity: network failures, latency, retries, eventual consistency, circuit breakers, etc. Martin Fowler’s first law of distributed design still holds: “Don’t distribute your objects.”
Communication Overhead
Microservices often suffer from communication issues:
- Synchronous APIs (REST, GraphQL, gRPC) tightly coupled services.
- Asynchronous messaging (Kafka, JMS) reduces coupling but adds delivery and consistency challenges.
- Event-driven systems can be powerful but only if your domain fits.
For example, I’ve seen request-reply messaging lead to duplicate shipments because the ERP backend wasn’t idempotent. And then there’s the N+1 problem. Lazy-loading over HTTP is a disaster compared to lazy-loading over JDBC.
Introducing Self-Contained Systems (SCS)
The Self-contained systems architecture (scs-architecture.org) was introduced by InnoQ and offer a different model. Each SCS is:
- A vertical slice of your system.
- Contains its own UI, business logic, and data storage.
- Is autonomous: independently developed, tested, deployed, and operated.
- Communicates only when necessary ideally asynchronously, or via the UI itself.
Think of Amazon’s checkout process. Each step from cart to shipping to payment feels slightly different. That’s not a bug it’s a feature. These are separate systems, communicating only via links and data exchange.
Why SCS?
SCS isn’t just about avoiding microservice pitfalls it’s about choosing the right boundaries, the right coupling, and making systems more resilient, scalable, and evolvable.
Here are the key differences:
| SCS | Microservices | |
| Size and Scope | Larger, handling complete business capabilities with UI | Smaller and focus on single business functions without UI |
| Independence | More autonomous – each has its own UI, database, business logic | Depend more on each other to implement a single use case |
| Integration Style | Integrate via links and async messaging, avoiding direct API calls | Use synchronous API calls and service discovery |
| Team Structure | Teams own the full vertical slice and can work independently | Teams often need to coordinate more due to service dependencies |
| User Interface | Include their own UI | Don’t handle UI concerns – they’re usually backend-only |
| Deployment | SCS can be deployed completely independently | May require orchestration due to dependencies |
Real-World Example: Modernizing an ERP System
I’m currently working with a wholesale company with over 30 cash & carry markets. Their ERP system is over 20 years old, and built with Eclipse RCP and Java 8. It’s a monolith: tightly coupled, hard to deploy, impossible to update without affecting everything.
We’re migrating it to a set of SCS:
- Each SCS has its own Vaadin-based UI, Spring Boot backend, and Oracle schema.
- We replicate read-only data across systems, decoupling master data access.
- Communication is mostly via UI links. For example, navigating from inventory to sales uses an internal registry and metadata to pass control.
- SSO ties it all together so users don’t notice the separation.
- We use a design system with common components to maintain a unified look.
The result? Teams can evolve their systems independently. We avoid complex synchronization issues. And best of all, we avoid the trap of rewriting everything in a Big Bang.
When SCS Makes Sense
SCS works best when:
- Your domain can be split into clear bounded contexts.
- You want team autonomy.
- You value loose coupling and independent evolution.
It’s not always the right choice but it’s often the better choice, especially for enterprise business applications.
Final Thoughts
SCS is not a silver bullet but it’s a pragmatic and battle-tested architecture style that can make your systems more maintainable, robust, and future-proof.
It’s about keeping things simple, cutting dependencies, and enabling long-term evolution.
Goodbye, microservices hype. Hell,o self-contained systems reality.
References
- Self-contained Systems, https://scs-architecture.org
- My talk at Voxxed Days Bucharest:
