Should You Bring Your Own Cloud?
Data is expensive and continues to grow. The challenge of managing data infrastructure includes technologies and costs to collect, process and store this data. Keeping this cost in line while managing compliance requirements is a constant challenge for customers.
There have been many blogs and discussions as of late around SaaS delivery models and deployments. One of the recent discussions is regarding Bring Your Own Cloud (BYOC) models, where the cloud is paid for and supplied by the customer, versus the SaaS provider paying the bulk of the cloud bills.
To adopt a new platform, there is typically a level of trust needed. This starts by using the platform for specific use cases before expanding the use of the technology for other use cases. As an engineer testing something, you want a simple, low-cost service.
This is often achieved by a serverless or shared tenancy model with a low cost to entry, but also a low service-level agreement (SLA). Often scalability can be limited, and finally security is limited due to the shared tenancy. As the organization increases adoption of said service, often dedicated services make more sense, which can have a higher level of performance and security SLAs attached to them.
If a solution provider is telling you their serverless data or streaming solution is fully elastic and will not suffer from spikes, they are likely coating over some future pain you will have. If this is, in fact, true, they have factored in some level of capacity that is free to be used on demand, and you hope this capacity will be available when required, and that another customer hasn’t taken it. This is why, as customers scale, they require dedicated environments accompanied by assurances for performance.
Before we get to the next steps, let’s explain the economics. As a SaaS provider of a managed data platform, there is a cost to deliver the service, let’s call this the “cloud tax.” This is what the SaaS provider pays the cloud provider, whether that is colocation or public cloud.
This means that, as a SaaS business, to get the profit margins reported back to investors or the public, there must be a markup of the “cloud tax” to cover the infrastructure to deliver the service to make a profit. If the SaaS provider can offload the cost of that infrastructure to the customer, then much more flexible pricing models are possible without affecting profits or the cost of goods.
The BYOC model allows a SaaS provider to offload the costs for the infrastructure back to the customer to make the infrastructure decisions. Most importantly, it allows the SaaS provider to avoid having to include the cost of infrastructure as part of the service cost. Ultimately, this allows for better pricing of the software component of the service. The cost of the infrastructure depends on how good your deal is with the infrastructure provider of your choice, as long as the SaaS provider supports your infrastructure provider.
This opens a new wrinkle to the discussion. Most organizations have a commitment level with one or more infrastructure providers, which can be burned down by using infrastructure and services. The larger hyperscalers (Amazon Web Services (AWS), Microsoft and Google) allow a portion of committed spend to be retired by marketplace purchases of third-party solutions. Some marketplaces have limits on how much can be retired this way, or how much the third-party solution counts against the commitments. This is not the complete story, but this is already compelling.
To optimize infrastructure spend, most organizations employ savings plans with cloud providers. These commitments are essentially purchased reservations for a given type of instance for a given amount of time (typically one to three years). These savings plans can save as much as 75% off the list price of an instance. When stacked with commitments, this can be a significant savings.
Savings plans are typically only usable on compute instances, not on other cloud services from the provider. The benefit of the Aiven approach is that we only use compute, storage and networking from our cloud provider partners; we do not use any other cloud services, making us portable and efficient.
When purchasing BYOC, not only can you leverage better discounting from the SaaS provider, but you are also leveraging cloud provider commitments for the marketplace in addition to the massive savings from your savings plans and commitments.
There are multiple ways that BYOC makes sense for organizations with large cloud provider commitments. This most likely doesn’t make sense for organizations that have cloud bills smaller than a few million dollars per year. Once you hit those levels it makes a lot of sense as you are likely heavily optimizing spending patterns.
Finally, the last advantage in BYOC has to do with data ownership. While you may tell auditors that you own the data when running upon a SaaS service, the SaaS provider owns the infrastructure you run on, and they own the storage your data sits on as it’s in their cloud account. If there is a reason you need to leave that provider, you have to play things carefully. However, if you are on BYOC, you own the infrastructure and data technically as it’s in your cloud account.
Side note: You can technically disconnect Aiven at any time, and your services will run until there is a need for control plane actions that would fail (more on this later). Aiven controls encryption and access to the data with BYOC as we perform automation including balancing, optimization, backups, restores and data management. We have plans to create data freedom where data can be made more automated and portable, but stay tuned for the plans in 2024 :)
Now for the downsides of this model. Everything is not perfect with BYOC. There are challenges associated with it, but also solutions. The first challenge is the shared responsibility model. With BYOC the networking is more complex, which means the teams have to work together to set it up, and more importantly, teams have to have good change control not to break the networking.
This has been an issue more than once for Aiven. We have built specialized tooling to help with monitoring and testing BYOC configurations to ensure that the customer experience is superb and connectivity is always optimal. We are very close to releasing our self-service BYOC, which automates the information exchange and implementation. However, the customer can always disconnect the control plane, as they have control, not the SaaS provider.
The second challenge with BYOC is that the customer has cloud commitments, which means specific instances must be used in specific regions of the cloud provider. At Aiven, we run mainly standard plans for our products where we select the best infrastructure for a given workload. We can and often do create custom plans for specific customer needs (similar to hyperscalers); this is something Aiven must do for the customer.
We plan to change this in the future to allow Aiven customers to self-serve and create the specific plans they need to meet existing commitments for certain types of instances to meet savings plans commitments.
Finally, there is the control plane. Today, Aiven runs a control plane that is redundant across a single cloud provider across multiple continents. The control plane allows us to drive automation, collect observability data and manage our single control point for our console, APIs and other associated product offerings.
This model will be changing as we expand our control plane to being fully multicloud in 2024. This is just the first step of where we are going. In the future, Aiven will have a more federated control plane, where the control plane does not have a single location and data can be federated across customer cloud accounts. This removes any single points of failure and makes data sovereignty even better than it is today.
As you can see, this is not a simple pro and con of specific solutions. Each customer and type of customer has different needs and requirements. When investing in a platform versus a point solution, there are different approaches to the right value proposition. For example, if we are approaching a small development team looking for Kafka, we would take a different approach than a global retailer looking for the entire data platform including PostgreSQL, Kafka, Flink and ClickHouse.
Multiple delivery models are required, along with the business flexibility to meet customers where they are today and where they are going. Our goal is to help customers as they grow from the small scrappy startup registered in our Cluster 2.0 program to the Fortune 500 where we create unique global footprints. Aiven is here for you along the way with the open source data platform for everyone.
