I have problems with Automation
For me the mantra of achieving speed via automation tools is nothing new. In fact I was ‘automating’ Citrix Metaframe builds using windows scripting techniques back in 2004. The market though, has become awash with different automation products and it’s fair to say that many enterprises now suffer from ‘automation sprawl’. This results in a tactical rather than the strategic approach to automation required, meaning that benefits are never fully realized. In fact, I have spoken to many companies for which the word ‘automation’ leaves a bitter taste in the mouth as they have been burned by failed implementations.
Now before everyone says “John, what about solutions like Chef and Puppet? They have been very successful so far” Yes, they have, I agree. They have both captured the market when it comes to turning infrastructure into code, so that environments can be rapidly and automatically built. I have no doubt that their solution or platform is easy to use but I would argue that the success of these solutions does not lie just with the product alone but with their execution. They made it very easy to share and encourage sharing of automation scripts and modules.
Here are my problems with Automation in relation to DevOps.
Problem 1: Speed can be dangerous
Speed is the nirvana for many enterprises when it comes to DevOps initiatives. The issue is that for many, their processes around release and change are centered on rigor and control, at the detriment of speed. I know I have sat through countless, pointless Change Approval Boards (CAB) in my time – one of the symptoms of this approach.
But going in all guns blazing in regards to release and change automation specifically, can damage your business. A widely accepted stat, backed up by formal research at Gartner, is that 80% of business service outages (read – application outages) are caused by release, change and configuration processes. Therefore the need for speed could easily amplify this stat. The solution is to make sure that you proactively monitor what matters in regards to business services. This means the end-user’s experience, the application itself through to the infrastructure workload, including the database. Our Application Intelligence platform provides this, hence why it’s a perfect partner to any infrastructure or application release automation tools.
Problem 2: Automation success isn’t about the tools but the people and process
I have heard two great comments in regards to automation in last couple of years. Firstly, “Don’t automate what you don’t understand” and secondly, “A bad process automated, is still a bad process”. I think these comments summarize nicely the problems which enterprises face in any strategic automation or DevOps initiative. While the automation product may be simple to use, understanding what to automate and what effect this will have on the organization and its people is a different matter.
If you are going to be successful with automation and DevOps, it’s essential to address how an automation script or series scripts/modules will interact with, or change your current processes – processes around which jobs, roles and emotions are centered. This becomes difficult in an enterprise, which has defined processes for areas such as release, change and configuration, plus all the politics which come with this. Any strategic enterprise automation initiative has to overcome FUD (Fear, Uncertainty and Doubt) amongst employees in which automation will change their job activities. By the way, automation may well improve an employee’s role but this does not mean that FUD will not be present initially. To overcome this barrier you need to think about the people and process first. Involving people in automation initiatives (I would even suggest shying away from using the word automation) from the outset and being as transparent as possible through each stage of the adoption is vital.
Problem 3: Automation is more than just infrastructure and application automation
In my discussions with IT professionals in regard to DevOps, I hear a lot of excitement, quite rightly, in regards to infrastructure as code, application release and configuration release automation solutions. But this should not be your only focus for DevOps. It’s still essential to be able to respond rapidly to emerging application and associated infrastructure workload issues before they impact the end-user (customer or employee). This means that automated issue response or remediation is an essential capability that you should look for in any APM solution.
One of our driving principles at AppDynamics is to enable businesses to act fast. This means that we make it easy to run a response to an issue or event. Another key capability is that we help enable modern application architectures by providing cloud auto-scaling. Our platform understands application demand via real user monitoring so it automatically knows when to scale up or scale down application components in a cloud-based environment. This ensures that the customer or employee continues to have great performance even during heavy utilization periods. This feature is essential for those organizations who have to deal with periodic events such as Black Friday or Cyber Monday.