Platform is such a lovely word. Software vendors like platforms because it gives them an additional capability to partner with a community of developers. In cloud era, platform is often associated with PaaS (platform as a service). For the last few years, PaaS was mentioned as a next step in developing of cloud platforms. PaaS is often seen as a layer (together with SaaS and IaaS) in many marketing cloud slides presented by software vendors. CAD and PLM vendors are using it too.
I put some of my thoughts about PLM and PaaS earlier – Cloud PLM and PaaS dilemma. It is a difficult task to create PLM platform that can be used by other developers. In my view, none of existing cloud PLM products regardless how they call themselves cannot be qualified as PaaS. Will cloud PLM vendors develop PaaS options is a question I asked last year. I don’t think we got any good answer so far.
The usage of word platform and PaaS is often controversial as well as a definition of a platform. Meantime, the bigger world of PaaS ruled by large platform vendors (Amazon, Google and others) are going to rethink PaaS too. TechCrunch article Whatever Happened To PaaS? speaks about some interesting transformations happening with PaaS development by large cloud vendors. Companies are not rushing to provide their strong commitments to PaaS platforms. Here is the passage explaining three reasons why customers are not running towards PaaS and keep IaaS option as preferable.
App Engine’s prices drop regularly, but they’re voluminous and confusing, and a single instance — a pretty puny virtual machine — costs more than a dollar day, not counting storage or bandwidth. Same for Heroku. You get more bang-per-buck by simply buying and running your own servers. You also get enormously larger headaches, and significantly slower development time; but that tradeoff isn’t worth it for many
Then there’s lock-in. Once you build your app atop App Engine’s custom APIs, you’re committed; there’s no easy way to back away and go to another provider. The lock-in is less for other PaaS providers, but it’s still there. There is no universal PaaS equivalent of de facto IaaS (infrastructure-as-a-service) standards such as OpenStack or Docker.
The third, least valid, and arguably most powerful reason is culture. Companies don’t want to give up perceived control over their systems–even if that control is never worth its associated complexity–and sysadmins, understandably, don’t want to evolve themselves out of a job.
In my view, it explains well why PLM PaaS idea may be dead on arrival. The only reason for partners and developers to use platform is cost and speed. If I can spin a new server in minutes and develop my own cloud application, why I should bother with using of PLM PaaS. The potential reason could be data access and interoperability. But it will come down fast to customer lock-in. Openness and interoperability is a big issue in engineering world. Engineers and manufacturing companies don’t like to be locked on a specific software. Even PLM PaaS will provide an attractive set of functionality, I hardly can see how developers of vertical applications and solutions will lock themselves on a specific PaaS and won’t keep an option to provide this solution for other platform and vendors.
What is my conclusion? For the moment, PaaS looks more like a marketing buzzworld used by PLM and CAD vendors. I think vendors will take time to understand what means to deliver cloud platform that will be robust enough not to break under the complexity of multiple vendor dependencies, long development and usage lifecycle and technological innovation. So, PLM PaaS is not here yet and may not happen after all. This is a not for PLM architects to watch technological trends of large vendors and think how to develop future PLM platforms. Just my thoughts…
Best, Oleg
Image courtesy of Stuart Miles at FreeDigitalPhotos.net
