As is the case with the advance of hurricane season, the cloud market has recently exhibited plenty of “unstable air.” Major players engaged in a variety of well-intentioned and thoughtful discussions about the market advantages of OpenStack and AWS, and the definition of what a cloud is– and isn’t.
CloudScaling’s Randy Bias wrote an Open letter to the OpenStack Community encouraging the development community to embrace the APIs of well-established cloud providers like AWS, Azure, and VMware to ensure OpenStack dominates in hybrid cloud.
Rackspace’s Robert Scoble responded with his own Open Letter to OpenStack management around the trade-off that any development community faces when allocating scarce resources on innovation projects vs on API development projects.
Subbu Allamaraju, chief engineer for eBay’s cloud program, posted a strongly worded blog highlighting the differences between the complexity involved in building and operating an OpenStack based internal private cloud, and the expectations that customers have around availability, scalability, and performance. Discussions about trade-offs between interoperability and innovation, and the operational complexity of running an internal private cloud are important, but what has gotten obscured is that cloud is about end users consuming a service. Just as touch-tone dialing didn’t just allow users to dial for themselves, but introduced interactive phone services, and the internet didn’t just provide a new way to read text but created the web as we know it today, cloud can be more than just APIs for infrastructure concepts.
End users don’t think about the infrastructure necessary to run the service – network resources, server processing and memory, storage – when they are using a CRM or ERP applications. They also don’t care about the hypervisors, or the management software that provides the necessary automation – whether it’s provided by a single vendor, built from scratch by highly skilled IT staff, or provided by an eco-system of developers. What they care about is availability, scalability, and performance of that service.
In a sense, all of the major players are all right. Skilled IT developers are in high demand to address the complexity involved in running a cloud service. And they need to make a trade-off in how they spend their time – building new services or ensuring compatibility with other systems.
Rolling out applications in a SaaS model is highly complex. Most enterprise applications have not been architected with the necessary capabilities to function in a cloud model, such as multi-tenancy, or metering to track consumption. Rebuilding code to incorporate these capabilities is costly and time-consuming, and may require skills that the enterprise doesn’t possess.
In addition, developing SaaS applications for large scale production environments requires adding new skills in storage, networking, security and more. These skills, once the domain of IT and operations teams, are now also required for application development teams. But these skills aren’t easy to find and can be expensive, as the teams likely have never worked closely with SaaS applications.
Lastly, SaaS involves more than just accessing code remotely. Users expect SaaS to offer more frequent updates with new features. Just operating the code by itself doesn’t immediately provide that benefit, so application developers need to consider how to accelerate the path from code to production.
While the discussions around AWS, OpenStack, and VMware have been focused on the infrastructure, an application-centered approach to cloud can help address these challenges. One approach creates a Virtual Business Service that virtualizes not just the server, but the entire infrastructure needed to run the service, plus the configuration of software, security, and policy enables the wrapping of code, data, storage, networking, middleware and configuration all into a single manageable object. Operators find much less complexity in dealing with a single manageable object, for the typical IT tasks than with services based on disparate parts, APIs, and layers of management. Resources are assigned to the object as a whole.
The service can be replicated with a simple cut and paste to additional customers or even across data centers. The availability of the service is monitored as a single entity. Resources consumed by the service can be tracked for usage- based billing or chargeback.
With all of the discussion on compatibility and operational complexity, cloud providers should not lose focus on the service.