We are changing where software runs

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. A lot of the feedback we heard was: “that is really hard” and “you are crazy for taking this on”.

We found a problem that would not only help many companies unlock significant revenue, but that it would take some companies a year or more to build for themselves.

Over the past few months, we have quietly started powering a handful of early customers who are offering BYOC using our platform — today I am excited to share a bit more about what we are doing with the world!

First, a little bit about how we got here…

Some personal background

In 2013, 4G was just coming out — mobile phones were ubiquitous and photo/video was wide spread — live video streaming felt inevitable — a perfect combination of market pull, technology capabilities and opportunity colliding.

I dropped out of USC as a senior, raised funding and launched my first company. We failed, but it did turn out that live streaming would be inevitable (albeit a bit early at the time). Along the way, while building our product I discovered my true passion was not in social, but actually in the cloud infrastructure that was powering more and more software (and evolving quickly).

I spent the following nine years working on platform teams, building platform products and tools to meet every different standardization that was happening in cloud infrastructure — from containers, to IAC, to observability, to data products on top. I kept finding a niche with each of these by building great workflows and developer experiences to let folks adopt different trends more easily.

In 2020 I started a company called PowerTools which was a turn-key PaaS in your own cloud — and unbeknownst at the time, this would lead me directly to finding myself on the frontlines of another inevitable **shift in software.

Discovering BYOC

Almost two years ago now, I had a potential customer of PowerTools ask me if they could use our PaaS to run their app in their customer’s cloud account. They were a seed-stage startup selling their product to a larger health company.

A light bulb went off almost immediately — why was a company of this stage thinking about “on-prem?”. Self-hosted was growing in popularity, but at the time broadly felt like way too much work for most companies. As they went on to describe wanting to offer a fully managed offering in their customer’s cloud, it all started to click and immediately became clear that this was now possible.

As an industry, we were getting to a place where we could offer fully managed SaaS experiences directly in a customer’s cloud account — sidestepping many compliance, security, and data sovereignty challenges, all while opening up new possibilities. A lot of standardization had come together:

• IAC (infrastructure as code) was now ubiquitous
• AWS had standardized IAM for multi-account setups
• Kubernetes and other orchestration platforms were now wide spread and being used to deliver some applications

I talked to about 20 or 30 companies over the next week or two about this concept of a fully managed experience in the customer’s cloud account. I kept hearing that many of these companies had thought about (or been asked) to provide something like this — it not only solved many security and privacy concerns, but often was cheaper and lower latency for many products. This is something that customers not only wanted but would pay a lot more for.

It seems like many people wanted the isolation and ownership of self-hosted, but with the experience of a fully-hosted product.

As I dug into the problem — a few more insights became apparent:

• Later-stage companies that had invested into building customer cloud (aka BYOC, managed SaaS, on-prem or whatever else they might call it) were seeing that most of their revenue was coming from those channels
• running software in the customer’s cloud account was cheaper for both the vendor and the customer when executed properly
• running software in the customer’s cloud account opened up new capabilities by allowing access to more and more of a company’s software stack.

The emphasis of these initial conversations was solely on business outcomes and the desires of end customers. However, a recurring theme emerged: companies found this incredibly challenging and had deprioritized it due to its perceived difficulty.

As my conversations around this issue continued, it became increasingly clear: this wasn’t just a difficult problem to crack. If solved, it could create an immediate new revenue stream for nearly every software vendor out there. With new security regulations, more inter-connected applications and AI looming, customer cloud felt more inevitable than live video felt in 2013.

I pivoted, and then we put together a team to build Nuon.

Building Nuon

Paul Graham has a great post on Schlep Blindness, and the idea that some of the biggest problems facing our industry are actually right in front of us. I could not help but feel the same way about where software runs when digging in — we have standardized most parts of the application delivery and management experience, but rooted in multi-tenancy, we were creating more and more problems for ourselves.

Running software in your own account is a pain in the ass, let alone your customer’s account, where you lack permissions, control, and access, is an entirely different beast. Consequently, many companies have kicked this can down the road, leaving the problem unsolved. The rhetoric of “we will solve this when we can’t hold off any longer” rang true, even though most companies have customers asking for this.

