« Database Automation Challenges | Main | Oracle Database Patching Just Got More Complicated »
Flexibility and Automation Don’t Go Hand in Hand
By Robert Gardos | June 18, 2009
Solutions in the datacenter automation industry seem to be squarely focused on being an extensible framework versus a content rich solution. Considering we’ve been selling in this space for nearly 7 years now it is quite clear why this is an attractive option. Before I get into that let me clarify what I mean by framework and content.
Framework – Ranging from a simple vehicle to push out arbitrary scripts to the management of complex workflow, the framework is the master facilitator. It serves as a repository of custom content, manages permissions around this custom content and audits the results of executing this content on target entities. By doing all these things centrally it can drive efficiency and accountability. It is limitless as far as what it can accomplish, although the actual ‘work’ must be created and more importantly maintained by someone.
Content – Automation content around common system tasks, like provisioning and patching, can be inherently provided by the software solution. The user defines all of the properties of the resulting configuration while the actual know-how to get there is the software’s problem. While this is attractive from an end-user development and maintenance perspective it is more limiting than the framework approach.
If you know anything about GridApp Systems, you know that we believe a content-rich solution is the only practical approach to automation, assuming the underlying infrastructure is dynamic in any way. Why do we view the flexible, framework-centric approach with such cynicism? The answer really comes down to the reasons folks embark on an automation project at all. What is the company trying to accomplish? The three most important objectives that we have seen are as follows:
1) Empower lower level people to independently perform senior level tasks. The key word in this statement is independently. Any type of escalation to senior engineering dramatically reduces the value proposition of automation.
2) Central audit trail of all activities dramatically reduces exception incidents. Any organization beholden to true process-driven regulation will tell you it’s not the auditing that’s time consuming, it’s ensuring the handling of exceptions are audited. Most challenging are the ad-hoc responses to failures.
3) Guarantee the end state of an environment is in-line with the company standard (driven by operational, security, etc. requirements).
Improving efficiency, saving money, etc. are all great high-level objectives but the key to accomplishing those are captured above.
How about, “making senior engineers more efficient.” as an objective? At least from our perspective, most senior engineers have already embraced the power of the all-mighty script. The good ones may have even built limited frameworks of their own. The incremental value of an automation solution is highly mitigated in these circumstances. This is ironic as we have often seen senior engineers make decisions based on this slight incremental value as opposed to the deeper benefits of automation. Good senior engineers are control freaks so how can you blame them.
This leads me to the initial question of why most automation solutions focus on the framework versus content. This is a simple function of the customer purchasing process. Unfortunately for the customer (and fortunately for the framework solution) it is wildly difficult to assess the practical issues of an automation solution without actually using it in the real world. Even within the confines of a POC, any framework solution can be made to work as the tasks and supporting environments are highly predictable. For instance, I can easily script out the process of applying a patch to an Oracle database at a given moment in time. According to the folks that run the POC, that automation product is capable of patching Oracle. In the real world, the required work changes based on variability in such things as the methodology of patching (e.g., NApply patches with molecules), operating systems, and the architecture (clustered/non-clustered). There are system dependencies (all of course pre-handled in the POC) that may be easy or difficult to determine. When the framework-centric automation solution is applied in the real world exceptions come up dramatically mitigating the value proposition (especially if you believe in the three main objectives listed above).
Beyond the POC the limitations of the framework-centric solution should be obvious to anyone that manages datacenter infrastructures. Since they often do not handle exceptions well, the operator will be faced with escalating or filing an exception report. Both are worst-case scenarios when it comes to driving empowerment and efficiency. The underlying automation is a moving target that will need to be regularly modified to handle inevitable system and application level changes. This is not only the actual automation logic but the framework and all the system dependencies that inevitably exist. Considering IT mandates often change within a few months it’s optimistic to think a team of consultants will be available in the not-so-long-term future to handle updated requirements. I guess there’s a reason why the average CTO lifespan is still 18 months.
So what are the limitations of the content based solution? While the loss of flexibility may seem the obvious Achilles heel, from a practical perspective that is not a real issue. IT is tasked with managing complex applications and by limiting process variability things get simpler with little loss to functionality. The true challenge of content based solutions is that they must be comprehensive, handling the vast majority of situations/exceptions that come up. If they aren’t able to handle the particulars of an environment they are less useful because they are not designed to be manipulated. This is a major reason why some of the few content rich solutions in the marketplace tend to focus on a particular area (e.g. GridApp Systems is only for databases).
I find it amusing that most of the deals we close at GridApp are from organizations that have already tried a framework-centric solution. At best, the end customer is getting a fraction of value promised from the original vendor and at worst they have written off this investment. The good news for GridApp is that the company finally recognizes that by slightly sacrificing flexibility they’ll get a solution that actually enables them to realize the objectives of the automation initiative.
It is important to note that most automation solutions are not strictly framework or content. While HP Opsware automation is a heavily framework centric solution, its OS provisioning/patching is handled by internally created content. Even at GridApp, while we tout our content, the product supports custom applications and scripts as well as logical points in predefined content to infuse custom logic into each process. The key to making a decision regarding automation is to think about the product’s functionality and ensure it is used in a way consistent with that functionality. Listening to vendors yap about what their product does, especially in a competitive situation, and thinking that will give you leverage in the future is a complete waste of time.
One last point. Beware of the senior engineer control freaks. They love all their gadgets and often view a product within the context of their day-to-day rather than the organization’s needs. While they may (and should) be influential it is important to reconcile that perspective with the objectives of an automation initiative.
Topics: Clarity, Consistency, Data Center Automation, Data Management, Database Automation, Efficiency, GridApp, Provisioning, Simplicity