The following table highlights the core features of the STACKL.IO platform.
|Unified REST API||STACKL.IO REST API abstracts underlying IaaS and PaaS platforms and becomes a single point of interaction.|
|Configuration Store||A data lookup system where configuration data is organized in a hierarchical and relational model. The configuration store function as a single source of truth within your automation landscape.|
|Configuration Store - Hierarchy||The resulting set of configuration variables depends on the relation and values can be overwritten further down the tree.|
|Configuration Store - Granular Control||Utilizing the hierarchical structure, a fine grain control can be achieved. Which automation tool to use for which role definition, which proxy agent is responsible for passing through an operation.|
|Configuration - Invocation||By default CRUD operations of stack instances, trigger an invocation for workflow execution. In case this is not desired or partially desired (eg. only for a particular environment, location, zone, role, etc.) then this can be disabled.|
|Configuration - Inheritance||Any object type within the configuration store can inherit from other objects of the same type. Example, a role definition can inherit another role to avoid duplication of configuration data within the configuration store.|
|Stacks||Common definition of the desired state of application and infrastructure services. Through the higher level of abstraction, stacks definitions don’t change in relation to target platforms.|
|Stacks - Dependencies||Within stacks, a resource or resource group can have dependencies to other resources within the same stack instance or to resources in other stack instances.|
|Actions||Actions are a definition of day 2 operations, that can be invoked on any object within the configuration store eg. environments, locations, zones, roles, shapes, etc.|
Caught a mistake or want to contribute to the docs? Edit this page on Gitlab!