Tag Archives: cloud

Cloud infrastructure Economics: Calculating IaaS cost

In our previous post, we referenced a number of financial factors and operational parameters that we need to take into account in order to calculate some meaningful costs for IaaS services. Let’s see now how these are combined to produce IaaS cost items.

Your mileage may vary on IaaS; you may be renting datacenter space, leasing equipment, operating your own facilities or simply using public clouds to run your business. However, at the end of the day, you need to utilize an apples-to-apples metric to find out which strategy is the most cost-effective. For IaaS, the metric is the footprint of your infrastructure, expressed in terms of virtual computing units: The monthly cost of a single virtual server, broken down to virtual CPU/Memory and virtual storage resources.

You can check online the formulas in this sheet here. If you want to take a peek on how the formulas work, continue reading.

For simplicity, we will not dive into virtua machine OS licensing costs here – they are easy to find out, anyway (those familiar with Microsoft SPLA should have an idea). We will calculate only monthly running costs of IaaS, expressed in the following cost items:

  • SRVCOST: Individual virtual server monthly cost: Regardless of virtual machine configuration, the monthly cost of spinning up a virtual machine.
  • COMPUTECOST: Virtual computing unit cost: The cost of operating one virtual memory GB and assorted CPU resources per month.
  • DISKCOST: Virtual disk unit cost: The cost of operating one virtual storage GB per month.

Almost all IaaS public cloud providers format their pricelists according to these three cost items, or bundle them in prepackaged virtual server sizes. Calculating these can help immensely in finding good answers to the “build or buy” question if you plan to adopt IaaS for your organization, or determine the sell price and margins if you are a public cloud provider.

Let’s see now each cost item one by one.

Individual server cost (SRVCOST)

How much does it cost to spin up a single virtual machine per month? What do we need to take into account? Well, a virtual machine, regardless of its footprint, needs some grooming and the infrastructure it will run on. The assorted marginal costs (cost to add one more virtual machine to our IaaS infrastructure) are the following:

  • C_SRV: Cost of maintaining datacenter network infrastructure (LAN switching, routing, firewall, uplinks) and computing infrastructure software costs (support & maintenance). We do not include here hardware costs since these are related to the footprint of the virtual machine.
  • C_DCOPS: Cost of manhours required to keep the virtual machine and related infrastructure up and running (keep the lights on)
  • C_NWHW: Cost of network related hardware infrastructure required to sustain one virtual machine. These are pure hardware costs and reflect the investment in network infrastructure needed to keep adding virtual machines.

An essential unit used in most calculation is the cost of rack unit. Referring to our older post for the EPC variable, this is expressed as


This gives us an approximation of the cost of one rack unit per month in terms of monthly electiricy and hosting cost (EPC).

C_SRV is expressed as a function of NETSUPP (monthly network operating & support costs), RU_NET (total network infrastructure footprint), CALCLIC (virtualization/computing infrastructure maintenance & software costs) and SRV (total virtual servers running). The formula is:


C_RU*RU_NET is the hosting cost of the entire networking infrastructure (switches, patch panels, load balancers, firewalls etc).

C_DCOPS is straightforward to calculate:


And finally C_NWHW is the hardware cost needed to add one more virtual server. To calculate C_NWHW we take into account the current network infrastructure cost and then we calculate how much money we have to borrow to expand it in order to provision one more virtual server. The way we do this is to divide the total network infrastructure cost with the number of provisioned virtual machines and spread this cost over the lifecycle of the hardware (AMORT), augmented with a monthly interest rate (INTRST):


Computing cost (COMPUTECOST)

As a computing unit, for simplicity we define one GB of virtual RAM coupled with an amount of processing power (CPU). Finding the perfect analogy between memory and CPU power is tricky and there is no golden rule here, so we define the metric as the amount of virtual RAM. The exact CPU power assigned to each virtual RAM GB depends on the amount of physical RAM configured in each physical server (SRVRAM) and the number of physical CPU cores of each server. COMPUTECOST is broken down to two cost items:

  • C_MEM: It is the cost associated with operating the hardware infrastructure that provisions each virtual RAM GB.
  • C_SRVHW: It is the cost associated with purchasing the hardware infrastructure required to provide each virtual RAM GB.

