Most discussions about cloud computing thus far have been about moving applications to the cloud. However, despite a high growth rate in cloud services, this strategy hasn't brought cloud spending to even 5% of IT budgets. Cloud leader Amazon Web Services (AWS) is signaling that there's another path to cloud success, one that uses the cloud to do things that would be difficult, expensive or even impossible to do in the data center.
If a platform service is offered through an open API that can be replicated in a data center (private cloud or even legacy software), that service could migrate into and out of the cloud for cloudbursting and failover. It could create a whole new model of hybridization.
The trick to capitalizing on this is to understand platform services, assess these services' options and design applications for platform services-based enhancement.
Getting the gist of platform services
For a cloud architect or planner, it may be convenient to think of platform services as a kind of horizontal SaaS, a set of tools that supports a set of applications that have common technical characteristics and needs, instead of a single vertical. (Salesforce.com and SAP are good sources of Software as a Service elements that use this horizontal orientation.) Collaboration and unified communications are two examples of SaaS tools that can be considered platform services, in addition to the many AWS tools available.
Build an inventory of horizontal software tools available in Web-services form by reviewing all these sources, then consider building applications from scratch around these tools. Where you have componentized applications in-house, the components can be added to these baseline platform-services-framed app ideas to create something more specialized to your business needs.
Assessing platform services options
The challenge for users wanting to leverage platform services is that those services aren't part of what we currently think of as the cloud.
The challenge for users wanting to leverage platform services is that those services aren't part of what we currently think of as the cloud. They aren't elements of current applications, so they can't facilitate a simple migration of those apps to the cloud. In fact, using platform services will almost certainly require some custom development, either by your own company or a third-party contractor. For those who see the cloud as way to lower IT costs, this seems counterproductive, but platform services can build applications with inherent capacity elasticity, better performance and availability, and even better user interface performance and quality of experience. The trick is finding true platform services.
When assessing your options, remember that all truly useful platform services will exploit the cloud in some way. There are useful management services -- such as orchestration tools, integration, etc. -- that could be offered using Web APIs and might be similar to platform services, but they don't extend the utility of the cloud; they only facilitate app migration and management in the cloud.
A good exercise in platform service assessment is to review Amazon's catalog of services, where you'll find management service extensions, database services that are extensions in basic cloud data management, and so-called application services such as AppStream and Kinesis; Simple Queue Service, or SQS; Simple Notification Service, or SNS; etc. It's this latter group of services that represent examples of true platform services: services that make a cloud application a better app. Prospective cloud users should explore this type of service.
Designing apps with platform services
The problem for the cloud consumer is that there are no standards for platform services and little chance that standards will evolve quickly enough or be broad enough to generate interoperability among providers. A platform service is effectively a virtual appliance, and if everyone who provides an appliance picks a different interface, there will be major problems if you have to change providers or adopt multiple ones.
There are some steps that can reduce the risks associated with nonstandard APIs for platform services. One is to create a single app component to run, instead of scattering references throughout the application. This way, there's only one component to change if you choose a new provider. Another strategy is to explore alternative implementations of the service from all possible providers, and then write your own so-called wrapper application, based on the broadly used conventions. This approach will allow you to make fewer changes if you change providers.
It is very likely that a general framework of platform services offerings will emerge from the competitive cloud market, but it's not likely that standards will emerge. It will always be important to recognize that platform services are powerful tools that can tie you to a smaller group of cloud providers, and that you'll need to weigh the benefits of platform services against the risk of having a limited field of cloud offerings.
About the author:
Tom Nolle is president of CIMI Corp., a strategic consulting firm specializing in telecommunications and data communications since 1982.
This was first published in February 2014