The traditional observability SaaS model involves storing data on behalf of enterprises; however, in recent years, this approach has been evolving, and the Bring Your Own Cloud (BYOC) model is gaining popularity. In this post, we’re going to explore why that’s happening and why companies are responding so positively to SaaS companies that let you keep data on your side of the network. TL;DR: It’s about controlling your own data, and enterprises are taking this approach for better cost control, security, and customization.
Access Control for Security, Trust, and AI Development
When data is locked away in SaaS observability platforms, access control becomes a challenge. On one hand, you have to trust that the vendor is keeping that data secure. On the other hand, you might want access to it for other use cases. Large language models (LLMs) and Model Context Protocol (MCP) servers have turbocharged these concerns. We’re seeing far deeper mining within logging and telemetry datasets that are fed into AI systems. There’s the risk of proprietary information making it into a model dataset that you don’t own. You may also want to own that data for training your own models, which is typically not possible when the data is locked in a SaaS platform.
Tuning the size of results from an MCP server to reduce context usage, or fine-tuning an LLM with your own dataset, is only possible when you own your data. What about the need to filter the data when providing it to an agent? If your vendor doesn’t give you that optionality, you’re out of luck.
Companies are moving to a “trust but verify” model, where the company trusts its vendor to handle the data. However, since the dataset is in the customer’s cloud environment, verification can be done relatively easily and without concerns about rate limiting or access pricing issues. Additionally, concerns about data access being provided to an external system can be easily audited. In other words, a company that stores and controls its own data in its own cloud environment can choose whether to share any or all of its data with sub-teams, vendors, contractors, and so on.
With control of data comes choice. Your (telemetry) dataset can be filtered for all kinds of use cases. Imagine you want to provide information as a POC to a vendor. You don’t want to give away all your information. If your data is stored in a third-party (telemetry) vendor, you have much less flexibility in terms of what you can share with the new vendor.
In the most concerning case, giving your telemetry to a vendor to control off-site increases the risk that your data is being used for training their models. In addition to security risks and the potential exposure of proprietary information, what if your business wants to use that data to build new revenue streams? Instead, you’re giving that data to a vendor, and potentially even paying them to profit off your data.
Controlling Costs
There are two key benefits to controlling your data: the ability to negotiate a flat, predictable spend with your storage provider and the ability to sample and filter your data to reduce the dataset size.
When a vendor provides a BYOC model, it often comes with a flat pricing structure. Flat pricing structures are better for finance as the spend is significantly more predictable over a multi-year period.
Managing overages, filtering, and sampling data to reduce dataset size is now more in the hands of the company than the vendor. Spending too much on S3 or compute due to upfront indexing, too much data, or too many queries? Not only can you have proxies to control this production and consumption of data, but the vendor is now more incentivized to help you reduce costs! Their flat fee removes the incentive to collect compensation on overages. Your savings are no longer in conflict with their profits.
Customized Systems: Build vs Buy
Many companies are effectively forced to buy new vendors because they lack control over their own data sets. As an example, if you are using an observability solution that has established a traditional SaaS model, it will become increasingly complex to use an LLM SRE (site reliability engineering) agent product that is not their LLM SRE agent.
What if you want to use other tools and products, but your solution doesn’t offer an integration for those tools? Or what if you want to build out your own customized system, such as an alerting or incident management system that better fits the needs of your business? With control over your data, you can build your own systems and explore other tools.
Vendors are in the business of handling the most standard use cases, given that they have limited engineering resources. If you have a different use case, controlling your own data means you can address the need much more easily. Need a system that generates reports only for Kubernetes CPU utilization per business unit? Having your own data means you can build it yourself, rather than relying on your vendor to develop the features you need eventually.
Company control over its own datasets invites both optionality when assessing other vendors and provides flexibility when building in-house.
Maximizing Value: Mixing and Matching Datasets
What if a company wants to cross-reference its telemetry data with its offline dataset and its org chart? It’s significantly easier to do when you control your data versus asking for permission for high-throughput data from the SaaS vendor where it’s stored. By integrating your telemetry data with other datasets, such as those stored in Databricks, you can significantly enhance the value of that telemetry data for data science and business intelligence use cases.
Preventing Vendor Lock-in
When you are working with a vendor that hosts your data on your cloud setup or you are self-hosting your own data, you can better protect yourself from vendor lock-in. You can decide when and where new vendors will be allowed to access the dataset. Want another product from a SaaS vendoron top of your dataset? It’s much easier to ensure performance and correctness when they have to call into your dataset to establish a product or feature for you because you have complete visibility into and control over your data. In contrast, if your data is stored on a SaaS vendor and you want additional features beyond the vendor’s use case, you are effectively locked into using the primary vendor. In this case, your telemetry data is locked away and cannot be easily combined with other products.
