HashiCorp Terraform leads IBM, Red Hat integration roadmap
HashiCorp and IBM have begun to knit together products such as Terraform and Ansible and divulged some roadmap details, but a few potential product overlaps are still unresolved.
HashiCorp Terraform and Vault spearheaded new integrations with IBM and Red Hat tools during the past two months, but some areas of potential product overlap remain unaddressed for now.
Ahead of a HashiDays user event in London on Tuesday, HashiCorp and IBM spokespeople discussed ongoing work to integrate the two companies' products, along with those from IBM's other IT automation subsidiary, Red Hat. But there's also significant work left to do, and areas of potential product overlap -- particularly in developer platforms -- where the long-term roadmap is still unclear.
Terraform and Ansible were identified as likely points of integration between HashiCorp and Red Hat long before IBM's $6.4 billion acquisition was finalized in February. The official Ansible provider was previewed during Red Hat Summit last month and has become generally available this week, according to HashiCorp officials.
Joint customers of the two companies said during presentations at Red Hat Summit that the previous community edition of the provider, which enables Terraform to connect to Ansible, couldn't perform multiple actions at once, but it's unclear whether this official provider supports that feature yet.
An official supported, tested, validated provider for Ansible will be the first step. The end goal is a unified set of services between the two over time.
Meghan LieseVice president of product marketing, HashiCorp
"An official supported, tested, validated provider for Ansible will be the first step," said Meghan Liese, vice president of product marketing at HashiCorp, during an interview with Informa TechTarget last week. "The end goal is a unified set of services between the two over time."
Laying strategic groundwork for Ansible and Terraform
Generally, Terraform will focus on provisioning low-level infrastructure declaratively at initial setup, and Ansible will take over to provide higher-level, continuously updated configurations as the infrastructure is used.
"The tool of choice generally depends on the type of workload being managed," an IBM spokesperson said in an email to Informa TechTarget on Monday. "Container workloads generally depend on the control plane. Assuming it's Kubernetes, OpenShift is a native place to start. Alternatively, the HCP Terraform Operator for Kubernetes could provide a similar experience while offering a consistent control plane for both container-based and non-container-based resources."
HashiCorp Terraform and Vault are already commonly used in Kubernetes environments, including OpenShift, but the HCP Terraform Operator for Kubernetes integration recently completed a certification process and was added to Red Hat's ecosystem catalog.
"For non-container workloads and containers not managed in a Kubernetes environment, it's all about Ansible providing the application deployment and configuration management workflows," the IBM statement continued. "[After that], Terraform ensures the infrastructure resources haven't drifted and are generally within established best practices. Similarly, Ansible is used to ensure that applications and their underlying components, such as operating systems, are patched, up-to-date and within defined specifications. OpenShift generally manages its cluster components and applications ... All three tools have their methods for decommissioning managed resources, and it generally comes down to using a consistent tool throughout the lifecycle."
However, the two tools take fundamentally different technical approaches to their separate areas of the infrastructure lifecycle -- Terraform is primarily declarative, while Ansible is primarily imperative.
"We're working toward a couple of improvements in this space, mainly turning Terraform's state into a source of truth for Ansible inventories," IBM said in the statement. "This means that once a set of resources is provisioned through HCP Terraform, the Ansible Automation Platform is automatically made aware and can trigger Ansible playbooks or workflows based on that information. It also provides a level of awareness throughout the entire lifecycle of an organization's infrastructure resources."
Whither Waypoint?
Other recent HashiCorp Terraform updates made clear that the company has shifted its strategy from its premerger SaaS focus toward hybrid cloud. Most notably, this included support for data center infrastructure that it previously didn't offer, such as IBM's Z mainframe, which now has its own official Terraform provider.
Steven Dickens
On-premises mainframe and IBM Power systems represent a fresh opportunity for both IBM and HashiCorp that neither company would have had separately, according to Steven Dickens, CEO at HyperFrame Research, and that could offer large enterprises new forms of IT automation consistency across hybrid cloud resources. Red Hat OpenShift also claims to address that consistency issue at the infrastructure level, but doesn't offer an equivalent to HashiCorp Vault, he said.
"Those are boring, old platforms, but secrets management on a mainframe is really valuable to a CISO at a big bank," Dickens said. "That's an extension HashiCorp Vault would probably have never gotten around to organically doing, along with Power and probably IBM Cloud, but IBM will have forced them to as part of the integration."
The shift away from SaaS-first also means HashiCorp will offer an on-premises equivalent of its HCP Terraform Stacks for Terraform Enterprise customers, according to HashiCorp's Liese. As for the cloud version, HashiCorp is clearly targeting larger enterprises with a new HCP Terraform Premium SKU, which shipped May 1. It added bolstered security features such as support for self-managed version control systems and folded in the HCP Waypoint internal development platform (IDP) that had previously been a separate product.
There are potential areas of overlap between HCP Waypoint's self-service catalog of infrastructure components and OpenShift, where operators can also expose a catalog of application and infrastructure services to users.
IBM is tight-lipped about how it will position OpenShift and Waypoint long-term. It declined to comment on plans for those specific products, or how and when HashiCorp tools might appear in the IBM Concert product as previewed by the company last year.
In the meantime, one Terraform Enterprise customer has already begun a migration to HCP Terraform Premium, drawn by the Stacks feature as his team builds an IDP.
"We're also experimenting with Waypoint now that we're on HCP Terraform -- that was the other big feature, because our big project for the year is building our developer platform," said a senior cloud engineer at a Fortune 500 company on the East Coast, who requested anonymity because he isn't authorized to speak on behalf of his employer in the press.
As in many large enterprises, some teams also run Red Hat OpenShift and Ansible in other areas of the Fortune 500 business. No strategic decision has been made about whether to standardize on one or the other, but the senior cloud engineer said he has no plans to consider OpenShift. Instead, given his team's familiarity with HashiCorp, the plan is to use Waypoint to create a self-service "infrastructure vending machine" for developers, he said.
Rob Strechay
One industry analyst pointed out that Waypoint actions, which can trigger external systems such as CI/CD pipelines, also overlap with some of the ongoing "Day 2+" configuration management functions otherwise delegated to Ansible.
"The big question is who is observing the state of packages and watching as the CI/CD pipeline pushes to production," said Rob Strechay, an analyst at TheCube Research. "I suspect this is one of a few places, including the HCP Module revocation, that will be looked at to bring Ansible and Terraform closer together. [IBM] must quickly come to an opinionated [position] of what you do in Terraform and what you do in Ansible."
OpenShift plans Vault expansion
Red Hat OpenShift and HashiCorp Vault have long been used together. HashiCorp's recommended integration remains that customers use Vault Secrets Operator (VSO) to integrate with OpenShift, which enables Pods to pull Vault secrets natively from Kubernetes.
However, a few details of further integration plans between HashiCorp Vault and Red Hat OpenShift were made public in a Red Hat blog post last month. Those highlighted include extensions to VSO to protect secrets in transit, at rest and at the point of use in shared environments; certification of the HashiCorp Vault provider for the Kubernetes secrets store Container Storage Interface driver; official OpenShift support that connects OpenShift clusters to HashiCorp Vault's public key infrastructure certificates; joint support for a Kubernetes external secrets operator to sync secrets from HashiCorp Vault to OpenShift Kubernetes clusters; and a Vault Config Operator that will allow for Kubernetes-native, GitOps-style administration for Vault running on OpenShift.
"[I]t's generally understood that Kubernetes secrets are not particularly secret," the Red Hat post read. "[They] are accessible to cluster administrators. Additionally, anyone with privileges to create a pod in a specific namespace can access the secrets for that namespace. While at-rest protection can be provided by encrypting sensitive data stored in etcd, even stronger protection is provided by integrating an external secret manager."
Beth Pariseau, a senior news writer for Informa TechTarget, is an award-winning veteran of IT journalism covering DevOps. Have a tip? Email her or reach out @PariseauTT.
Dig Deeper on Systems automation and orchestration