A Language a Day Keeps Value Away: Getting PaaS Right
One-man bands are impressive; typically able to play harmonica, guitar, drums, and a bunch of other instruments all at the same time with some meaningful composure but, unfortunately, with very little harmony. Despite this seemingly impressive feat, you never see a one-man band on the Billboard Top 100 – never (and John Popper doesn’t count). The reason for this is simple: one-man bands are good at getting attention on the side of the street, but they simply don’t make good music, let alone music that can be compared to that of a band of specially trained musicians. Being an expert at say, the guitar, requires that you dedicate every ounce of training energy into being a master of that one instrument. It also means that either as part of a band or solo, you can probably make the Billboard Top 100. This level of depth and dedication means that you won’t be relegated to a sideshow alongside the likes of that guy that pours molten lead into his mouth and spits out a cooled, solid lead slug; you have the opportunity to become a music legend. Certainly, Eric Clapton put in much more effort in learning to play guitar than every one-man band guitarist out there, and probably more than a few of them combined.
Building a PaaS is no different than making music. You can one-man band the hell out of programming languages and stack runtimes, but you’re just going to be making noise that sounds OK and gets eyeballs on the street. What you’ve done doesn’t have durable, legendary potential. It seems that lately, every PaaS provider wants to add as many languages as possible as quickly as possible. A week doesn’t go by where there isn’t a press release that is written in the stock format “<Insert Favorite PaaS Here> introduces game-changing, atom-smashing, world class support for <Insert Whatever Language the Other PaaS Said They Support Here>” This is a recipe for disaster both for the market in general, as well as for customers. There is an easy framework for understanding why this is bad business, and it all starts with being a real PaaS rather some heavily diluted manifestation of PaaS.
Building a PaaS the right way means that you’ve either:
- Invented a brand new language and execution runtime, or
- extended an existing runtime (JVM, CLR, etc.) into a new higher order runtime and systems architecture
In either case, the PaaS is doing some intimate, lower level heavy lifting and likely building a host of “base services” that are highly dependent on the language and/or underlying runtime. Those base services are exposed as APIs and are part of provided frameworks, or are capabilities that are instrumented into guest applications of the PaaS. Building all of this is non-trivial and takes a long time to build, but provides extremely rich next generation value to customers. This is the true meaning of “supporting” a language.
Much like the one-man band, when a PaaS starts laying claim to supporting its 37th language, they’re juggling too many things to properly be an expert at any one, and their version of “I’m good at the guitar” is not Eric Clapton’s version of the same statement. This statement redefinition and implied level of expertise is a good parlor trick, but can’t stand the test of time. The way PaaS providers achieve this is that they define “support” as deploying and loosely managing apps of that newfangled language or runtime type, but don’t provide any uniquely differentiated, high quality value. When a PaaS provider says they support a new language, they likely mean that they can move some pile of indistinguishable bits to a new underlying target application server and issue a “Website Start” command to whatever that target is (e.g. Tomcat, IIS, etc.) If that’s “next generation value”, then I’m in the wrong industry.
The huge downside to this multi-language craziness is that it creates a tremendous amount of market noise and distraction, and robs customers of time and value. Up front, a customer gets excited when they see “support” for so many languages. Some customers might not yet understand what the real potential and long term value of PaaS is. They’ll be satisfied with that PaaS, at least for a while. Once they starting building more complex cloud apps and realize that the PaaS does nothing to help them with this because it isn’t a runtime, then they walk away disenfranchised. For customers with more up-front sophistication, they see “support” as woefully inadequate out of the gate and began to get frustrated with PaaS as a concept in general.
A PaaS releasing support for language after language is a bad smell. It typically (I can’t claim always) means that they don’t have a sufficiently valuable piece of machinery under the hood, and they are likely not offering a runtime model. If they did, supporting the N+1th language would be hard work, and I would hypothesize that each N+1th language would take more time to support than the Nth language (rationale is fodder for another post). Now, to temper my sentiment, I do believe it is possible to support multiple languages/runtimes, but it has to be done correctly. The result is likely being able to support a small number of languages, rather than all of them.
If you’re an observer, practitioner, or customer in the PaaS space, don’t get distracted by the one-man band on the side of the street while walking to the rock concert – that would be a terrible reason to reach the ticket counter and hear the words “Sorry, we’re sold out.” If you’re a PaaS vendor, please, do it the right way and stop being distracted by shiny objects: support very few languages very well, rather than all languages very poorly. And remember, you might hire a one-man band to work your 8 year olds birthday party, but people pay lots of money and wear their finest clothes and jewelry for one night out at the symphony.
read more






