Your IaaS : Choosing the Provider
I recently found a need for a personal server lab – one independent of my regular employer. I initially wanted my own server where I could setup my virtualization choice(s), setup and destroy environments, and just all-around play with. After looking at the costs, however, I determined that was too costly and, frankly, unnecessary for my needs. I can buy a cloud instance instead, and get a more robust, enterprise grade, scalable datacenter with full support at a far cheaper cost than any single capable server.
The key to determining the best cloud solution (if any) revolves around use case. My use case was for a predefined “virtual appliance” I was testing out. As an appliance, all my requirements were predefined in the virtual machine; I just had to make sure the vendor could meet those requirements. This already defined 2 key requirements in my use case – 1) Must be able to load my appliance, and 2) must be cheaper than buying my own server. I was not particularly interested in a dedicated server due to the higher costs associated with them compared to shared instances – if I were, I would have just bought a physical server, but this is an option you should consider for your own deployments if it makes sense. It tends to be a particularly attractive option in situations where you cannot use shared instances, yet you have no other need for an on premise server. Two other common pricing models are contract and Pay as you Go. Contract pricing is a simple affair where the vendor enters into an agreement for a guaranteed minimum use scenario. You tend to get a significant price discount for this minimum use agreement, and still pay less for whatever you use above this minimum use. Pay as you go pricing (also called no contract pricing) is always the most expensive route per hour of use, but if it isn’t up all the time, it may still be cheaper when it comes time to pay. This defined my 3rd requirement – Pay as you Go pricing without a dedicated minimum.
These key requirements are absolute deal breakers, but there are several other issues to consider as well; and the effort to compare providers on an even basis proved quite difficult. Even among providers that fit the key requirements, many offered different levels of support, features, and of course pricing. What’s more, the pricing scheme was difficult as they priced each feature completely differently. Pricing was always based on resource per unit time, but how they measured the resources and the timeframes were all different from one vendor to another.
After a long time researching, I was able to come up with a spreadsheet to define vendor cost breakouts that was flexible enough to compare most vendors. By defining the server based on the factors listed on their site and the period applied to each cost breakdown, I was able to come up with a monthly cost, then by dividing by 730 (approximate number of hours in a month) I was able to determine the hourly cost for an instance. Comparing the total hourly cost provided a direct comparison.
Once I found vendors who could meet the requirements, I started comparing other factors that differentiated vendors. Many things are assumed addressed when you look into cloud vendors such as Security and Compliance capabilities, but how do you measure them against each other? What are their SLA’s for problem response and resolution? What kind of compensation do I get from a broken SLA? Also, how portable is the virtual machine once it is set up in their environment? Can I export my VM as an OVF file if I want to move to a different vendor? All these questions and many others are very qualitative in nature.
In the end, I made a simple chart for each aspect of concern and listed all concerns within that aspect. One secret I found was to consider all questions or concerns you have in that area and list them. Then look at what the providers offer in that area. If they match up, you can easily check yes or no. Often, however, they listed several items I either didn’t care about in my use case or that I never considered. Use these to expand your list. If they are of enough concern for the vendor to list them, you probably want to at least consider them and compare vendors based on them even if you don’t use them. If nothing else, it points to the vendor’s ability and willingness to comply with and address issues in that aspect. Once you have your lists, compare your various competing vendors and don’t be afraid to contact them if they don’t list an item.
I was able to narrow it down to only 2 competing vendors by this point. It was really nearly equivalent services so either vendor would do. The requirements were met, the concerns were equally addressed, and the pricing per hour use was less than 1/10 penny difference, so I just chose one. In the future, however, I would probably refine my spreadsheet to develop a weighting system against each concern. Then, I would weigh all the various aspects to try to objectively determine which provider fit all my needs the best.
Setting up IaaS: Post Mortem
I found implementation my virtual appliance just as simple and straightforward as choosing a provider was. Things I always took for granted in a traditional datacenter are critical to any IaaS implementation. Even things I expected to be important had some unexpected surprises about just how critical they can be. This pointed me to a lot of caveats I never would have considered before actually going through it.
I have always maintained that network connectivity is the lifeblood of any cloud solution by its very nature. What I did not expect was how critical it would be for that service to have decent upload speeds. Most consumer grade and SMB ISP’s provide asynchronous connectivity heavily weighted for downloads. The problem with this is the cloud service is a virtual datacenter. Bandwidth usage between a data center and the end users is far more balanced than a normal end user ISP typically provides. Don’t get me wrong, you don’t need equal up and down speeds, but you do need significantly higher upload speeds than you would normally need for just email and surfing the internet. Something like Verizon FiOS may provide appropriate upstream bandwidth support, for example, but my local DSL provider’s consumer grade access would not.
Another networking concern is the network connections within the cloud datacenter itself. This networking piece is a fairly opaque area frequently glossed over as “10Gb connectivity” or just as often not even disclosed. Indeed, I would expect this to be irrelevant in many cases, however it is something to consider. This was brought to light in a LinkedIn post I ran across comparing Zunicore with Amazon EC2 on Internal Network Performance. I will not disclose details on it; rather I will leave it to you to decide.
Another oddity I found was CPU sizing. Most of the providers offer a simple number of CPU’s, but there are a few out there that get a little more granular, giving you a CPU size to consider as well. It never really occurred to me this kind of throttling was metered, but internally we do it all the time to reclaim otherwise wasted processor time, why not a cloud provider? There are two reasons I can think of for providers NOT providing this to customers: 1) most providers provision servers ahead of time and sell only those images (or tiers) which may or may not be adjustable afterwards. 2) Providers throttle allowed CPU usage to guarantee time to other machines and forecast growth needs. There may be other reasons as well, but if you want to have that granular control like you do in-house, pay attention and make that a part of your requirements up front. In light of these minor issues, I was actually surprised that there were no issues to note with memory sizing or storage. They are both a straightforward cost per unit measure actually used.
My last major surprise was also my biggest single requirement – OVF importing. I couldn’t just spin up any OS on the cloud as the application couldn’t be installed. However, getting the OVF uploaded was a major headache. The provider acknowledged that OVF uploads were prone to failure and are all around not very reliable. Their suggested workaround was to spin up one of their available images and build an FTP server to get it into my virtual datacenter, and then use OVF Upload to install it. This was a clumsy workaround, but it worked. If OVF uploading is something of concern to you, though, be sure you have a fast, stable connection to your cloud provider. Alternatively you can upload it to a file server or http server where it can be downloaded from a machine implemented within the cloud service. Also note that if you have a particularly large amount of data and/or OVF files, many providers offer a service where you send them physical media with the compressed files on them to get them on their network. Discuss this with the provider before purchasing if this is of interest to you.
None of this was particularly difficult, but it was time consuming. What have been your experiences? What did I miss? How did you deal with your issues sourcing or implementing cloud computing? Let me know below.
Thomas Higgins
