Consumption models
The evolution of IT infrastructure systems has led to increased sophistication and productivity gains for organizations. However, it also resulted in functional silos and complex team-to-team handoffs, hindering agility. DevOps, application-focused teams, and cloud computing emerged to reduce handoffs and increase agility, offering sophisticated technologies without communication costs. Early adopters gained a competitive edge. Speed to market is now a crucial competitive advantage. Adopting practices like infrastructure as code (IaC) for provisioning and management is essential.
IaC uses code-based automation frameworks to define and manage data center components, proven effective in the DevOps model. Organizations typically offer two consumption models for Terraform Enterprise and IaC:
This evolution is leading to a situation where speed to market is more of a competitive advantage than ever. But for those organizations that made the jump or those that are considering it, it also raises the question of how to adopt those practices and technologies for infrastructure provisioning and management.
Infrastructure as code (IaC) is a way of managing and defining data center components with code-based automation frameworks. It is an effective pattern for provisioning and managing infrastructure in the DevOps model. When medium to large organizations begin using HCP Terraform and IaC, they typically offer two models of consumption to their IT customers:
- Service catalog model: This model involves defining a core set of standard infrastructure patterns from which end customers can choose. It provides an accelerated or certified consumption path for infrastructure provisioning with limited customization options.
- Infrastructure franchise model: Similar to real-life franchises, this model operates under a strict contract framework. With a robust policy model and supervision, end customers build and run their infrastructure independently, with significant customization options.
Comparing the two consumption models of Infrastructure as Code, it is clear that implementing a digital transformation project of this scale requires careful alignment of resources. Both models can coexist, but you can only begin with one as it requires a lot of resources to create the initial catalog or set up necessary guardrails.
The diagram below illustrates when each model is preferable based on the target user group's technical knowledge level, and the group's need for customization.
| Service catalog | Infrastructure franchise | |
|---|---|---|
| Primary UX | Vending portal (UI, ServiceNow and so on) | Custom workflow (Git, API/command line, CI/CD and so on) |
| Building | Standard modules | Use IaC within defined guardrails to build anything |
| Customization | Limited (using module parameters) | Unlimited |
| Primary security model | Validated modules | Guardrails (policy-as-code and so on) |
| Persona | Any - including business user/project manager | Development teams, SRE and so on |
Figure 1: Highlighting the functions and features consumed in the operating models.
Service catalog
A service catalog functions as a centralized vending portal offering heavily prescribed and pre-configured infrastructure components. The primary objective of this model is to facilitate an accelerated consumption path for certified infrastructure elements. More details about the key aspects of this model are below.
Vending portal
The catalog is a central platform where users can view, request, and build standardized infrastructure components provided by a core group of power users. The Platform team maintains this portal and its standard components, offering them as a service to end customers. The aim is to give users a self-service infrastructure experience, allowing them to audit requests and enforce chargeback policies.
Pre-configured components
The availability of pre-configured components underpin the service catalog philosophy. These components can range from entire application templates to specific infrastructure aspects. The goal is to guarantee uniformity in infrastructure deployment. Organizations can use two methods to create and certify infrastructure:
- Platform team: A designated central team creates and manages the organization's standardized patterns.
- Contribution Pipeline: Establish an endorsement path and contribution pipeline to allow people outside the platform team to create endorsed patterns.
Accelerated certified consumption path
Successful organizations, like Meta, Netflix, and others, attribute their success to defining consistent infrastructure. When starting projects, business units have two options as follows.
- Standard infrastructure patterns: Choose from predefined, validated infrastructure patterns to receive accelerated services and faster delivery.
- Custom architectures: Opt to define their own architecture, leading to a slower delivery process as each component requires building and verification.
Naturally, this approach encourages business units to access existing trusted infrastructure building blocks for their projects:
Features and capabilities to support a service catalog model
| Feature | Use case |
|---|---|
| Private registry | The private registry operates similarly to the public Terraform registry, enabling you to share Terraform providers and modules within your organization. It offers support for versioning and provides a searchable list of available providers and modules. |
| Private providers and modules | Your organization's private registry hosts providers and modules, restricting access to only members of your organization. In Terraform Enterprise, private modules are also accessible to other organizations configured to share modules with your organization. This allows for controlled access and sharing of custom-built modules across organizations within the Terraform Enterprise environment. |
| Run Tasks | Run Tasks in HCP Terraform enable direct integration with third-party tools and services during specific stages of the run lifecycle. When triggered, a run task sends an API payload to the external service, which includes essential run-related details and a callback URL for the service to respond back to HCP Terraform, indicating whether the task passed or failed. This feature allows seamless interaction with external tools, enhancing the flexibility and extensibility of your infrastructure automation workflows. |
| Third party certified integrations | There is a full list of certified integrations. You may also build and customize your own integrations based on your specific requirements. |
Infrastructure franchise model
The franchise model is a way of distributing products or services. It involves a platform team that sets up the company's best practices, available services, and general instructions for using the infrastructure service. The main features of this model are:
- The central control team
- Consumption workflows and upfront governance
- Controlled vending of specific components
Central control team
The franchise model has a platform team called the franchiser. This team provides franchisees with the workflow and resources they need. The franchiser is responsible for keeping the system running, setting rules, and adding extra capabilities to the workflow.
Consumption workflow and upfront governance
This model provides:
- A consumption workflow: Provide end users and customers with a way to access provisioning resources. This allows them to join the workflow and manage their own resource requirements.
- Upfront governance: Governance at the outset ensures that all customers and end users have the ability to provision resources while following legal, regulatory, and enterprise guidelines. Complying with regulations becomes easier and more cost-effective and markedly reduces time-to-market by obviating the need to acquire separate compliance sign-off ahead of go-live.
Controlled vending of specific components
The franchise model allows access to resources, but it also implements proactive controls to meet legal, regulatory, and enterprise standards. Common controls ensure the safety and security of the organization's existing resources. Also, policies control new resources as they go through testing, and validation. See below for an illustration of this model.
Features and capabilities to support an infrastructure franchise model
An example of how to use each of these features to support services in a franchise model is below.
| Feature | Use case |
|---|---|
| Terraform workspaces | When working with Terraform, you manage collections of infrastructure resources. Typically, organizations handle multiple collections. To facilitate this, Terraform employs a persistent working directory when run locally. This directory contains the configuration, state data, and variables for each collection of infrastructure. By organizing the configurations into separate directories, you can group infrastructure resources in a more meaningful and structured manner, allowing for better organization and management. |
| Terraform workspace projects | This feature enables the provisioning of self-managed portions of Terraform Enterprise. It allows end customers/users to use Terraform Enterprise while adhering to the same policies and controls as the root organization. |
| Sentinel policies | Sentinel is a policy-as-code framework embedded within HashiCorp Enterprise products. It empowers organizations to make fine-grained, logic-based policy decisions utilizing information from external sources. |