Software developers first came up with the idea of Infrastructure as Code (IaC) to address the problems with manual or manually executed script deployments to servers. The proliferation of public cloud and the perception of unlimited scale and instant availability only calls greater attention to the issues of slow, unreliable deployment. Infrastructure as Code ultimately offers more stable environments at a rapid pace and high scale.
To get to the bottom line, mastering Infrastructure as Code on any platform is a great way to make yourself not only relevant in 2019, but an essential part of your organizations DevOps practice. We're going to do our best to help IT Pros grow your IaC skills in a new series we're calling "100 Days of Infrastructure as Code in Azure".
Our goal for the series is to provide 100 valuable tips, insights and recommendations you can consume in 5 minutes or less, and begin incorporating into your Infrastructure-as-Code practices immediately.
We'll touch on a wide variety of topics over the next 100 days:
- We'll talk about declarative and idempotent deployment in many contexts.
- We'll talk DevOps tooling, from VS Code to Azure DevOps and beyond.
- We'll talk about a wide variety of Azure concepts that will help you advance your IaC and DevOps practices.
- We'll talk about CI and CD (Continuous Integration/Continuous Deployment) in the context of Infrastructure as Code.
- We'll talk about source control for IaC artifacts.
- And we'll talk about topics that come from your questions.
Have a topic you want to ask us to cover? Submit your suggestion as an Issue in the series GitHub Repo.
Our end game here is to help you become a key component of DevOps success in your organization. So let's eliminate one excuse right away. The all-to-common declaration "we're doing CI, but we are not ready for CD" is one we cannot (or at least will not) abide. This is generally an excuse to put off planning your CD strategy, and a recipe for long-term deployment immaturity.
It was Laura Thomson, Senior Director Of Engineering, Firefox Engineering Operations, who perhaps said it best:
You should build the capability for continuous deployment even if you never intend to do continuous deployment. The machinery is more important than your deployment velocity.
This declaration, which Laura made back in the early days of DevOps, was spoken at a time when her organization was not yet ready for CD in production. However, they had all the tooling in place for when the time came. Her words point to the importance of building this capability early your evolution.
This holds true for Infrastructure-as-Code as well; where automated, idempotent, deployment is really essential. (what good is great application code if it's deployed to dodgy cloud infrastructure?) If your development org is not using CD in production, here's your chance to get the ball rolling with CD in dev, test, or staging environments.
To keep it simple, if you strive for "no infrastructure deployment to production outside of a pipeline", you are heading in a good direction.
As Frederick Douglass said, "If there is no struggle, there is no progress". You will, without a doubt, struggle at multiple points in the process of growing your IaC skills. But if you do anything for 100 days, even in small amounts, you will become more proficient. As Einstein said, "It’s not that I’m so smart, it’s just that I stay with problems longer".
So tomorrow we'll "begin at the beginning" in this journey of a 100 days of IaC in Azure.
See you tomorrow!