Do Different IT Orgs Need Different Automation Tools?
IT departments need to get the most out of their systems through automation, but the variety of operating environments, tool vendors, and budgets involved is staggering. Is there hope for one-size-fits-all automation?
We tend to romanticize the Renaissance man: the true jack-of-all-trades, the self-taught master who loves to do it himself. But in the modern market, the wild variety of specialized segmentation has all but eliminated this kind of all-purpose problem-solver — there’s too much to know, too many square pegs and round holes.
The same is true in IT. While most IT infrastructures rely on the seamless integration of many different systems, it’s been hard for IT leaders to manage the entire sweep in a truly centralized, top-down fashion. This requires automation, but in order for automation to work, it has to deal with the many differing vendors, standards, and platforms involved — solutions are rarely cut and dry.
And even as these systems become larger and more complex, we must demand that they perform faster and more efficiently. IT managers need the efficiency brought by automation in order to remain competitive, but they can’t afford to take risks on a patchwork solution. In other words, they’re on the hunt for the Renaissance man — but can he be found in a modern IT infrastructure?
As Techtarget observes, IT professionals are making up for a lack of one-size-fits-all solutions, with some coding ingenuity. That is, DIY-ing bespoke, automated programming solutions that suit their particular environments.
Fortunately, there are strong developer communities willing to offer automation code and advice, depending on the vendor. But in point of fact, cobbling together workaround solutions may not be the wisest direction for IT to be moving in. Trial-and-error can be a pretty expensive method when applied to an entire IT infrastructure — indeed, the errors that occur in those trials can literally automate problems across entire systems.
But while this is an unsustainable practice, it’s a necessary phase in the evolution towards full automation.
Techtarget points to Microsoft’s PowerShell as the spark behind this movement, the first highly-popular automation tool to be mercifully compatible with other operating environments like VMware and Dell, opening up the possibility for larger-scale automation.
But while they trace how this movement has developed since, to products like Chef, Ansible, and Puppet Labs, they stop just short of its logical conclusion: infrastructure-wide automation tools that translate across systems, right out of the box.
Servers, applications, middleware, storage systems, hypervisors, operating systems: these are the areas IT professionals have had to assess and combine into single assessments by sheer force of will. But technology has a way of subsuming entire bodies of knowledge and condensing them into comprehensive, intuitive platforms.
The reality is that those efforts to make a wide variety of systems “talk,” and talk fluently, have already been aggregated and automated. For one such example, we can point to our own suite of Vityl products. Without boasting, we can say that they arrive with out-of-the-box compatibility across the vast majority of systems and vendors that businesses would ever think to use.
A far from complete list includes VMware, Oracle, Microsoft, Redhat, and IBM environments, operating systems like Linux, HP AIX, Windows, and Solaris, cloud environments from Amazon and Azure, databases from DBQ, Oracle, SQL, and Sybase, as well virtually any data source imaginable.
So, do different IT organizations need different automation tools? While there’s always a place for DIY problem-solving (in the true spirit of IT), it’s much easier for enterprises to simply eliminate the “Y,” zoom your focus out and onto the big picture, and move on. The idea that there are no true, one-size-fits-all automation tools is rapidly becoming myth — just in time for our good old Renaissance man to make a very real comeback.
(Main image credit: Robert Scoble/flickr)