C_MEM depends on running costs and is the cost of compute rack units divided by the total virtual RAM deployed in our cloud:


Note that in some cases (like VMware’s VSPP program) you may need to add up to the above cost software subscription/license costs, if your virtualization platform is licensed per virtual GB.

C_SRVHW is calculated in a more complex way. First, we need to find out the cost of hardware associated with each virtual GB of RAM. This is the cost of one physical server equipped with RAM, divided with the amount of physical RAM adjusted with the memory overprovisioning factor:


In a similar way with C_NWHW, we calculate the acquisition cost spread over the period of infrastructure lifecycle, with the monthly interest rate:


Virtual storage cost (DISKCOST)

Calculating DISKCOST is simpler. The two cost items, in a similar way to COMPUTECOST are:

  • C_STOR: It is the cost associated with operating the hardware infrastructure that provisions each virtual RAM GB.
  • C_STORHW: It is the cost associated with purchasing the hardware infrastructure required to provide each virtual disk GB.

C_STOR is based on the existing operating costs for running the storage infrastructure and is calculated proportionally to the provisioned disk capacity:


C_STORHW is the cost of investment for each storage GB over the infrastructure lifecycle period:



One can elaborate on this model and add all sorts of costs and parameters, however, from our experience, this model is quite accurate for solving an IaaS financial exercise. What you need simple datacenter metrics and easily obtained costs.


Cloud infrastructure Economics: Cogs and operating costs

Perhaps the most important benefit of adopting cloud services (either from a public provider or internally from your organization) is that their cost can be quantified and attributed to organizational entities. If a cloud service cannot be metered and measured, then it should not be called a cloud service right?

So, whenever you need to purchase a cloud service or when you are called to develop one, you are presented with a service catalog and assorted pricelists, from where you can budget, plan and compare services. Understanding how the pricing has been formulated is not part of your business since you are on the consumer side. However, you should care: You need to get what you pay for. There must be a very good reason for a very expensive or a very cheap cloud service.

In the past, we have developed a few cloud services utilizing own resources and third party services. Each and every time, determining whether launching the service commercially would be a sound practice depended on two factors:

  • Would customers pay for the service? If yes, at what price?
  • If a similar service already was on the market, where would our competitors stand?
  • What is the operating cost of the service?

Answering the first two questions is straightforward: Visit a good number of trusted and loyal customers, talk to them, investigate competition. That’s a marketing and sales mini project. But answering the last question can be a hard thing to do.

Let us share some insight on the operating costs and cost-of-goods for a cloud service and in particular, infrastructure as a service (IaaS). Whether you already run IaaS for your organization or your customers, you are in one of the following states:

  1. Planning to launch IaaS
  2. Already running your datacenter

State (1) is where you have not yet invested anything. You need to work on implementation and operational scenarios (build or buy? Hire or rent?) and do a good part of marketing plans. State (2) is where you have already invested, you have people, processes and technology in place and are delivering services to your internal or external customers. In state (1) you need to develop a cost model, in state (2) you need to calculate your costs and discover your real operating cost.

In both cases, the first thing you need to do before you move on with cost calculation is to guesstimate (state 1) or calculate (state 2) the footprint of your investment and delivered services. From our experience, the following parameters are what you should absolutely take into account in order to properly find out how much your IaaS really costs.

Financial parameters (real money)

  • EPC: Electrical power and hosting cost. How much do (or would) you pay for electricity and hosting. This can be found from your electricity bill, your datacenter provider monthly invoice or from your financial controller (just make sure you ask them the right questions, unless you want to get billed with the entire company overhead costs). EPC is proportional to your infrastructure footprint (ie number of cabinets and hardware).
  • DCOPS: Payroll for the operations team. You need to calculate the total human resource costs here for the team that will operate IaaS services. You may include here also marketing & sales overhead costs.
  • CALCLIC: Software licensing and support costs for IaaS entire computing infrastructure layer. These are software costs associated with the infrastructure (eg, hypervisor licenses), not license costs for delivered services, eg Microsoft SPLA costs.
  • STORLIC: Software licensing and support costs for your entire storage infrastructure. Include here in their entirety also data backup software costs.
  • SERVER: Cost of a single computing server. It’s good to standardize on a particular server model (eg 2-way or 4-way, rackmount or blade). Here you should include the cost of a computing server, complete with processors but without RAM. RAM to CPU ratio is a resource that is adjusted according to your expected workloads and plays a substantial role in cost calculation. If you plan to use blade servers, you should factor here the blade chassis as well.
  • MEMORY: Average cost of 1 GB or RAM.
  • STORINFRA: Cost of your storage infrastructure, as is, or the storage infrastructure you plan to purchase. Storage costs are not that easy to calculate as a factor of 1 disk GB units, since you have to take into account SAN, backup infrastructure, array controllers, disk enclosures and single disks. Of course we assume you utilize a centralized storage infrastructure, pooled to your entire computing farm.
  • NETINFRA: Cost of data network. As above, include here datacenter LAN, load balancers, routers, even cabling.
  • NETSUPP: Cost of network support (monthly). Include here software licensing, antivirus subscriptions and datacenter network costs.