These same companies kicking this down the road turned out to invest significantly more time and resources into trying to convince their customers to use their multi-tenant version — often losing these deals, or making software more expensive for both sides.

When we started building Nuon, we asked ourselves, “Can we lift and shift any company’s current software/architecture and give them a modern, seamless developer experience to run their code in their customer’s account?” Setting up this platform had to be seamless, and after the initial setup, it should “just work” and evolve along with the rest of their app—no endless developer tax on every new update.

At first, we were not sure if this was even possible (and to be honest, a lot of people told me it wasn’t) — building a product experience to achieve this goal would require:

• Handling an exponential level of complexity by accommodating every cloud and tech stack available.
• Architecting the platform to be both programmable and easily integrated with other systems.
• Implementing long-tail automation to manage every facet of software operation, beyond merely container deployment and infrastructure management.
• Developing the capability to manage infrastructure across foreign accounts while also catering to the stringent requirements of larger enterprises.

We started testing our first version in the market about 6 months in, and immediately took a step back and completely rethought our approach — it took us another year, but earlier this year we finally started onboarding our first vendors.

Along the way, we ended up solving quite a few interesting challenges that included:

• building a completely pluggable infra orchestration tool that could integrate with existing devops automation tools but also work on every cloud
• build an isolated data plane that could orchestrate thousands of different data accounts for each of our vendors — without making us a SPOF
• figure out how to package both application and infrastructure together
• make the long tail application + infrastructure provisioning process work at scale (turns out, this was the hardest problem of them all)

We have quite a few interesting topics to blog about in the future, but on the other side of this — we have built a platform that enables any company to create a new business line overnight.

With Nuon, you can integrate your existing application and infrastructure to create a fully-managed version of your app that runs in your customer’s cloud account. Some vendors use us to make self-hosted software easier, some vendors use us to make a self-service version of their app in the end-customer’s account and some use us to just unlock a few enterprise customers.

Unlocking BYOC For Everyone

One of our users told us early on that they were “shocked” that our program was programmable — that was a first principle of what we were building from day 1. Our team took that as a further sign of the schlep blindness around customer cloud.

Nuon is both programmable and pluggable, and designed to be completely white label. Once you have setup your application, you can program against our APIs, wire us up into your product flow or manually manage installs for your first few BYOC customers.

From there — you can push updates to Nuon as you change your infrastructure and application, just like you would with any CD tool. Behind the scenes Nuon will automatically orchestrate your installs and keep everything up to date.

With Nuon — you can create a new business line using your existing app without paying a developer tax whenever you want to make changes.

Even the most complex apps can be modeled with Nuon—some of our customers have a single Helm Chart or Docker image, while others combine many different Terraform modules and dozens of Helm charts into their application.

Nuon “glues” these pieces together and automates the process of installing, configuring, and updating each part of the product.

We have a terraform provider that you can use to set up your app — and all you have to do is tell us where to “find” your different infrastructure and application code. From there, we give you powerful primitives to connect things — you can do things like provision an S3 bucket and RDS instance in terraform and then use that infrastructure from within a Helm chart using shared configs.

resource "nuon_helm_chart_component" "app" {
  name   = "app-helm"
  app_id = nuon_app.main.id

  chart_name = "my-helm-chart"
  connected_repo = {
    directory = "services/e2e/chart"
    repo      = data.nuon_connected_repo.mono.name
    branch    = data.nuon_connected_repo.mono.default_branch
  }
}

resource "nuon_terraform_module_component" "app" {
  name   = "app-terraform"
  app_id = nuon_app.main.id
  terraform_version = "1.5.7"

  connected_repo = {
    directory = "terraform"
    repo      = "nuonco/mono"
    branch    = "main"
  }
}

You should be able to set up your Nuon app in literally 10 or 15 minutes if you have used Terraform before — if you have not, we’re happy to help set you up!

Creating An Installer Experience

Our customers have told us that it is mind-blowing how quick it is to get setup — if you already have Terraform and Helm you can literally turn Nuon on in minutes. However, we think the real value of our platform is in building a great customer experience for customer-cloud apps and enabling this for all of your customers.

Companies like DataBricks, MongoDB and others have customer-cloud wired up into their signup flow so any customer can deploy in their own cloud account in the first 5 minutes of trying their product. We designed Nuon from day 1 to support this type of experience — tying customer cloud right into the signup flow:

