Enterprise software delivery is hard, but there’s a better way.
Part 1: The Problem Landscape
One of the things I worked on at Amazon was helping internal teams collaborate without having to trust each other with sensitive data, as well as helping Amazon collaborate with other companies in a similar way. To overcome what are essentially trust hurdles, we explored a variety of techniques, including differential privacy and clean rooms. Enterprise software delivery presents a similar type of problem: How should you deliver your software product to enterprise customers that won’t share sensitive data?
In this blog post series, I'll explain enterprise software delivery models and why they are so difficult and expensive to implement (this post: part 1), and what an ideal approach looks like (part 2). Finally, I’ll describe the technical details of the approach we’re taking at Tensor9 to help you deliver your software to enterprise customers (part 3).
Enterprise Software Delivery Models
Let’s start with some basic principles, as the industry tends to use a mix of terms to describe the landscape. Enterprise software can be delivered in various ways, broadly categorized by who hosts the software:
Vendor-Hosted:
Multi-Tenant SaaS: A single instance of the software serves multiple customers, with data and configurations logically separated.
Single-Tenant SaaS: Each customer gets a dedicated instance of the software, hosted and managed by the vendor.
Customer-Hosted:
Cloud-Prem (aka BYOC): The vendor’s software is deployed into the customer's own cloud account (e.g., their AWS, Azure, or GCP environment).
On-Prem: The software is deployed on servers physically located within the customer's own data centers.
Air-Gapped: A specialized form of on-prem where the customer's environment has no connection to the internet or any external networks.
Compounding Problems
When vendors set out to deliver a customer-hosted option, they typically end up building and maintaining multiple products: their vendor-hosted SaaS product and one or more customer-hosted products. Why does this happen, even with careful planning and foresight? It’s because deploying, observing, operating, and securing these models is extremely complex.
Each of the above problems are further compounded by more problem dimensions:
Managed Cloud Services: If the customer uses the same cloud as the vendor (e.g., both on AWS), this dimension creates more problem combinations as the vendor might want to use specific managed services (e.g., RDS, SQS, Lambda). However, when the customer uses a different cloud (e.g., vendor on AWS, customer on Azure), then many, if not all, of the managed cloud services the vendor relies on for their SaaS product are simply unavailable in the customer's environment. If the customer is on-prem, this becomes even harder, as managed cloud services are typically not available at all, forcing the vendor to find equivalent self-hosted alternatives or re-architect significantly.
Customer Security & Operational Requirements: Customers have unique security and operational demands, such as specific data tagging policies, the mandatory use of security "side-cars" for all workloads, particular network configurations, or specific compliance certifications.
This compounding effect – each problem above combined with the problem dimensions – results in the vendor having to create and support multiple product variants. This simply does not scale for vendors and creates a huge operational headache, distracting from the vendor’s core business and differentiation.
Solutions Today: How Vendors Cope
There are a variety of ways that vendors typically solve for these challenges, each with significant downsides:
1. Avoid all customers that need a customer-hosted product: This severely constrains market share, as many enterprises, especially in regulated industries or those with significant data gravity, require customer-hosted solutions.
2. Avoid some customers, building product variants for specific customer-hosted needs: As vendors grow, they often start down this path. For instance, a vendor like ClickHouse started with an AWS cloud-prem offering and then, I assume, are planning to add more product variants (e.g., for Azure, GCP, on-prem) over time to capture more of the market. This means the vendor ends up with multiple variants: their primary vendor-hosted product and several distinct customer-hosted product variants.
3. Find a lowest common denominator for the customer-hosted segment: This usually means standardizing on Kubernetes for the customer-hosted version(s). The vendor then has at least two main product variants: their vendor-hosted product and their Kubernetes-based customer-hosted product. This is an expensive rebuild and results in a second product that is costly to maintain. This second product variant often severely limits the use of managed cloud services, or doesn't use them at all, making it even more expensive to build and maintain due to the need to replicate or replace those services with self-managed alternatives.
4. Build for the lowest common denominator from the beginning: Again, this typically involves Kubernetes. The vendor aims for a single product that can be deployed anywhere. The significant downside is that the product must, from day one, severely limit or entirely avoid the use of managed cloud services to achieve this portability. This is also a very expensive approach and often too slow for vendors who want to innovate and capture market share quickly by leveraging the rich services offered by cloud providers.
The harsh reality is that none of these approaches are sufficient: you are moving quickly to serve customer needs and ideally should be focused on your core value versus infrastructure and packaging. The platonic ideal would look something like this:
Singular product (versus multiple variants)
No more expensive to build or maintain this single product than the multi-tenant SaaS
Insulation from various problem combinations (deployment, observability, operations, etc.)
And for you, this means:
Maximum market potential
Minimized initial and ongoing costs
Focus on your core business
In the next blog post (part 2 of this series), we’ll look at a few possible platonic ideals and share how we’re solving these challenges at Tensor9. Stay tuned!
