HCP Consul on Azure to go GA, Plus More Consul News

Today at HashiConf Europe, we introduced a number of significant enhancements for HashiCorp Consul, our service networking solution that helps users discover and securely connect any application. These updates include HashiCorp Cloud Platform (HCP) Consul becoming generally available on Microsoft Azure, general availability of Consul API Gateway version 0.3, and tech previews of the upcoming Consul 1.13 and AWS Lambda support, scheduled for release later this year.

Here’s a closer look at all three announcements:

»HCP Consul on Azure Goes GA in July

HCP Consul on Microsoft Azure will graduate from the current public beta to become generally available in July. At GA, HCP Consul users will have the choice of deploying a production-ready Consul service mesh on either Amazon Web Services (AWS) or Azure infrastructure to support their various workloads. HCP Consul is the first managed service mesh to support multiple cloud platforms from both a runtime and underlying infrastructure perspective. It brings us one step closer to our goal of providing a consistent platform for deploying managed versions of all HashiCorp tools across multiple clouds.

For Azure users, HCP Consul can support applications running on Azure Kubernetes Service (AKS) or Azure Virtual Machines. Clusters can be deployed using either the HCP UI or the HCP Terraform provider. To help users get up to speed, we have released a number of new Learn guides for deploying HCP Consul on Azure for Peering HCP Consul with an Azure VNet, Configuring AKS as a Consul Client for HCP Consul, Using Terraform to Deploy HCP Consul on an Azure VM, and Configuring Azure VM as a Client for HCP Consul. To get started, log into your existing HCP account or create a new one at cloud.hashicorp.com/consul.

»Consul API Gateway 0.3 Is Now GA

General availability of Consul API Gateway 0.3 includes a new feature called highly available gateway instances. With this new feature, Consul API Gateway users will be able to deploy redundant versions of logical gateways that share the same configuration. These instances can be placed behind a traditional application delivery controller (ADC) or perimeter solution for load balancing inbound requests from various clients, adding a higher level of resilience in case of a Kubernetes pod outage.

Highly available gateway instances also give users greater control for scaling logical gateway instances up or down as needed, using a single kubectl command. For a deeper dive into what these gateway services are and how they work, please read our blog on Consul API Gateway 0.3.

»Consul Adds AWS Lambda Support

In recent surveys, we’ve seen that organizations continue to expand usage of serverless solutions, like AWS Lambda. In fact, in Datadog’s State of Serverless Survey, more than half the organizations surveyed state that they have adopted serverless technologies across all major cloud providers. Being able to run key functions wherever they’re needed adds agility and reduces the need for long-running infrastructure for small tasks. Seeing this evolution, we believe that serverless applications still need to benefit from the security and traffic management capabilities that a service mesh offers.

On June 16, we released a beta version of AWS Lambda support for Consul service mesh. This release allows users to make Consul service mesh applications aware of Lambda functions and set up intentions — Consul’s traffic management feature for routing traffic to these functions upon invocation. The beta version is available today with general availability coming later this year.

»Consul 1.13 to Feature Cluster Peering

Lastly, we previewed the upcoming release of Consul 1.13, highlighted by the introduction of a new feature called cluster peering. Cluster peering will help simplify how organizations connect multiple sets of Consul servers and share information between datacenters. This allows organizations to connect multiple multi-tenant environments while still maintaining isolation at the administrative level. Enterprises can use this capability to control what specific partitions are able to communicate with one another, allowing more fine-grained control of how service-to-service communication is regulated throughout the entire network footprint. And that fine-grained control allows operators to better adhere to the principle of least privilege.

In the past, Consul utilized a feature called WAN federation. This feature allowed WAN gossip to be shared between Consul servers, but it created a dependency on a single datacenter being the “primary” and new clusters being added as a secondary. With cluster peering, users will no longer have to specify a primary datacenter.

In this new model, users generate a peering token that allows connectivity to that datacenter. Users take this peering token and provide it to the connecting datacenter to establish communication and share the service registries of each environment. This new model also allows users to connect Admin Partitions in different Consul datacenters, providing more granular controls within multi-tenant deployments.

For a more in-depth understanding of cluster peering, please read Consul 1.13 Tech Preview: Cluster Peering.

»HashiCorp Consul Continues Its Evolution

We’ve designed each of these enhancements to help Consul users implement a robust service networking solution. For more information about these releases or Consul in general, please visit the Consul documentation or the HCP documentation. If you would like to see the announcement keynote, sign in to the HashiConf Europe virtual platform and look for the recordings – they will be available shortly after the keynote has ended.