Randy Heffner uses some broad numbers to generate some general financial analysis that help demonstrate when a cloud computing model like Infrastructure as a Service does and does not save money compared to a more traditional on-premise infrastructure. This is the third part of Forrester Analyst Randy Heffner's 2011 SOA in Action VTS keynote from June of 2011. The text below represents a partial transcript of the video.
There is so much that goes into getting good numbers for a cloud analysis. What I've prepared captures some of the basics, but your analysis would have to be more full and complete – using your numbers from your environment and your contracts and relationships with hardware providers and network providers and much else. So instead of spending a lot of extra effort to get more specific numbers that wouldn't really be any more applicable to your environment, I've done broad analysis to capture and demonstrate the concepts and the financial dynamics.
I used Amazon’s cloud cost calculator - it’s a pricing calculator - and Dell’s configuration engine to price out specific servers to do some analysis in trying to get equivalent computing power between those environments. After adjusting for CPU speeds and things like that, I used a basic 4 to 1 ratio. One Dell server that's got 4 CPUs and a bunch of memory equates to 4 Amazon machine instances.
If you acquire some Amazon instances, or other cloud provider, and you run them all the time, 24 hours a day, you’re not as likely to save money. Here I've got three numbers. The Dell number is buying one server and running it for 36 months. There are costs figured in for maintenance and for support and so forth.
For Amazon, I've got the grey line representing you run your Amazon environment 24 hours a day. The blue line is if you cut the system in half for the off-peak hours and run just a basic environment for most of the 24 hours. And here, the Dell server is only half of what the Amazon Infrastructure as a Service numbers are.
But one server isn't really a very good example. Let's ramp that up so we can really get a lot of value from being able to scale our system down in the off-peak hours. Now our numbers are a lot closer. Here we have 5 Dell servers and an equivalent number of Amazon instances. We're only running four Amazon instances (equivalent to one Dell server) all the time and we're turning the others on only when we need them at a three hour peak period. And now our numbers are much closer.
My point here is, it takes very close management of the cloud environment in order to make sure that you’re getting the value and it may not always be the least expensive environment.
Let’s look at a customer site backed by legacy - a more realistic kind of scenario. It's a big e--commerce website with a lot of stuff happening in legacy systems that we will assume are on-premise and we'll just put that website in the cloud.
It becomes very important to understand what’s going where on the network, because network access is part of the cost here, in both environments. Here we need a big fat network path that we’re going to need between our website and our customers and a little bit of a thinner amount of data going back and forth between the datacenter.
Same architecture, different scenario leads to a whole swap in economics in cloud versus on-premise.
If I was running this all inside my data center, that big fat pipe that I need out to my customers would be a dedicated internet access line for my data center. Those lines are very expensive. Tens of thousands of dollars a month as you get up to higher volumes and you’re talking big costs. We’re going to need a lot of network volume between the cloud environment and our customers. And here, the Amazon costs end up being about half of the Dell environment and your saving - in this environment - a million to a million and a half dollars and that's real money.
But let’s consider a different customer scenario. Instead of a broad customer base, we’ve got a small, very active customer base. So this causes a different network access pattern where now the fat pipe is between the data center and the cloud, and much thinner between the cloud and out to the customers. We’re spending a lot less on the site because it’s smaller volume. The Dell environment is now half of what the Amazon environment is.
Same architecture, different scenario leads to a whole swap in economics in cloud versus on-premise. In other words, you really have to understand your environment if you’re going to understand and make the right financial decisions for the company.
Read the full text transcript from this video below. Please note the full transcript is for reference only and may include limited inaccuracies. To suggest a transcript correction, contact [email protected]
Financial analysis of cloud computing versus on-premise architecture
Randy Heffner: As we dive in, I first want to start with a bit of a disclaimer. I'll get around to some financial analysis with cloud in just a bit, and the analysis, I'm confident, is a solid analysis. But, as I'll explain, it is so much that goes into getting good numbers for a cloud analysis. That, what I've prepared captures some of the basics but your analysis would have to be more full and complete using your numbers from your environment, and your contracts and relationships with hardware providers and network providers and much else. Rather than spend a whole lot of extra effort to get highly refined numbers that wouldn't really be more applicable to your environment, I've done a broad analysis to capture and illustrate the concepts of financial dynamics, and so I want you to understand that as we look at some of those numbers.
As I show you these numbers, let me tell you where they come from. I don't have time to go through all the details of every bit of how these numbers are calculated, but basically what I’ve done is use Amazon's cloud cost calculator, its pricing calculator, and Dell's configuration engine to price out specific servers, and to do some analysis in trying to get equivalent computing power between those two environments. So you see things like, at Amazon, the basic small instance is a 1 core, or 1 CPU, kind of environment. If you buy a Dell server, many of them are 4 CPU, 4 core environments, 4 core servers. So it takes adjusting some and analyzing some for CPU speeds and all of that. What I use for these numbers is a basic 4-to-1 ratio: One Dell server that's got four CPUs and a bunch of memory, to 4 Amazon's—so one Dell server for four Amazon machine instances. So that’s where you’ll see some of the numbers here.
First off, just to get a basic point out there—and this point has been made elsewhere: If you acquire some Amazon instances, or other cloud provider, and you run them all the time, 24 hours a day, you're not as likely to save money. Let's look at what some of that looks like. Here I've got three numbers. The Dell number here is buying one Dell server and running it for 36 months, and we've got some maintenance costs that I've added in for support, and it's higher support for the Dell server than for the Amazon instances, and that sort of thing. The gray line here is, if you run that Amazon environment 24 hours a day, the blue line in the middle is if you run that Amazon environment, you basically cut it in half during off hours and just run a basic environment for the 24-hour period.
Well, wow. Three years, the Dell numbers come out to half of what the cloud-based Amazon Infrastructure as a Service numbers are. So, that's real interesting. Well, but one server is not a real good comparison. What happens if we really ramp that up, so that we get more ability to get some of that turn off what you're not using in the Amazon environment. Well now things get a little closer. Here what we do is we've got 5 Dell servers, and an equivalent number of Amazon instances, but we're running only 4 of those AMIs equivalent to one server for all the time, and we're turning on the other ones only when we need them at a 3-hour peak period. Well now we get much closer numbers. One might even make these numbers closer, if you could take it down to just one Amazon AMI. So, you might get down to equivalent, maybe the Amazon numbers come out a little closer. But my point here is, it takes very close management in the cloud environment in order to make sure that you're getting the value. And it may not always be the least expensive environment.
But now let's get to something more real. Let's look at a customer site backed by legacy, kind of a more realistic scenario. Big e-commerce website, and so here we've got customers accessing the website, we've got some local data there, that's syncing and doing orders and product catalog updates and getting customer data from our back-end environment, that we're going to presume is still on premise. We're just going to put that customer website in the cloud. Let's see what happens with some of these numbers. Well, we need to get some real sizing numbers on here, so we're going to say, this is a big site, 21 million pages a month, and 43,000 orders, and 3 million SOA requests back and forth between the customer website and the CRM system a month. Lots of stuff going on. Well, here, if you look inside some of these numbers, it becomes very important to understand what's going where on the network, because network access is part of the cost here, in both environments.
We've got a big fat network path and we're going to need lots of network volume between the cloud environment and our customers, but a little bit of a thinner notion, amount of data going back and forth between the data centers. Here's actually what the specific numbers are: We need 1.6-gigabytes-per-second peak to the cloud if we figure that we've got a 3-hour peak, and a 12-hour peak, and we're running it 24 hours a day. Then we've got up to 116 terabytes a month, in and out, with some assumptions about page sizes, and number of pages to make an order, and things like that. Back to the data center, we need 22-megabytes-per-second peak, and there's a fair bit of data going in and out there.
So here's the important thing to understand: If I was running this all inside my data center that big, fat pipe that I need out to my customers would be a dedicated internet access line for my data center, out to one of the major Telco providers and then out to the internet. Those lines are expensive; thousands, tens of thousands of dollars a month, as you get up to higher volumes and you're talking OC3, OC4, OC48 and all these different kinds of numbers. So, it gets to be a big cost there, and the Amazon environment here winds up being half, or actually less than half, of the Dell environment. And you're saving, over this scenario, a million to a million and a half dollars, over three years. Wow, that's real money. That's great, let's all jump into the cloud. But, wait a minute, let's look at a different customer scenario.
Let's assume that rather than a huge, broad customer base, we've got a small, very active customer base. By very active, I mean this might be something like what some of Cisco's customers are as they dial in or go into Cisco's website to order hardware and that sort of thing. And they know what they want, they buy it. And it's not a whole bunch of folks browsing, and looking and a few folks buying. There's a bunch of people in there, they do it, they buy it, they're out. So this changes the numbers quite a bit. The red numbers are the ones that are different from the previous scenario. And so this causes a different network access pattern where now the fat pipe is between the data center and the cloud, in this scenario. It looks thinner between the cloud and out to our customers. These are some specific numbers based on my estimates, here.
Now in this scenario, it swaps around. Now, we're spending a lot less on the site, because it's smaller volume. The Dell environment now is half of what the Amazon environment is. Same architecture, different scenario, leads to a whole other swap in the economics of cloud versus on-prem. In other words, you've really got to understand your environment if you're going to understand and make the right financial decision for the company.