There’s been a lot of activity in the PaaS space lately. This is largely fueled by the successful exit of Heroku, and since a lot of investment tends to be made by looking in the rear-view mirror, a lot of people are turning their eyes to infrastructure and platforms. These sorts of businesses haven’t been as much in favor lately, and there’s more than a few startup “experts” who have been very critical of platforms and infrastructure. While it’s true that the business models for these have taken some time to adapt to the era of open source and the cloud, it’s silly to ignore just how much long term value and ROI has come from these types of companies. Oracle now owns MySQL, there’s a lot of ways to look at that, but I tend to view it as both companies won and won big (as did both platforms and closed source and open source, this stuff is nowhere near as mutually exclusive as the pundits would have you believe).
Now we’re seeing a number of other companies trying to follow the Heroku model. Unfortunately, these ignore some of the underpinnings of what made companies like Heroku and Engine Yard feasible and then what made them good businesses. Most PaaS vendors are basically giving you a place to run your code. Despite conventional wisdom, there are truly just are a handful of languages that are really easy to run as parts of web stacks. Java and .NET have very robust web application packaging and deployment capabilities. The P in LAMP was always PHP, not Python or Perl. Java, C#, and PHP are the three most popular web application languages in the world. If you think otherwise, you work at a Web 2.0 company. Hosting an app written in one of these languages in the last decade hasn’t been all that hard, and it’s gotten progressively easier. Deploying, running, and debugging a Java web application can be done without leaving your IDE to literally thousands of hosting providers. Amazon with Elastic Beanstalk has added some nice features on top of that to not just deploy but automatically scale Java apps. PHP already has a Heroku, it’s called GoDaddy.
Back to Heroku, what a lot of people didn’t expect was that Ruby on Rails would become as popular as it has, and what they didn’t fully appreciate was that Rails had a lot of capabilities that really became a lot more powerful when used in an integrated stack. So, basically, there weren’t a lot of good options for Rails hosting, and further, people who went with Heroku or Engine Yard were able to see a very significant increase in productivity because their Rails environments were fully provisioned with a set of stack services that could be readily leveraged.
Now, if you’re trying to do a PaaS in the “place to run your code” model, you’re likely going to miss the point, and you’re going to think that adding more languages is going to make the difference. The problem is that you’re moving down the long tail of languages, and any business that starts going down the long tail tends to have more than a few problems. I’ll stick to the product and technology issues in this post because they’re big enough challenges in and of themselves.
Let’s get into the weeds on this. If I want to build a Java app, there are a bunch of services all defined by standard API’s for everything you can imagine. What I want from a Java hosting service is a place I can upload my Java WAR file and all the jars for the apps I want to run. Not always that easy, but nowadays, it’s one-click to Amazon Elastic Beanstalk and, because Java is the most popular web programming language in the world, there are a lot of other hosting companies that will handle it too. There are a lot of high end companies that will run it enterprise-grade and low-end companies that just do the basics, but it’s a robust ecosystem.
If I build a Ruby app, I want the hosting service that knows Ruby and has super-optimized for it. I really don’t care if they support PHP too. I don’t want them to be spreading themselves thin on WSGI or Plack, or whatever else. I just want to be sure I can be the most productive on Ruby that I can possibly be, that the additional services that are provided in the stack are tested and optimized for use with Ruby, etc. That’s raison d’etre for Heroku and Engine Yard.
Similarly, if I’m writing Python, it better be awesome at Python. Hence the love/hate relationship Python people have with App Engine. It’s not the best Python hosting in the world, but there still aren’t a lot of options, and someone may yet do it right. Competing with Google probably deters the competition, but consider that App Engine now supports Java too. Most Java people who value their time or sanity seek other options, of which, unlike is the case for Python, there are many.
If you’re in the multi-language PaaS business, and you want to be world-class, which you have to be if you want to compete against either the low-margin low-touch hosting companies or the really great high-touch customer-service intensive ones, you better be budgeting $250K a year per language you list on your website, or you should just pack it in. Same thing for every database, every search engine, every message queue. Everything you purport to make “turnkey” or “dead simple”. Back at Six Apart, people would complain that we didn’t support some specific database with Movable Type. The reason we didn’t was that we just couldn’t allocate the resources to even pass marginal QA acceptance, let alone claim we had world-class support for that database. Really learning this stuff deeply takes time and effort, like a dedicated fulltime engineer. That’s why most tech startups have the “expert guy”, who’s the end-to-end guru of whatever language or technology they’re using. Like the person who wrote the ORM driver for Perl, or created Memcache, or invented OAuth, or contributed some major piece of code to Django, or figured out indexing in Cassandra, or wrote a book on Java. Customers choose PaaS so that they don’t have to have the “expert guy” at their company, because the PaaS vendor has them at theirs. Now you might begin to understand why these PaaS vendors have to raise so much money. If you’re a PaaS vendor, and you don’t want to, or can’t afford to, have more than one “expert guy” at your PaaS company, you have no choice but to just focus on one language stack, and the three or four most widely-used languages already have a lot of good world-class options for supporting apps in the respective web stacks for those languages, which means you’ve got a bit of a challenge in figuring out where to focus your efforts.
Just in case you’re wondering, yes, I am working on a PaaS startup. But I’m not getting into the “place to run your code” business.