Are PaaS Purchasers Looking for a Polyglot Language Promise?
Join the DZone community and get the full member experience.Join For Free
Are PaaS purchasers enamored by a polyglot language promise? PaaS Polyglot proponents are suggesting that the winning PaaS will be the polyglot language PaaS.
I’m not quite sure historical purchasing trends support the theory.
What structural change has occurred, which invalidates previous purchasing patterns and vendor actions? Throughout the history of compute, hipster languages and frameworks always exist; some die, some flourish. Language selection occurs at a micro-level, project by project. Vendor product (or PaaS service) has traditionally occurred at a micro-level as well (e.g. project by project, business unit by business unit, team by team).
History does not support the ‘One PaaS to Rule them All’ theory. True, PaaS environments supporting a greater number of languages may ease adoption by a greater number of developers, but the theory is untested. Microsoft .NET supports more languages. Do you see C++ and Java developers rushing to adopt the Polyglot CLR? Do you see rapid adoption of Mono in non-Windows environments? Decisions are often based on deep technical integration and a multitude of factors (i.e. performance, cost, technology standards, usability, interoperability, integration, capabilities).
What structural change impacts Polyglot PaaS adoption in a different manner, and is PaaS vendor focus on capturing a polyglot ecosystem an appropriate growth strategy?
The ‘it’s all about the ecosystem’ has historical merit (e.g. Windows, Android, Java, Facebook, iTunes). The defining attribute across the three first examples is NOT supporting ALL/many languages. The defining attribute across successful ecosystem offerings is an open architecture enabling an ecosystem of partners to extend the base platform with third party hardware, manufacturers, frameworks, apps, or music. The extensions enhance the platforms offering in a manner not offered by competitors.
Cloud Foundry has the correct strategy here; build a lightweight framework, which can be extended to run any application server, in any language. Cloud Foundry is a lightweight Cloudy server management framework, which must be paired with a language container (i.e. CLR, JVM, PHP shell) to offer an application platform as a service.
The strategy works right now because Cloud Foundry (the open source project) is not a complete solution, and PaaS providers desire to ride the VMWare marketing train (and obtain the start/stop server functionality ‘for free’). PaaS platform differentiation is a more nuanced situation. Every PaaS will eventually create an ecosystem delivering adequate components and tooling.
Differentiation will require tuning the offering to specific target markets (i.e. consumer, SMB, enterprise) and solving perennially challenging IT use cases. The market will determine winners first and foremost on ‘do you solve my pain’ rather than ‘do you support multiple languages’.
Published at DZone with permission of Chris Haddad, DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.