I’ll be the first to admit, I never took DevOps seriously. It had a sexy name, it was trending, it was all the rage. If you had it in your resumé you were hot-shit. But what is DevOps? I found out way too late, already having already taken a position with that description. But I’m not DevOps, no one really is. I’m just a Member of Technical Staff, your average code monkey. The more I learned about it, the more excited I became. DevOps is a way of thinking it’s a movement. It’s a combination of tools and culture. It’s all about developers taking over operations, usually handled by systems administrators. Everyone had their own view of it, I like to think everyone would agree on the ultimate goal: it’s the software defined datacenter.
Engineering lovers silos, especially larger companies. Developers write code, Quality Assurance verifies the code, and Operations deploys the code. Pretty cut and dry, Devs worry about delivering code, QA worries about making sure nothing embarrassing happens, and Operations ruins the deployment because they couldn’t follow the steps they insisted we documented for them. At least, that was my experience. If you think of the ideal case, there is no QA or Operations: there’s only development owning the entire pipeline. Each step you add along the pipeline becomes another bottleneck. Especially in larger well run organizations, you have Project Managers coming up with requirements, the Developers satisfy the bare minimum (which is a good thing, more on lean software later), QA gets in there somewhere along the way (earlier the better, but I’ve never seen that even when I make a conscious effort to involve them before a single line of code has been written), and then the code is thrown over the fence where we expect people who have never touched it before deploy it in a production with a service level agreement. There’s so much process divided among several teams the people writing the software have no idea how it’s deployed. So how do we solve this in the modern age? DevOps of course!
DevOps is all about removing barriers, empowering engineers, and trying to do the right thing. I’ve long been against QA, having been QA myself for years. I strongly believe developers should be responsible for both Unit and Acceptance tests, leaving a small number of QA to handle System Testing. Doing this will put a lot more pressure on developers, empowering them to make a greater effort in terms of software quality. Agile/XP methodologies strongly preach this, it’s nothing new and has been proven to be quite effective for many years now. But what if we take it a step further? What if we make developers not only handle the development and testing, but also the deployment? That’s DevOps, a combination of tools (let’s face it, developers don’t want to handle operations, they want to define it in software and fully automate the entire pipeline) and culture (empowering developers to own and support the entire pipeline). I keep saying pipeline, what’s that all about?
The heart of DevOps is to remove barriers from code change to deployment. Developers are empowered, they own the entire process. If something fails along the way, then their safety net saved their ass and prevented a disaster. Something gets by, and they’ve failed to plan ahead. It’s a lot of pressure, there’s no doubt about that. At the same time though, it’s an amazing cultural shift from the old norm of Operations people (i.e. System Administrators) who love and enjoy process (you would never lose an argument saying they love and embrace additional process). Developers have no time for this, they have no patience to add additional process. They need to deploy changes as soon as possible, with as little effort outside the code hangs as possible. This is where the Continuous Delivery comes from in the DevOps movement. By having test automation in place, we have replaced QA. By automatically deploying to production, we’ve replaced System Administrated with automation, with the software defined datacenter.
I’ll expand on each of the cases in later posts, the main point I’m trying to push is that DevOps isn’t a job title, it isn’t about Operations taking a deeper interest. It’s about Developers moving beyond their single silo and expanding their skill set. It’s about developers taking over the entire deployment pipeline and taking responsibility. It’s about removing barriers from code checkin to deployment. It’s about taking Agile to the next level. DevOps is the culture shift we’ve been waiting for a long time now, and it’s at the point where we can really make a big difference.
My boss takes great pride in saying Engineering is our customer. System Administrators have always been there to serve Engineering, to make sure their job is as easy as possible. DevOps is about empowering Engineering. We all love the word disrupt. It’s means we’re doing something so completely different, everyone should be wondering why we never did it to begin with. DevOps is about disrupting the roll of System Administrators, empowering them to find new ways to keep the lights on. Whether it’s some fancy new Virtualization feature, a container management platform (auto-scaling solutions are so sexy right now), or a simpler way of doing something we’ve always done. If it ain’t broke, don’t fix it. This phrase doesn’t apply to the DevOps movement, because everything can be done better.