Moving Your Fleet from AWS to AZURE with Terraform

October 22, 2018 Gabe Maentz

In the series of Terraform posts we have shown how to effectively utilize Infrastructure as Code to build, deploy, scale, and monitor a fleet of infrastructure across both AWS and Azure. The beauty of Terraform is that we can leverage providers to execute the entire deployment in a consistent way across clouds regardless of the particular constructs. The particulars (API interactions, exposing resources, dependency mapping, etc.) are taken care of by Terraform and the providers themselves.

To recap this is what we have covered so far:

Now that we have our fleet in both AWS and Azure, let’s move between them.

Moving Fleet between AWS and Azure

Below are the respective fleets in both AWS and Azure.

Having presence in both we will need to redirect our traffic to our cloud of choice. This is easily done via DNS. The Terraform output from our AWS and Azure deployments via Terraform provides us with the public facing DNS names for each of the respective environments. These are the same DNS names that we have used to validate our deployments in each of the given clouds during the previous steps.

We can then log into our DNS provider/management service (mine happens to be with Hover) and create three CNAME records. azure, aws and www. The domain name I will be using to access our fleet is couchtocloud.com

The aws and azure records are not necessary but I like to be able to browse to them directly for troubleshooting if necessary.

The www record can then be pointed at which ever cloud you want to traffic to be directed to, and modified to point to a different cloud when needed. We can now dictate which cloud we want to send traffic to with a simple DNS update. For a simple form of load balancing between the clouds you can create two www records, one pointing to aws and the other to azure. Requests will then round robin between the two clouds.

Wrapping Up

And that is a wrap for this series where we showed how to use Terraform to build out environments both in AWS and Azure and move between the two. Terraform is extremely powerful and I further encourage you to learn more on how it can be used for enabling you to safely and predictably create, change, and improve infrastructure.

How to Visualize Your Cloud Deployments - Hava

October 21, 2018 Gabe Maentz

This is the third in a series of posts highlighting tools I have found particularly useful for visualizing AWS and Azure, including:

In this post we will take a look at Hava - https://www.hava.io/

Hava

Hava is a web based service that produces automated diagrams of your existing infrastructure and network topology in both AWS and Azure. Diagrams are created by connecting to your AWS and Azure accounts via a read only user account, that securely gathers all items in a VPC or Resource group. Connections, security groups, cost estimates are all things that Hava diagrams provide. Below is a simple diagram of an AWS deployment.

Azure Support

Unlike other visualization tools, Hava supports both AWS and Azure deployments. Resources of a given Azure resource group are diagramed and their details are provided. Azure diagraming supports versions which allow you to look a differences within a given resource group over time. Below is a diagram of an Azure deployment.

Benefits:

Of the three visualization tools compared in this series, Hava is the only one that supports both AWS and Azure. I really like the flexibility to diagram both, as it helps show case multi-cloud deployments.
Hava provides not only infrastructure diagrams but also includes a security view for it’s Professional users. This is helpful to visualize security group interactions.

Excellent support. As I have been using Hava, I have run into a few snags with the live updates. I was very pleased with the level of support provided to correct the issues. In fact the website provides a chat window so talk directly with support to get questions/issues answered. Kudos to the Hava team, and in particular Adam for his help.

Nice to Haves:

I have found the pricing of Hava to be out of many’s price range. To get the infrastructure and security views, which I believe is one of Hava’s biggest benefits, the cost is $99/month. This is double the price of the other offerings. If you strip out the security components they do have a $49/month offer which is reasonable for being able to diagram both AWS and Azure deployments.
Azure support is there, but currently feels like a second class citizen. AWS resources and diagrams are more robust and security views are not yet available for Azure.

Below is a cost model for the different Hava subscription levels.

Building the Fleet in Azure with Terraform

October 9, 2018 Gabe Maentz

In the series of Terraform posts we have shown how to effectively utilize Infrastructure as Code to build, deploy, scale, monitor and destroy a fleet of infrastructure across multiple regions in AWS. The beauty of Terraform is that while we may have used it to build out infrastructure in AWS, we can also extend it’s use to other cloud providers as well. As I see more and more organizations adopting a multi-cloud strategy, let’s take a look at what it would take to deploy our fleet into Azure.

