Cloud

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.

In Part 1, we talked about the origins of the Site-to-Site VPN Service in AWS. As consumers began to scale in the early days, they faced tunnel sprawl, performance constraints, and the need for a simplified design. AWS responded with Transit Gateway. How did Transit Gateway simplify architecture leading to smoother operations, better network performance, and a scalable blueprint for the future network?

The necessity for protocols to keep communication secure has been around since the dawn of the internet. The first ever VPN was jointly developed by a vendor consortium (which included Microsoft) in 1996, and came in the form of Point-to-Point Tunneling Protocol. Although many are skeptical about the value of VPNs in 2022 and beyond, customer consumption of cloud provider VPN services have paved the way for additional features and exponential scale.

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!

The year is 2022, and Kubernetes is wreaking havoc on software delivery as we know it. Applications are going through modernization programs so they can be converted into microservices, but they are coming out the other end as distributed monoliths. Next thing you know, services exist across several clouds and even in your data centers. And, of course, the large majority of enterprises aren’t just greenfield.

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.