« Full Stack Automation- Critical For BSM | Main | Database Automation Challenges »
The Time For Application Automation
By Matthew Zito | May 28, 2009
Since the year 2000, we’ve seen an interesting change take place in the area of IT and infrastructure management. Prior to the rise in IT automation as a key business driver, organizations considered infrastructure management to fall into two key areas:
* Monitoring and performance tuning
* Admin “toolkit” solutions
Software products such as HP OpenView, IBM Tivoli, and Quest Software’s Toad for DBAs were considered “management software”. Organizations had a small number of servers, and weren’t increasing the footprint dramatically, instead tending to stack additional application instances on the same set of large servers.
However, the rise in Linux, Windows, and commodity x86 computing, coupled with the shift to a web-focused infrastructure, changed all of that. Now, organizations of all sizes were buying loads of fast, cheap, rack-mountable servers, and dedicating farms of them to various tasks. While this dramatically reduced the computing cost and enabled incremental scale and deployment, it increased the administration overhead.
Every new deployed server needed an OS, correct set of drivers, and third-party agents to do things like backup and recovery, performance tuning, monitoring, etc. In addition various configuration files needed to be managed periodically (e.g. OSes needed to be patched and new drivers deployed). All of this led to the first wave of IT automation – server deployment and provisioning.
This was led by Opsware and Bladelogic, now part of HP and BMC, respectively. They pioneered the idea of an elegant engine that innately knew how to deploy various operating systems, apply patches, track configuration changes, and report on the compliance of all of these things. On top of that, they offered an extensible scripting framework that could be used to tack on “extra” events and customization. Both products were huge successes, enabling organizations to finally take control of the security and configuration for their servers.
The second wave of IT automation had to do with process or runbook, automation. As the major server automation vendors tried to integrate into larger and larger environments, more complex workflow was required – with approvals, interactions with multiple systems, and other event management activities. Runbook automation provided this flexibility, allowing the server automation vendors to more elegantly manage these various environments.
More recently, the rise in virtualization has changed this equation. As the quantity of servers skyrocketed, the average utilization of those servers has decreased. With virtualization, many servers can be virtualized into one physical server, maintaining performance while reducing power consumption, datacenter space, etc. A virtual server, however, doesn’t require this complex OS deployment process that a traditional physical server requires. Instead of installing the OS, adding the correct drivers, patching the OS, etc., users can simply create a “gold build” image, store it, and then create new virtual machines with the click of a button. In virtual environments, “OS deployment” doesn’t require the complex, up-front process of defining a standard, managing the different drivers for different platforms, adding patches – build a gold image once, and clone it over and over again.
Between the server automation tools and virtualization, then, it seems as though server deployment and patching have been pretty well covered. The next step, then, is dealing with the applications themselves. The server automation and virtualization vendors have long claimed that they can easily handle application automation as well – VMWare recently described deploying Oracle by cloning a VM with Oracle installed, ignoring the issues of the datafiles placement, the reconfiguration of the listener, any clustering solutions or replication solutions involved, etc. Similarly, companies like HP/Opsware claim that through the scripting framework on top of their server automation tool, applications can be installed and managed, ignoring the fact that this turns a server automation user into a development organization, and one forced to keep up with the ever-changing application vendors.
While early server automation adopters have ignored these shortcomings, more and more organizations have realized that the server is becoming increasingly irrelevant. VMs can be built and destroyed on the fly, patches can be pushed en masse to farms of servers, but the applications themselves remain different on every node, and require special care and feeding.
Topics: Data Center Automation