Beginners Guide to DevOps: How to Make It into the Industry
If you are starting your career or looking to transition into DevOps one of the first things you’ll learn is that DevOps is a methodology more so than a job title. DevOps at its core aims to bridge any divide between IT Operations and Development to encourage collaboration and participation between both sides to reduce any surprises by the time an application needs to be deployed to Production with a strong emphasis on automation and standardization.
With that said, there are many of us who preach the core values of DevOps and have a set of responsibilities that are dedicated to the DevOps methodology, thus making us DevOps Engineers. From my experience some of these responsibilities are focused around these areas:
- Infrastructure (Cloud or On-prem)
- Monitoring
- Automation
- Networking
- Security
- Release and Deployment (CI/CD)
Obviously this is a wide range of knowledge to be fully proficient in as you start your career in DevOps, and I don’t believe there is a College or University degree called “Bachelor of DevOps”. So, how did the rest of us kick-off their DevOps Career?
From my experience DevOps engineers come from 2 backgrounds:
1- A Developer with interest in infrastructure and operations.
2- A System Administrator with strong development skills.
Regardless of what path you take, or even if you wanted to start your career right away in DevOps, due to the nature of DevOps you’ll often find yourself coordinating information from multiple teams (backend, frontend, DB etc) and being at the center of everything. This is both a blessing and a curse, but that depends on what you want to take out of the experience.
Now that you have a tiny bit of understanding of the role a DevOps Engineer plays at an organization, I’ll cover some of the soft and hard skills that I believe are key to be successful.
Automate everything mentality:
I mentioned briefly before that as a DevOps Engineer you wouldn’t want to be a blocker for a deployment. So it is important for you as a DevOps Engineer to have a set of tools that you are super comfortable with. And really these tools can be split up in a few categories:
1- Infrastructure As Code, examples are Terraform, CloudFormation, ARM, or Google Cloud Deployment Manager.
2- Configuration Management, examples are Ansible, Chef, Puppet, or PowerShell DSC
3- Scripting Language, examples are Python, Bash or GO
4- Command Line, depending on your environment (Linux or Windows) but get very comfortable in there. Forget about driving your workloads from a UI.
5- Repository Management, you will not go far in this industry if you don’t adopt Git or some form of VCS. Learn it, adopt it into your workflows as it will save you one day.
To be crystal clear the exact tool you land on is irrelevant, what matters here is understanding what and why you need these tools. These exact tools will change overtime but the skills and concepts are transferable.
These tools will help you do ad-hoc changes, build CI/CD pipelines, scale and most importantly deliver the business needs in the shortest time.
Stick to your standards:
All the tools we mentioned are great, but a word of caution is that 2 engineers can use the same exact tools but end up at a different implementation. Both can be a 100% valid and correct, just different. To solve this, establish or adopt a standard of coding and tooling.
One of the first things my team did when we embraced Ansible was to establish a strict YAML standard. This is hugely important because you will have new team members join over time and eventually you might even open up some of your tooling for Developers too.
Document, document, document:
When you start adopting IaC, Configuration Management Tools etc you will quickly realize that writing any documentation in Confluence or a Wiki is a lost battle. Your “Declarative Code” becomes your source of truth and your working document.
But you will ask, where do we document how to run all this? I would say the README.md file in a repo will always do the job.
Always make sure your project has accounted for documentation, and this includes commenting your code. I find it easier to do it as I develop rather than at the end.
Communicate and Engage:
Don’t set your blinders up and work on a task without making sure you have a full understanding of what your team’s vision and goals are. These team goals of automation, infrastructure as code etc. will help you understand how you are positively contributing to the team, to your own career and ultimately to the business.
For DevOps especially you need to communicate within your team and externally to other teams too. I truly believe the best systems are designed and implemented when you are part of a cross functional team and everyone offers their expertises and experience. At Slalom Build you can see that we take this part very seriously as its built directly in our Product Engineering Methodology (PEM).
Never say “This is how we have done it always”:
I have heard this line way too often in my career, the state of DevOps is always shifting and moving, if you did something one way there is always room for improvement. Keep an open mind to new ideas and new tools.
Keen sense of learning:
Depending on which area within DevOps you are focused on, there are tons of certifications available for you to do, either from cloud provides like AWS, GCP, Azure etc or even from tools like Kubernetes, VMware, RedHat etc.
Certifications are great as they help give you a base knowledge, but I find it falls short of giving you real life experience which can differ more vastly than a test. To bridge the gap between these two I find reading articles and listening to podcasts helps build that experience a bit, but nothing beats real real life experiences. Some podcasts I listen to stay in touch with new developments and help round my experience a bit:
- Full Stack Radio
- Google Cloud Platform Podcast
- The InfoQ Podcast (this is my personal favourite)
- All Things DevOps
More so, the book Site Reliability Engineering by Google is a must read in our industry as it will help you understand a few core concepts that we covered here.
