Skip to main content

Self-Contained Design

Context​

Microservices are being adopted. Each microservice comes with its libraries, runtimes, and other dependencies required to run them in production.

Problem​

  • Installation of libraries or other dependencies on the target machines conflict or lead to coordination and slows down technology (e.g. library, programming language versions, etc.) upgrades.
  • Deployment requires knowledge about which components need to be installed

Solution​

Design self-contained microservices shipping everything with them what they need to fulfill their task.

Self-containment comes in different forms. The following things can be included in a self-contained microservice:

  • Libraries: use technologies like container images to package all libraries or other local software components into one shippable artifact and isolate them from the technology used by other microservices.
  • Data storage technology: have dedicated data storages per microservice. The data a microservice owns is then contained within its vertical.
  • User interface: especially web-based UIs can be included in the microservice itself instead of having one monolithic UI speaking to many microservices. This is advocated by self-contained systems (SCS) - a variant of microservices.

The self-containment of microservices in its various forms leads to independence between them. In combination with container technologies it adds towards scalability, elasticity, testability, technology independence, ease of deployment, reduced coordination efforts, and maintainability (understandability of the self-contained component).

Maturity​

Proposed, requires evaluation.

Sources of Evidence​

L8:

  • self-contained system as variant of microservices
    • include UI (web UI)
    • frontend integration as much as possible

L9:

  • containers make deployment process easier, package all dependencies in them
  • leave few necessary parameters for operators to configure

L13:

  • wrap dependencies and vagaries of implementation inside themselves
  • containers might use master-slave or nested-container
    • both means to encapsulate dependent containers in some way
    • nested-container easier to manage, but overhead since two layer of Docker daemon

L16:

  • self-containment = services contain everything they need to fulfill their task on their own
    • not just business logic
    • also front- and backend
    • required libraries
      • => no installation required when shopped together
      • separated by containers => required libs of different services don't interfere with each other
    • its data
  • (+) helps to achieve scalability by replication in general
  • if deployed in single container
    • (+) better testability since production-like env
    • (+) ease of deployment (no lib installation)
    • (+) scalability by fast container startups

L17:

  • Microservices don't have external dependencies
  • (+) independent development, reduce comm/coord overhead

L20:

  • self-containment comes with bounded contexts
  • even if uses functionality of other microservice, it can be deployed without need for availability of other
    • continue running with partially working
  • (+) maintainability: analyse, understand, update microservice without need to know about other microservice internals

L28:

  • Containers include all required libs
  • Containers avoid conflicts among runtime environments

L32:

  • microservices are self-contained
  • (+) easier to change technology without coordination with other teams
  • (+) increased speed adopting new features of libs / language versions => advantage against competitors

L34:

  • Self-contained microservices are more efficient than SOA for
    • elasticity
    • scalability
    • automated and continuous deployment
    • => cloud-friendly

L41:

  • Difference to SOA: self-containment
    • data
    • user interface
    • persistence tools

L46:

  • not share resources like containers, caches, datastores with other enterprise software components
  • db as part of microservice
  • self-containment (esp down to db) is wishful thinking
    • very costly to split monolith
    • overall complexity overwhelms any advantage of agility or scalability at individual microservice level

L47:

  • docker image contains all its dependencies
  • service as a black-box with API

L49:

  • several software components (local storage, web server, etc) encapsulated in a container

L53:

  • microservices-based IoT system by self-contained and independent deployable software components
  • containerized microservice maintains own states and stores its data
    • => complexity encapsulated in black box

LN44:

  • Additional situation-dependent attributes of microservices: self-contained (among others)