This post was also published in VentureBeat.
When Salesforce’s Marc Benioff first started pitching on-demand CRM software, people thought he was insane and were convinced software-as-a-service would never work. Although we are now living in a SaaS heaven with all of the benefits of software that is always available and up-to-date, we are also beginning to see the SaaS hell naysayers were warning us about.
When selling Salesforce to a mid to large organization, Salesforce expects multi-year contracts with pre-negotiated user counts, exactly like the on-premise predecessors it ridiculed during its early days. The whole idea of “pay for what you use” has been subsumed by the realities of the sweet cash flow dynamics of a traditional enterprise sale, which ends up as shelfware when customers over-provision.
Compounding this issue is that the expense is accounted as an operating expense that affects EBITDA, a key Wall Street metric, while on-premise software was accounted as a much more palatable capital expense.
There are some other cracks in the SaaS armor. In a world of “big data,” enterprises are starting to realize that SaaS solutions do not offer unfettered access to their own data. Salesforce’s API access to your own data is metered and hinged off of user counts or API purchases – an enterprise has to take out its wallet and pay these vendors for scaled access to its own data. In a world of extreme security consciousness among CIOs, security is fully delegated to the SaaS provider. The multi-tenant model shares data infrastructure to the benefit of the vendor, not the customer. Integrating various SaaS silos has become so complicated that the field now has dedicated systems integrators like Appirio.
SaaS has become the orthodoxy du jour, with an ecosystem ranging from accelerators to post-traction venture funds focused solidly on SaaS. After 15 years of SaaS, you do have to ask, what’s left to SaaS-ify? In many segments, we are now on the third or fourth iteration of software that offers essentially the same workflow, such as Namely and Betterworks on the heels of Workday. The latest entrants are forced to target verticals in sluggish industries like construction and energy. So the question is, what’s next?
Containers and Containers-as-a-Service
There has definitely been a lot of buzz about Docker containers. The ability to separate an application, microservices, and their configuration from the underlying Linux operating system is very attractive. Orchestration layers built on top of containers such as Docker Swarm and Google’s Kubernetes make it easier to manage and scale clusters of containers.
The three major cloud providers, Amazon, Google, and Microsoft, have all added CaaS (Containers-as-a-Service), allowing any Docker container to run on their platform, filling a void between IaaS (Infrastructure-as-a-Service) that requires a lot more system administration and configuration, and PaaS (Platform-as-a-Service) that is typically very limiting in terms of language support and libraries.
Containers have been around for quite a while. As Bill Coleman, the former head of Sun Micrososytems’ Software group, recently reminded me, Solaris offered containers in 2005. What’s changed is that the new generation of Docker-powered containers have widespread support and are easy to learn. Now that there is a standard way to manage and deploy applications, there is the potential to reinvent how cloud software is delivered.
The Potential for CaaSi to Fix SaaS
Imagine a world where when you can purchase software or rent an application, then run it in the public or private cloud of your choice. Just like SaaS, the software would be automatically maintained by the vendor. But you would own and control all of your data, including the access by the vendor.
Until recently, this would have seemed like a pipe dream due to the intricacies of hosting, managing, and updating the software. Now, we are almost there. With some small incremental improvements, CaaS can evolve into CaaSi – Containers-as-a-Service for ISVs (Independent Software Vendors). Whether in a public cloud or in your own private cloud, the vendor would have the access and keys to manage and update the containers on your schedule rather than theirs. The vendor would not, however, have the ability to access your data without your explicit permission.
With the new CaaSi model, software customers have the best of the on-premise world combined with the best of the SaaS world. When customers buy software, just like with on-premise software, they have complete visibility into the hosting costs, full ownership of their data, tightly controlled security, and also the flexibility to use capital expense accounting. Just like with SaaS, they have the ability to scale as needed and receive automatic updates from the vendor.
Given such a huge transition on the horizon, it is no wonder that Docker is a newly minted billion-dollar unicorn with companies like CoreOS and Mesosphere battling over the best implementation of Google’s Kubernetes. In order to build out a CaaS/i future, CaaS providers need to add better support for immutable infrastructure by maintaining the separation between application containers and their underlying data, along with the delegated management of containers, usage metering for billing and abstraction for services such as logging and monitoring.
One highly material benefit that customers receive from SaaS is the network effect – the ability of the vendor to analyze in aggregate how all of the users are using the system and accelerate that usage in new features. In order to provide a similar level of functionality in a CaaS/i world, customers would need to opt-in to anonymous collection of their data usage in order to receive the same benefits of the analysis. But rather than a drawback, perhaps this is the point: the vendor should have to ask permission in the first place, and the customer should control their sensitive data.
A few startups are kicking off this trend. My own company, Sapho, is enthralled about the ship-as-a-container option and has launched that alternative. Tray.io, an orchestration backend, is only available as Docker containers. And Replicated and Infradash are providing the infrastructure for an independent software vendor to ship and manage Docker containers. The coming year should see a lot of activity on this front.