This article was written by Chris Blackden. He is a frequent contributor to the Adam the Automator (ATA) blog. If you'd like to read more from this author, check out his ATA author page. Be sure to also check out more how-to posts on cloud computing, system administration, IT, and DevOps on adamtheautomator.com!
Do you want to know how to become a DevOps engineer and progress along a DevOps career path? It's possible and even probable if you stick to a few key areas.
The journey to becoming a DevOps engineer is a little different for everyone. In a way, the process for getting into a DevOps role is a little like DevOps itself. The journey to DevOps can be a little strange at times, documentation is rarely helpful, and there's not one 'true' way that works best for everyone.
There isn’t just one way to get into DevOps. But no matter where you are or what you are doing, some of the same principles will apply. Sometimes the best way to illustrate those principals is to tell a story.
This my story.
No names will be mentioned here, but I promise you that every organization large and small is going to have similar issues and problems. By going through my story, you will learn some of the DevOps principles like I did. Hopefully, you can apply them to your own story.
- Always deliver value
- There is no value in no
- Become a knowledge worker (and never stop)
- Focus on the numbers
By the time you're done with this article, you'll have a good idea of what it takes to become a DevOps engineer and will be well on your DevOps career path. At the very least, you'll come away with enough knowledge to start making some stories of your own.
A DevOps Engineer Delivers Value
The first stop on your DevOps career path is a story about starting out in IT.
My first IT job title after finishing school was a help desk technician. A helpdesk tech is about as far from DevOps as you can get. When I started that job, my team's ticket backlog was in the hundreds and the hardware inventory room was always a mess.
My time as a helpdesk tech helped me realize to always deliver value to the business. How? Read on.
Cost-Benefit Analysis is King
After getting settled into the position, I discovered a problem. The regular display adapters being ordered to support another monitor were arriving defective. They were not taking into account that our new PCs had display ports. To get these adapter to work, we had to rely on faulty USB-to-VGA drivers that caused more problems than the extra monitor was worth.
I made a spreadsheet that detailed how much the company would save if they switched to a different type and brand, and showed it to my manager.
You might be wondering what this has to do with DevOps; three words. Cost-benefit analysis.
I’ve made a cost-benefit sheet every time a manager needed to be convinced to fund a project or a purchase order. It’s always worked. In this story, I was just a helpdesk tech. I had no experience in IT budgeting but was given more tasks in that area. That experience helped me develop other financial skills I still use to this day.
Businesses exist to make money. Making changes that either reduce the cost to the company or increase the quality of goods and services received for that money can often be the difference between success and layoffs.
Turn IT from a Cost to an Asset
IT is usually thought of as an operating cost. It doesn't matter how it works as long as it does.
DevOps can reduce the cost of software engineering, but it can be a hard sell unless you can demonstrate the value it will bring.
This strategy can happen at any level of an organization. From help desk to CEO, if you show that you can make the wheels of industry turn faster and cost less, it will be noticed and rewarded.
A DevOps Engineer Believes There is No Value in 'No'
One of my old colleagues once told me there was no value in saying no to an idea. Most people shoot down ideas because it's easy and puts them in a position of power without actually doing anything.
It's much harder but more beneficial to find a way to make ideas feasible. In one of the first talks recorded on DevOps, Paul Allspaw and John Hammond from Flickr recognized this as one of the more important parts of a DevOps culture.
You can still drop an idea if it won't deliver as much value as you might like.
In some cases, what sounds like a terrible idea at first ends up being the best.
Be Adaptable to New Opportunities
Not saying no got me into software development. I interviewed for a system administration position and talked at length with my interviewer about topics like Group Policy, Active Directory, and other experiences I had.
The job was out of state and I had a family. This endeavor would be a huge effort!. I decided to accept the job anyway. On my first day, I learned that I would be doing none of the things I interviewed for. I'd be debugging Java code instead!
At first, I was upset. After all, it was too late to turn back and there was no guarantee that I could get another job right away.
I had spent all my savings on a house. Being unemployed for any length of time was not an option.
That job was a terrifying and and turned into a, let's say rocky, introduction to software development.
I went from a comfortable job on track to rise to a leadership position in a few years to a junior position in a field I had no knowledge in. To make matters worse, the short deadlines didn’t take into account that I had to learn all the best practices on the job!
Regardless, I took on as many new tasks and responsibilities as I could. I immersed myself in whatever materials I could get my hands on to make it all work.
- Can you write some SQL queries to pull data for this CAB meeting? Yes.
- Can you write an AWS Lambda function to process a JSON payload sent to it? Yes.
- Can you add a step in our CI pipeline to trigger a Spinnaker deploy? Yes.
I spent hours immersing myself in e-learning sites like PluralSight, Udemy, and Microsoft Virtual Academy. I set a frantic pace to keep up. In a year, I went from having a little PowerShell and server administration experience to being proficient in four different programming languages, contributing to architecture meetings, and even writing automation scripts.
These new skills helped me slowly improve not only the systems and processes I was working on but also my own ability to contribute.
Slowly building on a project and making it better is one of the most important concepts in DevOps: continuous improvement.
Take some time to work on your personal skillset and try out different DevOps engineer tools. Start a personal project or three. When you get asked if you know anything about the next big thing in the news, you can give the right answer: Yes.
A Devops Engineer is a Knowledge Worker (And Never Stop)
Continuing on a DevOps career path, the next stop is being a problem-solver.
Companies hire people to solve problems. Sometimes that problem is simple and can be solved by not hiring anyone at all. Other times the problem requires a specific combination of training and education that is hard to find.
What do you call an employee whose primary role is to solve problems for a business? Knowledge worker.
If you're not already, strive to be a knowledge worker. Even once you are, you should always focus on gaining more knowledge. For an aspiring DevOps professional, this means learning about the things you are weakest at.
If you're a Java programmer, learn how a network assigns IP addresses. If you are a network engineer, learn how to check code into Git. Are you a Windows sysadmin? Learn how to fix a busted nGinx website.
Get Creative
I once worked with a software team that maintained an application that periodically connected back to a Git repository. This repository was hosted in the company’s data center to download updates. Occasionally, the process would fail to connect because of the latency between the client and the data center.
The software team discussed every possible solution they could think of. They talked about adding retry logic, making smaller and more frequent updates and even physically mailing a disc to the client with all the updates.
I asked one of the senior engineers on the team why they didn’t set up a content delivery network (CDN)? This was a textbook solution to the problem they were trying to solve. It was a surprise to me he had never heard of a CDN. Wouldn't you know that the operations team in this same organization just spent the previous year setting one up for other teams in the organization.
Everyone who has ‘senior’ in their job title is a popular misconception. Some people think that a senior engineer knows everything about the vast, ever-expanding realm of IT. This belief is especially true for software developers. These guys and gals seem like technical wizards to anyone not familiar in the art of coding magic.
There is just way too much going on in IT and software development for one person to know everything.
Organization reach the best solutions by hiring people who know a lot about how different technologies work together. Each team member can then keep up with changes in their respective areas. This is the dev and the ops.
At least half of what you do as DevOps engineer is writing code to solve other people's problems. The other half is letting them know when they don't have to write code because someone else already did.
If you want to have a solid DevOps career path, you must be creative.
Focus on the Numbers
No matter what kind of business you work for or what position you are in, you have a number that correlates to job performance. Maybe that number is number of tickets closed, code coverage, mean time to restore (MTTR), or even return on investment (ROI). You might not even know what that number is until someone asks the right question.
"How long is our average deploy outage?", my manager asked. I knew I was in for a long day.
I was working for a services company that had many clients. My company wasn't capturing any metrics from software updates and installation. When a client had issues or an extended outage, they would report it to their account manager.
The account manager would then relay the issue back to the engineering team. Only when the account manager hounded the engineers was when they would troubleshoot the issue. The process itself was agonizing and considered a great hazing opportunity for new engineers.
My boss decided to challenge me to do something about it which led me to spend the next few months building a solution with code. The solution ended up providing a self-service report for account managers eliminating the need to contact the engineers.
The tool also helped the engineers too by providing a history of changes in the Git branch. By knowing what had happened before, the engineers could now plan for things that were going to happen in the future.
I had developed a process automation tool that helped the organization.
Being a DevOps engineer is about iteration. It's about making small changes at a fast pace that improves the overall quality of the product.
If you don't like the quality of the work you're doing or your clients are growing frustrated with new features instead of less, you're probably not measuring the right numbers and you're limiting your progression in your DevOps career path.
Conclusion
DevOps is still a new field. No one has all the answers. Everyone is still figuring it out and no one gets there overnight. DevOps bridges the gaps between teams to look at the bigger picture. Sometimes organizations even create DevOps teams. It sets a precedent to simultaneously understand each team's tasks and how that relates to the bigger picture.
If you want to learn how to become a DevOps engineer, never be afraid to learn. Charge head-on into the uncomfortable! When the uncomfortable doesn't scare you or you get comfortable in a DevOps role, leave and find a role that challenges you every day.
Whatever you do to succeed as a DevOps engineer and continue on your DevOps career path, at the very least, it will make a great story.