Kafka in the Cloud: Why it’s 10x better with Confluent | Find out more
Bring Your Own Cloud (BYOC) is a deployment model where organizations host applications and data in their cloud accounts, instead of in vendor’s accounts. A good BYOC solution will support zero-access from the vendor accessing their raw data in their cloud under any circumstances. It is preferred by organizations that use cloud services but have compliance requirements that prohibit data from leaving their VPC. BYOC comes with tradeoffs of operational complexities given its shared responsibility model.
Confluent now supports BYOC deployments with WarpStream!
Bring Your Own Cloud (BYOC) involves deploying a vendor's software in a customer's cloud environment, typically within their own VPC (Virtual Private Cloud), while data resides in that customer’s cloud environment. Such design offers several benefits, including enhanced flexibility and control over your cloud environment, and stricter adherence to data sovereignty or liability agreements, allowing data to be retained in your cloud accounts and jurisdictions.
As a tradeoff, BYOC also can create ambiguity and risks in operational and security responsibilities. While the vendor takes care of application-level tasks, such as updates and support, the customer is responsible for the security and management of the cloud environment, including network configuration, access control, and ensuring the proper integration of services. This division of responsibilities could lead to complexities in troubleshooting and support, as both parties must coordinate to maintain the system's security and functionality.
A common flaw with most BYOC solutions is that they often allow vendor permissions into your VPC and your data for monitoring and troubleshooting cases. This fundamentally defeats the promise of data sovereignty with a BYOC offering. Confluent WarpStream’s Zero-Access BYOC is uniquely designed to reduce the operational and security ambiguity by separating data with metadata. This isolation allows customers to still enjoy some benefits of a cloud-native offering, while maintaining strong boundaries for security and operations.
In a BYOC model, customers leverage their existing cloud infrastructure to run applications provided by the vendor, keeping their data within their cloud accounts and some control flexibilities over their cloud infrastructure. As a tradeoff, customers have to assume partial infrastructure, security, and support responsibilities, shared with the vendor and cloud service providers.
SaaS, on the other hand, provides a serverless offering that is fully managed by the provider, eliminating the need for customers to handle infrastructure or maintenance. Security and operational burdens are fully managed by the vendor, while the user typically has options to add additional security policies and controls on encryption of sensitive data, access controls, authentication, edge protection, and more. This is becoming the de facto standard for most cloud services, whereas many vendors offering BYOC deployments eventually pivot to a SaaS offering.
A third alternative is a self-managed solution, which involves customers installing and managing the software on their own hardware or cloud infrastructure. This requires in-house resources for setup, maintenance, and updates but with clear costs and responsibilities and full control over their data environment.
Self-managed or vendor software deployed on-premises, with full operational responsibilities on customer.
Vendor deploys on customer VPC with shared infrastructure and support responsibilities.
Serverless offering offloading all operational and security burdens to vendor - best for eliminating operational complexity and minimizing risk.
SaaS solutions are in most times easier to use than BYOC since the customer can offload both hardware and software operations and security concerns to the vendor.
In a BYOC deployment, since customers still need to operate and maintain the underlying cloud infrastructure, support responsibility boundaries are often shared. The Shared Responsibility Model involves the customer, the Cloud Service Provider (CSP), and the BYOC vendor, and could lead to potential confusion regarding who is accountable for what. With a fully managed cloud service, there are clear responsibility boundaries.
Compared to operating SaaS, operating a BYOC solution also requires deeper technical expertise and more operational responsibilities. Operational efficiency in SaaS is exemplified by large-scale multi-tenant architectures, offering benefits like excess capacity, elasticity, per-customer quotas, stable environments, standard instance, and storage types, minimized versions and configurations, and streamlined tools and access controls.
Confluent Cloud offers the auto-scaling of logical Kafka clusters up to GBps+ and back to 0 without requiring the customer to wait for any physical scaling. The customer has an upper range for the size of the cluster (in terms of resources like throughput and connections/sec) implemented as a set of quotas/rate limits. Then the customer simply gets charged based on hourly consumption of what was actually used.
The reason to choose a BYOC deployment is not because it is inherently more secure, but because of a companies preference on data sovereignty within their cloud environments. When it comes to data sovereignty and control, BYOC might initially seem advantageous because the data resides within the user's account but the reality is data still resides in a multi-tenant cloud environment, just as it would in a SaaS offering. The ability to revoke vendor access to data is not unique to BYOC setups but also exists in SaaS models through mechanisms like customer-controlled encryption at rest.
The security of both BYOC and SaaS models relies on a balanced approach, including just-in-time access and detailed logging. With a BYOC configuration, the responsibility to secure the environment falls squarely on the customer. This includes controlling access to other systems and services and investing in proper security scanning and monitoring oversight.
There are also various degrees of security scrutiny in BYOC design. Most typical BYOC deployment models for data streaming require providing the vendor with expansive access and IAM roles to access your environment and data to manage your clusters and mitigate issues. In contrast, Confluent WarpStream is designed with zero access by default by separating data from metadata, so none of these excessive permissions are required to keep your clusters up and running.
Comparing the list price of a BYOC offering with SaaS is apples-to-oranges. BYOC pricing is based on a subscription to the software. Customers still bear infrastructure expenses from the CSP and additional responsibilities like securing the environment and private networking. BYOC also requires heavier operational and technical overhead on the teams using the solution. In contrast, a fully managed SaaS that encompasses all costs, covering underlying compute, storage, networking, security infrastructure, and support.
Seamlessly connect your data and apps everywhere they reside, across hybrid and multicloud architectures.
Confluent offers true deployment flexibility to support hybrid and multi-cloud architectures. Confluent exists everywhere your applications and data reside, providing you the freedom to leverage a fully managed service on all leading public clouds, a zero access BYOC service for compliance-sensitive workloads, and self-managed software for on-premises workloads, whether on bare metal, VMs, or Kubernetes. Best of all, you can seamlessly connect it all in real time with Cluster Linking, creating a consistent data layer across your entire business.
Leverage a fully managed, cloud-native Kafka service with Confluent Cloud
that is powered by Kora Engine to be elastic, resilient, and performant.Deploy on-premises with Confluent Platform with elements of Kora Engine that provide cloud-native benefits and bring a complete set of security and productivity features.
Keep data in your own VPC with Confluent Warpstream with shared support responsibilities, best for experienced Kafka users and latency-relaxed use cases.