Does Modern On-prem imply that SaaS is not a viable business model?
Modern On-prem acknowledges that SaaS is an important part of the ecosystem for serving all customers. This can be for small businesses, those without the technical skills needed to securely run applications, or even for data that is already publicly available or that doesn’t register highly on a confidentiality matrix.
Enterprise customers use AWS, Salesforce, & Slack, so they’ll use my SaaS app.
This is only true if the security controls that a team, application, or infrastructure has in place match the major cloud providers (i.e., Salesforce, Google, AWS, Microsoft). Even then, spreading data around to 1,000 different SaaS vendors increases the surface area for attack/loss by 1000x.
Can’t we just encrypt everything, use EKM or FHE?
While the market continues to tout encryption techniques like Enterprise Key Management or Fully Homomorphic Encryption to increase trust with enterprises, encryption is not the solution for fully functional applications and true zero trust. Find out more with SaaS Encryption Isn’t Secure.
It is too hard to build applications without the IaaS managed services (i.e. RDS, etc.)?
It was significantly harder before OSS was focused on operations, but now, most of the popular OSS components publish an HA Helm chart, or even a K8s operator. These components can be downstreamed into an enterprise distribution for delivery to enterprise environments.
We don’t need to do Modern On-prem because we are _______ certified or compliant.
Point-in-time certifications like SOC II, PCI, ISO, etc. are a great way to signal dedication to good security practices. However, as anyone who has ever worked at a SaaS company knows, their answers to most VSA questionnaires are generally the “best case scenario” answers. Additionally, the supply chain of many SaaS applications means that vendors are distributing data to several other sub-processors who might not be handling it with the care it deserves.
Can Modern On-prem applications charge as a subscription?
Yes, in fact, a recurring subscription model is the most common way to price (vs. models that dominated in traditional on-prem software: one-time fee + maintenance). To do this well, teams should explore the different licensing models that can be implemented for Modern On-prem applications.
What about managed single-tenant?
Managed single-tenant can offer a slightly more secure model than multi-tenant SaaS. It suffers, however, from the same data security concerns that necessitate Modern On-prem in the first place. While the infrastructure isolation of managed single-tenant SaaS can protect an end user from security breaches due to faulty business logic in the application itself, they still require trusting the software vendor with end-customer data. In both multi-tenant SaaS and managed single-tenant models, compromise of the vendor’s staff or infrastructure can lead directly to data breach.
Can I rely on ssh or kubectl access to my end-customer’s infrastructure?
Often, software vendors will allow users to deploy on-premise, on the condition that the vendor receives persistent shell/kubectl access to the infrastructure. While this removes the burden of installation of the maintenance from the end customer, it also requires them to give a lot more trust to the software vendor, undermining the core data security benefits of Modern On-prem delivery, espcially for high-risk data. Rather than relying on direct access, successful Modern On-prem vendors will adopt tools and capabilties that enable disconnected troubleshooting.
Our product needs customer data to learn & improve, so we need access to all data.
While many machine learning models are centralized, Apple has been using a decentralized, federated machine learning approach for many years. Additionally, Google recently open-sourced TensorFlow Federated to aid application developers with a framework to implement federated learning in their own applications.
We’re very comfortable Shipping an OVA or AMI. How is Modern On-prem different?
While delivering a full VM image like an OVA or an AWS AMI is a good way to create a repeatable install workflow, there are a few downsides compared to the Kubernetes-based implementation presented here. Not only are VM images generally slower to build than container images, they also restrict the addressable market of an application. Shipping an AMI limits an application vendor to only those customers who can run applications in AWS, and likewise for OVAs and other cloud-provider image formats.
Futhermore, shipping a closed appliance in a VM image places the burden of operating system maintainance on the application vendor rather than the end customer. When critical operating system patches are made available upstream, application vendors become responsible for publishing packages that can update an OVA in-place. If an open appliance model is used instead, the end customers gain the flexibiliy to manage the base OS.
All that said, delivering a VM does not preclude a software vendor from shipping a modern-on prem application, and can be a useful stopgap if an end customer has yet to adopt Kubernetes.
But we want to be a cloud only company like Salesforce!
We get it. On-prem delivery comes with substantial time and execution risk, and elastic delivery to dynamic clouds is a much easier way to bring a product to market. We believe, however, that rather than being dogmatic about only doing it one way or the other, it is important to give customers the choice of how they want to run an application. Benioff & Aaron Levie had to be dogmatic about evangelizing “The Cloud” in order to position themselves against the incumbents, but that’s now a 20 year-old philosophy. Modern SaaS companies focus on why their product is a better solution for their customers no matter where it is deployed–the fact that they deploy to a public cloud is an implementation detail. There was a time when SaaS vendors leveraged cloud-based marketing messaging to position themselves in the market years ago. 20 years ago, being able to start using software in minutes was novel when most incumbents required weeks or months of setup and provisioning. As on-premise delivery is rapidly enabled by Modern On-prem methodologies however, cloud-only is quickly becoming a legacy model. In general, software teams who fail to embrace Modern On-prem risk being disrupted by upstarts who do.