How do you start your career in DevOps? How do I shift my team to use those approaches? This is a question I run into more and more frequently. Either while speaking to candidates, or among colleagues looking to move their IT operations into a more devops aligned culture.
I want to look at that challenge from the perspective of a System Administrator. I’ve been an SA for 16 years now, and was able to fumble my way into being a pretty decent Devops Engineer. Much improved from fumbling, there are some clear objectives you can focus on that will get you there quicker.
What isn’t devops?
First, let’s talk about some of the differences between conventional SA and a DE. Many of these differences are direct results in the difference between conventional IT or Technical Operations and devops. A traditional SA role would involve
-
sole or shared on-call responsibilities only within the SA/NA teams
-
scripting for administration (bash, perl), very CLI based
-
silo’d from development, and possibly application support groups
-
heavy focus on stability and process
-
cultivating the walled garden
Great DE’s share a similar skillset with SA’s – strong understanding of OS and networking concepts, deep familiarity with hardware or resource planning, diagnosis of performance bottlenecks, and instrumentation and tuning against servers or systems. In addition, DE’s
-
share on-call responsibilities with developers and overlap duties
-
utilize more robust languages (python, php, ruby), utilize web and database frameworks
-
embedded with day to day operations of development and application, actively contributing
-
heavy focus on innovation and agility
-
flat rejection of walled garden mentality
There’s clearly a skillset component – in devops we’re writing code to admin and maintain systems, while implicitly acknowledge that systems are part of a broader ecosystem. I’m just as likely to address a file in an object storage system (s3, openstack) as I am on a file backed system. When I perform a system level action, I’m doing so because of a database flag, not a cronjob. I’m sending the result of a job to an API, not a filesystem log.
But perhaps more importantly there is a mindset component – in devops we’re friends with the developers. I say that tongue in cheek, but am quite sure everyone reading this knows what I mean. The thing I’m most looking for in a devops engineer is their ability to relate to, and share responsibility with developers. I’m looking for developers who are excited to share responsibility with operations and contribute to the systems their code runs on. I think this is the most marked contrast between old world IT and devops – they integration of two traditionally warring tribes.
So how do you start the transition?
Code. Write code. Not shell, not perl. Perl is code, so is shell. Choose a language, it doesn’t matter much which, and write a basic CRUD app that you can interact with via a web browser. In my experience this kind of coding is rare in traditional SA focused folks, but absolutely critical for a DE. As part of your project, schedule at least 2 hours to feed the trolls about whether python is better than ruby.
Puppet or chef. Stop everything you are doing and pick one of these up. Make yourself take an existing system and install apache on it using one of these tools. Configure apache using the tool. Make changes only in puppet or chef. As one recent AWS tips post said, disable ssh. In 2014 if you are not using puppet or chef you are terribly handicapped.
Get into the cloud. Set up an EC2, Google Compute, or Azure environment. Start and stop instances only with API calls. Make sure that once started, the instances are applying a puppet recipe. You can have a functional playground for free, I’ve had a personal goof off area in ec2 for a couple years now. $18/month or so is a small investment in your career. Set yourself some basic tasks, and implement them in a cloud environment.
DevOps is here to stay, and is a massively impactful methodology for quick iteration against systems and code. Whether you’re at a startup, or an enterprise, or looking to shift… adding some basic devops tools to your bag o tricks will be time well spent!
