So, you think you do DevOps? It?s time to test just how deep your knowledge and experience with DevOps goes. It?s easy to buy into all the hype around DevOps, but hard to find the shortcomings - the truths that nobody wants to talk about out in the open.
We?ve done that for you. We?ve pulled from a decade of hands-on experience to create this list of very important things that you should know before diving into DevOps. Keep score as you read and see just how deep your knowledge of DevOps really goes.
1. DevOps Is More for Dev Than for Ops
DevOps was born out of the needs of developers. The tools have been optimized for the early parts of the application lifecycle (dev/test). They are great at prototyping simple operational environments. However, most of the DevOps tools are better suited for the needs of developers than operations teams. Most of the tools were not built from the ground up for today?s complex production environments or large mission critical apps. It?s like Usain Bolt, the world?s fastest sprinter, suddenly being called upon to run a marathon.
2. Ops Can Be More Agile Without Starting From Scratch
People complain about IT runbooks. I get it. They are slow, human-executed, and non-automated. Some argue that all those processes should be thrown out and replaced with DevOps tools. But you have to wonder if you are throwing out the baby with the bathwater. The IT processes that you already have in place work. They are battle-tested. Sometimes it is worth questioning whether runbook and workbook automation might be a better fit than DevOps in certain situations.
3. DevOps Isn?t Well Suited to Complex Production Environments
Want to throw together a LAMP stack and run some integration tests? Nothing does that better than DevOps.
Want to manage and maintain a six-tier, rule-based, load balanced application with a federated database using master-master replication and multiple slaves? Nothing breaks that environment faster than DevOps.
The truth is that DevOps does not need to be the only choice?especially when it comes to complex environments. The requirements of developers don?t always overlap 100% with the requirements of operations teams.
4. Implementing DevOps Can Make Things Worse Before Making Them Better
Deploying DevOps can sometimes feel like turning off the main road onto a trail. DevOps tools approach operations in a completely new way. They don?t embrace the standard IT practices that have kept things working for as long as we all remember. They have a different way of architecting environments with cookbooks and recipes that have little in common with runbooks and workbooks. Something is always going to be lost in translation. So be prepared for things to be broken for a while if DevOps is your only automation strategy.
5. Open Source Isn?t Always as Important as Battle-tested
I?m a huge fan of open source. But I?m also a contrarian at heart. Ten years ago, when everyone was badmouthing open-source in support of proprietary software, most of them were wrong. Open source had more going for it than people gave it credit for.
Fast-forward ten years and now everybody is badmouthing proprietary software in favor of open-source. Closed is bad?open is good. As if open source automatically means better. The pendulum has swung too far. Not all open source software is battle-tested. And not all battle-tested software is open source. For IT operations, battle-tested should always be more important than open source. After all, would you fly in a plane on its inaugural flight?
So how did you do? Five out of five? Hopefully, there was a nugget in there that opened your eyes to the other side of the coin when it comes to DevOps. There is so much good that comes from adopting Agile practices in IT today, but if you?re not aware and prepared for some of the downsides, you are liable to create a mess of trouble for everyone involved.
