Luiz - Fotolia
There's increasing buzz in the market about raising cloud services above the infrastructure as a service (IaaS) level. In the cloud hierarchy, the next option up the value chain is platform as a service (PaaS). Unlike IaaS -- which is virtual machine hosting and requires the user to supply an OS and middleware -- PaaS provides the complete platform, both hardware and software, on which applications run. PaaS does more, so it has more potential benefits for users. And because of this, providers can justify a higher price tag.
PaaS may be a natural evolution from IaaS for cloud services, but there's more than one way to get there. Microsoft's Azure represents one path: Take an existing data center platform and replicate it in the cloud. A second PaaS approach is offered by tools like Cloud Foundry: Build your own "platform" from selected tools and deploy it. The third way, supported by Amazon Web Services (AWS), is to augment IaaS with Web services to create a "platform services" model. All three paths between IaaS and PaaS have merit, so deciding which trail you'll blaze means looking deeper into the details.
Joining Microsoft Azure on its path to PaaS
To follow the Microsoft Azure model of PaaS, your cloud-targeted applications must be running, or can run, on Microsoft's server software suite in the data center. Thus, the strength of this approach lies in the connection with the current software strategies; it's easy to evolve from Microsoft servers to Azure because the cloud provider is also the on-premises software platform provider. Keeping the two in synch should be straightforward.
The weakness of the Azure path is few data center server platforms are widely deployed in a single form -- and so, except for Microsoft, it's hard to point to a platform where the approach would be practical. Microsoft has resisted opening its Windows Server framework to prospective PaaS competitors, which means some Azure users feel locked in. It's not clear how Microsoft would mold Azure to add features native to the cloud that are not relevant to Windows Server, such as the cache services now available from AWS.
Other examples of this Azure PaaS model are the cloud platforms based on the Java virtual machine (JVM), which is a portable platform that runs on multiple architectures. Amazon and other public cloud providers offer hosted JVM and Java apps that run on almost any data center or desktop system. However, this approach works only when the target applications are written in Java -- a serious limitation for many users.
Composing PaaS with third-party tools
The second approach to PaaS is more generalized. Tools such as Cloud Foundry and OpenShift provide a start with IaaS and add in OS and middleware tools to build a cloud platform. With this approach, apps have a dependable hardware/software combination to run on. Users and application lifecycle processes are immunized against maintenance efforts of platform software.
The problem with composed PaaS is figuring out who will build and maintain the platform images. A public cloud provider could use a composition tool to build a platform to base PaaS, but it's unlikely a vendor would take this risk. The vendor would have to bet on whether there are sufficient apps available to run on it to create a viable market opportunity. If the composition tool's agility is exploited to create multiple platforms, then keeping each up to date becomes labor-intensive, and management costs rise. These tasks would be passed on to cloud users.
Users themselves could compose a platform using the same tools and run it on IaaS. Users will benefit if these tools allow them to organize middleware and OS components and make them available for app deployment. This is an alternative to remaking every machine image they have when there is a change in OS or middleware. In fact, it's the largest use case of platform composition tools today. However, finding a market niche for a given platform makes it doubtful that this path will be widely used for public PaaS.
Taking the platform services approach
The final option is platform services, which is being adopted de facto by AWS. Platform services presume the goal of PaaS is to add highly cloud-optimized or cloud-specific services and support them in any app that exercises a Web service through a URL. This approach is unique because it's targeting applications changed or written for the cloud rather than ones migrated from on-premises.
This focus on the future makes platform services the driver of public cloud service trends. The platform services model offers improved agility -- like the composed platform model -- but, it aligns new platform elements with valuable cloud application features.
Where it falls short is that users must maintain their machine images, because this model doesn't host OSes or middleware. Adding a composed platform tool such as Cloud Foundry to manage those elements could address this issue for users.
In theory, a public cloud provider like AWS could provide so many platform services that it would effectively be defining a cloud OS. If this were done -- and if special development tools were provided to build applications to that cloud OS the same way they're built for current platforms -- on-premises platform providers might decide to support it to take advantage of the new apps. Then the cloud would have arrived, shifting the market from the cloud accommodating on-premises platforms, to on-premises platforms accommodating the cloud.
About the author:
Tom Nolle is president of CIMI Corp., a strategic consulting firm specializing in telecommunications and data communications since 1982.
OpenStack dominance in question?
Pivotal PaaS criticism holds water
Trek to the top of the IaaS mountain continues