The close down of Xeround and discontinuity of Rackspace support from AppFog has caused a lot of chatter in cloudland. This chatter is mostly focused on the polyglot nature of the providers in question, speculating both on the support they were getting from the IaaS players in the market and the politics behind the scenes. Although there is a lively and healthy debate about the long-term effects of these events, almost everyone agrees that in the short-term they are not helpful toward customers confidence in small cloud SaaS vendors.
Interestingly, Ben Kepes points to the failure of small vendors in the market not solving the unit economy of their offering before becoming polyglot providers of their services on as many clouds as possible. Although I am in agreement with Ben’s argument about theeconomies of these services, I think each individual case had specific underlying issues that were not easily addressable.
The Universal On-Demand Omelette Making Service
Xeround was a MySQL as a Service provider. They perfected the art of hosting and scaling MySQL in the cloud and were present on many cloud vendors from AWS to Rackspace to HP. For the users, services like this sound great: offload the complexities of building, running and scaling backends to the experts. It is Database as a Utility. This has been the case for many technologies from database (hosted MySQL, MongoDB, Redis,) to messaging and middleware (hosted RabbitMQ, ZeroMQ,) to caching (hosted MemCached).
This model has fundamental issues however. Issues that in my opinion have largely contributed to the demise of Xeround, will go on to claim more victims, and ultimately are the reason that public PaaS has not picked up as it was envisaged.
The central issue being that the providers of hosted open source utilities do not add value that matters greatly to their users.
Let’s look at the case of a hosted open source tool like MySQL. MySQL is an open source tool that can be picked up by almost anyone and put on a dedicated or cloud server as a database. This part is easy. Users who use MySQL at this level usually don’t care about many of the scaling and availability issues at the beginning. Those are usually bridges to be crossed at a much later date.
The challenge of hosting a utility - like MySQL - is doing it at scale where you can deliver a robust, scalable and economical service. This is where things break down. Running a scalable and robust MySQL is an engineering challenge that some companies are willing to outsource, but the challenge for the utility hosting company is even greater as they have to host farms of utility servers.
This is like running a service that sends a chef to your home in all major cities in the world every morning to make you an omelette. Although it is great for customers to have omelette-on-demand with a phone call, the company providing the service needs to solve huge logistical problems to make it happen. This greatly impacts the unit economy of the service in a way that’s not easily solvable.
So here are the available options: The service providers either host their utilities in silos in which each customer gets their own dedicated cluster of servers - like having your own dedicated omelette chef, or they have to solve the huge problem of a robust multi-tenanted environment - where users share the underlying infrastructure.
Hosting is cheap, show me the IP
This is where the economies of hosted utilities break down: In a world where anyone can buy commoditized cloud servers from Amazon directly, these utility vendors have virtually no margin on hardware. If they choose to host their customers in silos, they will have to charge them for the operations they run. Running operations doesn’t benefit from the economies of the scale. The number of sysops usually grows with the number of servers and since the provider doesn’t have any valuable IP (it’s all open source after all, remember), they essentially become glamorized sysop consultancies.
In a non-silo model where the company adds value by cracking the difficult problem of multi-tenancy, they can benefit from the economies of scale and pass that on to their customers, giving them financial incentive over hiring their own sysops and running their own servers. The issue here is that those difficult problems are extremely expensive to solve and take a long time to mature as technologies. It is possible to solve those problems however, and some companies will eventually emerge as winners of the hosted utility providers in each category. Now these companies will have another economical issue: the presence issue.
Running a multi-tenanted utility only becomes economical with a certain threshold of number of users per instance is passed. Also in almost all cases, the utility servers need to be at the same datacenter as the consumption point. This means the providers need to be present on AWS, Rackspace, HP, Google and many other vendors, which means a lot of servers to be paid for before breaking the customer/server threshold. These vendors also need to be polyglot from day one before they can sort out the unit economies of their service and that’s where it starts to hurt financially. All this, is assuming the IaaS vendors are not going to climb up the value chain by providing hosted solutions themselves (see ObjectRocket acquisition by Rackspace).
Walled gardens
There are companies (and products) however that approach hosted utility business differently: they have their own proprietary (own IP) tools that are not available as open source solutions. These are usually built from the ground up as hosted solutions: TempoDB, Iron.io products and Amazon Dynamo DB and RedShift are some examples.
These companies take the approach of solving niche problems (time series data for example) and polishing them to perfection. Their markets are not as big as a hosted RDBMS but the added value is clear to the user and they can have a meaningful impact in the marketplace in the long run.
The game of hosted utilities is not over yet. Innovation and new IP is happening every day and great companies show up from San Francisco to Beijing every month. Open source, proprietary, multi-tenanted or dedicated, with SLA or no SLA are all factors affecting the outcome of this game, and although the end is not written yet, the long-term winner is already known: the happy customers who can benefit from the choice and commoditization that is caused by all this.