Eighty20 Solutions | The state of Infrastructure as Code for Azure

24 May The state of Infrastructure as Code for Azure

Posted at 12:02h in News by Terry Antoniou

This post was co-authored by Sayan Ghosh, Cloud Practice Lead, Eighty20 Solutions and Michael Friedrich, Cloud Solution Architect – ISV, Microsoft Australia.

Why consider Infrastructure as Code

Infrastructure as Code (IaC) has become one of the most prominent trends in DevOps and cloud computing, as we spoke to our customers, partners and industry network, this is one of the foremost concerns on everyone’s mind. A recent study by Snyk suggests that 63% of survey respondents were just starting out with IaC, while only 7% feel they have implemented IaC to the best of current industry capabilities. Considering these statistics, Infrastructure as Code feels like a very relevant conversation to have. In addition to being a culmination of many years of automation practices which developers and engineers naturally warm up to, IaC provides several business benefits which makes it a must have requirement in cloud projects today.

Security and Governance – the topmost concern for organisations deploying applications at scale to the cloud.

ability to always deploy proven secure configuration
ability to perform automated security scanning and linting on code that produces infrastructure
ensure all secrets are contained in a key management solution and dynamically accessed
ensure role based access control so developers, testers or release managers don’t have root access to all environments

Governance and Consistency – helping managing cloud sprawl, spend optimisation and operational excellence.

ability to always deploy proven configuration following recommended practices
idempotent, i.e. respects the state of your environment without having to write additional logic to account for it
use consistent naming and tagging convention across the cloud estate
avoid configuration drift and misconfigurations across environments
controlled infrastructure code subject to same rigour and lifecycle controls as application source code

DevOps and Automation

eliminate time spent in manual engineering work for the same set of configuration being delivered over and over again
streamlined disaster recovery testing and orchestration
auto-scale and auto-provision, including just in time provisioning
integrate right into application DevOps processes and work

If we take an Australian independent software provider as an example – the benefits start at the very beginning of the sales cycle. Imagine a potential customer from The United States looking at your website pondering an upcoming project in the middle of the night in Australia. Now, a “try us” button on your website could trigger a DevOps pipeline which goes ahead and builds your demo environment in Azure, and then deploys the source code and initial data migrations – offering a ready environment for your prospect to try the software on – with an expiration date of 7 days! This will mean the prospect would have tried and loved the platform – and sent you a query for a production instance – even before you started your day! Compare that with a traditional lead which comes through for someone to get back in touch with the customer and initiate the conversation! It is all about shifting left in a world dominated by automation.

Let us also consider a large Enterprise bank operating an application estate across multiple private and public clouds. You are probably leveraging all of Azure, AWS, GCP, Oracle and IBM clouds for certain specific workloads, using various SaaS platforms and hosting workloads in VMware based virtualisation environment. The ability to drive consistency and delivery velocity across these platforms, disparate internal and external teams, numerous stakeholders and internal organisations is key to your infrastructure strategy. Infrastructure as code artefacts plug straight into the request management systems (such as ServiceNow) for provisioning and governance, eliminating the delay from manual provisioning and deliver functional, well-governed environments in minutes to the application teams.

How to implement Infrastructure as Code

With the business value from IaC being quite clear, the conversation often steers into how – what tools should I use, and why? This space is crowded and one is spoiled for choices. The final decision, as always, depends on context and what we want the IaC toolkit to deliver for us. The Snyk survey puts this into perspective with “The opportunity is still wide open for most organizations to lay a firm foundation and implement the right tools and practices before widely adopting IaC.”.

Let us take a closer look at what’s there –

