· BYOC · 9 min read
BYOC is not as simple as just running your app in a customer’s cloud account. We want to share some learnings on different deployment patterns that are emerging for BYOC.
Since many of these BYOC deployment patterns have emerged only in the last few years, and new patterns are arising, we thought it would be helpful to take a few minutes to share what we’ve learned in the market, working with the companies putting these into production.
For the past 15+ years, most of the software and infrastructure consumed between businesses has been hosted — vendors offer a fully managed experience where you simply hit an API, UI, or other entry points.
Along the way, many companies realized the challenges of offering and selling a hosted product into the enterprise. These challenges are different for different products, but they generally fit into a few buckets:
These challenges are just the beginning. New regulations, breaches, and complexity in software have exacerbated these problems — many companies and their users have started reconsidering whether the hosted delivery model is suitable for all customers.
In many verticals, OSS and self-hosted software have become common ways to solve many of these problems, especially in the enterprise. Companies can offer their users a self-hostable application version to deploy inside their infrastructure and manage with their tools. While it solves many of the problems above, the delivery model as a whole has some severe tradeoffs:
Despite these tradeoffs, self-hosted has become a popular deployment model, ultimately leading to BYOC.
BYOC is a deployment model where software is hosted directly in the customer’s public cloud account — it balances the trust, ownership, and sovereignty of self-hosted with the fully managed experience of a hosted application.
Despite being a challenging delivery model to implement (we’re working on), BYOC has emerged as the standard way to deploy AI, data, and infrastructure products. It offers a more secure, cheaper, and tightly integrated delivery experience for vendors and customers.
As standardizations have emerged for server-less infrastructure and application tooling (built on public clouds), BYOC is now possible, albeit with a significant investment to offer. As tooling continues to improve to support these types of deployments and the complexity of hosted software in the enterprise, increase in public cloud spending, and new privacy/security regulations arise, BYOC will become ever more required.
However, the devil is in the details. Creating a BYOC offering can be fraught with complexity, options, and customer requirements. In many cases, it is not as simple as just “deploying your app in a customer’s account” and considers reckoning about shared responsibility, customer infrastructure requirements, and more.
Let’s discuss each of today’s BYOC deployment models.
Fully managed deployments involve running your entire application stack in a customer’s cloud account in an entirely new environment you manage. This means packaging your infrastructure, backend, and frontend, and deploying it into a cloud account that the customer grants access to.
While fully managed deployments offer the most security, reliability, and peace of mind for the user, as the entire application is in their account — they tend to be the most complex. The long tail automations to expose both the frontend/backend in the customer’s account often require reworking parts of the application (usually frontend and authorization/authentication).
Since most modern frontends use full-stack frameworks like Next.js hosted on Vercel or Netlify — they often require refactoring and reworking parts to run in a container. This means the application can be deployed inside the fully managed install in the user’s account. Still, it also means maintaining these changes while evolving a hosted BYOC application. In the simplest case, the user can provide a Netlify or Vercel account for the front end to be deployed into.
Authentication and authorization often require integrating with the customer’s VPN, SSO, or OIDC tool of choice and commonly require refactoring applications originally designed as hosted products to have flexible AuthZ/AuthN stacks.
Most often, fully managed applications are deployed into a dedicated sub-account for the product, granting the vendor more permissions to manage the application while keeping it isolated from other critical or sensitive infrastructure.
Like with self-hosted, where many newer products are architected intentionally to make it easier to self-host, some new products are being architected with BYOC in mind.
The control-plane / data-plane architecture is an architecture where customer data for each tenant is managed using the single-tenant infrastructure. Since AI, data, and infrastructure applications require storing, reading, and writing large amounts of customer data, this architecture has become extremely popular as it reduces the risks, costs, and overhead of managing customer data.
Historically, this architecture has been hosted, and companies like SnowFlake have standardized the separation of the UX, computing, and data for their products. Recently, with the rise of BYOC deployments, many vendors see this as a stepping stone for running all or part of their applications in a customer’s cloud account.
This architecture requires building logic to query or interact with different data stores and data access layers based on what tenant is being used. The data plane often consists of a datastore such as a transactional acid, SQL database, NoSQL database, or modern analytics database.
While deploying a data plane in the customer’s account often requires fewer moving pieces than deploying a full-stack account, it forces the user to operate critical data stores in the customer account and manage access between the data plane and their hosted control plane.
While deploying the data plane can leverage cloud-provider managed datastores, operating them and providing visibility into the status of the data plane often requires implementing remote observability in the account — and in some cases, an agent or runner that can be deployed with the simple goal of monitoring.
Connecting the control plane with user data planes often requires requesting new firewall rules to allow ingress, integrating with a hub and spoke network, or meeting the requirements of network topologies in the user’s account. Furthermore, VPC peering is usually a non-issue due to network overlaps amongst customers and the sheer resource limits and cost of managing many connections.
While some products may attempt to leverage VPN or mesh-network-type products to simplify some aspects of the connectivity requirements, these are often the hardest to get approved and require significant assurances to customers. Network ACLs, audits, and other assurances may be required to ensure that the customer data in the data plane is not stored or cached in the control plane layer.
Runner and agent deployments are an even simpler version of the data-plane architecture, broadly designed to be lighter weight, require less infrastructure, and be easier to work with complex network issues in the customer’s cloud account.
This architecture involves creating a part of the application that can be deployed per tenant, and “phone” home by talking to a hosted control plane. The agent does not require any ingress, generally works as a single process or container, and is responsible for collecting data and executing jobs as directed by the control plane.
This architecture is typical for infrastructure products such as CI (where customers demand isolation of builds and integration with internal systems) and data collection/management products where accessing on-prem or data in internal systems or warehouses can be complicated otherwise.
Runner/agent deployments are often the simplest to pull off — and can be highly effective solutions for some architectures. Still, they frequently struggle with the limitations of their architecture and, again, customer requirements around data access and control. Ultimately, these runners grow in complexity as more and more processing is shifted to them to prevent having to send additional data to a hosted control plane.
Depending upon the complexity of the end customer and the application, some deployment models might require shared infrastructure. This model is where the customer provides some pre-configured network or computing infrastructure to meet their requirements or to allow the product to run closer to existing computing or infrastructure.
Shared responsibility models where a customer provides an existing VPC network often allow a product to be deployed and access different network parts immediately. In a hub and spoke architecture, this might be a new spoke network provisioned for the product in a sub-account with pre-configured ingress/egress routing to work with a corporate firewall. These can be some of the hardest deployments for vendors because they often require coordination between IT/network-admin teams and the stakeholders buying a product. The network requirements around these deployments often require stringent auditing and can create highly hard-to-debug network problems.
In some cases, customers might have requirements around managing computing (particularly Kubernetes), where the BYOC application has to run on pre-configured, hardened, and approved VMs. For shared Kubernetes clusters, RBAC, controllers, and different version matrices of dependencies can make each customer environment completely bespoke. This makes it harder for the vendor to ensure the quality of service, and debugging can often require working with multiple teams, asking for logs, or passing scripts to be run.
While shared responsibility deployments can unlock some of the largest customers, they can often be the hardest to execute.
BYOC is becoming an emerging standard in every B2B SaaS category — from AI to infra to productivity tools. As more and more software touching data is moved to BYOC deployment models, more tools that interact with them will also be forced to offer BYOC deployments.
For companies starting out and considering BYOC — the options are endless, and the customer asking, “Can this run in my cloud account?” is not only opaque and vague but can be fraught with many different requirements throughout the procurement process.
Offering BYOC is a journey; many customers will have different requirements, and various deployment models will best fit other products. Most companies who decide to provide a BYOC offering will find themselves constantly tasked with new offering requirements — from supporting different models to meeting different customer requirements to requiring support for other cloud providers. As their application complexity and footprint grow, so does the challenge of deploying into each of these various models and ensuring quality of service.
If you have a BYOC offering today or are considering a future offering — we’d love to get in touch! Nuon provides the composable infrastructure to allow you to create the best BYOC offering for your business while meeting customer needs.
After countless conversations with companies who have built or evaluated BYOC (bring your own cloud) offerings, as well as helping customers create new offerings — we have learned A LOT about what it takes to create a BYOC offering.
The current deployment dynamics of SaaS have the potential to leave your sales team with their hands tied. Deployments as Revenue (DaR) is a new business methodology that shifts the perception of software deployment from a routine internal operation to a strategic function aimed at driving profitable growth.
Over the past two years, we’ve been sharing our mission to build a platform that would enable anyone to create a bring your own cloud (BYOC) version of their app overnight.
Create a consolidated deployment and billing experience with SaaS Listings, Private Offers and BYOC.