Terraform

For many moons, importing existing infrastructure (that is to say, infrastructure running outside of Terraform state), has not been a trivial task. Historically, Terraform did not generate any configuration. You would have to write the infrastructure-as-code in a manner that reflects how it was deployed. Then, to make matters not easier, you would fetch the ‘ol shovel and dig out the unique resource identifiers to feed through the command line. Handling a single resource in this manner is pretty simple. Wrangling 20+ resources like this is not. Last month, Terraform v1.5.0 was released, offering the ability to use import blocks. Let’s test this new feature on my favorite infrastructure provider, Alkira.

What fits somewhere in between re:Invent and Community Day events? That would be the AWS Summits! This year, I got to experience a double dose of fun by representing Alkira at our booth and presenting at the AWS Community Developer Lounge. I may be biased, but I believe the Alkira team is the best in the world.

Usually, when it comes to technology, my grandmother doesn’t know much because she doesn’t care. What is the cloud? How to install a new browser on her laptop? What is 2FA? I might be speaking French to her as I discuss these things. Yet, she knows what ChatGPT is. This shows the vast amount of publicity, hype, and polarization that has ensued since November 2022. I tend to avoid AI fear-mongering and focus more on, how could a tool like this help enhance my daily grind? Can ChatGPT write Terraform as elegantly as a poem written from the perspective of Samuel L. Jackson in Pulp Fiction? Let’s take it for a spin on AWS using infrastructure-as-code.

Blowing out cloud spend is an easy thing to do. This McKinsey Report notes that 80% of enterprises consider managing cloud spend a challenge. I recently presented at the Cloud Security Alliance in Kansas City and had the opportunity to network with some tremendous DevOps and Security professionals. One excellent side conversation somehow transitioned to a deep discussion on better ways to understand cost implications in the era of infrastructure-as-code. Shouldn’t cost be someone else’s problem?

Optional attributes for object type constraints is almost here! I’ve been waiting for this feature to come along for a while. I have tested it extensively in -alpha, and I can confidently confirm that it is a game changer. This feature is long in the making, being discussed as far back as this thread in 2018. Today, it is now in beta, so the official release could be any day now. Let’s demonstrate how this is useful and build some common AWS infrastructure.

There is a reason why enterprises prefer the best-of-breed approach to connect and secure their network and intellectual property. Alkira announced its integration with Fortinet at AWS re:Inforce in July, and this is a perfect example of the best in action. As anyone that reads my blog knows, I have an automation first approach to everything. Alkira’s Terraform Provider is Fortinet ready, so let’s take it for a spin!

Anyone that has worked in tech knows that building greenfield is much easier than dragging along brownfield environments through a roller-coaster they aren’t ready for. Tools like Terraform make infrastructure-as-code a breeze, but what about all that infrastructure you already have provisioned? April Edwards, Cloud Advocate at Microsoft, recently posted a blog about Azure Terrafy, a new tool in preview which aims to simplify the process. You can find the original blog here. Let’s take it for a spin!

In Part 1, we laid out our foundation. In Part 2 and Part 3 we connected various networks (both cloud and on-premises) and provisioned NGFWs that scale to real-time capacity. By default, networks connected to our corporate segment have full-mesh connectivity to each other. Let’s build some policies in code that can work with the groups we created to produce logical micro-segmentation that mirror a few real-world use cases.

Check out Part 1 and Part 2 where we put together a scalable foundation and connect cloud networks from AWS, Azure, and GCP. For Part 3, we will bring on-premises back into the spotlight and connect some sites over Cisco SD-WAN and IPSEC.

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.

HashiCorp’s Terraform needs no introduction. It is all but the de facto vehicle for delivering cloud infrastructure, and for a good reason. What Terraform did for Multi-Cloud Infrastructure as Code, is precisely what Alkira does for the network. What happens when you use these two platforms together to deliver networking in and across clouds? If providing network services in code faster than ever before sounds interesting, this multi-part series is for you. Need a quick primer on Alkira? You can read up here.

Effectively automating infrastructure is no longer a luxury but a staple in the enterprise move through future transformation. I wrote a blog recently about using Terraform with Packer together, and wanted to take this thought further with breaking down Terraform Modules and getting well connected with Terraform Cloud. I recently put together a simple module for building base infrastructure in AWS for the purpose of testing Alkira Network Cloud. Let’s dive in!