Rawpixel - Fotolia
IaaS and PaaS blurred lines increase lock-in risks
There are three distinct cloud service categories: IaaS, PaaS and SaaS. However, IaaS and PaaS are getting a little too close, and you need to be aware of vendor lock-in risks.
Organizations are accustomed to the question of whether to adopt IaaS or PaaS as part of their cloud migrations. That choice requires real soul searching -- or, at least, a lot of research -- for decision-makers.
But while IaaS and PaaS still have their differences, the distinction between the two blurs as the cloud matures. "Ten plus years ago, when AWS came on the scene, the game was mostly about IaaS: replacing fixed-cost, inflexible, on-premises hardware with flexible [and] pay-as-you-go cloud infrastructure," said Melanie Posey, analyst at 451 Research.
Back then, she added, AWS' key products were Amazon S3 and EC2. Since then, the progression of cloud technology has pushed its users to "do more with IaaS than mere lift and shift from on premises," she said.
PaaS evolves
PaaS also underwent a slow makeover in the last decade or so. "In the early days, you had PaaS providers offering application development and integration frameworks, essentially middleware and runtime environments," which abstracted the infrastructure needed to enable the activity, Posey said. PaaS often targeted app-focused tasks, such as development, management and integration, with something like a Hadoop database or machine learning system, she said.
AWS incorporated PaaS functionality into offerings. AWS Elastic Beanstalk, for example, packages VMs, load balancing, auto scaling and other services, which enable developers to focus on the application rather than the underlying infrastructure. In essence, AWS provides both IaaS -- the VMs and storage -- as well as PaaS technology, for all the capabilities that run on top of the infrastructure. Therefore, Posey said, AWS is both an IaaS and PaaS provider, which muddies the distinction regarding service types.
Emerging technologies, such as containers, all still run on top of IaaS, but they should be considered PaaS. "[Because] containers are a way to package and deploy apps, they are technically PaaS, while VMs remain firmly in the IaaS camp," she said. Ultimately, the public cloud now performs IT functions, rather than simply provides a source of cheaper, better, faster compute and storage than the corporate data center.
With that being said, some providers, such as Apprenda, positioned themselves as cloud application platforms -- PaaS providers that use hyperscale IaaS or their own hosting environments for the infrastructure layer. "What they're selling is application platforms and development frameworks," Posey said.
The IaaS and PaaS distinction is less clear from a provider standpoint, but it is clearly less important for end users, noted Deepak Mohan, analyst at IDC. "It doesn't matter what you call it. What an end user wants is a selection of tools from a big palette; some are SaaS, some are PaaS and so on," he said. "Across the spectrum, the end user just picks and chooses."
With AWS, for example, an end user might rely on serverless computing, database, machine learning or management tools, like identity and access management, without worrying about how far up or down the application stack the service falls.
Vendor lock-in risk with PaaS
Deepak MohanAnalyst, IDC
When it comes to vendor lock-in, IaaS and PaaS are clearly still different. Each PaaS offering tends to be specific to each vendor, which can limit your options. "Many abstraction options exist for the infrastructure services [IaaS] today to help avoid lock-in, but on the PaaS layer, you are locked in," said Lauren Nelson, analyst at Forrester Research.
Mohan agreed. "You must remember that the lower you are in the stack, the more consistency there is across different platforms and the more you have the freedom to build in-house," he said. Conversely, up the stack, the choices become less transferable and more proprietary. As you pick and choose technologies to support a workload, think about your strategy, he said. For example, you might want to build similar platforms on different cloud providers, but early decisions can't easily be changed. "If you start using Cloud Spanner [relational database service] on Google Cloud, it isn't equivalent to what's offered on the other providers, so the code you write and the tool you create in-house won't be portable," he said.
For many users, strategy boils down to functionality and affordability. "You should have a three- to five-year plan on a platform and a clear idea of what your constraints and requirements are as far as portability," Mohan said.