Six months in DevOps

Six months ago I switched gears and became a Technical Lead in DevOps. I’ve never worked as an Ops before. I dedicated 10 years of my career to Dev.

I always knew something was missing. As a developer and later as an architect I was supposed to design and build complex e-commerce solutions.

Design and Build systems to Run.

But how that “run” was happening I had no clear idea.

Many developers consider “ops” and “support” as something boring and non-inspiring. Very often developers are throwing a product over the wall and move on to the next task or even a project. But there is an Ops team on the other side of the wall that has no idea how exactly the product was built. Ops don’t like changes because it can break existing set up. Developers bring those changes all the time. Very often without a clear understanding how exactly it will run in production.

That’s how DevOps was born.

“Dev Ops” term was used first time at a Velocity conference in 2009. It was a presentation from Flicker about how you can deploy 10+ times per day when your dev and ops team collaborate.

Great presentation. It started a cultural shift in development! It worth checking out:

Why did I move to DevOps?

I love improving the development process. I love nice and clean code that is covered with tests. I love efficiency.

As an architect, I was curious how to bring this efficiency to an organizational level. How to design and deliver (not only develop!) projects faster. And I was lucky to find a book that tried to explain it.

Multiple things need to happen for a big organization to become lean. Organizational changes, cultural changes, architectural changes. And that might cost millions of dollars. Moreover, I had no way to influence that.

But what I could change is to improve release processes and release cycles. That would reduce waiting time between teams and can help to move them faster.

And when I was asked what I want to do, I said – DevOps!

I do believe that bringing dev and ops together will help to improve processes and overall efficiency.

Working with DevOps

Team diversity

Many companies “adopting” DevOps by renaming part of the Ops team to DevOps. But it’s extremely difficult for Ops guys to start thinking like a developer. And you can’t expect that it happens overnight.

In case if you have a team that is called “DevOps”, the key to success is to have a diverse team. People with diverse engineering backgrounds: from development, QA, monitoring, ops, and support. In this case, they can work together on a solution that would allow frequent production deployments with fewer risks.

You can’t do DevOps if you don’t have right people.

Skillset

I found out that I have a huge gap in skills. That’s a problem, but it is solvable. For me being efficient in this role required to bring dev mindset first and then catch up on tools and technologies.

Tools and technologies required for a developer who wants to start a career in DevOps:

1. Linux Administration
2. Cloud. You won’t miss if you start exploring DevOps aspects of AWS. Google cloud and Azure are still far behind
3. Configuration Management – Chef, Ansible, Puppet
4. Get familiar with Infrastructure as a Code. I would recommend this  excellent book
5. Containerization: docker and kubernetes
6. Python

A couple of courses on Udemy and a few books can help you to catch up on these skills fast.

What are DevOps doing?

You would be surprised, but DevOps are developing.

In an ideal world, all tasks should be automated, and DevOps engineers should never touch any servers with their bare hands. All configs, all scripts should be in VCS, and if any changes are required, they should be checked in first.

Probably, you are not living in an ideal world of DevOps, and your DevOps team spends a lot of time on support of existing applications. In this case, first of all, you need to start measuring what your team spends time on:

1. developing new features and implementing some unique requests
2. doing repetitive tasks, like disk cleanups or deployments
3. or fixing issues in existing systems

Your goal is to have your team spend more time on #1. At least 50% of their time. If it’s not there, find inefficiencies and create a plan how to address them!

Good luck!