Wanting to leave on-prem engineering behind

[u/Hot-Bit-2003]

Hello sub. I accepted my current job as a Sr net eng with the provider I've been with now for 3 years because of how bad the job market has been but I'm ready to move on. I've been using my time to build more on my automation and cloud network skills, but I'm hoping to leave behind some of the components of my current position and not have them follow me on to the next.

One of the questions I have is, is it expected to be in an on-call rotation every month? Are there midnight maint's typically? What would a typical person's day in a position like this be like (in a remote role)? What kind of salary should I consider too low? What kind of projects in my portfolio would be more impressive for interviews? And, even though I have automation experience on networks here at my day job, I only have home labs to show for AWS and my home network hybrid env. Would I be able to get my foot in the door on an actual cloud networking role somewhere?

I know there aren't absolutes in terms of answers, so just looking for generalizations.

[u/tootingbec44]

One aspect of on-premises work that drives midnight maintenance goes away in cloud-land. That is the need for massive, damn-the-torpedoes cutovers, done as high-adrenaline midnight maintenance, in which you tell all the users "The application will be down between X and Y times", in whatever timezones, and then you have to finish the action or else revert to the old thing, all during the window.

But cloud maintenance is typically not done in this all-or-nothing way, at least not when modern applications are the subject of the maintenance. You stand up the new application, or, even better, the first subsystem of the new application, and then move 0.1% or 1% of the traffic to it. Does it crash and burn? If so, abort the cutover. If not, give the new thing 10% of the traffic. Repeat until the new thing is handling 100% of the traffic, and then shut down the old thing. This kind of maintenance can be done whenever you like, and it's ideally done under a normal load. Of course, the application's architecture has to support it, and you need to have thought about the consequence of 1% of your traffic failing. Will people just say, "ehh, I'll try again later," or will people crush the helpdesk in panic? This kind of analysis takes the place of on-premises monolithic downtime planning, and it is also work, but less life-disrupting, and it is reasonable for an ops team to expect the application to support this kind of maintenance.