This is my journey into Infrastructure as Code, and let me tell you, it is still an ongoing journey.
A long time ago, back in 2004, I started as a sysadmin apprentice working with on-premises Microsoft Enterprise technology. Troubleshooted some batch-script and made some minor Powershell-scripts on my way, but it was 95% click-ops.

January 2012 I went from Sysadmin to IT Consultant, and went head-first into Office 365 and Windows Azure. I even got to experience some customers on BPOS (Business Productivity Suite), the predecessor to Office 365. There where some PowerShell-scripting with Office 365, but Windows Azure (Classic) wasn’t nearly anything like Azure is today. IaaC/IaC wasn’t a buzzword yet, but we started using PowerShell to create some Windows Azure resources.

The years went by, and it was mostly click-ops doing Office 365 migrations. It wasn’t until 2014 Microsoft renamed Windows Azure to Azure and launched what we today know as the Azure Portal.
This re-launch of Azure and the Azure Portal was the remake necessary to later give us Azure Resource Manager with IaC Templates (ARM templates).
AzureRM (PowerShell module) was released in 2018 and that’s when ARM Templates immerged to the surface and at least for me started the journey towards IaC. Using JSON files with ARM describing the infrastructure, deployed into Azure with PowerShell.
But I didn’t venture down that rabbit whole. It was quite a high doorstep from click-ops to writing the architecture in code. I didn’t do it over and over again, so it wasn’t timesaving for me. The Azure Portal was saving us a lot of time already, and most time we spent inside the operating systems. The architecture in Azure wasn’t that complicated. It wasn’t large enterprise landing scales, third party firewalls and hub/spoke network designs.
Even in 2018 I was still writing more PowerShell scripts for Office 365, then I was writing code for infrastructure in Azure. Or migrating customers from ADFS to Azure AD (click-ops). Or deploying Azure AD Join and Intune managed devices (click-ops). Or implementing Information Protection. Or implementing Conditional Access strategies. Or Azure projects by click-ops.
I did start to play with ARM templates and Github, as we didn’t have Azure DevOps yet. But being my private repositories, it wasn’t that useful to learn how we work with repos and commits. I didn’t use any pipeline or co-writing code at this time.
In 2019 I was hired to do the infrastructure for a Dynamics 365 project, where the infrastructure where part of the agile process of developing Dynamics 365 for the a customer. This was where I met the practical difficulties of agile developing infrastructure. Even in 2020 it was something sysadmins didn’t comprehend, and trying to keep up with an agile development working project working with one and two week sprints. It wasn’t easy. But I also managed to pass Azure DevOps Solutions exam, and was on a roll to prove my expertise in Azure, Office 365 and Device Management.

But it was a major experience for me, and I started believing this was something I just had to master, for the future of my career. That is when I blogged about Azure Lighthouse setup using Azure DevOps, because we had to manage the infrastructure across multiple Azure AD tenants and Azure Subscriptions. A big thanks to all developers in that project, practically introducing me to agile development and the community for helping at lost soul navigate.
I think everyone was surprised my primary personal goal with the project, was to get more comfortable writing code. Or that is how I thought of it. And being in a developer team I was hoping for the push and cheering I needed. This is also the time I went from using PowerShell ISE to Visual Studio Code. I cannot recommend this change enough. Sadly I wasn’t there long enough to see it born to life, but I am grateful for the experience and all the developers I met during this project.
Life and career went on, but not much changed. I have always had device management and identity as side-hustle, so I went on doing that type of projects for some time.

Now it is October 2022 and I still feel like I need to really start using IaC. It feels like I should start all over again, but what do I do different this time? How would I recommend you start using IaC?
Number 1, read and learn other peoples journey to IaC, and share my own journey so far.
Many before me have made the same journey from Sysadmin click-ops to IaC, like my two colleagues Truls Dahlsveen and Tor Ivar Asbølmo.
Number 2, read, learn and try the different type of IaC today.
My colleague Tor Ivar over at codewithme.cloud has a great post about the different tools available to use IaC today, Exploring the basics – Choosing the right IaC tool.
Number 3, find the opportunities to use IaC.
As a consultant you don’t always get the projects you want, they might not be looking for a consultant right now. Or other projects are more in need of your side-hustles at the moment.
So how can we start practicing IaC without a project? You can make your own project, for instance like Tor Ivar did by moving his blog from WordPress to Azure: WordPress to static hosting with Hugo.
Or create your own Contoso and simulate creating infrastructure with IaC. Because what I have learned from all these years, you have to do the work yourself. It will not come to you as miracle, and we are not born with coding abilities. It sounds cliché, but it is also true when it comes to manage IaC.
If you made it all down here, thank you very much for reading and I hope it was helpful to you.
I will continue to report on my journey in the future and it is very helpful to revisit your past some times. It can open your eyes and give you new angle to attack again.
Leave a Reply
You must be logged in to post a comment.