Business Drivers for Cloud Infrastructures

There are several business challenges that drive the cloud discussion and cloud infrastructure market. These business challenges are very different from the technical challenges that are more commonly discussed along with cloud. It's key to differentiate between the two because typically only one or the other is relevant to any given audience. If you're talking to an engineer something like hardware redundancy is quite relevant, but that same concept isn't relevant to an end-user or CxO.

For this discussion we'll focus on Business drivers for cloud and save technical demands for a later time. While thinking about business demands you'll want to put the data center as a whole in perspective from a business standpoint. Put on a CxO hat for a minute and decide what data center means to you. If you're thinking like many CxO's you're thinking of the data center as a cost center, not much different from the cost of paying the lease on a building, or paying taxes. It's a necessary expense of doing business.

Recently this has been very true, for instance the business needs a way to communicate more quickly than the typed memo so they invest in an email system, the email system is a cost no different from the paper and ink required for the memos. This wasn't always the case, originally Information Technology (IT) was a competitive advantage, remember way back when not everybody had a data center infrastructure? Back then building a server or network for a business application gave you an edge, lately it's more of a keeping up with the Jones's, who by the way are very hard to keep up with. That brings us to our first business driver for cloud:

Competitive Advantage: The ability to do something, better, faster, or at lower cost than the competition.

Applying that to the cloud: If my competition is thinking/building their IT infrastructure in the traditional methods and paying the price for it what can I do to improve on that?

Now let's look for some other business drivers, and lets grab the easy ones ('low hanging fruit.') Nearly every business on earth has one common goal, 'grow the business.' There are few if any businesses that hit a certain size and say 'This is just right, let's stop right here!.' That only works for Goldilocks. So then to put this in simple terms let's assume all businesses want the ability to 'scale.' Now that seems easy enough but let's take that idea one step further: in a good economy I may want to scale out (grow), in a bad economy I may want to scale in (focus on core competencies.) With that in mind let's move on to our next business objective:

Ability to scale the business (out and in): Being able to deploy business applications on demand and retire them when needs change.

Applying that to the cloud: I need to bring new business initiatives online quickly and decommission non-profitable initiatives on-demand.

So now we have two business drivers, and while there are many we don't have time for a comprehensive list. Let's look for one more that is another nearly ubiquitous driver. In most companies globally, private or publicly traded, there is one major focus and that is profit. Profit is what can be applied to the owner's pocket or increase the share value. Profit is what's left over after all of the business costs. What's an easy way to increase profit? Reduce cost.

Reduce Costs: Reducing the amount spent to run the business. If the goal is increasing profits then costs must be reduced without sacrificing revenue (total amount of money received by a company for goods or services sold.)

Applying that to the cloud: I need to reduce IT overhead without sacrificing business revenue.

So three of the major business drivers that push the various cloud initiatives are: Competitive Advantage, Ability to scale, and Reduction in cost. These are the real reasons people are looking to cloud architectures of all shapes and sizes in order to redesign the way IT is done.

The most important concept is that cloud is retooling the way we think of IT. If you think in terms of 'How can I improve upon the way I run IT now' you'll miss the mark. In order to gain the maximum benefits from cloud infrastructures you need to think 'What am I trying to do and what's the best way to do that.'

What's a cloud?

So to start things off I thought I'd take a stab at defining the cloud. This is always an interesting subject because so many people have placed very different labels and definitions on the cloud. YouTube is filled with videos of high dollar IT talking heads spitting up non-sensical answers as to what cloud is, or in many cases diverting the question and discussing something they understand. So before we get into what it is let's talk about why it's so hard to define?

Part of the difficulty in defining cloud comes from the fact that the term gets its power from being loosely defined. If you put a strict definition on it, the term becomes useless. For example put yourself in the shoes of an IT vendor account manager (sales rep), if you are an account manager stay in your own shoes for the next excercise and forget I said sales rep.

Now from those shoes imagine yourself in a meeting with a CxO discussing the data center. A question such as 'Have you looked into implementing a cloud strategy and if so what are your goals' can be quite powerful. It's an open-ended question that leaves plenty of room for discussion. Within that discussion there is a large opportunity to identify business challenges, and begin to narrow down solutions which equates to potential product sales to meet the customers requirements.

