What is Bring Your Own Cloud?

What is Bring Your Own Cloud

BYOC is an emerging deployment model where software is deployed directly onto customer-managed infrastructure (i.e., an AWS, GCP, or Azure account) and managed by the vendor. It’s essentially a hybrid of the SaaS and self-hosted models, balancing a set of tradeoffs that make it ideal for AI, infrastructure, and data workloads.

Nuon believes this model is so straightforward that, with the proper tooling, any business selling software to other companies will use it by default. We predict that within 5 years, this will be as ubiquitous a way of deploying software as Cloud SaaS is today.

SaaS, for B2B

As we’ve written about before, the emergence of the cloud shepherded an entirely new paradigm — hosted SaaS. While it may sound like ancient history (and if, like many engineers, you don't even remember software before the cloud), at one point, software was primarily delivered by passing around artifacts for customers to install, manage, and update on their hardware. Obviously, the cloud changed that, and today, we live in a world where signing up and using a new software service involves visiting a URL and using software that the developers behind it manage.

Along the way, our industry has made it easier and easier to build software for the cloud — it is now easier to capture and leverage user data, build more innovative and deeply integrated applications, and ultimately, AI-integrated products. The hosted model is the best way to deliver software to the masses, allowing users to try or evaluate new products with no strings attached.

However, when it comes to workloads for other businesses, the “no strings attached” nature of hosted SaaS quickly breaks down because evaluating or piloting the simplest products in the workplace means migrating large amounts of data, sensitive or critical workflows, or potentially sharing internal IP. As the B2B SaaS, data, infrastructure, and now AI verticals have grown, they have faced increased scrutiny from users because, by nature, a good B2B SaaS product should be critical in nature (otherwise, it would not be valuable). It’s a cycle — builders are creating more deeply integrated products that solve increasingly complex problems, and buyers are gaining a clearer understanding of these capabilities, leading them to want to buy them now, more than ever. These same buyers are trying to manage risk versus reward with each piece of vendor software they purchase, knowing that the more critical the function it powers, the more data, integrations, and risk it entails.

The re-emergence of self-hosted

BYOC is not a new idea. In fact, BYOC is essentially a hybrid of the hosted and self-hosted models, and the recent surge in popularity of BYOC is a direct result of the resurgence of self-hosted software.

Self-hosted is hard because of the operator experience — simply put, the person who builds the software is always going to be best at operating it. Very few software systems are designed for a good out-of-the-box operator experience, and oftentimes, if they are, it requires building specifically for the operator experience by limiting architectural options.

How does BYOC work

While self-hosted software is similar to shipping your users a CD in the mail to set up your software, BYOC is meeting your users at a shared data center (the customer’s cloud account), letting the vendor in once to set up the software (installation), and granting them occasional access to update your app. Sometimes, your app experiences a catastrophic failure, and you have to let the vendor back in (break-glass) to fix the issue.

In Nuon’s BYOC model, vendors securely operate their application in a customer’s cloud account. From the customer’s point of view, the application should be deployed in their account, but it should have the look and feel of a SaaS. The vendor securely provisions and operates their application in a foreign account, managing ongoing maintenance updates to the application.

In this model, the software operates in 4 distinct modes:

• Provision Mode — Initial setup of the install, while preparing for production. This often has elevated permissions and more oversight by the customer and vendor.
• Maintenance Mode — Day-to-day operations that include updates, security patches, and managing the infrastructure.
• Break Glass Mode — Irregular operations where the application is not working or functioning and requires escalated permissions.
• Deprovision Mode — Permissions to tear down the install and remove it from a customer environment.

In each of these modes, the installation is operated with a minimal amount of permissions, and in the typical case, the vendor should never have direct access to the customer environment.

Software Lifecycles

Let’s start by discussing the various modes of these installations, as they will inform much of the future basis for explaining the BYOC model.

In the BYOC model, the customer is responsible for the underlying infrastructure — often the cloud account and the network (i.e., VPC), along with other “bring your own” parts of the product, such as databases that need to be integrated. The vendor packages their application in a way that allows it to be automatically configured within the customer’s account and connect to their existing infrastructure, network, and dependencies.

Balancing trust and responsibility for managing the install has different requirements for each of the modes.

Provision Mode

During installation, both the user and the software vendor have some ownership. The user grants one-time elevated access to set up the installation, which enables the vendor the ability to provision a new cluster, configure networking, and get the application working. While each system is different, this often requires some combination of both the user and vendor contributing to the initial configuration of the software. Where the customer may provide secrets, the vendor can then use those secrets to set up identity providers, talk to databases, and more.

Compared to the SaaS or self-hosted model, BYOC breaks out of the one-size-fits-all nature of SaaS, allowing a customer to make some changes to the system configuration. Relative to self-hosted, the vendor has some control to help operate when things go wrong, and across customers, a more homogenous architecture can be maintained, making operations at scale easier.

Maintenance Mode

In the best of times, both the user and the vendor want to be on the latest version of an application. Everyone wants new features, security patches, and peace of mind that they are not stuck on an old version of a critical piece of software or infrastructure, right?

In SaaS, this is easy — the vendor updates all users simultaneously, making operations much easier. For users, the tradeoff becomes that they are forced to upgrade to the latest version, regardless of whether they need to update things that integrate.

As the customer base grows, vendors must manage multiple versions of each application, turning even simple migrations or updates into complex, months-long efforts.

With the BYOC model, the user grants maintenance permissions to the vendor, allowing the vendor to push updates and keep the application up to date as new features are shipped. When new migrations are released (such as modifying or changing infrastructure), the customer has some control over when they are applied, but is not responsible for applying them themselves. In some cases, sensitive customers who need to coordinate change management across teams and organizations can opt out of changes by removing maintenance permission.

In the BYOC model, there is a balance between control and updatability by both sides.

Break Glass Mode

Bugs, breaking changes, and infrastructure failures occur, and just as in the previous modes, there are trade-offs between BYOC, self-hosted, and SaaS.

As users, we all know it - when a major service (looking at you, Github…) goes down, it’s time to go home (or at best, share HugOps on Twitter while you cheer on the SRE teams of your favorite vendors). In the SaaS model, the benefit of having every user on the same version becomes a tradeoff when things go wrong — everyone is affected simultaneously.

Self-hosted largely side-steps this issue, because each user gets to self-manage and opt into any updates. If a problem arises in the SaaS version of an application, any users who are self-hosting can simply wait to update until they are ready.

In the BYOC model, each user has their own installation, utilizing their own infrastructure and resources. Since each environment is isolated and not interconnected, a single outage or breach has a significantly smaller blast radius (i.e., affecting only a single user), largely sidestepping the issue of large-scale outages. Savvy users will point out that the BYOC model is not without its downsides — a user can still experience an outage (accidental resource destruction, a cloud outage in their region, scale issues, etc.) — but the benefits far outweigh these for both the user and the vendor. The vendor can limit the blast radius, preventing a large-scale outage (only a single user will be affected at a time), and the customer has some agency to help mitigate issues within their control.

Deprovision Mode

Deprovision mode operates similarly to installation mode, and usually has the most escalated of all permissions. In most situations, the customer is entirely responsible for deprovisioning a BYOC application.

Why BYOC?

BYOC software is inherently complex—it's challenging enough to operate software in your own environment, but it's even harder to run it in a customer’s account where you have no access and limited visibility.

Despite this complexity, modern software architectures and business problems are driving the adoption of the BYOC model. Enterprise requirements, a desire to innovate, and emerging capabilities with AI are shifting the idea of BYOC from a niche to a mainstream approach for all software businesses.

Today’s B2B software and infrastructure providers require:

Innovation velocity — with the fast-moving nature of software today, velocity is paramount to finding product-market fit and scaling. It is table stakes to add new features, support new technologies, and integrate at market pace.

Integration — systems must integrate with user LLMs, networks, internal systems, databases, and more from day one.

Flexibility — selling to different customers often means meeting the needs of data sovereignty regulations, dealing with sensitive workloads or interacting with large existing infrastructure presences and commitments.

When done right, BYOC offers the best of both worlds — users get a SaaS-like experience, with controls over where the application is deployed and when it is updated. Dealing with sovereign data requirements, user LLMs/AI infrastructure, and more becomes much easier because the application goes to the user, instead of everything having to move to the vendor.

As a vendor, when done right, BYOC enables you to build, iterate, and scale a single product offering for your entire customer base, and in some cases, pass on significant infrastructure costs to customers with more spending power (more on that in a follow-up post). The BYOC model allows you to ship like it’s SaaS while maintaining some controls over your application in your customer’s cloud account.

BYOC

BYOC is not a silver bullet. Today, it’s primarily adopted by the most technically sophisticated companies—those that intentionally design for BYOC from the start. Attempting to retrofit an existing SaaS product for BYOC can require a significant investment in automating application management and updates. In the worst cases, it demands extensive redesign, refactoring, and rearchitecting just to make it work.

Offering BYOC

Offering a BYOC model requires overcoming several technical challenges tied to the unique nature of deploying software directly into a customer’s environment.

Each mode comes with it’s own set of requirements:

• Install — Package your app, ensuring that automations and configurations work as expected. Build a self-service portal or user portals.
• Maintenance/Updates — Provides your customers with controls to opt into various features. Figure out how to operate the application when not everything is in your account, where you have root access.
• Break Glass — When things go terribly wrong, ensure that you can mitigate risk.

As a vendor offering BYOC you have to figure out not only how to package your application, but how to support operations in each of these different modes — all without breaking the trust or security model at each point. This requires investing in automating your application (full-stack automation, not just deployments) and operating at each stage of the install. From there, balancing customer integrations, configurations, and environments creates a challenging surface area to test your application in.

The BYOC Inflection Point

When offering BYOC, there is an inflection point that comes after the large upfront cost of productionizing BYOC. Once you have the ability to seamlessly deploy, maintain, and update your application on user infrastructure, you can quickly scale up from there.

The pain of BYOC up front turns into easier operations later on. Instead of needing to manage and scale a hosted SaaS with each new step of company growth, vendors who adopt the BYOC model upfront only need to consider managing scale up to their largest customers. Painful and costly migrations that once required months of coordination to mitigate risk in a large hosted environment can simply be rolled out customer by customer (and depending on the customer, tradeoffs like downtime windows are much more acceptable when planned).

If you’ve made it this far into this post, you can tell we are bullish on the future of BYOC, even though it’s hard today. We believe that with any technological evolution, the early adopters will pave the way for new tooling and infrastructure providers to enable advancement for all. At this point in the BYOC lifecycle, the handful of industry leaders have paved the way and established this model, and we are on the cusp of enabling BYOC for everyone.