The Cloud’s Great Unifier: Platform Services

I’ve blogged through all of 2013 that of our three “revolutions” of cloud, NFV, and SDN, it’s the cloud that’s the senior partner.  The transformational aspects of SDN and NFV depend to a very large degree on our harnessing cloud capabilities to host network features.  We’re also hearing that Amazon is on a tear, with Credit Suisse estimating their cloud revenues at $3.5 billion and their growth rate at 60% or more.  From this, you might think that our cloud senior partner is going to be a runaway success and drag the other stuff along.  Well, maybe.

The challenge for the cloud today is simple; myopia.  If you believe that IaaS by itself, the hosting of applications that could have been run on dedicated servers or virtualized ones, is a revolution, then you’re likely someone who’s avoiding real stimulation.  There is simply not enough value in IaaS-cloud versus virtualization versus just shared hosting like we do every day for web pages or email.  So the cloud has to be more to be a revolution, and it has to do more than IaaS to support SDN or NFV.  What?

Amazon has been quietly answering that question with what I’ve called platform services.  A platform service is a web service presented through a network interface via an API, and designed to effectively extend the set of APIs that operating systems and middleware normally provide.  It differs from platform-as-a-service in that a cloud architecture based on platform services says in effect “I don’t care what you do to satisfy traditional operating system or local-middleware APIs; make your own choice and build a machine image.  But in your application, do cloud-specific things using platform services that are cloud-optimized.”

Amazon has been adding platform services to EC2, ranging from caching and HTML acceleration to flow optimization and desktop-as-a-service.  All of this stuff lets you build “cloud applications” that would have been impractical/impossible without the cloud, which is IMHO the only way you can generate a lot of true cloud migration.  As large as Credit Suisse’s estimate for Amazon’s cloud revenue stream is, it represents only about a quarter’s worth of server revenue for HP or IBM.  We’re going to have to do a lot better than that to create a revolution, and that’s exactly what platform services could do.

Could already be doing, in fact.  Some of my sources tell me that almost 60% of Amazon’s cloud revenue comes from applications that have a significant platform services component, which means that it may depend on a more-than-IaaS model of cloud computing.  Furthermore, those sources tell me that at least three-quarters of Amazon’s cloud revenue growth can be attributed to these platform-service-consuming applications.

For all of the importance of platform services, we don’t really know too much about them except by example.  Obviously you don’t want to make every operating system or middleware service into a platform service because it wouldn’t add any value.  Disk operations is an example of something that could be extended as a platform service, and many cloud providers offer distributed data operations.  Caching is necessarily a platform services because you have to distribute caches to make them useful.  Amazon’s flow-related stuff (AppStream an Kinesis) are clearly platform services because they draw on specific cloud elasticity features to work.  But there are many other kinds of platform services that could be defined as well.

One example is in the area of information services.  An application doesn’t know much about a user other than what the user is doing with that application, but network applications increasingly depend on understanding the context of the user at the time.  Location-based services could be considered platform services, both because they rely on knowledge of where a user is at the moment that could come from a variety of sources.  Other services related to the user’s current context/presence could also be viewed as platform service.  Is the user on a call, is the user stationary or moving, or in a restaurant or theater?  You can see that this information could be valuable to applications that wanted to apply policies based on what their user was up to, and we’re not going to write all of that stuff into every application individually.

The information services linkage demonstrates that platform services can extend to the API-based services already offered by many social networking, search, and network operator  firms today.  That’s not a bad thing; most revolutions build on the past rather than demanding that everything change radically.  What we’re doing with the cloud is making it possible to define, or compose, applications by assembling information and IT resources from a variety of sources, in an application component set that runs where and when it’s convenient—and runs how it’s most profitable overall.

If you look at SDN and NFV in this light, you can see how the cloud can be a supporting revolution to both.  It’s far easier to understand how an application could define network services if we assume a set of platform services that offer the control of the network, apply policies based on what the user will pay for, how the network’s stability and security can be protected, and what mix of resources will earn the best return with suitable performance and stability.  It’s easier to visualize what a practical NFV service would look like if we assumed that the virtual functions might themselves define platform services and that static features defined as platform services might get composed into a retail offering alongside virtual functions.

A final interesting point about the platform services side of the cloud revolution is that it’s really the unifier of “the Internet” and “the cloud” because as information services offered as platform services evolve, the notion of a web application and a cloud application converge.  At the API level, they’re increasingly the same; the difference between them would likely be primarily whether the hosting of the components had to be very dynamic because of shifts in usage or geography, or could be static as they would be today with a dedicated server or VM in some ISP or OTT data center.

So when you think of the cloud in 2014, don’t get caught in the IaaS trap.  That’s so 2013.

Leave a Reply