Getting Started With Alkira And Terraform (Part 2)

In Part 1, we started with a scalable foundation that can adapt over time as the business grows and adjusts to changing markets. With Alkira’s Network Cloud, we take a cloud native approach in enabling our customer’s transformation. No appliances need to be provisioned in remote VPCs or VNets, and no agents need to be installed on workloads. Getting started is as easy as kicking off a build pipeline. For Part 2, let’s connect some networks from AWS, Azure, and GCP.

In Part 1, we set up a hypothetical Line of Business called LoB - Digital, which has the following network requirements:

  • Cloud Native applications will be deployed in AWS; Application lifecycle requires DEV, TEST, STAGE, and PROD VPCs
  • Azure gets the same network types as AWS for cloud native workloads; In addition, Azure will also get a MIGRATION VNet which will act as a landing zone for workloads being migrated from on-premises
  • A new product surrounding data analytics is being established, and the product team wants to leverage GCP; The product is not production-ready, so only DEV, TEST, and STAGE VPCs are required

Topology
Topology

Since no appliances get installed inside cloud networks, how does Alkira interface with the cloud providers? Alkira takes the cloud native approach of using existing authentication methods in each cloud. For instance, in AWS, this would be IAM Policies and with Azure, Service Principals. Most enterprises are already interacting with the cloud this way today, so integrating with their existing automation + pipeline strategy is seamless.

We will be using the following Terraform Resources in this post:

NameTypeDescription
alkira_credentialdata sourceReference existing credential
alkira_billing_tagdata sourceReference existing billing tag
alkira_connector_aws_vpcresourceProvision connector for AWS VPC
alkira_connector_azure_vnetresourceProvision connector for Azure VNet
alkira_connector_gcp_vpcresourceProvision connector for GCP VPC

Alkira’s Terraform Provider does quick work of connecting cloud networks to our foundation. The following snippet will connect an Azure VNet, place it in the group we provide, and attach a billing tag.

azure_connector.tf

HashiCorp recommends One Workspace Per Environment Per Terraform Configuration. Since we are provisioning and connecting so many networks + environments across all three cloud providers, I simplified a few things. With Azure, for example, repositories map to Workspaces like this:

Repos to Workspaces
Git

Like Part 1, we will use Terraform Cloud for provisioning. A successful merge to our main branch will automatically trigger a plan, and apply.

Provision Infrastructure
Provision

Twelve VPCs/VNets across three public clouds couldn’t be easier! By default, networks connected to our corporate segment have full-mesh connectivity to each other. Later in this series, we will build automated policies to work with our groups that produce some logical micro-segmentation.

UI Validation
Validation

For Part 1, we built a scalable foundation, and in this post, we connected networks from AWS, Azure, and GCP to it. One area where enterprises struggle is securely connecting their data center or remote offices to the cloud. This use-case often maps back to migrating workloads to the cloud or running Tiered Hybrid Workloads. In Part 3, we will connect a few on-premises networks into the mix to see how Alkira can help solve this problem.