The Cloud -- Don't Be the Driver, Be the Mechanic
In this opinion post, I am arguing why knowledge of how infrastructure works is still as important as ever.
Maintaining Your Car
Have you ever taken your car, automobile, or horseless carriage, depending on what terminology you use, to a mechanic and watched them work? I recently had a breakdown on Ireland’s busiest road. I called my roadside rescue service and a mechanic was out pretty quickly. Once we had the car at a safer location, the mechanic went to work. He asked me about any alerts I saw, which I reported. He asked about any symptoms, which I reported.
Say Goodbye to Traditional PC Lifecycle Management
Traditional IT tools, including Microsoft SCCM, Ghost Solution Suite, and KACE, often require considerable custom configurations by T3 technicians (an expensive and often elusive IT resource) to enable management of a hybrid onsite + remote workforce. In many cases, even with the best resources, organizations are finding that these on-premise tools simply cannot support remote endpoints consistently and reliably due to infrastructure limitations.
And then the mechanic did what all mechanics do. He took out a little gadget and plugged it into the car. This is the equivalent of asking a computer, “Hey, what is wrong?” After a second or two, the gadget reported that the car had no errors but the car still did not want to start.
The engine attempted to ignite but it sounded like it was starved of fuel. After some attempts to start the car, the mechanic used his knowledge, experience, and skill. He took out a spanner, tapped the engine (I am not kidding), and asked me to try to start it … And, it started. It died a minute later but the mechanic knew the cause. It was a thing called a solenoid on the fuel pump that was jamming. Every time he tapped this tiny component, the jam cleared and after a while, it jammed again.
I am a perfectly good driver (others might disagree with that self-assessment) but I was useless at troubleshooting the problem. My solution was to call the mechanic. When you are the IT pro, supposedly, the IT mechanic for your organization, is this a good solution?
Relating this to Azure
So what has my breakdown got to do with Azure? Sitting there gave me plenty of time to think, especially because I had just done 5 hours of driving to-and-from a customer to talk about Azure. We are getting to a point where Azure is getting easier to deploy. Whether you want to deploy a single web server or a big SharePoint farm, Microsoft has shared pre-canned templates that make it possible with just a few clicks.
- Deploy an Active Directory in virtual machines with the domain of your choice
- Configured a highly available RDS farm and shared the desktop
All I had to do was add some users into AD and sign into the RDS farm! I did not need to know a thing about storage accounts, managed disks, virtual machine configurations, virtual networks, load balancers, NAT rules, network security groups, and all that jazz! It was Azure-time and the deployment was easy.
Be the Mechanic
What if something breaks in the above SharePoint farm? What if I am asked to expand out a tier or add a virtual network? What if security rules need to be restored? Maybe there is a performance problem. Do I know what do if there are IOPS or throughput issues on the storage of my database machines? By doing a click-the-wizard deployment and sipping coffee, I could become the driver. And that is bad because that is not exactly career enhancing.
I am an advocate of knowledge. I have spent the last 16 years of my career focusing on learning and in times like this, re-learning. One cannot just jump into a cloud such as AWS or Azure and expect that skills will transfer. Some do. Sizing an RDS farm on-premises is no different to sizing one in Azure but you have to understand how the pieces work, how it ties together, and what the implications are of each design or implementation choice. Like the mechanic that saved me, it is not enough to rely on some device. Knowledge, experience, and a little bit of gut feeling are the keys to success.
In my day job, I have seen quite a few styles of deployment. The have-a-go-heroes often end up with problems. Those that do not learn how to use Azure and its tooling are the ones that face problems. Those problems might be immediate but more often, the problems sneak up on them. Then there are the people who read and listen. They are the ones that learn how to use the cloud that they are adopting. Not only do their employers and customers have a better experience but their engineers also have an easier time. Their engineers are often spending less time on the eventual firefighting and excuse-creating.
I know, you are under constant pressure for time. There is always another fire to put out. You do not have time to learn how to do things correctly, let alone keep up with the constant change in the cloud. But do you really want to build a solution using kindling or do you want a fire-resistant architecture? My advice is that you learn how Azure (or AWS, Google, IBM, etc) works and use the tools and best practices that it offers. Going cowboy will only get you lynched!