InfraKit vs Terraform

Terraform and InfraKit share the features of declarative infrastructure.  Terraform can provision infrastructure resources and reconcile differences between infrastructure and user specification.  InfraKit builds on the same concepts and adds continuously running microservices or controllers, so that the reconciliation is continuous rather than on-demand.  InfraKit also provides features such as node scaling group so that cluster capacity scaling can be triggered directly from higher-level orchestration systems.   In this use case, InfraKit and terraform can be complementary, with terraform being the ‘execution backend’ for InfraKit.  As an example, there is a terraform plugin in the project which can be leveraged to provision resource types currently not natively supported by InfraKit.

Terraform and InfraKit differ in terms of state management and deployment.  InfraKit can leverage the system it is embedded into, such as Docker Swarm or etcd, for leader election and persistence of user specs.  Unlike Terraform which has its own schema and different backend plugins for storing infrastructure state, InfraKit derives the infrastructure state via introspection and queries supported by the lower-level platform (tags and metadata).  The infrastructure itself is the master of records, rather than a representation of it which can be corrupted or go out of sync. InfraKit can be a part of the control plane of a higher-level orchestration system without additional resource requirements.  In this use case, InfraKit also readily integrates with the higher level system as service containers, while Terraform is primarily a CLI tool for ops and not meant to be run as a service for higher level systems.

InfraKit is designed as an active system continuously monitoring your infrastructure and reconciling its reality with a specification provided either by a user or a higher level orchestration system, with an immutable infrastructure approach, while Terraform is designed as a tool to automate existing ops workflows using a declarative description of infrastructure, without the active monitoring and reconciliation approach.

InfraKit vs BOSH

BOSH is much more vertically integrated than InfraKit in that it is itself a full-fledged distributed application with its own datastore (Postgres) and server components.  In terms of workflow, BOSH also covers areas outside of infrastructure provisioning and management -- it has opinionated workflows for application definition and software releases which reaches into the upper layers of the CNCF model.  The full system serves as part of control plane of a much larger platform and thus requires its own provisioning and management.  

InfraKit takes a lighter weight approach.  As a set of pluggable microservices, it is meant to be embedded into a larger system to minimize additional operational burdens.  With InfraKit embedded in the same control plane, these systems can self-install and self-manage.  InfraKit also does not require a database such as Postgres to store state.  Instead, InfraKit inspects the infrastructure and reconstructs what is in the environment for reconciliation with user specification.  This means the only thing that can diverge from user spec is the true infrastructure state.  If divergence is detected, InfraKit will attempt to correct it.   InfraKit also can play the role of a cloud-provider for a node group autoscaler for a container orchestrator like k8s or Docker Swarm, thereby bringing the elasticity common in the public cloud to on-prem bare-metal or virtualized environments.

InfraKit vs Digital Rebar

Digital Rebar compares similarly to RackHD or MaaS.  Currently there is community integration with RackHD, and there is a MaaS plugin in the InfraKit repo.  At a high-level, Digital Rebar and InfraKit are complementary in that InfraKit can leverage Digital Rebar for bare-metal provisioning via DR’s PXE/DHCP/TFTP infrastructure, while InfraKit provides the orchestration capabilities such as scaling up/down clusters and rolling updates.

Digital Rebar is itself a full-fledged distributed application of many components, including a Postgres database where it stores infrastructure state. In terms of deployment, it has its own control plane that needs to be provisioned and maintained.  InfraKit can be embedded inside the control plane of a higher-level orchestration system such as Kubernetes and Docker Swarm.  InfraKit leverages these systems for persistence of user infrastructure specification and for leader election (to provide high availability), and infrastructure state is reconstructed by introspecting the infrastructure.  This means that InfraKit is more a ‘kit’ then another platform and higher-level systems can incorporate InfraKit to provide self-managing and self-provisioning capabilities.