Operational parameters (Facts and figures)

  • RUAmount of available rack units in your datacenter. This is the RU number you can use to install equipment (protected with UPS, with dual power feeds etc).
  • RU_STOR: Rack units occupied by storage systems
  • RU_CALC: Rack units occupied by computing infrastructure (hypervisors)
  • RU_NET: Rack units occupied by network infrastructure
  • SRV: Virtual machines (already running or how many you plan to have within the next quarter)
  • INTRST: Interest rate (cost of money): Monthly interest rate of credit lines/business loans
  • TOTALMEM: Total amount of virtual memory your SRV occupy
  • TOTALSTOR: Total amount of virtual storage your SRV occupy
  • SRVRAM: Amount of physical memory for each physical server. This is the amount of RAM you install in each computing server. It is one of the most important factors, since it depends on your average workload. A rule of thumb is that for generic workloads, a hardware CPU thread can sustain up to 6 virtual computing cores (vcpu). For each vcpu, you need 4 GB of virtual RAM. So, for a 2-socket, 6-core server you need 2 (sockets) x 6 (cores) x 6 (vcpu) x 4 (GB RAM) = 288 GB RAM. For a 4-way, 8-core server beast with memory intensive workloads (say 8 GB per vcpu) you need 4 x 8 x 6 x 8 = 1536 GB RAM (1.5 TB).
  • MEMOVERPROV: Memory overprovisioning for virtual workloads. A factor that needs tuning from experience. If you plan conservatively, use a 1:1 overprovisioning factor (1 GB of physical RAM to 1 GB of virtual RAM). If you are more confident and plan to save costs, you can calculate an overprovisioning factor of up to 1.3. Do this if you trust your hypervisor technology and have homogenous workloads on your servers (for example, all-Windows ecosystem) so that your hypervisor can take advantage of copy-on-write algorithms and save physical memory.
  • AMORT: Amortization of your infrastructure. This is a logistics & accounting term, but here we mainly use this to calculate the lifespan of our infrastructure. It is expressed in months. A good value is 36 to 60 months (3 to 5 years), depending on your hardware warranty and support terms from your vendor.

If you can figure out the above factors, you can proceed with calculating your operating IaaS costs. Keep reading here!

Squeezing VDI in a box

Virtual desktop infrastructure (VDI) is nothing new. Decoupling a Windows desktop from a physical PC and converting it into a virtual image, accessible from more than one terminal has been around for many years, pioneered mostly by Citrix. XenDesktop is the platform of choice for large enterprises, rolling out hundreds and thousands of virtual desktops for internal users and mobile workers.

However, implementing a VDI solution is a complex project with lots of moving parts, and XenDesktop is no exception: For an end to end solution that can be used from all sides of the enterprise (intranet, Internet and extranet users) one needs all of these: Virtualization platform (hypervisors and shared storage), connection brokers, catalog repositories and asset database, provisioning services, desktop image preparation tools, connection proxies, firewalls and load balancers.

Well… Citrix has managed to squeeze all of the above in a single box, with VDI-in-a-box (ViaB). The acquisition of Kaviza in 2011 led to the release of ViaB with tight integration of HDX (the network protocol used by XenDesktop to move pixels, keystrokes and data from the virtual desktop to the user endpoint) and NetScaler (Citrix’s load balancer and application proxy). ViaB comes in the form of a virtual appliance, ready to boot in your favorite hypervisor (ESXi, XenServer and HyperV). The ViaB appliance talks directly to the hypervisor to provision virtual desktops, itself is a connection broker, provisioning server and image preparation platform and works in a grid with other ViaB instances, forming a VDI cluster by just setting up more hypervisor servers, each with a ViaB appliance and joining them in a single cluster. ViaB works with local storage in each hypervisor – no requirement here for DRS or shared SAN storage.

