This post is by Tomasz Tunguz from Tomasz Tunguz
Click here to view on the original site: Original Post
When we announced our investment in and partnership with Mattermost about a year ago, I wrote about a new architecture for SaaS. I’m starting to see that archiecture more and more, but with a twist. The idea behind the new architecture is split a SaaS app into code and the data. The SaaS company writes, updates, and maintains the code. And the customer manages the data. Typically, the data resides in the customer’s cloud account. This cloud account has many names but no real moniker yet. Some call it a VPC for virtual private cloud. Others call it cloud prem, a contraction of cloud and on-prem(ises). On premisis or on prem means deploying software on datacenters the customer owns. Today, many of those data centers are in the cloud, hence cloud prem. But the drivers are real. The first is cost. Cloud is more expensive for larger enterprises. Many
considering moving back to their own infrastructure and using the cloud to manage bursts. The second is control. If you’ve used the AWS IAM (identity access management) console, you realize how complex access control has become. This means securing cloud assets that may be open to the public or accessible via API means battling a Medusa. The third is compliance. More regulation seems a forgone conclusion in technology. Better to prepare now and be structured to manage legal process later by controlling data centrally. Assume this happens at some scale in the enterprise. Let’s fast forward a bit. Imagine an enterprise now has several, maybe a dozen applications deployed this way. They won’t have a database for each application. They’ll have one or two. And each piece of software will be pointed to those databases. That’s the twist. In the classic SaaS model, 12 SaaS products means 12 databases; each database controlled by the vendor. In the cloud prem world, the databases are controlled by the customer and accessed by the SaaS product. In the simplest case, the customer has one database. The 12 SaaS products query the database for the data they want to. Each SaaS product is a different cut, filter, or view of that central single data store. It’s a change from point-to-point data to hub-and-spoke data. This may seem like a pretty simple advance but it’s a fundamental rearchitecture that is going to change the way applications work. Today, an enterprise might have hundreds or thousands of applications. Each is a hermit, operating its own database in solitude. The very biggest create APIs for pushing and pulling data into other systems (eg, Salesforce App Exchange). That provides a huge amount of leverage to Salesforce, because they control the data. But if the customer controls the data, then power dynamics in the relationship change dramatically. The customer controls the data, and can reshape it, move it, share it with a competing vendor. And the customer can create a marketplace of applications to suit their own needs. And the integration between applications no longer has to be achieved at the application layer with Salesforce to Marketo APIs. Instead, it’s done at the database. Salesforce expects marketing data in a particular place in the database and reads it directly. Novel database querying engines like Dremio, Presto, GraphQL enable this vision. There are benefits to the SaaS vendors too in the form of higher gross margins. They won’t be paying for storage costs. The customer pays the cloud vendor directly. The trade is a much more complex deployment model. I’m painting a simple picture here to explain this vision. Reality will be far more complex - it always is. Technology integration will be harder. Enterprises will move pieces of their business over. But we’ll see this new architecture deployed in the mid-market as an innovation, just the way modern startups centralize on a single datawarehouse, like a Snowflake, while the bigger companies have several data stores. But this is the way enterprise software will be delivered in the future. Most of the market today believes that cloud-prem is about packaging the application to run on a Kubernetes cluster in a VPC, but it’s a much deeper, more fundamental evolution than that.