Contributed by Randy Jones, Senior Director, Technology Innovation
The combination of cloud computing and ubiquitous Internet connectivity has lowered barriers to entry and made global markets accessible to a new breed of Software as a Service (SaaS) developer. Those who succeed will experience rapid growth but the same cloud services that enabled growth can, if not managed properly, decimate the business. I call this challenge “the cloud trap”.
What is the cloud trap?
The cloud trap occurs because of the tension between “pay-for-use” cloud services and the custom automation code needed to control resource consumption. Software as a Service (SaaS) developers can get caught in a trap between two difficult scenarios:
- Without automation: High risk of “Bill Shock” (i.e. high usage fees) and poor solution scalability,
- With automation: Locked into the features, API, and prices of their chosen Infrastructure as a Service (IaaS) provider.
Neither scenario supports long-term, sustainable business growth
Without automation, cloud resources must be statically provisioned for an anticipated, yet often unknown load. At $20 per instance per month, having five idle instances would waste roughly $100/month. More uncertainty comes from usage costs related to storage and bandwidth consumption. Consider a service allowing users to upload and share rich content (i.e. pictures, audio or video) unhindered. The developer running this service may be shocked to receive the $900.30 charge resulting from 10GB of data transferred out of the service 1,000 times. This could occur because each Gigabyte of storage above a basic quota typically costs 3 cents per month to store and 9 cents per transfer from a cloud. Automation is one of the few options developers have to control costs while scaling their business.
Automation is critical to achieving optimal elasticity in cloud resource usage. But automation software development is a non-trivial activity, requiring a clear understanding of the behaviour of a SaaS under varying load conditions. A critical factor is understanding how compute, storage, and network resources are consumed as a function of offered load. Developers also need to understand how fees are charged as resources are consumed. This is often more complex than it appears on the surface, and achieving cost certainty is a challenge. Ultimately, automation requires a significant investment.
Automation is tightly coupled to the protocol and information models of a given IaaS providers’ APIs for resource usage control. Unfortunately, there are no standardized, broadly available APIs across the most popular cloud service providers. Open source IaaS cloud management systems such as OpenStack show promise of delivering a de-facto API standard, but until these are consistently available across IaaS providers, developers will incur switching costs when they have to re-work costly automation code to move to a different IaaS.
Why lock-in is a problem right now
The IaaS market is going through a classic tornado phase. Few developers consider anything but cloud-based solutions for new offerings, and to capture this demand, new entrants are combining open source cloud management software such as OpenStack with cost-effective hardware to offer new and compelling IaaS services. The resulting competition is driving costs down rapidly.
IaaS fees are declining rapidly and have lots of room to decline further. At time of writing, a web server hosted on a small instance provided by an IaaS costs roughly 5-10 times that of the same web server running on a commodity web hosting service. Considering that cost drivers for offering IaaS and web hosting service are similar, we should expect competition to drive IaaS service costs down sharply over the next 1-2 years. Developers who pin their SaaS to an IaaS price laggard could face a debilitating competitive disadvantage.
The need for cloud independence
To avoid lock-in, developers need to consider plans for cloud independence. We define cloud independence as the ability to host a SaaS on different clouds with tolerable switching costs and/or minimal service disruptions. Achieving cloud independence requires a mix of technical and business practices:
- Minimizing dependencies upon proprietary Platform as a Service (PaaS) features,
- Achieving and maintaining application code portability,
- Automating image synchronization between cloud services,
- Automating data migration procedures between clouds,
- To the extent possible, developing automation for clouds based on a common platform and API set,
- Profiling resource consumption relative to offered load,
- Maintaining a catalogue of cloud providers meeting technical and cost requirements, and
- Understanding the differences between APIs on different cloud services.
Granted, this is a long list with significant lifecycle costs. However, a compelling business case can be made for doing some or all of this work when offering a SaaS with broad appeal. Additionally, developers may consider use of a Cloud Service Broker (CSB) to help in achieving cloud independence. Like brokers in other industries (e.g. insurance), a CSB offers unbiased choice of services for a fee. An IaaS CSB takes on some of the more costly aforementioned practices for developers by:
- Providing a single consistent API with policy based selection of sub-tending cloud providers,
- Aggregating usage monitoring, and
- Maintaining fulfillment and settlement relationships with cloud providers.
Are CSBs part of Canada’s digital infrastructure?
The need for cloud independence is becoming clearer to cloud consumers. While CSBs show promise to help, it’s early days for their availability and use.
With widespread adoption of both public and private cloud services in the digital economy, it’s easy to imagine a future where digital infrastructure will include a CSB. Whether that becomes reality will depend upon many factors including the degree of consolidation and standardization of cloud services in the commercial market, and the evolution of the complex relationship between stakeholders in private clouds for research, education, and government use.
What are your experiences and opinions related to cloud independence and cloud service brokers? Contact Randy directly at [email protected].