This post was originally published on The Data Source, my monthly newsletter covering the top innovation in data infrastructure, engineering and developer-first tooling. Subscribe here!
In this interview series, we dive into how enterprise software companies approach Bring Your Own Cloud (BYOC) deployments. Through conversations with founders and technical leaders at companies of varying scale and maturity - from early-stage startups, ParadeDB and Earthly, to the rapidly scaling Cockroach Labs, to the enterprise-proven Okta - we uncover the technical decisions, market dynamics, and implementation strategies that shape BYOC offerings. Each company brings a unique perspective based not just on their stage, but on their specific technical challenges and customer requirements.
Interview with Philippe Noël, Co-Founder and CEO, ParadeD
ParadeDB, an early-stage startup building a Postgres-based alternative to Elasticsearch, represents how newer companies think about BYOC from day one. Their approach to BYOC deployments shows how companies can and should architect their deployment strategy around existing customer infrastructure requirements.
For ParadeDB, the decision to embrace BYOC became obvious through talking with customers. "Our customers already have a primary Postgres cluster, often on Amazon RDS or Google Cloud SQL. ParadeDB extends Postgres for Elasticsearch workloads and naturally our customers want us to deploy within their cloud environment, where their existing Postgres cluster(s) already live.”
ParadeDB's approach to implementation leverages existing open-source tools while maintaining tight control over its deployment footprint. "For our customers who opt-in to the BYOC offering, we're building this sort of NASA-like mission control dashboard where all of our BYOC deployments metrics report to a centralized management system. This allows us to offer the service quality of a fully managed offering while deploying in the customer’s cloud environment." Philippe shares. Their customers typically provision a sub-Amazon account or Google Cloud project, enabling ParadeDB to maintain visibility while respecting security boundaries.
On pricing, ParadeDB charges on a usage basis, with an additional premium for BYOC deployments. About half of their customers self-host, often due to air gap requirements in highly-regulated industries, while the other half uses the BYOC offering.
Interview with Vlad A. Ionescu, Founder and CEO, Earthly
Earthly's journey offers a fascinating look at how technical architecture evolves to meet enterprise requirements. Their approach to BYOC centers on a fundamental architectural innovation: the clear separation between control plane and data plane. This separation has proven crucial for both technical efficiency and customer acceptance.
Architectural Evolution
Earthly's architectural approach emerged from a deep understanding of customer concerns and technical constraints. The company made a strategic decision to maintain their UI and orchestration layers in their own cloud while deploying only essential build runners in customer environments. "99.9% of people were saying, yeah, that's totally fine. I don't care where the UI is, as long as you're not exposing secrets or IP," Vlad explains.
This architectural decision led to a significant rethinking of their connection patterns. "We had to reverse a bunch of connections," Vlad shares. "Initially, these agents were monitored by being regularly pinged by other processes inside our cloud. Now we have to reverse that connection where the agents are reporting the metrics to our cloud because we don't want those to be accessed from the internet. We had five or six such connections we had to rethink."
The team paid particular attention to permission models, implementing a carefully scoped system that limits access to only the resources created by Earthly. "If you're creating an EC2 instance, and then you have the permission to destroy EC2 instances, that permission should be scoped only to what you've just created," Vlad emphasizes. This granular approach to permissions has proven crucial for customer acceptance, particularly during security reviews.
Market Timing and Customer Needs
One of the most surprising aspects of Earthly's BYOC journey was its timing. "We realized we had to do this at the seed stage when we were maybe expecting it at Series B," Vlad recalls. This early adoption was driven by two key factors in the CI/CD space: cost savings and security requirements.
The cost factor becomes particularly compelling at scale. When using managed services, companies typically pay by build minute, with vendors adding significant margins - "somewhere over 50%" for some providers. "As soon as you have some sort of scale, like a hundred engineers, it becomes much cheaper to bring that in-house," Vlad explains.
The security requirements came from an unexpected source. Even companies in non-regulated industries often needed BYOC because they were "vendors adjacent to regulated industries." These companies required SOC 2 compliance and found it "so much easier to not have to deal with a third party that accesses your production."
Interview with Jordan Lewis, Senior Director Engineering, CockroachDB Cloud
Cockroach Labs' perspective on BYOC reflects the challenges of a rapidly scaling database company serving diverse enterprise needs. Their journey from a self-hosted only product to a fully Managed Cloud to exploring BYOC options offers valuable insights into how deployment strategies evolve with company growth.
Market-Driven Architecture
Jordan outlines distinct BYOC requirements across industries, with the banking sector being particularly decisive. "For most of our banking customers, with the exception of one of them, which is the most tech forward one, they will not use a fully managed cloud," Jordan explains. Even companies in AI and gaming have specific data privacy requirements that often preclude managed cloud solutions.
In response to these market needs, Cockroach Labs is exploring a Cloud account-based BYOC implementation (or Bring Your Own Account). This approach would be simpler than an agent-based solution: "No agent, it really just gives us the keys to your account and we'll do everything on your behalf. This is essentially the BYOC model that Databricks uses." They believe this will provide a better customer experience compared to an agent-based approach. As Jordan notes, "We think that could be harder, and we also think it's going to lead to a less good experience for the customer. We think the best experience is going to be this account-based method."
Interview with Suchit Agarwal, Director of Engineering, Okta
As an engineering leader at a public company serving major enterprises and as someone with nearly 20 years of experience in the industry, Suchit brings a unique perspective to the BYOC discussion. His analysis offers particularly valuable insights into why companies might choose alternative deployment models over BYOC.
Business Case Analysis
From Suchit’s perspective, BYOC is a means to an end. Customers are generally interested in specific outcomes like isolation, higher performance, data residency etc. and BYOC is not necessarily the best or even the most efficient method to achieve those outcomes, both for the customer or the vendor.
Implementation Realities
The complexity of implementing BYOC at scale becomes particularly apparent as companies grow and complexity grows with it. Depending on the service, doing a big bang BYOC can be a massive uplift, and can easily require huge amounts of new work and rework, Suchit warns. A lot of the assumptions and specific choices that might work in a vendor’s own environment will not necessarily work in customer environments, especially given that different customer environments can also differ in subtle ways.
Operational Challenges
The challenges to deliver BYOC for customers do not end once the service is successfully deployed inside a customer’s environment. There are critical operational and process issues to consider when it comes to uptime, support, and updates & patches. Vendors have to address several problems, such as:
The Private Cloud Alternative
Instead of full BYOC, Suchit sees more promise in a Private Cloud model. Customers can sign up for a dedicated, yet managed instance of the service. The private cloud model can provide customer isolation, higher performance guarantees, and data residency guarantees depending on the needs of the customer. This model can be a lot more efficient for both the customer and the vendor. Customers do not have to take on the operational cost of running the service, and the vendor can operate the private cloud using their existing internal processes, tools, and systems.
The Reality of Customer Demands
Suchit believes that the private cloud model is here to stay and, unless BYOC is absolutely necessary for legal or compliance reasons, is likely to be the preferred approach for customers looking for specific outcomes and vendors looking to serve those customers. In terms of business investment and ROI, it presents a much stronger story.
The collective insights from these interviews reveal several crucial considerations for engineering leaders evaluating BYOC:
Understanding Market Requirements
The decision to implement BYOC should be driven by a clear understanding of market requirements. These requirements often emerge earlier than expected, particularly in sectors adjacent to regulated industries. The need for BYOC isn't limited to traditional regulated industries - it can be driven by cost considerations, data privacy concerns, or compliance requirements.
Architectural Decisions
Successful BYOC implementations often share certain architectural characteristics. The separation of control plane and data plane has emerged as a crucial pattern, allowing companies to maintain operational efficiency while meeting customer requirements. Minimizing the footprint in customer environments and implementing carefully scoped permissions are also key success factors.
Business Model Implications
BYOC significantly impacts business models and pricing strategies. While it could command premium pricing, it also requires substantial investment in support and maintenance. Companies need to carefully consider the long-term implications for their operations and resource allocation.
The experiences of these companies and individuals suggest that BYOC isn't just a deployment option - it's a fundamental business decision that affects everything from architecture to pricing to support models. Success requires careful consideration of all these factors and a clear understanding of your market's specific requirements.As BYOC reshapes enterprise software deployment, founders must strategically determine the right timing and approach for its implementation.
If you're building in data, machine learning, or cloud infrastructure and want to discuss technical GTM strategies, I’d be happy to share insights from our work with founders navigating these critical early decisions.
*Note: All opinions expressed here are solely those of the individuals and do not reflect the views of their employer.
**Earthly and Cockroach Labs are Work-Bench portfolio companies.
