When I started my career as a Systems Administrator, I thought that I would be doing that for my whole career. A few years later, I thought to myself, ”If I were to progress, what would be my next step?” After a little bit of research, I learned of a position called a DevOps Engineer. Since I had been learning how to code on my off time, I thought that this would be a perfect next step for me in my career. After doing a lot more research into DevOps, I came to realize that there was a lot more to the position than I previously understood.
So, what exactly is DevOps?
- Is it a new and improved Systems Administrator position for the Cloud era?
- Is it a culture in which Developers and Operation Engineers work in unison with shared responsibilities?
- Is it a combination of the two?
The answer is not as concrete as one may think and is going to differ from person to person and from company to company. Some companies will say that Dev/Ops engineers are just Operations engineers. If you Google “What is DevOps?”, there are a lot of companies that will give you their definition and for the most part, they all sound similar. For example, here is the definition of DevOps from AWS:
“DevOps is the combination of cultural philosophies, practices, and tools that increases an organization’s ability to deliver applications and services at high velocity: evolving and improving products at a faster pace than organizations using traditional software development and infrastructure management processes. This speed enables organizations to better serve their customers and compete more effectively in the market.”
The term DevOps doesn’t necessarily mean that it pertains to Operations Engineers. The term also doesn’t mean “Strictly Infrastructure Automation”, although it is a big part. I believe DevOps is a culture and position that bridges the gap between Developers and Operations Engineers. Much like test-driven development, Operations metrics/tasks should be moved over to the left of the development cycle.
A byproduct of that is the application getting shipped quicker and everyone taking responsibility instead of trying to pass it elsewhere. Another byproduct is the better audibility of the infrastructure. A few examples of this would be; Pull Requests on Terraform / Cloudformation / ARM templates, developers being a part of the operations on-call rotations, developers being embedded on an operations team or vice versa. Another case where Operation Engineers are embedded into feature teams can be found at Spotify.
Ultimately, DevOps is not just one thing. It brings a whole “hodgepodge” of processes and tooling together to make a smoother and more enjoyable Software Development Lifecycle.
There’s been a ton of coverage of the recently discovered Capital One breach. I’m generally very skeptical when AWS security makes the news; so far, most “breaches” have been a result of the customer implementing AWS services in an insecure manner, usually by allowing unrestricted internet access and often overriding defaults to remove safeguards (I’m looking at you, NICE and Accenture and Dow Jones!). Occasionally, a discovered “AWS vulnerability” impacts a large number of applications in AWS – and it also impacts any similarly-configured applications that are *not* in AWS (see, for example, this PR piece…um,…Read More