I recently read a great article by Alan Sharp-Paul, cofounder and co-CEO of ScriptRock, called “You’re Doing DevOps Wrong. Automation in the Enterprise.” So I reached out to Alan for a Q&A session about DevOps. The following is a recap of our discussion.
Talking DevOps
MK – I liked your recent post and especially the quote, “Don’t automate what you don’t understand.” Talk about this quote and what you have seen and learned over the years on this topic.
AP – It is interesting that many people hear DevOps and translate it into, “We need to automate everything!” Automation is good, but there are steps one must take before automating. First you must understand what you have, which means gaining knowledge of legacy systems and processes. If you don’t know what the requirements are, you are destined for failure and could very well be automating inefficient processes, or simply missing things.
Silos will kill you. Often the ops team automates things in a bubble without input from development, and they wind up automating the wrong things, things they don’t have enough system knowledge about, or bad processes. It is even worse when the development team automates in a bubble and then drops it on the ops team at the last minute.
MK – Startups and web companies get DevOps, but enterprises struggle with it. Why is that, and how can we help them?
AP – We need to simplify the message. It is too ambiguous at present and far too easy to get lost down a rabbit hole. We also need to make more of an effort to make the tools associated with DevOps easier to use. Stories of cutting-edge tools and radical methodologies make for captivating conference talks, but there is a chasm between the vanguard of the movement—with its poster-child companies (Facebook, Google, Etsy)—and the average enterprise. DevOps and cloud computing are noble goals, but more focus needs to be placed on helping enterprises get there, rather than simply showing them what to do once they are there.
MK – ScriptRock has built some great tools, but a fool with a tool is still a fool. How do you help companies beyond providing them with tooling?
AP – Like you said, a tool is just a tool. Tools are not DevOps. Enterprises should be asking, “Where are the bottlenecks?” They should be focusing on the business problems. They should continue to leverage existing frameworks like ITIL (Information Technology Infrastructure Library), because quite simply, they work. DevOps does not replace them. I find it often helps to consider DevOps instead as a means of process improvement, operating through the dual lenses of collaboration and automation improvements.
MK – Some new technologies like Docker have emerged recently. Why are containers taking the world by storm?
AP – I do believe that the justifiable hype around Docker is precisely a response to what we’ve been talking about. Infrastructure management is still too hard. Automation tools are making incremental improvements in usability, with Ansible the most recent project to win fans in this regard. There hasn’t been a step change in ease of use, though. Docker, a new take on an old technology, looks to have achieved this. It has the potential to have the biggest impact in the infrastructure space since virtualization. We’re sold on it at ScriptRock. We use it internally and have added support into our GuardRail product that allows export of curated configurations into Dockerfiles.
MK – What advice would you give an organization starting a DevOps journey?
AP – Start by reading The Phoenix Project. It does a better job than any other literature in providing a frame of reference for the key considerations and prioritizations. Again, take it up a level. Figure out what business problems you are trying to solve, and don’t simply, for example, do CI/CD for the sake of doing CI/CD. Work out the metrics that will allow you to measure how you are tracking in achieving these goals. Beware DevOps vanity metrics such as number automation scripts written or deploys per day. If they’re not moving the needle for your business or—worse still—if they are making things worse, then you will need to reevaluate. As I wrote in the blog post you mentioned earlier, always seek to begin from a basis of a solid understanding of your environment.
MK – Tell us about your product and what’s coming out on your roadmap.
AP – We don’t talk publicly about our roadmap, but I can tell you where we are focusing. We are focusing on addressing what we see as the key prerequisites to any DevOps, and in particular, automation and initiative. We describe them as waves and break it down into:
- Wave 1, Visibility: Our GuardRail platform offers automated scanning and visualization of server and network device configurations, configuration drift monitoring, and visual configuration differencing of like devices.
- Wave 2, Accountability: Understanding your state is a great start, but being able to validate is the crucial second step. With GuardRail, you can filter and curate configurations to create policies that can be used to validate configurations on an ad hoc or continuous basis.
- Wave 3, Automation: All policies can be exported to Chef, Puppet, Ansible, Docker, and Windows PowerShell DSC.
We give customers the freedom to use whatever tool they want for automation. With their config being scanned and monitored, what matters is that they can validate their state at any point in time. A key focus for us has been usability. We don’t want to inhibit the collaboration part of DevOps by introducing yet another config management tool that is difficult to use. GuardRail can be delivered as multitenant SaaS, single-tenant SaaS, or on premises as a virtual appliance.
MK – Alan, thanks for your time and insights. For more information on ScriptRock’s GuardRail product, click here or go to Alan’s great DevOps blog here.