System Garden is often described as ‘Two Levels’ above the cloud. But what does that mean?
It refers to two things.
Firstly that the system is not directly attached to any one cloud provider. We don’t have to endorse one company as our system is not hard-linked to their methods and only their methods. We are not reliant on their features or their components and do not expose the complexity to users.
System Garden uses existing orchestration systems to get around vendor lock-in and use their abstractions to make sure it is done simply and correctly. It also provides a way of slightly changing the implementation model, typically by providing a level of state and by providing integrations to many other software products and services.
This leads us to the second level away from cloud provision, which is to abstract the orchestration layer as well. Why lock into one system when there are several, with their own life cycle of popularity and feature pros and cons.
Both these choices are represented by the catalogue, a key System Garden concept. When each catalogue is built, there are settings for cloud provider and orchestration system. Each will draw on different code generators, allowing catalogue authors to decide on component selection and any specific extra code needed to deliver their vision for the item they are delivering.
The benefits of this approach is many-fold.
Firstly, the avoidance of lock-in to any one vendor, so we can avoid the experience of database programmers. Once a fully featured application has been written on one platform, not only is it hard to port to another, it may not be financially worth-while.
Secondly, as System Garden has a vendor neutral form for conceptual drawings, it can be leveraged to convert from one cloud to another. This is actually done by swapping out catalogues that represent technology choices via the neutral form.
Thirdly, for the user it is low-code, using diagrams as the main form of expression. Its still technical and requires engineering domain knowledge, but it does not need tedious JSON skills or its inevitable errors to when attempting to maintain a system engineering code base in parallel to a business code base.
Fourthly, expressing a system with the visual vocabulary of System Garden gives huge leverage in the capabilities of the engineer in constructing the solution. With a single drawing one can create instructions for systems, services, storage and a code stack, integrating them in to a deployment of a downloadable file for CI/CD pipeline code.
Finally, as catalogues are the single method to express the cloud providers, orchestration method, components and integration, it becomes a simple-to-understand way to master the range of complexity in modern IT. As System Garden makes those catalogues freely exchangeable, it is possible to make a share and market this knowledge in expressive and engineered architecture stacks.
System Garden. Two levels above the cloud.
About the Author
Nigel Stuckey
CTO of System Garden
System Garden
Agile Infrastructure for Enterprise DevOps
Design from diagrams, document and deploy to your cloud.
systemgarden.com, Twitter @systemgarden