<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Design &amp; Development :: Solidblocks</title><link>https://pellepelster.github.io/solidblocks/cloud/design/index.html</link><description>The overall design of Solidblocks cloud is led by the following rules
Only basic building blocks that are widely available across the majority of cloud providers are used, e.g. VM, storage disks, DNS and private networking to keep the setup simple and portable Instead of complex container schedulers or API driven control-planes Solidblocks clouds relies on plain Unix services and docker containers started with systemd No extra or intermediary state is used, the source of truth is the configuration file. Resources are identified solely based on its name Apart from the data and backup disks, every created resource must be treated as ephemeral. It must always be possible to re-provision from scratch and get the same system-state as before The created VMs can survive standalone, it must always be possible to use them without Solidblocks cloud It is open for integration of resources that are managed out of band with other IaC tools It optimizes for MTTR over MTBF, instead of complicated failover or rolling update processes, short outages during service deployments are acceptable Overview Solidblocks cloud uses a cyclic process starting with a high level configuration that is transformed into a runtime model defining all resources that are needed to implement the services. During the plan phase this model is compared with the running state inside the cloud, and a diff is created containing all missing or changed resources. Based on this diff during the apply phase the running state is diverged towards the intended model derived from the configuration.</description><generator>Hugo</generator><language>en-us</language><atom:link href="https://pellepelster.github.io/solidblocks/cloud/design/index.xml" rel="self" type="application/rss+xml"/></channel></rss>