The SaaS Innovator's Dilemma - And How We're Addressing It

Hearing more and more concerning warstories about troubled #SaaS projects has motivated me to capture some of their underlying problems, and describe what can be done about them.

Let me frame this within the Innovator's Dilemma, and how it applies to the ongoing generational transition from #shrinkwrap #software products to #scalable software #services ("SaaS").

The Innovator's Dilemma

Here's an illustration how the Innovator's Dilemma typically plays out:

1. As a new technology / solution reaches sufficient feature scope and maturity, it crosses the threshold to becoming a minimally viable product (MVP).
2. Subsequently, the typical well-known technology s-curve unfolds, which entails rapid product improvements until the product can become the incumbent through achieving market leadership.
3. As the incumbent matures, its complexity increases and its #technicaldebt accumulates, so its feature velocity deteriorates, and it increasingly struggles to keep up with the market. A watershed example is the ongoing transition from shrink-wrapped (scale-up) products to (scale-out) software services.
4. Meeting new market demands requires new product architectures that entail considerable investment. So while incumbents struggle to keep up with the market, innovators struggle to catch up to MVP requirements. This time window defines the Innovator's Dilemma - with big disruption potential.
5. Eventually, the innovators achieve market leadership through architecture modernization that gradually replaces the incumbents.
6. This virtuous circle repeats with every technology innovation cycle.

Now let's examine how this applies to SaaS software development.

Software-as-a-Service (SaaS)

Meeting the requirements of a SaaS is typically only possible with scale-out ("distributed") software architectures. Distributed systems are fundamentally different from traditional systems as they essentially have operations built in. This allows delivering them "as a service."

However, their nature significantly increases system complexity and R&D investments vs traditional scale-up designs. So if a solution doesn't require service-like properties such as continuous availability, massive scalability, geo dispersion or rolling upgrades, it can (and should) be implemented using easier traditional scale-up system design.

Unfortunately, the considerable complexity of distributed systems expands the Innovator's Dilemma into something akin to a SaaS Innovator's Valley of Tears. The effect can be visualized as follows:

Effectively, the SaaS innovator cannot meet evolving market requirements and replace the incumbent in time, or even worse, it may never quite catch up with an ever moving MVP goalpost. This is the root cause for the significantly increased failure risk of cloud migration projects.

For instance, #Kubernetes is a popular and powerful operating platform for distributed applications. However, it isn't a great development environment: Creating Kubernetes operators requires a surprising amount of solid distributed systems expertise, which frequently results in brittle software services with a prolonged time to value.

How to Accelerate SaaS Projects

To compress the SaaS Innovator's Valley of Tears back into something more tenable, VMware applied some lessons we learned from decades of pioneering large-scale distributed systems, and complemented Kubernetes with a development framework that addresses many of its key weaknesses, such as:

• gRPCs: Remote Procedure Calls are a great concept that turns into a bad programming reality, as they can fail in distributed systems, which requires commensurate complex failure handling (on exception paths with typically low test coverage). Our agent programming model requires only local reads and writes, while delegating distributed state management to a resilient cluster state DB and runtime, which allws a much simpler and resilient local programming model.
• ClusterDB: We replaced etcd with ClusterDB, a high performance resilient distributed cluster state DB with an integrated event fabric. This allows a simple Lambda-style ("serverless") programming model, where agents are automatically alerted to state changes. ClusterDB exponentially increases versatility: It has a tiny memory footprint (so it can be embedded everywhere), high performance (so it can accommodate the most demanding workloads), and is massively scalable, from a single node (via an external quorum service) to distributed multi-clouds (via seamless federation).
• Desired state: Our control model is based on desired state. Agents continuously reconcile desired with actual state through local variables that automatically notify their subscribers on writes. Desired state is invariant and eventually consistent by nature, which makes it innately stretchable. This allows simple, portable, scalable and composable declarative infrastructure-as-code (IaC) programmability.
• Code generator: Our code generator automatically generates the distributed runtime scaffolding from SaaS service specs. This includes the ClusterDB schema, role-based access rights, agent stubs with type-safe APIs, automatic runtime type checking (RTTI), state marshalling, and the entire pub/sub event connectivity fabric. The code generator also generates Day-2 operations, including the logic for clustering, membership, replication and lifecycle management. So programmers can focus on just adding their local business logic into agents.
• Failure model: For benign failure models, the ultimate failure behavior is to "simply" crash. So agents just need to know how to restart (preferably fast to minimize MTTR), and they need some degree of version tolerance. Our runtime handles everything else, from managing failure tolerance to rolling platform and independent component lifecycle management. This really increases simplicity, failure resilience and programmer productivity.

These are some of the more prominent attributes that allow us re-platforming shrink-wrap products into SaaS services in a fraction of the time that would typically be required.

To address these issues, we created a game-changing scale-out development and operations framework (with seamless Kubernetes integration) to unlock the upside of distributed systems, such as much better scalability, resilience, continuous availability, rolling upgrades, etc., while eliminating most of their typical challenges and maintaining a traditional time to market envelope:

We couldn't have done it without the help of many talented folks from Datera , 思科 , 微软 , 英伟达 , etc. Let me name just a few of them here: Claudio Fleiner , Raghu Krishnamurthy Guillermo J. (Bill) Rozas , Shailesh Mittal and Michael V Dvorkin .