HashiCorp Terraform is the leader in the infrastructure as code space and should be credited with making IaC so successful and popular – in the mainstream and the enterprise. We believe this is a strong choice for organisations managing large and complex infrastructure across multiple platforms – multi-cloud, private cloud, software as a service etc, – as Terraform works based on providers and there are many of them available. Putting in an Azure specific lens, Terraform is an awesome choice and Azure has embraced Terraform and amped up the support for the provider. However, in practical scenarios, we come across clients who worry about support for relatively new services in Azure, including preview ones. The Terraform provider does not provide zero day support – which makes complete sense from their perspective as an enterprise offering, but also means that for certain properties and services, you will end up leveraging certain work arounds such as calling an ARM template from within Terraform.

CDK for Terraform – While domain specific languages are fit for purpose for IaC, they are not programming languages and if developers are the ones authoring IaC artefacts, they have fierce allegiance to their favoured programming languages. CDK for Terraform brings in support for languages like Python and TypeScript into Terraform – so you can author your infrastructure in a language of your choice. An exciting development and great to see the contribution and support from our friends at AWS. I still remember how excited I was at the launch for CDK and that hasn’t changed a bit.

ARM templates – the traditional and native method of delivering IaC on Azure – JSON templates. ARM is preferred by many pure Azure houses, i.e., organisations that use primarily Azure as their infrastructure platform. The obvious advantage is zero day support, pretty much anything that you can do using the Azure portal goes through the ARM APIs, which means you can use ARM templates to define them. The downside, however, is that JSON is supposed to be machine readable and ARM templates can be verbose. Not the easiest of development languages out there. The Snyk survey shows 30% of users using ARM templates, and 80% using the cloud platform specific options from Azure, AWS and GCP.

Azure Bicep – Enter project Azure Bicep, a new Microsoft initiative to provide a domain specific language (somewhat like HashiCorp Configuration Language used by Terraform). Bicep code gets “transpiled” into ARM templates and therefore provides a much more elegant, simpler way to write your IaC, but retain the coverage of ARM. Having recently released v0.3, the team states that Bicep is now supported by Microsoft Support Plans and Bicep has 100% parity with what can be accomplished with ARM Templates. There are no breaking changes currently planned, but it is still possible they will need to be made in the future. We are very excited about Bicep as it delivers a very strong authoring experience without losing the ability to define cutting-edge Azure services. Having used Bicep in a recent project, we are excited about the productivity gains this gives teams and are looking forward to embrace this going forward.

Pulumi – Having covered CDK above, the merits of using a conventional programming language for IaC is already established. Pulumi is a brilliant solution which covers a wide range of infrastructure platforms and the ability to use your favourite programming language – TypeScript, Python, C# and Go. The native Azure provider for Pulumi offers same day support for Azure resources with native integration to the ARM API layer, which combines a lot of the benefits seen above and makes this a great choice combining a lot of value demonstrated by the choices above.

Honourable mentions –

Cloud Maker – A fantastic product which allows you to visually design Azure environments and either deploy them or integrate with Azure DevOps pipelines.

Farmer – a .NET based DSL option which is also quite elegant and can be an interesting choice.

Infrastructure as Code - Where to from here?

So where does that leave you in terms of the next steps? It depends on what your focus areas are. If you are primarily an Azure shop – we would recommend a close look at Bicep; while if you are looking at a multi-cloud estate, Terraform is the top bet while Pulumi or CDK represent strong choices if you wanted to use traditional programming languages over domain specific languages. We quite like the summary by John Gallant – Bicep vs Terraform – A fair and balanced comparison – YouTube, which looks at both options and shows the relative strengths. At the end of the day, IaC is a strategic infrastructure investment and key component of your platform strategy so we recommend you spend time on the decision and validate with all your technical stakeholders who will be involved as part of your Cloud Operating Model.

At Eighty20 Solutions, our goal is to deliver technology transformations in a faster, simpler, and more collaborative manner working with our clients. If you are looking at a cloud journey and are looking at partners who get in the trenches, work shoulder to shoulder with your team, and stay the course, while you help your organisation to sustain long-term, strategic technology investments, embrace change, and realise benefits – as opposed to leaving the teams grappling with shiny new technical debt – reach out to us today!