Updated on February 5, 2016 by UpGuard
DevOps is awesome. Or at least the promises being made with DevOps are: faster deployments….more stability, resiliency & availability….save tons of money through automation….and make IT more relevant to the business. I definitely can understand why there is such tremendous interest in DevOps. Break me off a piece of that!
There is a tendency, however, for enterprises of all shapes and sizes to want to jump in and “do DevOps” as soon as possible. Many start with automation tools like Puppet, Chef or Ansible and others spin out skunkwork teams to try this new way of working before trying to boil the ocean. Both approaches makes sense and can be a catalyst for business transformation, so shoot for the moon and see what becomes of the strategy. In addition to the various toolsets that get revisited when starting the DevOps journey, many recognize that this is more than just a technology problem - it is a business & people problem. So there is lots of talk about culture, collaboration, communication and empathy. As the old adage goes, it’s all about people, process and tools.
But this is where things start to fall apart.
If you’ve read The Phoenix Project (I’m on my third reading as we speak), you know that Sarah has the hearts & minds of the business decision makers and for the most part gets her way until the IT team begins to change the way they work. Sarah doesn’t really care HOW the work gets done, she just needs it to get done in the timeframe that has been agreed upon. The business doesn’t care about the culture of IT and they definitely don’t care about the processes by which work gets delivered, so therefore there is a strong tendency to throw more technology at the problem. This sort of tools mentality is more commonplace than not and will not magically transform your enterprise into DevOps experts. Tools certainly have a place in the ecosystem, but to primarily focus on them is a mistake if adopting DevOps principles is a strategic imperative for your business.
We recently poked fun at this point and created a new video: DevOps in a Box. If you haven’t watched it yet, we’d love it if you did. While some have scorned us for the parody and satire, we think it makes an important point: there is no silver bullet for DevOps.
In the not too distant future, DevOps will just be the way to run an IT department, much in the way Agile has become the way to write software. For DevOps you are learning to work together to solve the most painful things. With a continuous improvement mindset focus on any area that is causing the most pain and improve on it. It doesn't need to be perfect, just enough so it isn't so painful any longer. Remeasure and attack the next pain point. The mindset used in DevOps works everywhere.
In The Phoenix Project, it explain that you want to achieve the three ways:
1. Form a flow from development to operations
2. Then send feedback from operations to development
3. Once the teams start working together on that and experimentation leads to more improvements the third way will form which is a relentless culture of experimentation and learning.
None of this happens overnight, and most of it will be different between most companies. The core and thought process is the same, a drive for continuous improvement in everything that you do. I’m fairly certain we can all agree upon that.
Misconfigurations are an internal problem that emanate from within the IT infrastructure of any enterprise; no hacker is necessary for massive damage to occur to digital systems and stored data. And the problem is pervasive, with Gartner estimating anywhere from 70% to 99% of data breaches result not from external, concerted attacks, but from internal misconfiguration of the affected IT systems.