So you want to get a job in Devops. Or maybe the first step is that being a question.
Devops is a "new" tech buzzword. It's the combination of code and infrastructure and the pursuit of automation of these resources. Getting a job in Devops means you understand lots of aspects of modern computing and it's far from an extension of your typical OS or desktop experience.
Here's my advice, you're always going to start out using the console/GUI to do things. In Windows Server, that's similar to a Windows desktop experience. You have all the familiar things like the Start button and Wizards for installing/configuring applications. In Linux, this is more abstracted by using Bash, or maybe you're using Gnome or something else, but primarily using a Terminal to configure and execute. Abstracted further, if you understand virtualization, maybe you're using VMware, or Hyper-V or public Cloud infrastructure, but in any way you use computing, you're usually starting out using a console.
Now do it using code. PowerShell for Windows, Chef/Puppet/Ansible for Linux. Use images in Cloud, Cloudformation in AWS, AzureRM/JSON in Azure. Whatever you're doing by button-fucking, do it with code, and now you're on your way to being a Devops Engineer. Pass some certification tests. This doesn't mean you know everything. In fact, it means you know the basics. Certs represent as baseline of understanding, much like getting a degree in College. They represent a commitment to a subject or subjects, but they are far from being as valuable as real world experience. They represent your desire to learn so much about a subject, that a manufacturer of that product says, "Yup, this person knows some shit."
Get a job in tech. You may have to start out doing shit you don't like, like desktop support. I started out as a Helpdesk tech in a local municipality. It sucked, but I showed initiative at work, and I sponged up as much information as possible. Within a year, I was promoted to a Tier 2 position. I kept learning more about enterprise networking and routing, virtualization in a datacenter environment using VMware, physical rack-and-stack servers, physical SANs and related media. Within another year, I was promoted to a System Admin(Tier 3). This is where I really cut my teeth with private cloud infrastructure. I stood up and replaced servers, I was responsible for data backups, I managed and maintained Active Directory, Exchange, File Server Resource Manager, and Systems Center. I implemented new changes that brought value, like Quotas on SMB shares, and disaster recovery by utilizing high availability and fault tolerant architectures. As soon as I vested, and I decided I was ready for a change, I found a job at a Managed Services Provider.
These are companies that sell IT as a service. Here, I was exposed to hundreds of environments. They teach you about how people fuck things up. They teach you about
leveraging best practices. They teach you why you never want to do it
certain ways. And you'll spend countless late nights deciphering
someone's bad decision. You'll have to be a garbage man for awhile.
Then I shifted to Public Cloud. I got all my certifications-8 in Azure, 2 in AWS, 1 in GCP. I spent a year
and half, heads down, studying, learning, passing tests. I proved to
people that I knew the basics. When you combine that with my actual
experience, demonstrable skills in understanding how computing,
networking, systems, and virtualization work, I was 10x better than
anyone else. Right now, the market is flooded with two options, people
who never touched traditional infrastructure, and those that think they
know everything already. Being in the middle is a rare commodity. Most
people coming into Devops come from a software engineering background
where they learned how to do some cloud because they needed it for
software deployment reasons. But there is a real gap for people who
learned with traditional infrastructure, Windows, VMware or Hyper-V, and
then move into cloud. Along the way, I picked up PowerShell. I use it
everyday. I used it to manage Server, Exchange, Active Directory, if I
could do it in GUI, I wanted to do it with PowerShell. I work everyday
to eliminate toil. I don't like button-fucking. If it takes 2-3x as
long to do it with code, yeah it sucks now, but it's going to save me
hours on the other end when I'm using it. I promise and I deliver. The only thing consistent in IT is that everything is going to change. So, roll with the punches.
I updated my LinkedIn. I set the flag that says I'm "Open to work". I put in "Cloud Engineer, Devops Engineer, Cloud Support" as the roles I wanted to hear about. Recruiters started to hit me up. Even if I didn't like the opportunity, I still responded and said no thank you. This increased my "score" rank in Recruiter searches. No matter what, I don't like my time being wasted and certain requirements, like a high enough salary, or lack thereof, are a deal-breaker. Don't be afraid to advocate for yourself, to say no, and tell recruiters what you need in order to make a move. In my opinion, most have appreciated the transparency.
I'm never not interviewing. It's the way I always sound confident.
When you've answered a similar question 50 times, you sound like you know
the answer. Finally, If you like this kind of stuff, learn about CI/CD like dev cycles/methods and pipelines. Github, Gitlab, Bitbucket, Azure Devops. ITIL processes. Cloud Adoption Framework. Well-Architected framework. Sign up for Azure free tier, find a terraform course that walks your through step-by-step. I use Whizlabs.com for all my cert training.
Learn Terraform and you'll become one of the highest paid Engineers on the planet. Everything you just went through, years of learning about virtualization, using and running Windows or Linux servers, understanding enterprise networking and routing, executing PowerShell or Bash, all becomes useful when you start to use Terraform. Infrastructure as code is the foundational building block of devops and automation. Terraform isn't the only thing that does this. CloudFormation, AzureRM templates/JSON, etc are the same, but different. Building resources with code means that whatever you can do with it is repeatable, the configuration is uniform, and reliable. It can be used for auditing, to understand what's changed, to manage configuration drift across business units. Customer A wants a thing, bam, execute some code, and save your business hundreds of hours of configuration and Mr. Legacy-Engineer-who-needs-to-retire's opinion about how a thing should work or be named. It's no longer relevant. There's a generally understood(best practice) way to implement everything in public cloud and you better believe that it fucking matters. Provide instant value. Value to your business, copy the code, sync it to a new repo, make some changes to the names, and bam, execute it for Customer B. Instant value to the customer, time to market is negligible or less than one day. Not sure you remember everything about how you turned on backups for Customer A? Doesn't matter, it's in the code.
Your mileage may vary, but this formula is what worked for me. Working somewhere for 20 years and getting a gold watch doesn't exist anymore. The quickest way to being valued appropriately and doing something you want to do instead of something you have to do is to find someone else who will value you or what you want to do. Take what I've written all over this site, it's free of charge, and really understand how it works. Build on it, execute it, fuck it up, at some point, you'll get it right. Reflect on what you did to get it to work. You're going to do awesome. Connect with me on LinkedIn: https://me.seehad.tech.