Azure Specifics

If you are familiar with AWS, Azure provides many similar services and features. The Azure Terraform provider is used to interact with many of the Azure resources supported by Azure Resource Manager (AzureRM). A brief overview of the Azure resources will will utilize to move our fleet to Azure are:

Azure Authentication: Terraform supports authenticating to Azure through a Service Principal or the Azure CLI. A Service Principal is an application within Azure Active Directory whose authentication tokens can be used as the client_id, client_secret, and tenant_id fields needed by Terraform. Full details to create a service principle are well documented on the Terraform website.

Resource Group: Azure holds related resources for a given solution in a logical container called a Resource Group. You cannot deploy resources into Azure without assigning them to a Resource Group which we will create and manage via the Terraform Azure provider.

Virtual Network: Akin to a AWS VPC, Azure’s Virtual Network provides an isolated, private environment in the cloud. It is here where we will define our IP address range, subnets route tables and network gateways. This build will utilize the Azure network module maintained in the Terraform module registry.

Scalability: In order to scale our fleet to the appropriate size, Azure provides Azure’s Virtual Machine Scaling Set (VMSS). AWSS is similar to AWS Auto Scaling allowing us to create and manage a group of identical, load balanced, and autoscaling VMs. The fleet will be front ended by a load balancer so that we can grow/shrink without disruption and will utilize VMSS module up on my GitHub terraform_azure repository.

Deploy to Azure

For our initial Azure deployment will will create a new set of Terraform files, including a new main.tf to tie together the details of the Azure provider, modules and specifics for how we want to the fleet built. Inside the file we have declared our connection to Azure, the resource group to build, the virtual network details as well as the web server cluster. The VMSS module referenced also builds a jump server/bastion server in the event that you need to connect to the environment to do some troubleshooting. I have specified my Azure credentials as environment variables so that they are not included in this file.

All files to create this fleet in Azure including the main.tf, output.tf and VMSS module are available in the terraform_azure repository of my GitHub account.

We can initialize, plan and apply our deployment using Terraform and immediately see our Azure resources being built out through the Azure Portal and inside our devtest resource group.

Once the deployment is complete, we browse to the DNS name assigned to to the load balancer front ending our Azure VMSS group. This address displayed at the end of the Terraform output, as we included an output.tf file to list relevant information.

Browsing to the DNS name we can validate our deployment is now completed. At this time we can check the health of the deployment - remember there is a jump server that is accessible if needed.

Once you are happy with the state of the new fleet in Azure it can be torn down with a terraform destroy. I recommend doing this as we prepare for the next step in the series: Moving the Fleet from AWS to Azure.

This is part of a Terraform series in which we have covered:

How to Visualize Your Cloud deployments - Cloudcraft

October 4, 2018 Gabe Maentz

This is the second in a ‘series’ of posts highlighting tools I have found particularly useful for visualizing AWS and Azure, including:

In this post we will take a look at Cloudcraft.

Cloudcraft

Cloudcraft is an online diagraming tool that allows you to both create diagrams through a designer interface and also pull in live inventory from AWS via a secure connection. Cloudcraft is all in on AWS. In fact if you are doing a fair amount of work in AWS there is a good chance you are already familiar with Cloudcraft, but if not it is worth checking out. I liken their designer as a “Visio on Steroids” for AWS. The design below was built using the CloudCraft visual designer to illustrate a web app deployment on AWS.

Within the designer you can perform a search to highlight AWS components including a region, tag, or component name. Below we are highlighting all components in the us-east-1 region. This search could be refined for example to show all EC2 instances within the us-east-1 region tagged for production.

In addition to visualizing the deployment, Cloudcraft also offers a pretty impressive budget feature. This breaks down the anticipated cost and allows you to modify the design by exploring different compute, database, storage and networking sizes broken down by cost. When making changes within the budget view your design is automatically updated to reflect the updates. You can also export your design as a PDG for PNG, as well as share via a link to others on your team.

Once deployed, Cloudcraft offers a ‘Live’ mode as part of the professional subscription which allows you to discover and import your AWS inventory into the designer view. Below is the Cloudcraft visualization of the web application deployment highlighted in several of my Terraform posts.