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:

  1. Each SCS is an autonomous web application.
  2. One team owns each SCS to develop, test, maintain and operate.
  3. Communication between SCSs or 3rd party systems occurs asynchronous whenever possible using RESTful HTTP or lightweight messaging.
  4. An optional service API can be included.
  5. Each SCS has its own business logic and data storage.
  6. Features of an SCS are made useful through its own user interface using ROCA principles which may be linked to another SCS UI but is not shared.
  7. No business logic is shared between SCSs.
  8. Technical decisions within an SCS are made independent from other systems, such as programming language, frameworks, tooling, and workflow.

[See Also: QA in DevOps is Shrinking – Here’s What You Can Do About It]

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.

[See Also: Software Defined Datacenters Will Revolutionize Your DevOps Environment]

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.

Introduction Package

Zymr blogger

0 comments

Leave a Reply

© 2019, Zymr, Inc. All Rights Reserved.| LEGAL DISCLAIMER | PRIVACY POLICY | COOKIE POLICY