Table of Contents
Hi my name is Mert, and I’m a DevOps practitioner for over 4 years now. I am one of the DevOps engineers you see nowadays, who was once performing an IT Operations / Systems & Networks Administration type of role and shifted or transitioned to a “DevOps” title. If you are performing the above roles in a technology company, where there is some sort of software operation, and the businesses core value/service is developing, delivering and supporting that software then you are already one step closer. Although this is my path and background in this post I will discuss what you need to know in general and what to focus on extra if you are not coming from a systems & networks background.
Why Did I Even Become a Network / Infrastructure Engineer in the First Place?
Are you one of the people who has graduated from a Computer Science / Engineering degree but programming didn’t come to you naturally. Well, to be honest I was even one of the good ones amongst my peers, but even so I wouldn’t feel confident in my coding skills back in University.
At that time online resources were not this plenty and available. The programming languages we started to learn were difficult, the concepts were not that well thought, hence even though I had a rough idea of all of the concepts nothing was really clicking for me. Biggest problem was the amount of resources available online. IDE’s were paid, Open Source Software was not popular, licensing models were perpetual and entry barriers were high.
Then I got exposed to Systems & Networks Administration during my first internship. I’ve developed an interest in this field and ruled out programming for the rest of my career. Upon finishing my Bachelor Degree, I’ve enrolled into a Masters Program on Network Systems and even attained Cisco CCNA Routing & Switching , CCNA Security and Microsoft MCITP training and certifications.
These laid out a great amount of foundation of my skill set today, however once public cloud was getting more and more popular I soon realized the way I used to do things would need to change.
Natural Transition to DevOps from SysAdmin
Early in my career I was working in a company where we had traditional IT Operations and Software Development silos. Silo meaning two different teams with not much intersecting operational goals. Developers are responsible to deliver features and IT was responsible to make and keep everything operational in an optimal performance. As the IT team, we were responsible for providing web servers, database servers, DNS zones, Firewalled protected networks redundancy and availability of these systems, Disaster Recovery mechanisms, long term data retention , Backups and accessibility of these systems via least privileged but non road blocking way to your internal staff.
Software team(s) were responsible for developing and distributing their applications and we were just there to make sure everything was running smoothly, but not had much responsibility in the process from the operating system and platform upwards. For example, I would be monitoring a cluster of fibre switches, hypervisor clusters and then all the logical Windows Server Operating Systems, and then services on those operating systems, and maybe availability of our external endpoints such as APIs and Websites. It all happened one day, I’ve been trying to troubleshoot a production issue after a recent deployment. I don’t remember exactly my troubleshooting steps that day, but I remember I was able to fix it by fixing some formatting inside a connection string for a ASP .NET application we were hosting.
The Developer Lead was shocked. How did you? How do you even? I’ve explained to him that in our discipline we mostly troubleshoot by elimination. After I’ve made sure all other possible suspects were working fine, I’ve checked the application configuration (web.config file of IIS Web Server in my case) and see the disparity fixed it and get the application back online. I’ve told him that, I’ve seen this application in our non-production environments so much that I’m now familiar with it in a way that I can perform a simple sanity check and have an expectation of how it should be looking like (on the server side) and how it should behave.
We got along very well ever since. I was getting invited into a sprint meeting when developers could’t know about a certain Infrastructure aspect that would affect how they proceed with their projects. We’ve started exchanging information that enhanced both parties in terms of how things get done.
Time passed and things have changed in the company. Company I was working for was sold to another company, but our boss would want to start a new company with a smaller team for a brand new project, what is also known as Greenfield project.
This in itself would be great because it would be the first time for me to set up a full company IT footprint almost from scratch. Moreover, we were going to use Office365 and Microsoft Azure and Azure DevOps for all of our hosting and licensing needs.
I was offered to govern the software delivery (CI/CD) as well the regular IT and Production Operations duties I already have. The difference this time was there was almost zero physical hardware to maintain due to all the cloud SaaS, IaaS and PaaS offerings.
ClickOps is not scalable You need to Automate
The transition to do things with code or automation was something I mostly saw suited for large scale operations. Once you start to use a public cloud provider, you soon realise that you are supposed to interact with it differently.
That’s when I realized I need to bridge this skill gap and learn the tools to exercise cloud providers REST API and do things via code, templates and automation.
DevOps is not just about Automation and Pipelines
Although what took my interest first in DevOps was automation tools and the scale we could achieve with these new tools, I’ve soon realized DevOps is not just about automating things.
There are lots of descriptions for DevOps and vaguely it’s a culture that encompasses everyone in a company. However, there are also roles which include “DevOps” in their tiles and they need to bring in certain things to the table.
These things are the knowledge and skills which developers often lack or have less of, which is very natural.
So What do you need to know?
The following is my personal high level breakdown of what a DevOps Engineer should now at the minimum:
Platform Knowledge (Azure, AWS, GCP, VMWare, OpenShift)
You should be the subject matter expert for the platform you are using. It is a very high claim to be an expert on a dynamic field like this but let me explain further what I mean.
Know the fundamentals of your platform
Each of them might have different ways of doing things in terms of little details and implementations but overall most of these platforms work the same way. You need to know the most basic fundamental 15-20 services at least %80 to be able to help others.
That missing %20 is your skill to attain knowledge when needed, which I like to call the ability to “Just in Time Learning”. I still don’t know a lot of things, I forget how to do things and so on, but I know exactly how to find the information I’m looking for via documentation, reference pages and other various online resources. In order to do these I’ve developed rituals, bookmarking systems, documentation systems that I’ve developed over years, and I recommend you to develop your own.
Cost Estimation
You should be able figure out and explain the cost component and breakdown of the cloud infrastructure and service layout overall.
Pay as you Go pricing made it an easy choice for businesses to adopt cloud, but it also brought uncertainty in terms of how high their costs can go.
You should be able to tell how well a solution architecture can scale in terms of performance and cost.
Ownership & Operations
You need to know where the platform providers responsibility starts and ends and where yours starts. You need to know below the cloud abstraction if needed and be able to identify which parts of a particular is in cloud providers responsibility and which parts are yours. When making an Infrastructure decision, you need to consider this ownership burden and how much of an accumulated effort to be expected for the long term operations.
There are no right or wrong answers here, it will all depend on the scenario but you should ideally be able to identify these matters from the start.
DevOps Fundamentals
DevOps has passed it’s experimental period and now there are some widely accepted mottos or high level guidelines. You should know these so you can practice them. Some examples to these best practices are:
Never do anything twice.
Script/Automate everything as possible to reduce repeated effort.
Build and treat your infrastructure like a herd rather than a pet.
To expand on this analogy, you should ideally have all of your infrastructure interpreted as code or configuration. This way you can generate and dispose of them at the same consistency.
In comparison, in the old times sometimes it’s typical that system’s are just deployed as bare and then configuration was done in manual steps which caused incostincy and in some cases special behaviour or configuration related to particular systems.
Build Once Deploy Many
This is one of the most known mottos. This tells us two things, first is application logic and environment configuration should be so separated that we can deploy our “Once built” artifact to as many environments as we want just by simply applying different environment configuration to our code.
You should be deploying the exact same binaries to your full pipeline so you can be confident that the same binaries will perform the same once you release them to Production.
Second thing this will allow is that you can identify your built software artifact with a specific version as you now have a reference to the exact process (build pipelines particular run) it was generated by. You can use a number based versioning timestamp, based on the unique run id of the build pipeline. The most important thing is you should have a system that you can consistently reference and use in confidence as you version/stamp your artifacts.
Inner and Outer Feedback Loops for Software Development
DevOps processes consist of inner and outer feedback loops.
These loops are essential to improve code stability overall quality.
An example for an inner loop may be a simple build pipeline that builds a C# application and run some unit tests.
In this example developer has the luxury to receive feedback on each commit to see how his changes are affecting the application health.
An example for Outer Loop is raising a Pull Request and merging your feature branch into a target branch. Outer loop may include things like code review, full end to end integration tests, security & vulnerability scans and more.
The distinction between, inner and outer loop is the time & effort it takes to finish the feedback cycle.
Outer loop takes time so you don’t want to run it every single time. On the contrary Inner loop(s) should be fast and efficient so you want to run it as frequently as possible.
Technical Skills
You need to learn a programming language.
There is no way around it. You need to at least be able to use interpreted languages for scripting purposes.
My recommendation on this is to learn PowerShell or Bash first depending on your use case (Windows / Mac/Linux).
Python and JavaScript are also very easy to learn, along with C#. Although these are fully fledged programming languages they can also be used for simple DevOps automation.
PowerShell 6+ especially sharing some .NET Core framework with C# you can use most of the C# System Libraries that make it an even more powerful language. Like any skills this can be learnt. There are tons of free resources to learn programming even from scratch.
You don’t need to write complex objects or classes most of the time. Just known language basics like built-in data types, loops, conditional, string manipulation, accepting and passing CLI arguments to your scripts, piping outputs from one script to another.
If you already know programming a little but looking for a fun way to brush off your skills, you can start with something like https://www.codewars.com/ and start practicing there with the language of your choosing.
You need to learn CI/CD tools
You can start with an open source tool like Jenkins or start using a hosted service like GitLab, Azure DevOps.
Version Control System
Learn Git, it’s the most widely accepted and most suitable tool for Agile and DevOps methodologies. You may also encounter TFS (TFVC) or other technologies but Git is the most widely used system at the moment.
Infrastructure / Configuration as Code
This will highly depend on your platform but learning one would definitely make it easier to learn others.
You can use cross-platform and multi-provider tools like Terraform or Ansible, however you may also want to use the cloud providers official tools like Azure Resource Manager (ARM) Templates or AWS Cloudformation templates.
Again what you start with doesn’t matter much. You can learn all of them once you know one.
Good Old Systems & Network Engineering
Have you ever heard of the story of a TCP packet in a network? How he conquers the world being born in a small modem in our house and reaching mighty servers of the Internet land. This was a fun story I had heard during my first CCNA training.
Jokes aside, although today we have lots of abstraction around networking and Infrastructure administration particularly due to the rise in PaaS offerings and Cloud providers coming up with convenient methods such as built-in DNS hostname, built-in SSL/TLS protection, patching & updating and so on.
It is all good to have these and spend time on things that matter. I’m by no means advocating learning networking in a huge detail if you are seeking a DevOps career.
However you need to know Internet related technologies such as IP Addresses, DNS, HTTP / HTTPS, TCP/UDP Ports, Operating Systems, Firewalls / ACLs , Monitoring and list goes on.
You can just learn the cloud way of doing those things today, as long as you are confident you know how exactly your services connect to each other and how to protect these links, you should be mostly set.
Who can become “DevOps” ?
Although DevOps capable Sysadmins are somewhat more treasured in some environments due to their numbers being so low, some companies are also accepting DevOps candidates from other walks of the Information Technology Industry.
I’m seeing a lot of people Software Developers, QA Engineers or fresh graduates are now spending attention and want to get into the DevOps field.
This thing I’ve heard countless times, it’s easier to teach an operations engineer how to do these new “DevOps” stuff whereas it’s more difficult to teach a software developer how to get the sysadmin skills.
This is somewhat true, and I can understand why this complaint is made. Too many people claim the title “DevOps” unfairly without necessarily having the skills or mindset.
I don’t believe in these limitations, I think everyone can branch out and expand their skill set in the area they are lacking. I’m a very good proof of this transition. Around October 2018 I’ve decided to seek out an exclusive DevOps role.
I had to get rejected a couple of times until I got my first opportunity in February 2019, but then once I did get the chance I worked so hard and learnt so relentlessly even my manager was in shock and awe with me.
In a period of 9 months, I had learnt Git, Jenkins, TFS, Powershell, Bash, Docker, Kubernetes a whole lot more of Azure and AWS services, Terraform and Packer and used them in a commercial environment, for real projects.
I was in constant learning and experimenting mode. To top it all off, my manager told me to get a cloud certification just for my sake, and I did. I got my “Microsoft Certified Azure Administrator” certificate in October 2019.
Becoming very good friends with him later on, he even gave me a great reference for my next job which I got headhunted even without applying for the position myself.
Focus on What you Already Have and Bridge the Gaps
To further expand on my points above, you can come into DevOps from all disciplines. It’s all up to you. Depending on your past role you can have other type of strengths
QA Engineer / Test / Automation Engineers
You already write code to automate tests. So you know how to code. You know how software development lifecycle works and you probably had more contact with Developers so far so you would be better at communicating with them. You are already a %50 DevOps engineer.
Software Engineers
You already know how to write build & test and possibly deploy your code. You are very familiar with the software development process. Maybe you were the one who was always left out to do the production deployment in your team, and now you want to get into DevOps. You are already a %50 DevOps engineer.
The most important thing you will notice is that, being an operations engineer means the way you work will be different now. You won’t be picking up backlog items from your story board.
When earlier I’ve said you need to be a subject matter expert, I was also trying to imply that you need to also own your work domain in terms of creating your own stories.
As a developer or QA engineer, you are more micro managed in terms of how you would work. DevOps engineers work towards goals but they are often responsible to come up with how to achieve these goals either solo or collectively with other DevOps engineers, which may also be referred as “DevOps Practice”
Don’t Worry and Just Learn Learn Learn
If you want to make the transition there is no better time. Although I’m not a recruiter I can tell from my interactions with them that DevOps engineers are still a rare breed.
This allows for employers to be more accepting for candidates from other areas and allows them time to learn and adapt to the role eventually.
Some companies would also prefer software background candidates if the roles also require a lot of development work as well.
As long as you show your ambition in this path and you are learning and growing, I believe in today’s market there is a place for you to start your DevOps journey if you choose to seek one.
If you want to start this journey and have questions; please get in touch with me via comments or my social media accounts, I would be glad to help out if you have more questions.
