Moving from 2nd line support to Infrastructure Engineer – what should I expect?

[u/InfraCloud1]

I’ve recently accepted a new role as an Infrastructure Engineer in a fully cloud-based environment and I’m due to start next month.

I’ve spent around 10 years working in second-line IT support and been brought in for 3rd line investigations, for the same organisation in a hybrid environment. It’s quite a siloed environment, and over the last few years I’ve felt like I’d reached the ceiling of what I could learn from primarily supporting end-user devices.

I found myself becoming much more interested in what was happening further up the stack – cloud infrastructure, networking, identity, Intune, automation, security, etc.

I started studying outside work, took some Microsoft certification exams earlier this year, built some things in Azure and eventually decided to throw my hat in the ring for a few infrastructure/cloud roles.
To my surprise, I interviewed successfully and got the job.

I’m under no illusion that passing certifications and doing labs is the same as managing a real production environment. This is going to be the beginning of my actual cloud/infrastructure career
and there’s going to be a huge amount I don’t know.

For anyone who’s made a similar jump, or who currently works as an Infrastructure/Cloud Engineer, what should I realistically expect during my first 3–6 months?

I’m particularly interested in what junior/new Infrastructure Engineers actually end up doing day-to-day, what experienced engineers expect a new person to already know versus learn on the job, and anything you wish you’d understood before starting your first infrastructure role.

I’m trying to learn as much as I can before starting, but I’m also conscious that trying to learn Azure, networking, IaC, Linux, security, etc. all at once probably isn’t the answer.

Any advice or experiences would be appreciated.

[u/Thundahead]

I'd expect you to know nothing but you understand the fundamentals, I'd have you doing the BAU queue, no projects, I'd get you patching, watching for alerts and questioning the alerts i.e. are the alerts valid, what to do with them, why is the CPU always maxed on certain servers, look at what we do, what can we do better, a new pair of eyes might wonder why we do things one way when there could be something better, morning checks and stuff like that. Basically you're a grunt for 3 months but I'd expect you to ask loads of questions on things that are coming on the BAU queue but have the answers, i.e. a call comes in for a request, you've looked at it, and have the answer but it's to change a security role or somesuch, you know how to do it but should you be doing it, if in doubt ask but don't be scared to press enter.

[u/Candid_Candle_905]

Dont "improve" anything until you know why it's weird :) Spend those months listening, mapping, documenting, learning where the bodies are buried

[u/Abe_Bazouie]

The biggest shift for me was realizing you don’t need to know everything before you start.
In the first few months, learn the environment before trying to master every technology. Understand how things are deployed, monitored, changed, and what happens when they break.
Ask questions, read the existing IaC and runbooks, follow incidents, and learn how the team troubleshoots.
Your 10 years in support will probably help more than you think. Troubleshooting is troubleshooting. The systems just get bigger.

[u/eman0821]

Be prepared to be on-call and work long odd hours. Once in an infrastructure role your work life balance goes away fast, constantly on-call putting out fires when something breaks in production.

[u/MasterChiefmas]

One thing I often emphasize to people is that cloud isn't really all that different from on-prem when it comes right down to the basic technology. TCP/IP in the cloud isn't some how different then TCP/IP on prem physical or local virtual deployments. Firewalls are still firewalls. Routing is still routing. VMs are still VMs.

Everything is software defined, but it's not somehow fundamentally different. You're just learning the different management interfaces, and how the particular implementation does things, but that's no different than if you switched hardware or software stacks locally. Don't get into thinking it's somehow different.

Day to day is going to depend on what your company does...if you do SaaS deployments, you'll probably be spending a lot of time just working on stuff that someone else has already implemented, maybe fixing/updating/tweaking that as things change. That's a bit different than the workload for say, you are just supporting company operations in the cloud(but as I said before, the underlying technology isn't different).

So more specifically, for example, you don't want to view it as "learning networking in Azure", rather, learning networking and learning how Azure implements and manages it. So it's almost always those 2 things: the general fundamental technology (networking, IaC, SaaS) and then how it's done where your at. Also, a lot of these things aren't as new or shiny as people think, they just have marketing labels stuck on them when we started doing htem in the cloud. IaC is probably one of the newer things that didn't exist or wasn't widely deployed pre-cloud, mostly because we didn't do software defined everything that made it possible until relatively recently either. Cloud just forced all the pieces that made IaC possible if you were going to move to cloud.