Running cloud automation isn’t as simple as pressing “Go.”
One of the key aspects of cloud’s value to an organization is the way in which its implementation and processes can impact the bottom line of a business. Cloud automation, in particular, is an issue in the cloud that can have a major effect on cost, and there are two major ways to think about what generates the automation ethos that informs a company’s cloud strategy.
From the engineering perspective, if something needs to be done more than once, it should be automated. This saves times and effort, becomes a repeatable task, and since it was automated, everything comes out uniform. All of these
Business considerations are the other main drivers for automation. Is it cheaper to implement a human solution to a problem, or is it cheaper to install a piece of software? Regardless of the engineering ethos, when a business gets to the level of asking these questions, there are cases where it’s cheaper to utilize human power or where it’s cheaper to rely on a machine powered solution or a combo thereof.
There are cases where you don’t want to automation. Disaster Recovery (DR), in particular, is a situation that can become a double edged sword. Very large scale business continuity implementations with multiple data centers full replication, etc. can work beautifully. Meanwhile, other implementation can run into serious issues relative to the “automate versus human intervention” question.
For example, if the idea at the onset of DR planning is to have one regular facility, one DR facility and automate the failover between those facilities, there are multiple points where serious failure can occur. False positives and false negatives in the automation mechanism can occur. If this scenario plays out with things breaking down, it actually would have been cheaper to throw human capital at the various pain points. If something requires human intervention, downtime might be a little longer, but you don’t have false downtime.
So how does this impact the economics of a business?
The big economic issue is that there is a separation in the class of automation. There is the smaller scale model, in which the lone engineer or small engineering team are using off-the-shelf, open source, free tools plus their time to create tools to automate. This definitely can work wonders for a business at a reasonable, predictable cost. For example, if you are automating at the small scale and deploying 10 servers per week, you costs are similarly more manageable. You will have a person to rack and stack, and you have some kind of automated deployment system – be it Clonezilla or Cobbler. And this all works well.
There are also the explosive growth scenarios where those off-the-shelf tools don’t scale well for exponentially increased demand. In these instances, the technical requirements of a business dictate a move to a more enterprise-class automation system. That evolution represents a huge gap between what works on the small versus what large scale infrastructure automation means from a financial output perspective. If you shift to deploying 1000 servers per week this process breaks down. The professional tools available to automate at the large scale start to get into the millions of dollars, even before the hiring of qualified expertise to run the systems.
Having the automation need but not having the business resources to fulfill the necessary implementation (whether because of other uses for the capital or the lack thereof) is one of the key drivers for businesses outsourcing these processes to managed service providers – the cost for expertise but also implementation goes down, human capital on your side is freed up to focus on different parts of the business, and the required automation outcomes are achieved enabling your business to more comfortably scale.
Cloud computing is often as much a business innovation issue as it is a business finance issue. There are many roads to establishing a system that works for you, and automation is a large part of successfully reaching that point. Take the time to understand what priorities govern your IT strategy and then make the necessary investments – don’t simply automate on the large scale if that’s not what’s required.
By Jake Gardner