type SignupRequest struct {
	Name	   string `json:"name"`
	IAMRoleARN string `json:"iam_role_arn"`
	Region	   string `json:"region"`
}

func (s *service) Signup(ctx *gin.Context) {
	var req SignupRequest
	if err := ctx.BindJSON(&req); err != nil {
		ctx.Error(fmt.Errorf("unable to parse request: %w", err))
		return
	}

	nuonAPI, err := nuon.New(s.v,
		nuon.WithAuthToken("your-api-token"),
		nuon.WithOrgID("your-org-id"),
	)
	if err != nil {
		ctx.Error(fmt.Errorf("internal api error"))
		return
	}

	install, err := nuonAPI.CreateInstall(ctx, "your-app-id", &models.ServiceCreateInstallRequest{
		AwsAccount: &models.ServiceCreateInstallRequestAwsAccount{
			IamRoleArn: &req.IAMRoleARN,
			Region:     req.Region,
		},
	})
	if err != nil {
		ctx.Error(fmt.Errorf("internal api error"))
		return
	}

	ctx.JSON(http.StatusCreated, install)
}

Not every company will be ready to build a fully self-service customer-cloud offering on day 1. Just how Stripe allows companies to start with payment links, and then migrate to full self-service payment flows, Nuon enables you to start by unlocking a single customer in their own cloud and then evolve towards self service.

If you just have 1 or 2 customer cloud installs, you can manage those installs in Terraform:

resource "nuon_install" "east_1" {
  count  = var.east_1_count
  app_id = nuon_app.main.id

  name         = "jp-morgan"
  region       = "us-east-1"
  iam_role_arn = var.install_role_arn
}

You can also create a custom installer (imagine a stripe check out link, but for customer’s to install your app in their own cloud).

We are still early and we have just begun to scratch the surface of what is possible with this new paradigm of running software in customer cloud accounts. This paradigm shift is going to power new types of software applications, shifts in the revenue and pricing models of both open source and large scale providers and a more secure, reliable and better software experience all around.

We are hard at work onboarding more vendors every day, and planning to launch support for every public and vertical cloud in Q1 next year — we strongly believe that the future of BYOC is not just in your customer’s AWS or GCP account, but is also in your customer’s Vercel, DataBricks, and OpenAI accounts.

Who should sell customer cloud?

If you are reading this and wondering if customer cloud is right for your business — the answer is probably yes.

In short — every single company that sells software used by businesses that handles or processes data in any way, or is considered “critical”, falls into this category.

Funny enough, the only companies we have talked to who should not sell customer cloud, are the companies that are themselves trying to be considered the “cloud” in BYOC. Ironically, some of them, like Snowflake, use some of the isolation techniques in the customer cloud to create an architectural advantage and earn the trust of their largest customers.

Our team has engaged in discussions about BYOC with hundreds of companies at this point. Uncovering the reasons customers want apps in their own accounts and the identities of those customers are considerably more nuanced than initially thought—pun intended.

We’ve learned a few things along the way:

• AI is a forcing function for moving software into the customer’s cloud account for smaller and smaller companies—many of these customers see AI as a massive unlock, but the ambiguity around how data is used (and specifically for training) is a massive risk to organizations of all sizes.
• Data-intensive products have lower costs for both vendors and customers when deployed in the customer’s cloud account—and often, become much easier to manage for both sides.
• Even non-sensitive applications are moving to the customer’s cloud account to interact with more things inside the customer’s network. When your app is portable, it can provide more value by meeting enterprises where they are in their network.
• With the explosion of vertical clouds—vendors can gain a significant competitive and cost advantage by using customer accounts for LLMs, computing, and more. Bring your own Databricks, OpenAI, and more is coming.

An even stronger signal — only a few companies have told us they haven’t heard from customers yet that this is a need. Just a few years ago, SOC-2 went from something that companies will have to support “down the road”, to something that almost every seed stage startup has had to invest in today.

We’ve spoken to hundreds of companies, and only a handful have said they don’t plan on investing in BYOC. They see themselves as the next Snowflake, Vercel or Databricks.

Whether we like it or not, BYOC is cheaper, faster and more secure for both customers and vendors — and like we say at Nuon, inevitable.