|By Jason Bloomberg||
|September 15, 2013 05:30 AM EDT||
We know we want it, so Cloud must be a thing, right? If we’re carrying our enterprise IT shopping basket around, we know we want to stop at the Cloud shelf. Once there, we might select a nice fresh IaaS or perhaps some of this SaaS or that. And whatever our selection, we’ll pay the bill at the register. Good thing we brought our shopping list, and with it, our budget for Cloud, right?
Such is what the Cloud marketing machines at the various vendors and service providers want you to believe. Need Cloud, budget for Cloud, pay for Cloud. Cloud is a thing, after all, and we all want that thing.
Not so fast. Cloud isn’t a thing at all. It’s in reality dozens of different things: compute, storage, network, database, development platform, business applications, and more. The value these offerings provide is similarly varied: pay for automated self-service, pay for elasticity, pay for managed services, and so forth.
But if the problem with budgeting for Cloud were simply that such a budget would require many lines of our spreadsheet instead of one, then sure, our budget might be messier than we’d like, but we’d still have one. In reality, the Cloud budgeting problem is far more fundamental. For many organizations, budgeting for Cloud at all is confusing, counterproductive, and deleterious to their long-term IT strategy.
Budget for the Solution
ZapThink’s mantra for many years has been to understand the business problem and focus on the appropriate solution to that problem. Whether it be a software product, an investment in an architectural initiative, or spending money on Cloud, it’s essential that the stakeholders understand the problem they are trying to solve before funding a tool or approach that should lead to a solution. Buy a business intelligence tool if you have a business intelligence problem. Invest in a SOA initiative if the organization is looking to achieve greater levels of business agility in the face of a heterogeneous legacy IT environment. And budget for Cloud when…
When what? There’s the rub. In many contexts, Cloud isn’t the solution. It’s part of the answer, and whether the money should go to Cloud or to some alternative will depend on the nature of the problem. Here are some examples. Let’s say the problem is that market changes have led to new demands on some legacy system, and that system, while it still provides value, isn’t up to the task of responding to the new demands. The solution? Leverage SOA to implement a hybrid Cloud approach that extends the legacy asset by adding new SaaS-based capabilities. Cloud is an important part of this modernization solution to be sure, but as with most hybrid on-premise-to-Cloud solutions, it’s by no means the whole story.
Not all examples are enterprise centric. Many companies that have outgrown the startup category are finding their Cloud environments to be less and less cost-effective as the company grows. Sure, for a startup, putting a new capability in the Cloud is a no-brainer. But for many companies, buying and running their own servers becomes a better deal at some point. If such firms had simply budgeted for Cloud, then they would have had to change their IT strategy when they reached the break-even point. Instead, by budgeting for application hosting, without necessarily designating Cloud as the only option, then the IT strategy would basically say “invest in the hosting option that gives us the best total cost of ownership (TCO),” which is a far better strategy than “invest in the Cloud.”
Budgeting for Elasticity in a Public Cloud
Perhaps the most important benefit of the Cloud (Public Cloud in particular) is elasticity: the ability to rapidly and automatically scale up on demand as capacity requirements grow, and then to scale back down as demands wane. Compared to a traditional data center environment that must provision enough servers to handle peak demand, leading to under-utilization across most of the calendar, the Cloud’s elasticity allows you to pay for only the capacity you require when you need it, which is ideal for any organization with unpredictable spikes in demand.
However, if your workloads have stable, predictable demand patterns, then the elasticity of the Cloud is far less of an advantage, and in many cases, traditional data centers are more cost-effective for such workloads. The conclusion, therefore, should be that if you expect unpredictable spikes in demand, then budget for Cloud, otherwise, budget for more traditional hosting, right?
Again, there’s a problem with this argument. Even for firms with spikes in demand, the spiky demand pattern isn’t necessarily permanent, and won’t generally apply to every workload. In other words, elasticity needs vary from workload to workload, and may vary for particular workloads over time. A better approach is to align your budget with the needs of the applications you are looking to run. By constraining your budget to Cloud, you are limiting your flexibility in how you distribute your workloads to achieve the best TCO.
Budgeting for Elasticity in a Private Cloud
If you’re trying to budget for your Private Cloud, the elasticity value proposition is even more complicated. The problem is that your Private Cloud is elastic until it isn’t. In other words, every Private Cloud has a maximum size at any point in time. If workloads hit this upper limit, you’ll have problems.
Furthermore, the only way to maintain high server utilization when elasticity is a priority in a Private Cloud is when there are several workloads that have different traffic patterns running simultaneously, in the hope that the spikes spread out over time, rather than bunching up. Whether this assumption is reasonable depends upon the number of such workloads as well as the underlying business cause for such spikes in demand. If all your workloads spike on Black Friday as the holiday season kicks off, or if some news event drives traffic to all your workloads at once, then the best laid Private Cloud plans are all for naught.
One way of handling the elasticity limitations of a Private Cloud is by Cloudbursting to a Public Cloud when workload spikes require it. But as I’ve discussed before, Cloudbursting is problematic at a technical level. Even if you can get Cloudbursting to meet your needs, you must still budget for it—and predicting how much it will cost you is fundamentally impossible, since the whole point of Cloudbursting is to deal with completely unpredictable situations.
Again, the answer to this problem is not to budget for the particular technology. Instead, budget for the solution that addresses the core business problem. If you’re an online retailer with seasonal spikes in demand, your budget should reflect an emphasis on the best answer to dealing with that seasonality. Cloud is sure to be part of the answer, but there will always be more to the story.
Budgeting for SaaS
There’s more to budgeting for SaaS apps than simply shifting the capital expense of software licenses to the operational pay-as-you-go that characterizes the SaaS world. True, you do pay as you go, and true, you can typically increase or decrease your per-seat fees depending on shifts in your demand for such apps. But you can’t simply say, “we were budgeting $X for our Siebel license, and now we can budget $Y per month for Salesforce instead,” because mature SaaS apps like Salesforce have fundamental differences from traditional enterprise apps like Siebel. Since Salesforce offers PaaS capabilities as well as SaaS, supported by rich APIs, it’s possible – and actually encouraged – to mix and match Salesforce capabilities with other capabilities available online.
Once again, the budgeting decision should focus on how to solve the business problem, rather than which product to buy or rent online. If you need exactly what a Salesforce offers, no more and no less, and that requirement never changes, then sure, put Salesforce in your budget. But that way of thinking is so twentieth century. Today, budget for the capabilities you require and then put together the best solution available, allowing for change in what that solution consists of. Cloud will indubitably be a big part of the answer. But the answer is rarely or ever simply Cloud.
The ZapThink Take
If my suggestion that you mix and match SaaS capabilities online to meet diverse business needs sounds familiar, you’re right. We call the end result of such conglomerations Distributed Hypermedia Applications, and such applications have been a central part of ZapThink’s architectural research for a few years now. As I discuss in my book, The Agile Architecture Revolution, and illustrate graphically in my new ZapThink 2020 poster, the Cloud is pushing the enterprise to leverage the power of Hypermedia-Oriented Architecture (HOA): the architectural style that was the original intent of REST. So, how can you budget for a SaaS app when it’s really an interconnected web of hyperlinked assets? The answer: focus on the problem and budget for the solution. Don’t budget for a buzzword.