I recently had the chance to setup ViaB as a proof of concept. Literally, the solution is enclosed in a single box. Using a 16GB RAM dual-socket server with ESXi 5.1 (free edition), BiaB was setup and configured in less than two days, given that everything was configured from scratch. The recipe is:

  • A Windows 7 Pro DVD iso image (and corresponding valid key)
  • A Windows 2008R2 server iso image
  • A physical server. Anything with 16GB RAM and 60GB local storage is sufficient for a PoC with five concurrent desktops.
  • Citrix Netscaler 10 virtual appliance (I used version 10, build 71)
  • VDI in a box version 5.1.1 ESXi virtual appliance
  • To test with Internet desktops, two public IP addresses and a FQDN valid DNS entry pointing to the Internet IP address of ViaB. The other IP address is used for outbound connections from the desktops to the Internet via NAT, through NetScaler.

There are detailed guides from Citrix to setup your environment here; the process is quite straightforward, just pay attention to small details like setting up your ViaB to talk correctly to active directory services and your DNS server. In a nutshell, that’s that you do:

  1. Setup your hypervisor. A single Ethernet will do for Internet access. All the other subnets and port groups will be contained inside your hypervisor virtual switch. You need one virtual switch and three port groups in ESXi: an Internet port group, attached to your Internet public network, a private numbered port group to run your virtual desktops, the ViaB appliance, your Windows domain controller and the internal Netscaler proxy port, and finally another VMkernel port group, in the same IP private subnet as your VDI subnet, so that the hypervisor can be accessed from your ViaB appliance. Make sure you have configured an ESXi management address there. The setup I used is shown below:
  2. Install NetScaler with an access gateway license. NetScaler is a fully featured application delivery controller (ADC) which, in our context, will be used as an HDX proxy for desktop connections to the end users via Internet through SSL (TCP port 443) and also as a NAT gateway/firewall, so that all virtual desktops can send traffic to Internet hosts. Installation is easy, download the virtual appliance from Citrix and deploy on ESXi. Setup one NetScaler interface on the public (Internet) network and another interface on the internal private network.
  3. Install the ViaB appliance. The whole process takes minutes. Just deploy the OVF template, directly downloaded from Citrix. Add a license and configure ViaB to talk to your ESXi through the management port setup in the VMkernel port group.
  4. Install a Windows 7 image, enter a valid key, apply latest Windows updates, install VMware tools and leave it running. This image must have a single Ethernet interface attached on the internal VDI network.
  5. Install a Windows 2008R2 server, add active directory services, configure DHCP and DNS, apply Windows updates, install VMTools. Again, attach a single interface on the VDI network. Promote to domain controller and setup a new forest, which will be used to authenticate your desktop users, attach virtual desktops to the domain and apply group policies. This domain controller will be used also to host your users’ roaming profiles, since the desktops that I will deploy will be stateless, erased and recreated every time a user logs out. Here, you can of course use an existing domain controller, just make sure you configure your virtual networks and routing correctly. Best practice is to use separate OUs for desktops and users. Find a snapshot of the AD structure:

    AD structure

  6. Configure a public FQDN pointing to your external NetScaler IP address. Create also a NAT rule in NetScaler, permitting traffic from the internal VDI network towards the Internet.
  7. Now, go to Citrix and follow the instructions in this article. Configuration occurs in two places: NetScaler, to setup the access gateway and the ViaB appliance. The most tedious part is the configuration of NetScaler. I preferred the methid described above instead of using the access gateway wizard, since it’s easier to go back and correct mistakes.
  8. After you have configured NetScaler and access gateway, you are ready to start building desktop images. VDI in a box here is a great tool to use, since it hides all the mechanics of using sysprep and other tools: It prepares your Windows 7 image, installs Citrix HDX agents, configures Windows firewall and lots of other settings.
  9. After you test your image, create templates, add users or groups from your AD and you are set to go. To access virtual desktops, your users have to install Citrix Receiver and point any browser to your NetScaler external HTTP port. There, they enter valid credentials from your AD and connect to desktops.

