I'm a DevOps engineer, and that is how others see my role in the team. But, often nobody in the organization doesn't really know what that means or how to proceed with DevOps. DevOps is often confused with a modern sysadmin, the person who "deploys" the software and helps developers to create environments. DevOps is a methodology on how modern software organizations should do software development. The DevOps team works on automating things by using different tools and techniques and making environments not just automated, but automatic. DevOps also requires development, but the development part is done on the tools that make deployments automatic or making software better suited for modern technologies - Cloud native. Nobody needs to do the deployments. They should be automatic. If the software cannot handle that, make it work. You as a DevOps Engineer should do that and make the first step.
How I started?
I started my professional career as a deployment/system engineer. Back then, our deployment team was writing shell scripts to deploy the software to different environments. Also, we owned all environments and we were maintaining them. Tools like Puppet or Chef were not well known and not used that much, not to mention containers or even cloud. I remember one of our first production migrations to a new datacenter. We worked the whole week to deploy it. And a few weeks after it went live we were fixing some bugs and managing configurations. It was a nightmare. And the whole team was dedicated to maintain the environments and to do deployment among other things. We were not able to do any improvements because of huge maintenance tasks.
Think of Infrastructure as a Code.
Now, it is really a paradise if you want to automate deployments and use DevOps as a huge benefit to your organization. Deployments can happen on a daily basis if you make it right. Container technologies, cloud, easy to use monitoring solutions like Sematext, are here to help you. Think of Infrastructure as a Code. There are a lot of DevOps tools and some companies are even built around DevOps, like HashiCorp.
DevOps is "maybe" a confusing word for a role in the team or tools naming. DevOps is just a software delivery, the way of thinking and a way of working. So, how then I'm a DevOps engineer? Industry defined that, and we can not choose our titles. Just embrace DevOps, the title is not important after all.
Some tools that I use and that will help you down the road:
- and many others...
Also, knowledge of some programming language like Go can really boost your productivity and encourage you to extend some tools by contributing and making them better suited for your needs.
SRE or DevOps
Somewhere I read that "DevOps is more for development/testing while SRE is for production." I have to say, I don't agree with this. SRE started from Google, and for them, that means that SRE engineers should work 50% on operations (tickets, on-call, manual tasks, etc) and another 50% actually doing development. SRE tasks also include SLA, monitoring, latency, availability, performance, capacity planning, etc. In such big organizations like Google, it probably makes a lot of sense to have teams just to work on a production along with some development, so they don't have to wait for development teams to work on something that will improve the software to work in automatic fashion. Development teams could focus more on new features and fixing bugs. SRE in a nutshell, Andrew Widdowson says "Our work is like being a part of the world’s most intense pit crew. We change the tires of a race car as it’s going 100mph."
But, chances are, your production is not equal to Google's production. And, as a DevOps engineer, you will have to work on creating procedures and processes for deployment, work on continuous integration, decide on which tools to use, be aware of all environments and work closely with development teams on planning and still work on a production. Of course, you probably need to do the development as well. You will do the development on something that will improve DevOps.
SRE or DevOps, you should work with all environments. Deployment procedure needs to work from development to production environments using the same principals. Of course, you don't need High Availability and Load balancing or even persistency in lower environments, but the core concept needs to be the same. Don't treat each environment as a special case.
DevOps is not a 50/50 split between Development and Operations!
Project managers like to say, ideally, we want you to do development and operations, so we will call you a DevOps engineer. This is just a misconception. Development of what? DevOps engineer should not work on fixing some frontend issues.
If you want to know more about SRE, I recommend a great and free Site Reliability Engineering book from Google.
Cloud native infrastructure
This is where it gets interesting. A quote from Pivotal: "Organizations require a platform for building and operating cloud-native applications and services that automates and integrates the concepts of DevOps, continuous delivery, microservices, and containers."
The cloud-native applications should be predictable, independent (microservices), be to able to scale automatically and to have rapid recovery (containers) while working in dynamic environments (cloud). Think of cloud-native infrastructure as a service. It is a really interesting topic which I will not cover here, but if you want to learn more I recommend great
Cloud Native Infrastructure book and interesting interview of it's authors.
How Kubernetes fits into cloud-native? Take a look at the picture below.
Infrastructure is a software problem now!
DevOps is more about the people and processes than the technology. It is a systemic approach to software delivery. SRE or DevOps, I don't see the difference. I think that DevOps engineers should be SRE engineers and that DevOps is just a methodology where software developers are working together to deliver software faster. If you don't deliver it, you don't have a product. Code delivery process should work for every environment. DevOps is a set of principles, a set of practices, and it is often up to company how it will implement all of this. It is same with Agile, each company does it in a different way. Your role is mostly defined by company size. We are all software developers, but, in DevOps, you are orchestrating the stuff. How cool is that? :)
What do you think about DevOps? Please leave a comment or tweet me at @alenkomljen.