Documents and Types
A Document is a Key/Value text-file in the JSON or YAML format that models IT infrastructure building blocks, application service definitions, and their configuration data. Documents are the simple key unit through which STACKL understands the user’s IT environment and does work: nearly every task will, in some way, affect documents. This can be storing, changing, or deleting models of the IT infrastructure, submitting application or service descriptions, actually instantiating and representing running applications, and so on. Documents belong to one of two broad categories and are strictly typed.
There are two categories of documents: items and configs. Configs represent documents that model or describe elements or concepts of the user’s IT environment and are files that by themselves are not actionable but serve as configuration. Items are documents that are tangible elements of a user’s IT environment, namely files that are actionable or represent an interactable entity. Items can be the result of processing other documents. For instance, a deployable piece of hardware (i.e., infrastructure target) described by a document is an item and can be the result of a user’s environment, zone, and location documents which together uniquely represent that hardware. In terms of how they are created, configs are always user-submitted direct models or descriptions of things to be used by STACKL and thus are not the result of a hierarchical K/V lookup. Items, in contrast, are actionable elements that are either submitted or generated by STACKL and so can be the result of a hierarchical K/V lookup of other documents.
- represents an environment used within your IT infrastructure; production, testing,
- represents a logical network or security zone used within the IT infrastructure; subnets, security groups, etc
- represents a logical (or physical) location used within the IT infrastructure; vm’s, machines, …
- models IT infrastructure as infrastructure targets originating from the environment, location, and zone and possessing a set of infrastructure capabilities
- models the application as a set of services with their requirements, links and any policies
- configuration packets required of the operating environment for the service to perform its functions
- hardware resource requirements to run the service such as CPU, memory, hard disk capacity, …
- Service and Application requirements that give additional specifications for how the service or applications functions, such as multiple service instantiations, service latency links, availability conditions, …
- An instantiation of one of the viable solutions of a ST on the IT infrastructure
- A template for possible stacks as a deployable set of services matched to suitable infrastructure targets
- a virtual or physical entity capable of executing software (VM’s, desktop computers, …), that can be targeted to run services
- Software entity that performs a small piece of functionality and has a clear set of service requirements