At Guidepad we're developing what we believe is the future of modern software system development and management. To us, this means moving out of files into data as much as possible, and shifting the problem of building a distributed system to one of programming a distributed system. To illustrate the difference between the current standards and where we think things should go, we want to take a little bit of time to discuss the differences between our way of doing things and some of the current standards in systems like Terraform (TF) and OpenTofu (OTF). In the remainder of this blog post we'll refer mostly to TF but the points made equally apply to OTF.
Systems like TF are control planes that allow users to manage the state of a set of resources. In TF, a resource is a configuration primitive that describes some system component. Teams write code (HCL in TF or in a given language via the Cloud Development Kit for Terraform (CDKTF)) that specify their system components' desired state as a set of files (called a module), which is then often kept within a version control system. In TF, an entity called a provider implements the logic of using the resource definitions to manipulate state in some remote system to reify the desired state expressed in those definitions. TF maintains a database of current state for the resources so that providers can calculate the delta between the current and desired state and make a plan to bring the states into alignment. Teams can then parameterize their modules to allow them to be configurable for different use cases and target environments.
The above arrangement of concepts means that:
Guidepad removes these constraints by abstracting at a level higher than the control plane and shifting configuration from a compile time concern to a run time concern. To facilitate the shift to run time configuration management, Guidepad stores system definitions as dynamic data rather than static files. As far as Guidepad's abstractions, we can loosely map them to TF concepts:
So to summarize, Guidepad services, environments, control planes, state plans, and operations mean that:
So all of the above is great, and gives teams using Guidepad unparalleled visibility and flexibility when building and managing modern systems. But what if we want to automate the transition between states in those systems in response to real world conditions? Guidepad's state machine abstraction provides that capability:
State machines allow for specification of the valid states within a distributed system, as well as the allowed transitions between those states for each service in the system. Importantly, each service can use a different control plane, with a different state plan, targeting a different environment in its own transition from state to state. Each transition can also be assigned requirements, which are logical gates on when the transition is allowed to fire. Requirements are another extensible part of the Guidepad framework and new requirements can be added either as data records or via guidepad plugins.
Some common examples of requirements include:
The Guidepad state machine orchestrator monitors all state machines with the "autonomous" flag set to true, and will automatically move services to new states when the requirements for the state transitions are satisfied.
It is important to remember that each transition can utilize a different state plan/control plane combination, meaning that teams have fine-grained control over how services change their state. Does a state change make the most sense using Terraform, written in HCL? Use the Terraform control plane. Is the team responsible for managing this particular state change most comfortable with Python, or Bash, or Rust? Use one of the control planes tailored to executing code instead. Maybe your team has a large set of Pulumi IaC that you're not ready to move away from. With Guidepad you can utilize a Pulumi control plane to use those existing IaC resources and migrate to different control planes as need dictates.
A moment should be taken here to highlight the built-in Terraform control plane in Guidepad, since this is a blog post mostly about Terraform-like capabilities. This control plane allows for nodes within the State Plan DAGs to be written directly in HCL, but still utilize all of Guidepad's other system modeling capabilities. With the Terraform control plane, Guidepad automatically manages state artifacts for each service x state x environment combination via other subsystems within Guidepad. This control plane is also an excellent example of how straightforward it is to add new control plane support to the system, as the file implementing the control plane in our code base is less than 100 lines.
If you'd like to learn more about the Guidepad system or request a demo, please reach out at hello@guidepad.io.
Guidepad's ML Plugin
Jul 28, 2023 · 10 min read read
Guidepad's Managed Embeddings Service (Part 1)
Aug 8, 2023 · 10 min read read
Guidepad's Managed Embeddings Service (Part 2)
Aug 8, 2023 · 10 min read read