If cloud had a strict definition such as 'Providing an off-site hosted service at a subscription rate' it would only be applicable to a handful of customers. Any strict definition of cloud based on size, location, infrastructure requirements, etc. reduces the overall usability of the term. This doesn't imply that cloud is just a sales term and should be ignored, but it does make the definition more complicated.

From a sales perspective the value of cloud is the flexibility of the term, which is quite interestingly one of the technical values to the customer (we'll discuss that later.) From a customer perspective the real challenge is defining what it means to you. Service providers such as BT and AT&T will have very different definitions of cloud from Amazon and Google. Amazon and Google will define cloud differently than SalesForce.com, and they'll all have totally different definitions than the average enterprise customer. This is because the definition of cloud is in the eye of the beholder, it's all about how the concept can be effectively applied to the individual business demands.

Part of the reason engineers tend to cringe when they hear the term cloud is that it has no real meaning to an engineer. Engineers work with defined terms that are quantifiable, bandwidth, bus speed, port count, disk space. If you use any of those terms in your definition you've already missed the point. To make matters worse the more cloud gets discussed the more confusing it becomes from an engineering standpoint, we started with just cloud and now have: private cloud, internal cloud, public cloud, secure cloud, hybrid cloud, semi-private cloud. It's akin to LAN, MAN, WAN, CAN, PAN, GAN to describe various 'Area networks' except at least those can move data and cloud is just a term.

Cloud is not an engineering term, cloud is a business term.

Cloud does not solve IT problems, cloud solves business problems.

So to bring a definition to the term let's stay at 10,000 feet and think conceptually, because that's what it's really all about. Think about the last time you saw a PDF, or drew a whiteboard that discussed moving data across the internet. Did you draw the complex series of routers and switches, optical mux's and de-mux's that moved your packet from London to Beijing? Of course not, but what did you draw instead, why? If you're like most of the world you drew a cloud, you drew that cloud because you don't care about the underlying infrastructure or complexity. You know that the web has already been built and it works. You know that if you put a packet in one end, it will eventually come out the other. You don't care how it gets there, only that it does. The term cloud is no more complex than that, it's all about putting together an infrastructure that gets the job done without having to dwell on the underlying components.

The point of moving to a cloud architecture is a rethinking of what the data center really does and how it does it in order to alleviate current data center issues without causing new ones. Start by asking what is the purpose of the data center, and really take some time to think about it. The entire data center, from the input power through the distribution system and UPS, the cooling, the storage, the network, and the servers are all there to do one thing, run applications. The application truly is the center of the data center universe. If you've ever been on a help desk team and got a call from a user saying 'the network is slow' it wasn't because they ran a throughput test and found a bottleneck, it was because their email wouldn't load or it took them an extra 15 seconds to access a database. The data center itself is there to support the applications that run the business.

That tends to be a hard pill to swallow for people who have spent their lives in networks, or storage, or even server hardware because in reality the only Oscar they could ever receive is best supporting actor, applications are the star of the show. No company built a network and then decided they should find an application to use up some of that bandwidth. We've built our infrastructures to support the applications we choose to run our business, and that's where the problems came from.

We've built data center infrastructures one app at a time as our businesses grew, adding on where necessary and removing when/if possible. What we've ended up with is a Frankenstein type mess of siloed architecture and one trick pony infrastructure. We've consolidated, and scaled in or out, we've virtualized all to try to fix this and we've failed. We've failed because we've taken a view of the current problems while wearing blinders that prevented seeing the big picture. The big picture is that businesses require apps, apps come and go, and apps require infrastructure. The solution is building a flexible, available, high performance platform that adapts to our immediate businesses needs. A dynamic infrastructure that ties directly to the business needs without the need for procurement or decommission when an app comes up or hits its end-of-life. That applies to any type of cloud you care to talk about.

In future blogs I'll describe the technical and business drivers behind cloud solutions, the types of clouds, the risks of cloud, and the technology that enables a move to cloud. I'll do my best to remain vendor neutral and keep my opinions out of it as much as possible. I welcome any and all feedback, comments and corrections.

The cloud doesn't have to be a pig