Embracing the chaos in customer environments

We make it pretty easy to lift and shift an existing application into a BYOC deployment model. A lot of our value comes from the continuous delivery to customer environments after setup. I wanted to talk a little more about actually operating a fleet of BYOC deployed customers.

One thing I find interesting about BYOC in general, and why it's such a hard problem, is that all those environments look significantly different. Basically, the second you get your thing deployable via BYOC, you start to unearth all the different configurations that customers want to control. (We covered a lot of the up-front version of this in BYOC, The Hard Parts and in what vendors ask us before going BYOC .)

It's an interesting balance. Some customers will just take the full-stack version, and not care about the network etc. But as soon as your app starts to connect to actual different internal things like a customer's database, they will want to control and own some parts of the infrastructure. This is really a spectrum, which we wrote about in designing BYOC permissions to suit your needs .

So, what does that mean for you? You have a different level of ownership for each environment. Multiply that by N customers (with most customers having more than one environment), then suddenly you have what looks like a pretty chaotic and heterogeneous roll-out process.

There are several things that start to be customized and changed by customers first:

• Clouds
• Networks
• Integrations into existing systems (LLMs, databases, etc.)
• Access + Encryption Keys
• Storage (specifically blob storage)

This means that for any complex application, not only are you wrangling different versions of your application, you are wrangling different permutations of your customer's environment. Let's talk about some of the common configurations we see.

Cloud Platforms, Regions and Setups

This is the most obvious one. Inevitably, as you offer BYOC, you will eventually grow to support the three primary cloud platforms and then vertical / niche clouds that you are not operating a SaaS with. Essentially every cloud and every region will require support at scale. (Nuon's platform support covers AWS, Azure and Google Cloud today.)

Then, customers will have different "base accounts", where they apply organizational configurations into a new cloud account — everything from policy limits, to network configuration and more.

Network Configurations

Most customers who ask for BYOC are either extremely security conscious, or want to connect your application into existing systems and infra. Inevitably, that same group of customers are going to have opinions and requirements for your application's network.

The most common configuration model for BYOC deployments is where the application is deployed into a hub and spoke network. There's a central hub where all network traffic is routed to, and each application gets its own isolated network that is connected to the hub. Routes are used to configure traffic through the hub for monitoring, allow/deny controls and integrations to other systems in a customer's network. This is one of the reasons we support bring-your-own-VPC and customizable sandboxes — the base network layer has to bend to the customer, not the other way around.

With the exception of network heavy data platforms, most applications are deployed in isolated networks. However, for products like a message-bus, data-streaming platform etc., it's common to run those (mostly for cost/latency purposes) in a customer's existing network. While this most certainly heightens the security risk and requirements, for specific applications it can make sense. Fred wrote more about how this plays out architecturally in BYOC control plane / data plane architectures .

Integrations Into Existing Systems

After networking, one of the most common configuration changes of a BYOC application is integrating it into a customer's existing internal systems. Some of the most common systems include:

• Internal APIs - your product helps automate or otherwise work with a customer's internal APIs and systems.
• LLMs - your customer has made investments around LLMs of choice and want you to use their existing providers that may be deployed locally in their environment (with guardrails etc.)
• Databases - your product connects to a customer's database

The more things your application can connect to and integrate with, the more powerful it is, but that also means your application has to work alongside those systems inside a customer's environment.

Access + Encryption Keys

Often, your application will have some SaaS dependencies (such as an auth provider, an LLM / inference provider, analytics etc). Customers will prefer to bring their own accounts and connect to those platforms if their environment will rely on a third-party SaaS. Some common dependencies like an auth provider, database provider or other infra product can be connected. For instance, we see many applications that will connect to an end-customer's ClickHouse BYOC/Cloud, Temporal Cloud, PlanetScale, DataDog and Grafana account (those are the most common dependencies and often your customer may have already picked a vendor in the space they expect you to integrate with).

Secondly, if your application does any encryption of data, your customer can demand that they provide or own any keys used for encryption. While you can provision new keys in their account (and should when needed, by default), they might run something such as HashiCorp Vault that they expect you to integrate with. This is exactly what secrets and operation roles exist for — so credentials and least-privilege IAM can differ per install without forking your app.

Storage

If your application is storing data in a database or using blob-storage, these can require compliant configurations for the end-customer environment you are deploying into.

Blob storage is a common one — let's say you are using S3 or another blob storage system. Enterprise customers will often have bucket templates or requirements to enable versioning, key-namespace requirements or encryption. Further, some customers might actually require you to operate in specific regions for storage or not allow you to create the bucket at all, instead opting for a "bring your own storage" setup, where they provide a bucket for your application. (It's worth noting, the classic "accidentally enabled public objects in a bucket" incident is one of the first things a customer will be trying to protect against here.)

Similar requirements can exist for transactional and analytics databases. Customers can demand that you configure your database following their rules and regulations (enable encryption, regions, versions, etc). This is where policies become the difference between "we hope every install is compliant" and "every install is continuously checked."

For analytics databases and warehouses, it's usually a safe bet that some customers will ask you to leverage or send data to their central warehouse, if applicable.

The Amplification Problem

With BYOC deployments, each customer has their own environment (at least one). For core infrastructure products that power a BYOC customer's product, we could see dozens of environments for a single customer (for instance, one of Nuon's customers has a single end-customer with over 20 environments — one powering each of their end-customer's regions).

This means you have a huge amplification problem — as you evolve your application, you have multiple versions of your application + infrastructure (just like SaaS), but now, with BYOC each of your customers could be on a different version, and with different configurations and ownership.

This means every change to your application or infrastructure is amplified to at least N (customers) environments but in practice more like N * 2 (most customers have at least a stage and prod environment of your app). However, each of those environments could be configured completely differently! It's not just different clouds and regions, but different ownership and integration models like mentioned above.

Getting this right is the whole reason the Nuon Runner lives inside the customer's account, and why we've invested in runbooks and actions for day-2 operations across a fleet.

Embrace the chaos

With better tooling, I think all vendors who offer BYOC should embrace this customization. To date, the first thing that most customers and vendors think when building for BYOC is that when they deploy into a customer's environment, they need to limit their architecture, dependencies and commit to splitting their application logically. While those all might be best practices, it's nonsensical to limit what you can build, just because of where you need to deploy it. You should be able to take your application, evolve it, add dependencies and let customers pick and choose what they own and control.

This has been one of the core things we make possible with Nuon — let you define customer inputs to control customer configurations, define toggle-able components (essentially parts of your app that can be turned on / off per install) and then define per-customer overlays via install configs (change your app configuration per customer).

If you want to see what that looks like in practice, the AnswerLayer case study walks through a BYOC-default product running inside regulated enterprises, and Nuon for single-tenant covers the adjacent case where you own the account but still have N environments to manage.