My guinea pig was my 9-yr old daughter, which by herself logged in, installed Chrome (and flash) on the virtual desktop and accessed her favorite web site, all from the iPad:

Windows 7, iPad view

According to my trusted reviewer, the GUI was snappy, without latency and the whole thing felt much faster. Reasonable, since the desktop was running on a Xeon server.

This is the same view from a conventional PC:

Same view from Windows 7 desktop


Of cloud and factories

The most common metaphor for cloud computing is that it’s like your electric power company. Flick the switch on, log in to your cloud service, pay for what you use, log out, flick the switch off, go to sleep. Well, it’s a bit more complicated that that.

Power companies offer a single product: Electric Power. How many variations are there? Compare them to the myriad cloud offerings: Infrastructure as a service (virtual machines, Windows or Linux), Storage as a service (online, backup, archiving), Software (everything). To me, it looks more like manufacturing and selaling cars. And the cloud business has striking similarities to car manufacturing: Just assume that every car manufactured and sold is a month of a cloud service – any kind cloud service. What are the analogies?

  1. The infrastructure that powers a cloud service is like a car factory. There is an assembly line, pumping out a particular car model/cloud service. In both cases, the product is as good as the materials it’s made of and the quality of the manufacturing process. Also, the pricing catalog varies accordingly.
  2. Cars shipped out of the factory need an extended and reliable transport network, like rail, ports, RORO ships and so on. The same is true with cloud services: Since they are delivered over the Internet, cloud providers need multihoming (peering with at least two Tier-1 or Tier-2 providers), low latency and high bandwidth.
  3. Economies of scale and just in time production: The more cars you build and sell, the cheaper they are. Same thing with cloud services (Amazon Web Services). Also, adding more capacity as you grow is the only sustainable model for cloud providers – the analogy in the car industry is just in time production.
  4. Go to market: Building a cloud service is one thing, selling it is another. All car brands have an extensive network of resellers and dealers, cloud service providers rely also on partners and heavy Internet advertising and market awareness to bring in the sales volume to sustain their business. And volume is key to cloud services, just as it is in the car industry.
  5. Product qualities: Cars come in all sizes, shapes, colours, equipment. The same applies to cloud services. They all look alike (for example, all cloud service providers offer Windows servers), they do the same job, but what really matters is performance, capacity and reliability. What qualities would you look for if you were on the market for a new car?
  6. Common technology: Have you opened the hood of an Audi, Skoda, VW and Seat? The mechanics are the same, but the badges are different. Moreover, three technologies (soon to be four) power all cars on the globe: Gasoline, Diesel, hybrid (and electric in a few years from now). Guess what, it’s the same with cloud computing. There are only a handful of hypervisors and automation platforms that power most cloud service providers, yet, every provider has their own look and feel.

The perfect analogy would be the factory this gentleman used to run:

Usage metering and charging with Cloudstack

One of the prominent features of an IaaS cloud is that one can meter its resource usage by its consumers. Metrics are everywhere: From the hypervisor, virtual disk size, network I/O, occupied IP addresses, virtual CPUs and RAM, they are all over the place, waiting to be collected. As soon as you can grab a handful of metrics, you can implement chargeback policies and report back on your users on their resource consumption or, if you run a public IaaS shop, somehow transform these metrics to invoices.

Cloud.com’s cloudstack comes with an excellect usage server, recording metrics directly from its accounts. During installation, simply select the “Install Usage Server” option and perform some basic configuration, and you are all set to go. The usage server collect no less than thirteen (as of cloudstack release 2.2) metrics, which can be found here. In short, some of the most important ones are:

  • RUNNING_VM: Total hours a virtual machine is started and running on the hypervisor
  • ALLOCATED_VM: Total hours a VM exists (no matter if it’s up or down). Useful parameter for charging OS license usage, for example Microsoft SPLA licenses.
  • IP_ADDRESS: Self evident; applies to public (Internet) IP addresses consumed by a cloudstack account. These addresses are (according to cloudstack architecture) attached to the virtual router of the user
  • NETWORK_BYTES_SENT and NETWORK_BYTES_RECEIVED: Traffic passing through the virtual router of a user
  • VOLUME: Size in bytes of user volumes
  • TEMPLATE and ISO: Size in bytes of user-uploaded VM templates and ISO images
