Developers love PaaS. It frees them up from thinking, managing and tinkering with infrastructure. Heroku, the biggest generalist public PaaS provider boasts more than 4,000,000 applications running on it. It was sold for $212MM to Salesforce in 2010.
However PaaS vendors havent made much impact beyond the world of prototypes and tinkerers. No other public PaaS vendor has made it big. Even in Herokus case and despite their size, only 9 of the top 10,000 websites run on it. It seems that no public PaaS vendor is making much money. Many argue that Herokus revenue was and still is nowhere near something that can justify the price tag Salesforce paid for it.
Why is that?
Many have tried to answer this question. Default surface responses are: lack of control, cost of running on public PaaS or the fact that it is public.
However, I have yet to see any justified answers to this question, or to any of the following:
- How can a product be so popular with its customers, yet fail to make money in such a dynamic market?
- If the problem with PaaS is price, why isnt competition driving the prices down?
- If it is the lack of control, why havent companies with more open/flexible PaaS solutions succeeded?
- If it is the public nature of it, why are companies happy to run their infrastructure on public cloud vendors like AWS?
- If it is the 3rd party risk, why are companies happy to run their infrastructure on Rackspace that is 20x smaller than Salesforce (Herokus parent company)?
Some claim that this is a problem with the developers market. They claim there is little money in selling developer-focused tools. However, this group cannot answer how companies like Github, Twilio or many other developer focused companies have grown so big, and are generating healthy revenues.
In my opinion, the answer has three parts: Economic, Cultural and Operational.
Economic
Public PaaS providers rely on a variety of complex technologies to run their operations: Linux containers, isolated file systems, reverse proxies, load balancers and more.
This technology stack enables public PaaS vendors to provide a platform to their customers, but more importantly, it provides one of the core benefits of public PaaS in taking care of the difficult parts of the customers infrastructure, transparently allowing that customers business to scale. Each part of the public PaaS technology stack represents an engineering challenge for a small business. It is however a massive and expensive engineering challenge at the scale that a public PaaS needs to run.
While the economies of scale move a public PaaS company to a unified technology stack, the vast number of apps running on them makes maintaining and updating the whole stack very expensive.
On the other hand, the initially unsubstantiated promise of easy infrastructure makes it almost necessary to operate the business on a freemium model; meaning developers can move their workloads to the platform, make it work and see the benefits, before their growth. This builds up a huge subsidized layer of users of the platform, making it even more expensive for the paid accounts. The recent move by dotCloud to ditch their free plan is evidence to this. Heroku is also moving towards an ever more crippled free tier.
To make running a PaaS cheaper, the vendors usually fine-tune their platforms for a single IaaS vendor (like Heroku on top of AWS). This unfortunately passes the vendor lock-in to their customers. People usually perceive vendor lock-in as a bad thing for economic and 3rd party risk reasons. But the IaaS vendor lock-in as a result of a public PaaS choice goes beyond those: any existing, non-PaaS and legacy systems of the customer should run on the same IaaS, to be in the same data center as the PaaS vendor even when there are financial and technical reasons against it.
Another big selling point for PaaS vendors is the NoOps aspect of it: Drop in your code and it just runs. No need to get involved at the infrastructure level. This means the PaaS vendors become responsible for providing a lot of additional adjacent systems to their customers: monitoring, backups, database as a service, APM and more. This is not something that a single company can feasibly do.
There are numerous open source tools available to help Devs and Ops with their needs in application management. However, the closed, proprietary and hands off nature of PaaS also stops customers from using the vast array of open source tools that are available to developers when running on their own servers.
Thats why public PaaS vendors have integrated add-on shops where they sell their partners products as a service to their clients.
This is great for the PaaS vendor if they can build an ecosystem to attract both sides of the network: Providers and Customers. But as with any other double-ended network, it is a difficult thing to do and only a few notable PaaS vendors have managed to build such a network (Heroku and Force.com).
PaaS addon providers mostly sell the same service as an addon or outside of the PaaS marketplace. However the former is sold 30% cheaper. This puts 3rd party vendors participating on PaaS add-on shops in a difficult position: Firstly, they are reluctant to participate in marketplaces that have little traction, as it requires investing in integration with no clear or guaranteed returns. Secondly, they dont promote their add-on presence in the hope that the customers will engage with them directly rather than through the add-on marketplace.
Furthermore, PaaS vendors have to charge the increased fees to subsidize running an expensive freemium platform (it’s suggested that more than 80% of Heroku revenue is from the add-on store). Which also means they are not incentivized to reduce their partner charges.
All of this ultimately makes running on a public PaaS expensive for end customers: PaaS fees on top of all of the 3rd party tools they need ends up being a huge part of their tech expenditure and after a while it becomes difficult to justify, so they move out. This is a visible fact in the public PaaS market.
Cultural
PaaS is popular with small companies, but why? The biggest reason is that small companies usually have developers who take care of ops as well. This means that the adoption of PaaS is not putting anyone in danger within the organization. PaaS removes the need for Ops and small companies have no Ops function. Conversely, Public PaaS is not as successful in bigger companies that have an Ops function as it takes control away from them which they naturally resist.
Combining this with cost of a public PaaS means companies which currently run on PaaS will eventually move away from it: The costs get too much, so they hire Ops teams to do it themselves and subsequently would never go back (even if the cost issue could be resolved): they now have internal resistance against it from their Ops team.
One of the reasons configuration management tools like Chef and Puppet are successful in large organizations is that they are tools for the Ops teams and therefore empower them. Developers have their code and Ops have their Recipes: everyone is happy.
Operational
IT teams bigger than a certain size will usually divide the decisions between Devs and Ops. This is a natural result of the business requirements of change management. Furthermore, those teams usually operate on different work cycles: Devs are mostly supporting new requirements while Ops take care of supporting the business systems (thats also why Devs teams are the first ones to get the chop during downturns while Ops teams are the last).
Public PaaS disrupts this by force-merging the two cycles into a single cycle: the Devs one; which is unfortunately not always the one in tune with IT as a supporting function of the existing business.
What about private PaaS?
Many cite the public side of public PaaS as an issue with big business. They use the growing success of private PaaS solutions like CloudFoundry as an evidence for this. The success of public clouds like AWS however, is evidence against this perception.
I believe the success of private PaaS is a direct result of addressing the cultural and operational problems that exist with public PaaS, and have little to do with privacy or vendor lock-in of public PaaS. By acknowledging and empowering the existing forces within organizations, private PaaS and configuration management tools have managed to face little resistance in large organizations.
Where is Cloud 66 in this?
On the surface it is simple to compare Cloud 66 with a PaaS solution like Heroku. This comparison is based on the technological outcome of what we do. We reduce the cost of Ops by simplifying the automation of infrastructure management. We also do this by starting with code, which makes us more similar to a PaaS solution.
However, and crucially, where we differ from PaaS is around the economic, cultural and operational aspects of it.
By using the customers own infrastructure thereby alleviating the need to share our stack between multiple customers, we reduce our costs and increase agility in moving the platform forward at different speeds for different customers. In real terms this translates into a solution that is 60% cheaper for the customer. Additionally this frees them from IaaS vendor lock-in which is of course appealing to them.
By giving the customers Ops team power and access to their own infrastructure, using tools and practices they are familiar with, and integrating with their existing workflow, we empower them and avoid cultural issues within the organization, all the while allowing the Ops teams to retain control over their own operational work cycles.
Ultimately this aligns with the natural state; giving the Devs team control over what needs to run through their code, and the Ops team control over how it needs to run.