· Development · 12 min read
BYOC is the new open-core
Not only are many of today’s infrastructure companies built on open-core, but they have shepherded in a new business model that has powered a boom of businesses building new services and disrupting existing incumbents in just about every SaaS, Infra, and Data vertical.
Over the past decade, open-core businesses have exploded in popularity — this model was a competitive advantage that helped create massive enterprise models. Today — BYOC (bring your own cloud) enables a similar shift in the software ecosystem.
Not only are many of today’s infrastructure companies built on open-core, but they have shepherded in a new business model that has powered a boom of businesses building new services and disrupting existing incumbents in just about every SaaS, Infra, and Data vertical.
Companies like Datastax, Confluent, and GitLab were early adopters of open-core, evangelizing the business model for many companies that have come after.
A similar shift is happening today — companies like RedPanda, DataBricks, and others are creating a massive competitive advantage by using BYOC (bring your own cloud) deployment models and building large enterprise businesses.
Let’s break down BYOC and show how it is as fundamental of a shift as open-core.
What is BYOC?
Bringing your own cloud is a new way to run software that creates a fully-managed “SaaS” experience, with an application running directly in the end customer’s cloud account.
The customer grants access to a cloud account that they own to a vendor, and the vendor is responsible for deploying, maintaining, and updating the software application. The customer benefits from owning the application’s infrastructure, ensuring data sovereignty and isolation, which helps reduce the security perimeter and often reduces customer outages.
As a vendor, while this business model requires a significant investment upfront — once adopted, running software in the customer’s account allows the vendor to not only sell to more sensitive industries but change the cost dynamic of running a SaaS. Instead of investing resources in operating a multi-tenant cloud-based SaaS in many regions and countries + scaling for the aggregate of every user — the vendor can focus on their product experience.
When done right, the BYOC experience is cheaper for both sides and enables more robust applications that more sensitive customers can use.
Who is BYOC for?
BYOC as a deployment strategy is effective for any company that is selling into the enterprise, leverages customer data, is AI-driven, or is a critical infrastructure product. Suppose a product is essential to a business using it, and downtime, breaches, or security incidents can affect the end customer. In that case, BYOC is not only a competitive advantage but is often required. Suppose a product leverages internal data or benefits from working with as much customer data as possible to provide more value. In that case, this deployment strategy is also a competitive advantage and again, is often required.
BYOC is not just for private source companies but it’s as beneficial to open-core companies. Many challenges of monetizing open-core businesses can be solved by offering BYOC — and further, BYOC can help open-core companies better understand their customers and product usage.
While BYOC is emerging for more SaaS providers, at the same time, more vertical clouds are becoming popular — creating more targets for these deployments. These emerging vertical clouds, along with the incumbent hyperscalers are creating a forcing function where more end-customers want to use software that can leverage them — from cloud data warehouses to cloud language models and more.
The Business Case
Open-core businesses have source code available for some parts of their product and are often self-hostable. When selling into new verticals, sensitive and enterprise customers can not only self-host the product during the trial but can evaluate the source during the deal.
Some open-core businesses sell into enterprises by selling support contracts against a self-hosted installation of their product, while others use the source-available premise to help earn customers’ trust using a hosted SaaS.
Regardless of the deployment strategy, open-core has enabled many companies to build massive enterprise businesses.
The most common sales objection
“Can I run this in my own cloud?” is arguably the most common objection for early companies selling into the enterprise. With modern trends around security, AI and data sovereignty, the customer cloud objection is moving down into the mid and small market. Like open-core leverages self-hosting + source available code, BYOC can leverage where software is deployed.
Forcing customers to hand over access to their data to a third party or sending data outside their premises is often a non-starter — especially in sensitive verticals. Often — this data is inaccessible outside the customer’s VPC, requiring lengthy integrations like connecting a VPN, setting up network links, or safelisting IP addresses.
A BYOC model broadly side-steps this objection and the technical/security challenges of sharing access data. Being able to directly deploy software into the customer’s cloud account from the earliest phases of a deal means shifting the conversation from earning the customer’s trust to sharing data and providing value immediately.
Even further, doing POCs in the customer’s cloud account can often leverage more valuable and actionable data immediately — this enables the vendor to show more product value earlier. When a BYOC model is entirely self-service, the end customer does not require shifting IT or engineering resources to set up the POC as well.
Cost benefits for vendors and customers
Building and scaling a multi-tenant cloud offering is expensive and relies on massive economies of scale to create a cost-effective customer experience. Historically, this led to a cheaper experience for the customer.
However, in today’s enterprise, this has broadly shifted. Vendors are relying on more “serverless” experiences from the major cloud providers — not just running software on virtual machines. Serverless products usually cost more than directly leasing and using the underlying compute. This cost is passed onto the customer and means dedicating more resources to managing cloud costs.
When software is run in the customer’s cloud account, the cost is generally nominal and becomes cheaper for both sides. The customer only pays for the baseline (the minimal amount of VMs + infra needed to run the application) + their own usage on top.
Even further, since many applications are leveraging serverless products from public cloud providers, the cost of running an application for a single tenant is going down, while running a multi-tenant product is going up! Some BYOC products can be run for just a few dollars a month for the customer.
Open up new verticals + regions.
Data sovereignty laws and latency requirements force SaaS companies selling globally to invest significant resources into running their product in many different regions or providers.
This is a growing concern for growth-stage companies as it requires significant resources to run applications on many different premises. Infrastructure teams essentially invest substantial resources to operate “many” different hosted experiences. Managing these environments comes with two enormous challenges:
- It is harder to achieve economies of scale in all environments, increasing customer costs.
- It is harder to ensure a great product experience — with different regions and clouds in the mix, extensive investments in deployment strategy + operations are required.
BYOC broadly side-steps this challenge by allowing customers to pick the region where they want to run the application. As long as the public cloud provider is localized, they can run their application close to their company location or compute presence. This takes a show-stopping objection many companies can face when evaluating software, and makes it a competitive advantage, allowing them to use more products.
The Product Case
Open-core products often “punt” on building a SaaS offering until later in a product’s lifecycle. This allows companies to focus on the core product offering, iterate faster, and test their product with enterprise customers earlier. Furthermore, open-core communities can leverage open-source contributions to help them improve their product with fewer resources.
Similarly, BYOC further allows teams to punt on the challenges of building and scaling a managed SaaS offering, enabling them to focus on their core offering.
Removing the scale challenge
Building and scaling a multi-tenant product means creating one or more environments that can scale to support all of your users. Each step function in scale means building out infrastructure that is not only robust but can support more and more customers.
As companies scale, large infra and SRE teams are required to ensure service quality — these teams often end up investing significant resources into:
- system recovery, failover, and route around
- monitoring and observability
- re-architecting around scale bottlenecks
Since a single bad deployment, provider outage, or downtime can affect every customer, these teams are built to mitigate risk. As systems scale to meet the needs of more users, they also grow in complexity, which has a cascading effect on the ability to deliver software quickly and effectively, ultimately slowing down and inhibiting iteration speed.
BYOC software represents a paradigm shift from this investment that companies make in their multi-tenant product. While it is never a case of either/or (at least today), creating a BYOC offering is a compelling way to mitigate risk and side step solving many of these scale challenges in the future.
When applications are delivered directly into the customer’s cloud account, they only have to scale to the size of the largest customers, this means building for many orders of magnitude less usage for many products while also giving companies the ability to isolate their most prominent customers who would be the most affected by significant outages.
Furthermore — running software in each customer’s cloud account enables vendors to reduce the risk of large-scale breaches, privacy challenges, and outages by having customers spread across their own environments.
Integrations and access
Integrating with data and internal systems and leveraging a company’s existing network can differentiate products and increase their perceived value. Hosted products that live in the vendor’s cloud account require teams to set up access directly — by either shipping data to a third party, setting up custom integrations, or safelisting IPs for access.
Sharing access with or moving data to vendor applications limits what the application can leverage, ultimately creating friction for users and more. Beyond the product limitations, sharing data makes it harder to understand data lineage, usage, and accuracy — forcing customers to limit what data they share with the products they leverage.
Since BYOC applications run in the customer’s cloud account, they can directly and securely access local systems and integrations — this is both more secure for the customer and allows the vendor to build more powerful product experiences that were not possible before and leverage existing systems.
BYOC opens up a new realm of applications, applications that can:
- talk to systems on the customer’s internal network
- directly integrate with the customer’s VPN or auth provider
- work with data that is in the customer’s data lake, warehouse, or transactional database
Customer data isolation and access control
One of the biggest challenges with managing a hosted SaaS product is ensuring customer data access control and isolation. In a multi-tenant system that stores data for many different customers, vendors are forced to invest significant resources in both their internal application security + isolation and managing internal access to customer data.
As a SaaS product grows and starts selling into the enterprise, requests to store customer data in different regions or separate from other customers require significant investments in storing and managing data. Further, guardrails around how customer data is accessed and audited become requirements and force companies into building custom internal tools and other ways of controlling access.
Increasingly, more and more companies are building isolated data and control planes for their products — by decoupling where data is stored from the user interfaces and application surface, vendors can mitigate some of these risks and even run part or all of the application in a customer’s cloud account.
BYOC for both the data plane and, increasingly, for entire applications, helps to side-step the risks of managing customer data. By having customer data live in the customer’s cloud account, the vendor no longer has to control access to customer data but can also ensure isolation between all customers — this is not only a more secure model for the customer but aligns incentives by enabling products to leverage more customer data to provide more value.
BYOC is hard (today)
We have discussed the business and product advantages of BYOC, but what does it take to build a model like this? Well, it historically is not easy…
Creating a BYOC product experience requires automating your entire application to the point where a customer only has to provide access to their cloud account to get a fully working version of your product (or data plane).
As an industry, we have standards and automation tools that are rooted in building large-scale multi-tenant products. Building a BYOC product that is self-service requires not only investments in these tools and best practices but also investing in long-tail automation to ensure that not only is every step of the product automated from infrastructure to application to data layer — but that it is provisioned in the correct order, in any account environment.
Furthermore — building BYOC product experiences requires investing in operational tooling to enable teams to monitor, observe, and debug products. Modern observability and monitoring tooling are often limited in these environments because they were designed for multi-tenant products — and using them to manage hundreds, thousands, or millions of different customer environments is not possible or prohibitively expensive.
While it requires a significant amount of engineering expertise and resources to build an entirely self-service BYOC product today — as an industry, we are moving towards a world where BYOC is not only inevitable but a requirement for many companies. We believe that infrastructure for BYOC should not only exist — but should enable every company to create a BYOC offering for their product today.
