Opinion Piece on Infra as Code.
This post is a bit of a departure from my normal posts about technical aspects of creating solutions in the cloud. Recently while chatting with some experienced practitioners of cloud, the discussion moved to the merits of different systems of Infrastructure as Code. ( IaC ). For some context I’ve deployed solutions using click-ops in the console, the cli, some hand-crafted shell and python scripts, Terraform, Cloud-Formation, CDK, and most recently had a play with WingLang.
The internet is littered with comparisons between the different approaches for IaC, some of them go as far as to say, ‘XYZ is best’. I’m often left thinking best for what? and best for who? One thing that cloud computing has given us is a plethora of choice, and infra as code is no different. It can be quite a dizzying situation.
As advocates of IaC, we must not lose sight of the end goal. The end goal is not the IaC process itself; it’s getting reliable, secure solutions deployed that solve real problems and deliver real value. Part of the value proposition comes from return on investment. Maximizing the ROI is really important and its worth considering. There is always a sweet spot, and you can both under and over invest in your approach, and this should drive your choices about IaC.
If you want to win the Olympic 100meters, you will need to invest more in training than a run around the block on Saturday morning. You’ll be fully invested with a complex regime. If your objective is just to remain healthy, then a few hours a week probably is enough.
Likewise with deploying solutions to the cloud. You might just be able to make something work, with a pre-canned wizard. An example of this is AWS light sail. Just a few clicks and you can have a reasonably useful website in a few minutes. The time required is minimal, and you’ve got your thing going, as long as your thing, was exactly what was on the tin! This is the equivalent of being a couch potato and ordering dinner from uber-eats. But You’re going to be exhausted if you tried to run to the end of the road.
You might be able to get a ‘simple’ solution going with click-ops. You’ll need to learn how the console works and a few cloud concepts. It’s likely the solution may have some non-optimal security or operational considerations, but that may be acceptable. A bit more complex than a wizard, but you’ll not have a heart attack after running 5km on the flat.
A more complex problem may come along, that lends itself well to a solution using a declarative solution like Terraform or CloudFormation. You’ll get the advantages of good pipeline deployments, and version control. It comes at a cost. There is an effort to learn CF or HCL, both of which are specific styles of defining what infrastructure should look like. It’s quite flat, and to some extent you are providing a long list of all the things that need configuring. There is not much you can’t do with Cloud Formation and Terraform, if you work with it hard enough and long enough. Most ‘engineering type’ folks can get going with this way of doing things with some training investment. You will be able to run the London Marathon and probably get across the finish line before its dark, and they let the traffic back on the road.
After a while, of doing things declaratively, some folks will see that there’s lots of common patterns and things that probably could be done faster and better and quicker by a ‘machine running some code’ that a human. A good example of this, is dealing with IAM policy. IAM policies are time consuming to create properly, and prone to error. This is where a programmatic approach to doing IAC can come into its own. What was many lines in a declarative approach can be reduced to just a few lines of ‘code’, written in a general purpose programming language. For a proficient user of a programmatic approach, there is an opportunity to get dramatic improvement in the time it takes to get a working solution. The cost of this proficiency however is an investment in learning how it works. Not only will you be fast, you’ll be able to produce great results, and you’ll probably be in contention to enter the 100m at the Olympics. Examples of this are AWS CDK, cdk-tf ( Hashicorp CDK for Terraform ). Both of these offer the choice of using python, typescript, Golang, java and dotnet to program your infra and app.
Do you see the pattern?
The more efficient, and flexible methods of approaching infrastructure deployment, take more effort to learn and master. But once proficient, there is considerable gain to be had. My personal experience has been that it was a hard slog to get proficient with aws-cdk. I did not have a strong programming / development background, and much of what I have had to learn was learning about typescript and python. Several of my younger colleagues who learned programing at university, were up and running much faster than me, it was almost a natural approach, ‘Oh just use these library’s, no problem.. got it. and they were checking in code later in the afternoon. Perhaps part of my problem was having to unlearn the habits and thinking from a time when floppy disks were still a thing.
Ultimately there is no ‘golden rule’ or best practice that you can just steal from everyone else. You have to work out what is best for you. Your project or current job may not permit you the time or effort to become confident with programatic approaches to IaC. It may not even be sensible to make the investment if you only have one or two jobs to do. For me, the investment has paid off in spades, as using a programmatic approach to IaC, is something I use every day. Your project or job may also benefit from it to.
My call to action is to ask you to try something new. Don’t spend too much effort trying to think about if it might work for you, instead have a go, you’ll have a much better idea, based on your actual experience.
I’d love to hear what you think about this. By all means tell me if i’m totally wrong! You may well find me lurking in the cloud networking automation slack group. Please pop in!
Leave a Reply