(For those who are not familiar with cloudstack’s architecture, cloudstack users are part of accounts. Virtual machines belonging to a single account live in their own private VLAN, totally isolated from other accounts. Access to the Internet, DHCP addressing, DNS and VPN termination, all take place in a special cloudstack virtual machine, a virtual router. Every account has its own virtual router, not directly controlled by the end user, but via the cloudstack API).

The service (“cloud-usage”) starts along with the rest cloud services on your cloudstack controller and its configuration variables are at the global parameters of cloudstack. The most important are usage.stats.job.aggregation.range and usage.stats.job.exec.time. The first controls the aggregation interval (in minutes) of collected metrics and the second the time the aggregation algorithm kicks in. Remember to restart the usage server service (“cloud-usage”) everytime you play with these variables.

All metrics are stored in a second database, called “cloud_usage”. To see if your usage server really works, connect to that database and see if its tables start to fill (all metrics tables start with “usage_*”). Data can be retrieved from the database, however, a more elegant way is to use the cloudstack API. The most useful API calls are:

  • listUsageRecords: Takes as arguments account, start & end date and returns usage records for the specified time interval.
  • generateUsageRecords: Starts the aggregation process asynchronously

Accessing the API is a breeze: Generate the secret and API keys from the console and pass them as arguments to a python script or a simple wget and target the API port (which is 8080 for plain http, or a designated SSL port).

So, what do you do with all these collected metrics? Well, there are two ways to deal with them. The first is to write a few complex scripts that collect the metrics from the API, sanitize them, implement your billing scheme and export to your reporting tool or ERP to generate invoices.

The second is to use an off the shelf charging/billing solution. As of January 2012, Amysta have a product in beta and Ubersmith offer complete cloudstack billing in their product, Ubersmith DE.

Breaking up with your cloud provider

Suppose you run an average SMB business and you’re proud of having achieved a fairly low TCO by hosting all your operations on your favorite cloud provider, AcmeCloud, who do an excellent job running your virtual machines flawlessly with a 100% uptime and perfect network latency figures. All is well, you have no IT in house and your computing geeks funnel their resources developing new services and bringing in new customers every day. AcmeCloud does all the chores for you (operating VMs, allocating storage, snapshoting and replicating volumes, maintaining SSL certificates and network load balancing) and charging you only for what you use. Until that day…

It started with a 2-hour outage, attributed to a lightning strike. Then, two months later in the peak of the holiday season, you are notified that you must change your SSL certificates due to an intrusion to AcmeCloud secure server – and inform your customers, all 2000 of them, to do the same. And a few weeks later, due to a mishap during a network upgrade, your data volumes suddenly become unresponsive for a whole day causing data loss and forcing a rollback to 2-day old snapshots. Time to find a new home for your data services.

As easy as it is to start using cloud services, that’s how difficult it becomes to change to a new cloud provider. Downloading VM images and uploading them to another provider over the Internet is expensive – you have to utilize high bandwidth for a long time. Exporting data sets from an SaaS data repository and importing them to another is even more difficult, since you may have to adjust data schemas and types. Hoping that all will go smooth and you will be done in a few days is equally possible to finding a pink elephant grazing in your back yard.

In the traditional, old-fashioned IT world we all love to hate, where you have your servers in your little computer room backing them up to tapes and NFS volumes, the story described above is equal to a disaster recovery event. Something breaks beyond repair and you have to rush to find new servers and Internet uplink, then restore everything – well, everything that’s possible – to the new systems and restore services. This has happened once or twice to IT veterans and it’s quite painful to recall.

One could argue that a disaster recovery site and a BC plan would be the solution to this, but, how many average SMBs do you know that can afford a second datacenter? Very few. But, what would be the analogy of a disaster recovery site in the cloudified enterprise? Simply, a second cloud provider. Let’s take some time and weigh the pros and cons of moving your SMB to the clouds, using two cloud providers from day one.

