Five years ago I wrote a business plan that described an archiving SaaS project built on cloud computing. In 2007 that was an uphill battle to convince prospective investors “the cloud was the future.” And at that time there was really only one cloud, from the e-commerce giant Amazon. Amazon Web Services really started the modern cloud movement. No existing IT provider (IBM, HP, Microsoft, Dell, etc.) would have had the gusto to upset their current business model with a “disruptively priced” cloud option. For the past four years those IT giants fought the cloud momentum until they had a credible cloud themselves. But for a lean start-up getting funded five years ago, it wasn’t a stretch to assume other clouds would appear to take on Amazon.
The graphic above was my crude way to visualize how a cloud-powered digital archive, anticipating someday living on multiple clouds, could in essence become a “cloud of clouds.” A lot of positive breakthroughs would need to occur to be able to successfully operate a single reference architecture software stack across more than one cloud. There was no terminology to describe this desire. We weren’t using terms like “Big Data” or “DevOps” nor many of the acronyms that today are common lingo in our modern cloud-enabled world. The business plan depicted a system designed to manage lots of data, and being an enterprise document archive, the data itself was large in size and numerous in quantity. We probably started one of the worlds first cloud-big-data projects.
In the beginning the multi-cloud goal was a fantasy dream, a placeholder for a future that seemed possible, but the actual crawl, walk, run steps not precisely defined because we didn’t yet know “what we didn’t know.”
So why in 2008 were we thinking about “multi-cloud?” The answer is we wanted to avoid single vendor lock-in and maintain a modicum of control over our infrastructure costs. The notion of an evolving multi-cloud strategy meant the ability to seek lowest cost of goods from multiple cloud vendors. In the pre-cloud IT world, when services were built on actual hardware, pricing flexibility was derived by negotiating better deals with hardware vendors. The customers didn’t know or care that their SaaS app might be powered by HP sever one day or a Dell 1U box the next. Those decisions were up to the discretion of the SaaS provider to get the best infrastructure value by shopping vendors. But in a single cloud, when there is only one choice, there’s no ability to negotiate between multiple vendors, unless you have multi-cloud dexterity.
Multi-cloud capable means the necessary infrastructure and abstraction layer is available to run a single common reference architecture on different clouds at the same time, with one master operator console. Multi-cloud is almost like, but not exactly, the concept of running a common program across IBM, DEC, Control Data mainframes. The clouds today somewhat resemble massive time-sharing mainframes of the previous decades.
Our early start five years ago, and all the hard lessons learned since, allows us to easily assume a commanding position in multi-cloud deployments. Engineering teams just now starting their “cloud journeys” will learn from us pioneers, but there is an old saying; “until you’ve walked a mile in my shoes, don’t claim to know anything otherwise.”
Multi-cloud requires a demonstrated prowess at:
- DevOps expertise
- Automated deployments
- Cloud-aware security and systems monitoring
- Cost analysis and modeling frameworks
- The learned, trial-by-fire understanding of how virtual infrastructure is very different than a physical hardware hosting environment
- And the right use case for cloud computing
I have covered many of these topics in previous posts.
So as we take our next steps on the multi-cloud journey, here is what we are learning.
Types of Clouds:
- Amazon Web Services and derivatives like Eucalyptus
- Rackspace Cloud and derivatives powered by Openstack
- IBM SmartCloud
- Microsoft Azure
- VMWare and CloudFoundry Clouds
- Boutique clouds like Softlayer, Joyent, Terramark and others
Some clouds (like Amazon) offer a combination of IaaS and PaaS, while others focus mostly on IaaS (IBM, Rackspace) or PaaS (Microsoft Azure).
Our preferred strategy is to work with large public IaaS clouds like AWS, Rackspace and IBM. This is because PaaS centric environments are less flexible and force vendor lock-in. In a few years the cloud landscape (cloudscape?) will mature, and the same way we think about IaaS as being more flexible than PaaS, the PaaS problems of today will be worked out and it will be possible to plan for a time when multi-cloud can embrace PaaS as well as IaaS.
Most of the IaaS clouds behave the same with regard to API’s and underlying operating concepts. This is a good thing, and makes multi-cloud easier to implement. But what we are seeing as differences between the popular IaaS clouds is the costing models. AWS, being the first, did set standards such as “pay as you go” and a simplified billing model that is easy to project monthly expenses.
The differences are in areas like the ratio of compute cores to local storage. And the availability of commodity priced object stores and block-based logical volume file systems. Our internal cost management tool is being extended to map the different cost models to a common view across all IaaS infrastructures. We’re now measuring spend by cost per object processed, cost per hour for all processing, and setting budget alarms when trending data starts to deviate from plan.
It’s an exciting time be at the forefront of the cloud (re)volution. We were there for day 1 of the original cloud, mastering it (and sometimes being defeated) and now we are charting new territory with multi-cloud deployments.