Why Self-Contained Systems Might Replace Microservices: Key Differences Explained
This article introduces Self-Contained Systems (SCS) as an alternative to microservices, outlines SCS core characteristics, compares both approaches across granularity, communication, UI handling and integration, and concludes with practical insights for large‑scale, multi‑team projects.
What is SCS (Self-Contained Systems)
SCS is an architectural approach that splits a large system into many independent, cooperating systems. Its characteristics include:
Autonomy : each SCS is a self‑contained web application with its own data, logic and UI.
Single team : one team owns a SCS and has final say over its code base.
Asynchronous dependencies : communication with other SCS or third‑party systems should be asynchronous, allowing the SCS to keep working even if the other system is offline.
Optional API : a SCS may expose a service API, but it also has its own UI for direct user interaction.
Own data & logic : both data storage and business logic reside inside the SCS.
Own UI : the UI is part of the SCS and is not shared with other systems.
No shared business logic : business code is not shared between SCS; common libraries may be used.
Minimal shared infrastructure : shared resources such as a single database are avoided; if used, each SCS should have its own schema or model.
SCS vs Microservices
Both share concepts like isolated deployable units and technology‑agnostic choices, but key differences are:
Granularity: microservices are smaller; an SCS can be large enough for a whole business module.
Number of services: a system may have hundreds of microservices but only 5‑25 SCS.
Communication: microservices freely call each other; SCS aim to avoid direct calls, preferring asynchronous integration.
UI: each SCS includes its own UI, while microservices may separate UI from logic.
Integration: SCS integration happens mainly at the UI layer; microservices integrate at the logical layer via APIs.
In practice an SCS can be further broken down into microservices, making it a specific micro‑architecture.
Conclusion
After comparing SCS with microservices, the main take‑aways are:
SCS are larger in scope than typical microservices.
Fewer SCS are needed to cover a domain.
Asynchronous communication (e.g., enterprise bus) is preferred.
Each SCS owns a complete UI and business functionality.
Integration is often done via front‑end components or a small piece of JavaScript.
Programmer DD
A tinkering programmer and author of "Spring Cloud Microservices in Action"
How this landed with the community
Was this worth your time?
0 Comments
Thoughtful readers leave field notes, pushback, and hard-won operational detail here.