The bad stuff first:

  • Costs will double: You pay two providers. That’s straightforward (really?)
  • Complexity will also double. Each provider has their own interfaces and APIs, which you have to familiarize with.
  • You have to maintain data consistency from one provider to the other. If you go for an active-passive scheme, you have to transfer data from one provider to the other on a frequent schedule
  • You have to control your DNS domain so that you can update your domain entries when you have to switch from one provider to the other


The good stuff:

  • Costs will not necessarily double! By utilizing both providers at the same time, you can split services among both. When either fails, utilizing their elastic cloud infrastructure you can instantly fire up dormant Vms on the other.
  • You have the luxury to make tactical decisions at your own time, not under time pressure. For example, you can tune your online services at your own pace by balancing them across both or preferring one of them that offers better network latency, while keeping data services on the other that offers cheaper storage.
  • You can plan a cloud strategy, by eliminating one of two providers and migrating to a third without losing deployed services.
  • By being forced to move data back and forth from one provider to the other, your IT skills in data governance and transformation will be enriched, mandating your organization to retain control over your data lifecycle and not delegate this function to the cloud provider.


Planning a cloud strategy with two cloud providers instead of one is the same pattern that cloud providers themselves utilize: Reliable services built on unreliable resources. You cannot trust 100% any cloud provider, but you can trust a service model that is built on redundant service blocks.

Adding value to SaaS

Software as a service is an entirely different animal from IaaS or PaaS. Implementing the latter two can be done (almost) with platforms available off the shelf and engaging a few consultants: Grab your favorite cloud automation platform (pick any: Eucalyptus, [Elastic|Open|Cloud]stack, Applogic, Abiquo, even HP SCA, throw in volume servers and storage, host on a reliable DC and you are good to go).

On the other hand, SaaS is something you have to:

  1. Conceive. IaaS and PaaS are self explanatory (infrastructure and platform: Virtual computing and database/application engine/analytics for rent); SaaS is… everything: from cloud storage to CRM for MDs.
  2. Implement: SaaS is not sold in shops. You have to develop code. This means, finding talented and intelligent humans to write code, and keep them with you throughout the project lifecycle.
  3. Market: Finding the right market for your SaaS is equally important to building it. SaaS is a service; services are tailored for customers and come in different sizes, colours, flavors. One SaaS to rule them all does not work.
  4. Sell: Will you go retail and address directly end customers? Advertising and social media is the road to go. Wholesale? Strike a good revenue sharing deal with somebody that already has customers within your target group, say, a datacenter provider or web hosting.
  5. Add some value to your SaaS. Cloudifying a desktop application brings little value to your SaaS product: It’s as good as running it on the desktop; the sole added value is ubiquitous access over the web. Want some real value? Eliminate the need to do backups. Integrate with conventional desktop software. Do auto-sync. Offer break-away capability (take your app and data and host somewhere else).
Let’s take two hypothetical examples: Cloud storage and CRM for doctors.
Cloud storage is a good offering for customers seeking a secure repository, accessible from everywhere. Let’s consider two approaches:
  • High end branded storage array with FC and SSD disks
  • 5-minute snapshots, continuous data protection
  • FTP and HTTP interface
  • Disk encryption
  • Secure deletion
The second approach would be:
  • WebDAV interface
  • Data retention
  • Daily replication
  • Auto sync with customer endpoints
  • Integrated content search

What’s wrong with the first approach? It is typical of the IT mindset: Offer enterprise IT features, like OLTP/OLAP-capable storage to the cloud. Potential customers? Enterprises that need to utilize high-powered data storage. Well, if you are an enterprise, most likely you’d rather keep your OLTP/OLAP workloads in house, wouldn’t you? Why bother?

The second approach offers services that are not delivered from your enterprise IT machinery. It’s added value to a cloud storage service and at the end of the day, they are deemed too expensive or complicated to implement in house. Potential customers? Enterprises that have not implemented these services but would seriously consider renting them.

Let’s consider now a cloud CRM for doctors. What would be some value added features for private MDs, apart from a database with customer names and appointment scheduling? I can think of a few:

  • Brief medical history of patient delivered to the doctor’s smartphone/pad. Can save lives.
  • List of prescribed medicines with direct links to medicare/manufacturer site. Patients can forget or mix up their prescribed drugs; computers never forget.
  • Videochat with patient.
  • Patient residence on Google maps and directions how to get there