BACKGROUND IMAGE: iSTOCK/GETTY IMAGES
Revolution is a big word, and one that's overused much of the time. In the case of cloud computing, the revolutionary potential seems bogged down in pedestrian early applications. Many enterprises report that the majority of their cloud applications have been simple extensions to Web hosting or server consolidation. But for the cloud to reach its potential, it has to be more than that.
Fortunately, a few trends are driving the cloud to the right place at last. These trends -- which represent the future of cloud apps -- include platform services, cloud-centric operations and support, and cloud-ready software and data models.
Platform services: An 'in-between model'
Infrastructure as a Service (IaaS) alone is simply hosted virtualization. It will be valuable to users with low utilization and high cost of labor for hardware support, but it doesn't offer enterprises enough economy-of-scale benefits relative to their own data centers to spawn a real revolution. Platform as a Service (PaaS), which locks users into a specific operating system and middleware set, displaces more current cost but has a narrow target of opportunity. Led by Amazon, the cloud industry is creating an in-between model: platform services.
A platform service is a service that is made available through an application program interface (API) to any application running in the cloud. The idea is to take a generally valuable application service feature (such as content caching or database management) and make it a service of the cloud rather than a component of an application that's moved to the cloud. That lets the cloud provider optimize the platform service for cloud operation and get the maximum economy of scale, and as a result, provide the lowest cost to users. For users, in turn, it simplifies application development and lowers development cost by creating a packaged feature they can build into new development quickly.
Amazon Web Services has long offered platform services, but Amazon has augmented basic database and management services with caching, Web page preprocessing, and now flow management and optimization. All are offered as APIs, so, as Web services, they don't limit a buyer's choice of operating system or middleware. In fact, users report that they can adapt current applications to use these new features fairly easily. The result: We are evolving current data center applications into something new and cloud-specific as we migrate them to the cloud. We're building the first cloud applications.
New cloud operations tools and frameworks
We are evolving current data center applications into something new and cloud-specific as we migrate them to the cloud. We're building the first cloud applications.
Another factor driving the future of cloud apps is the evolution of cloud operations tools. Cloud users know that deployment, integration and management of cloud-based or hybrid applications can be complex and costly -- sometimes so much so that the paradigms of cloud cost-savings are at risk. Cloud stack vendors are working to address this with new models of development and operations (DevOps) integration, but these are often narrow in application and require changes to the applications themselves. That may change with a carrier initiative called network functions virtualization (NFV).
Network functions virtualization aims to allow software features to be installed on hardware and composed into sellable network services. While the telecommunications companies that are driving NFV have aimed it at network features such as firewalls or load-balancing, there's no reason why it can't deploy customer relationship management or other application software just as easily. That could create a model of Software as a Service (SaaS) deployment for cloud providers -- or even IaaS or hybrid cloud deployment for enterprises -- that is simpler, cheaper to manage and more easily changed in response to changes in market needs or business opportunities.
As we evolve both the platform services and operations frameworks of the cloud, we'll start to see applications develop that aren't simple transplants from current data centers, but applications that neither did, nor ever could have, run there. That will expose developers, users and cloud providers to the challenges of cloud-specific applications for the first time.
Social-media companies such as Twitter and Facebook; media companies such as Netflix; and search, Web and cloud giants such as Google are already moving toward the future of cloud apps by developing applications that push the boundaries of current software technology and practices. We are evolving the enterprise notion of service-oriented architectures into the notion of a Web-like, simple, event-driven application framework. We are evolving relational databases into management architectures for big data and unstructured data. Examples such as Hadoop and MapReduce have already emerged -- and more are on the way.
The cloud horizon
What can we expect, then, for the future of cloud apps? First, future applications will be written for the cloud directly. In addition, future applications will use cloud-hosted services offered by both cloud providers and third parties, and even authored by enterprises, and delivered through generic, Web-like APIs.
Finally, future cloud applications will be deployed using a DevOps model that works for any kind of distributed application, whether the components are hosted in a data center or in the cloud, and whether they are application features or network features. This will all be based on a new architecture that will start by defining cloud-specific applications and end up defining a development model that will gradually evolve from being a cloud architecture to being the only architecture.
That's the key evolution for the cloud because it's the only evolution that assures that the cloud's benefits are fully realized. Today's notions of IaaS and PaaS and SaaS, of hybrid and public and private, are evolutionary factors inhibiting the cloud revolution. In the cloud, everything is a service, everything is represented only by an API, and everything looks and is managed the same. It's just a matter of where the cheapest place to put it might be.