I’ve learned that there is no typical path to becoming a DevOps Engineer. I’ve met fellow DevOps Engineers from a wide array of backgrounds, including former software developers, linux gurus, and a former analyst in the international relations space. I’ve personally held positions across the spectrum, from vegetation research at a remote field station in Colorado to developing simulated hardware for a large government contractor. My journey in DevOps began as I was looking to relocate back to Chicago. I was already familiar with Civis’s work and was intrigued by the DevOps Engineer position despite having no experience in DevOps or systems engineering. As someone driven by attainment of knowledge, I was attracted to the myriad of tools in the job posting that I knew absolutely nothing about. I received an offer and eagerly accepted, though secretly I was feeling wholly unqualified (imposter syndrome is REAL). I learned later from my colleagues that the biggest boon to my candidacy was my willingness to jump into unfamiliar technologies during the interview process and the ease in which I learned them. Being a quick learner has certainly helped me advance as far as I have, but I would be remiss if I didn’t point out how helpful and supportive my coworkers have been in this journey.
How DevOps Works at Civis
At Civis, we are huge advocates for infrastructure as code because it allows us to review and keep track of all changes to our stack. Everything we do in production is codified, tested in our staging environment, reviewed by a fellow DevOps Engineer, merged, and deployed. We use both tools and design patterns to accomplish this. Tools include Ansible, Cloud Formation, and custom boto3 scripts. Patterns include creating easily composable and reusable Ansible roles and Cloud Formation templates. After all, how can you accurately test a production change in staging if it’s a different template?
DevOps roles tend to be interrupt heavy since these roles touch all parts of an organization’s stack. However, the engineers on our team are researching or developing 75 percent of the time. We strive to be at the forefront of technology and are often testing out and incorporating new tools and solutions into our stack. For example, we are currently in the process of moving our main stack to Kubernetes. This has allowed us to research and implement really cool new tools, like Argo. In my time here, I’ve cut my teeth on Kubernetes by developing the manifests for our platform deployments and building out the pipelines to deploy them onto our Kubernetes cluster.
There’s plenty of opportunity to code too if that’s your thing — for example, fellow DevOps Engineer John Kerkstra and I developed a robust and well-tested python application to help deploy our data science platform, Civis Platform. One of the modules in this application sends notifications at each stage of the pipeline to a Slack channel, allowing developers to view the status of their deployment. Another module implements a queuing system to address issues around concurrent deployments. Furthermore, to appropriately scale our Kubernetes cluster to meet user demand, our team developed an application that scales compute in our cluster and made it configurable so that it could be administered by our client success team. An important philosophy to our team is continuous improvement, and we do this by empowering engineers to fix repeat asks and develop internal self-service tools like our compute scaler.
Challenges
My experience as a DevOps Engineer has been great, but it has required a shift in how I approach problems that I encounter. As a software engineer, I was used to looking up issues with my code and finding an answer on StackOverflow immediately. While that occasionally happens if I’m lucky, I often find myself either wading through Github issues, opening a new issue and hoping it will be addressed, or combing through source code to see if the behavior I’m seeing is expected or intended. This is the flip-side of working on the bleeding edge of technology — we’re often one of the first few teams to be utilizing a new technology in a certain way so previous reports of errors are often non-existent. I don’t see this as a bad thing though — my troubleshooting skills have gone through the roof after 8 months in this position.
Why DevOps Appeals to Me
The skills I’m attaining in this role are desirable in every single industry — companies from very early-stage startups to megacorporations need to have robust, secure, and scalable infrastructure to keep their applications running and their data backed-up and secured. Therefore, DevOps Engineers are in high demand and jobs are secure. Additionally, I have yet to encounter a position that allows you to play around with the latest and greatest tech and implement it so quickly.
All in all, being a DevOps Engineer at Civis has exposed me to some of the most sought-after skills in tech and involves a great deal of learning about and implementing the most cutting-edge tools. If anything above piqued your interest, check out Civis’s job board for DevOps opportunities!