Traditional software architectures ventured into development of monolith applications: software that had to be deployed as a single product. These monoliths are hard to develop and maintain over time. Sometimes, dependencies would be erroneously introduced which contributed in value degradation for a company. The complexity of a monolith would make it harder to test and deploy. When a monolith is no longer useful, replacing it would be a massive chore.
Self-contained systems (SCS) are smaller, isolated units of application focusing on specific functionality. Like monoliths, SCSs will have a user interface, business logic and persistent storage. However, each SCS will operate independently from another SCS. The characteristics of an SCS are:
Advantages of Self-Contained Systems
The independent nature of an SCS is its greatest draw. Multiple SCSs can be combined to provide greater functionality without adversely impacting the individual SCS. If one SCS fails, the other SCSs are not affected. Technology decisions and requirements can be limited to a single SCS; where requirements to a monolith would impact the whole. The risk to testing out new technologies or approaches is minimized as it is implemented on a single SCS.
Each SCS can be independently scalable: therefore, a single SCS may be run on multiple servers because of high loads, while other SCSs are running on a single server. Each SCS is independently replaceable. Theoretically, an SCS may be a 3rd party application which provides specific functionality to the whole with minimal impact. When moving from legacy monoliths to an SCS architecture, the migration is easier as each SCS is completed and introduced. Overall resilience is improved as SCS are loosely coupled.
Self-Contained Systems in Practice
Self-contained systems are not necessarily small. A big system can have several self-contained systems. The main concern when using several SCSs is integration. Since each SCS is a web application, the resolution is a common navigation header with seamless links to each system. This process provides even greater flexibility because as the lifecycle of the first systems complete over time, they can be easily replaced or updated without touching the other systems.
Another integration concern is data sharing. Each SCS stores and handles its own data and other systems cannot touch that data. If data from another system is used, the SCS will duplicate that data for its own use. Two possible resolutions are available: when the ‘owning’ SCS has new or changed data, it will send out an asynchronous message with the updated data for any other SCS listening and duplicating the data; or an HTML snippet is included on presentation page of the ‘dependent’ SCS to the ‘owning’ SCS data.
Self-contained systems are not complicated, though they may be complex. By focusing on a single problem or function for the business, development teams are able to provide the most effective solution possible. By keeping those functions separate, teams manage requirements and dependencies such that the whole system will not become complicated or overwhelmed with integration code.
Everything you need to know about outsourcing technology development
Access a special Introduction Package with everything you want to know about outsourcing your technology development. How should you evaluate a partner? What components of your solution that are suitable to be handed off to a partner? These answers and more below.