When you move an application onto a platform in the cloud, you will be paying utility-style prices, which are “pay as you go.” Thus, you need to estimate those costs up front. In addition, you’ll need to estimate whether the additional load on your connectivity will require a bigger pipe. Here’s how to do it.

Putting an application into the cloud can happen in at least two ways. You can do it as Software as a Service (SaaS) or you can put it on a Platform as a Service (PaaS). If it’s SaaS, such as hosted Exchange, you’ll usually be charged for the service, not for the underlying processor, storage and bandwidth. But if you put an application on a platform, you will be charged for those underlying items. This article addresses how to estimate bandwidth when you’re putting an application onto a platform. It also shows you how to estimate the load on your connectivity.

Bandwidth is usually measured in one of two ways, and both of them are needed when moving to the cloud. Measuring total usage in kilobits (or Megabits)per second will tell you what size Internet access connection you need. Measuring bandwidth in total number of Megabytes sent and received by the server per month will predict your charges from the cloud provider.

In this example, we’re using Microsoft Exchange as the application. This may be a bit strange, since ordering Exchange as SaaS almost always makes more sense than putting an Exchange server into the cloud, but the for purpose of estimating bandwidth, the example works fine.

There’s a nice, long article on TechNet that describes estimating remote office bandwidth for Exchange in detail, and we’re basing this article on that. It’s at
http://technet.microsoft.com/en-us/library/cc745931.aspx

We have been comparing the numbers in that article with our own data on our current hosted clients. So far they certainly seem in the ballpark.

The numbers are based on Exchange 2007, but we’ve seen no reason to believe bandwidth requirements increase for 2010.

The basic method for estimating any application’s bandwidth requirement is to estimate the size of a transaction with the server and then to multiply this times the number of users and the number of transactions a day (based on the kind of user) . This will yield the number of kilobytes per day for each kind of user. It’s then just a question of aggregating the numbers and converting them from total bytes to kilobits per second. Our example does it this way:

The bandwidth estimate is broken down into three parts: (1) A definition of light, medium, heavy, and very heavy user, then (2) average Kilobytes per day of usage that one would expect based on the four classifications and type of E-mail client, and (3) the bandwidth that one might expect based on a 100 user organization under the various conditions.

1. Definition of light to very heavy user

2. Bandwidth usage is

3. Scenarios by classification

You can use this Table 3 to estimate your bandwidth requirements based on the number of mail-users you have and about how many would fall into each of the Usage categories. The High Hour numbers assume a daily peak of twice the average usage.

Again, two expressions of bandwidth will be necessary for moving into the cloud, both in Mbps and in terms of total MB sent and received per month.