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 seriously 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 has been proven to be 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 stacks 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 are empowered to 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, SNOW etc.) | Custom workflow (Git, API/CLI, CI/CD etc.) |
| What can be built? | Standard modules | Anything via IaC within defined guardrails |
| Customization | Limited (via module parameters) | Unlimited |
| Primary security model | Validated modules | Guardrails (policy-as-code etc.) |
| Persona | Any - including business user/project manager | Develeopment teams, SRE etc. |
Figure 1: Highlighting the functions and features that will be consumed in the operating models.
Service catalog
A service catalog functions as a centralized vending portal offering heavily prescribed and mostly pre-configured infrastructure components. The primary objective of this model is to facilitate an accelerated consumption path for certified infrastructure elements. We'll go into more detail about the key aspects of this model which include:
- A vending portal
- A menu of pre-configured components
- Accelerated certified consumption path
Vending portal
The catalog is a central platform where users can view, request, and build infrastructure components that have been marked as "standard" by a core group of power users. The Platform team usually 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 service catalog philosophy is based on the availability of pre-configured components. These components can range from entire application stacks 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 is authorized to create 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 (previously Facebook), Netflix, Wayfair, and others, attribute their success to defining consistent infrastructure. When starting projects, business units have two options:
- Standard infrastructure stacks: Choose from existing standard infrastructure stacks to receive accelerated services and faster delivery.
- Custom stacks: Opt to define their own stack, 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 | HCP Terraform's 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 | Private providers and modules are hosted on your organization's private registry, 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. |
| 3rd Party Certified Integrations | There is a full list of certified integrations available for Terraform Enterprise, and here are some of them: Aqua Security, Palo Alto Prisma Cloud, Firefly, Infracost, Kion, Lightlytics, Snyk. 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, services that can be used, 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. For existing resources, common controls are put in place to ensure the safety and security of the organization. Additionally, new resources go through testing, validation, and are controlled by basic policies. This model is illustrated below.
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'll be managing collections of infrastructure resources, and 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 and can be extended to utilize information from external sources. |