Flexibility and portability are two of the most valuable features that brings to the table. But, preserving those features requires the right technology partners and strategy. open-source software Countless database-as-a-service (DBaaS) providers of open-source data technologies require customers’ data to be hosted on their domains. They offer the simplicity of a single cloud bill but build obstacles to flexibility and data access. While many DBaaS providers host data simply to provide a streamlined out-of-the-box service, some “open core” providers (mixing open source and proprietary code into what are ultimately proprietary offerings) frankly don’t have open source principles—or even their customers’ best interests—at heart. I’ve always thought it very important to empower and encourage organizations to harness many of today’s leading open-source data technologies with a “run in your own account” (RIYOA) strategy if they so choose. RIYOA (running in your existing public cloud accounts like , GCP, or Azure) preserves an enterprise’s direct control over its own data and makes it simple to move that data if and when it needs to. You want organizations to retain services due to a provider’s strengths—not because they’re, well, a captive audience. AWS A RIYOA strategy neutralizes “open core” traps Freedom from vendors and proprietary technical lock-in are fundamental open-source benefits. “Open core” DBaaS providers trade on open source’s good name while enveloping true open source technologies in their own proprietary offerings that are nothing but lock-in traps. These open-core services might require an connection or navigating a serverless model for enterprise teams to access their own database. DevOps and developer teams, therefore, must shape their data models and applications to the needs of their host. In contrast, RIYOA rightfully maintains true open source freedoms, eliminating lock-in threats and allowing teams to pursue the best data strategies available for their own needs. API RIYOA = rapid and versatile data access When a database is hosted externally, developers have to ask the host anytime they need data access…and suffer the latency and obstacles of that process. That makes quick ad hoc queries that deliver timely insights all but impossible. RIYOA means never having to ask. Developers can efficiently examine their own data as they like. Use cases requiring rapid access to customer data, or historical backup data, are easily achievable—enabling applications and features that teams with external hosting likely wouldn’t even consider given the roadblocks involved. RIYOA ensures access to multiple database technologies, and the visibility to optimize Enterprises that let providers host their data are restricted to that provider’s prebuilt control plane software—software that is generally not designed to offer easy connectivity to other database technologies. This then forces teams to leverage complex workaround schemes involving APIs and connectors. Black box open-core technologies make those connections much more difficult. RIYOA simply avoids these issues, with no added obstacles to combining multiple pure open-source technologies. As I’ve seen at Instaclustr by Spot, maximizing database flexibility is only becoming more critical. DBaaS A RIYOA strategy ensures that monitoring data is in-hand instantly, rather than as a follow-up to an access request. As an example, developers working with Apache Kafka will only be equipped to maximize their deployments if they can access schema to understand data and data transitions. RIYOA eliminates security paperwork and lets customers know their data is safe Storing customer data with a third party in the form of a DBaaS hosting provider creates security concerns. It also means a mountain of security paperwork, and the need to reassure customers to tame risk perception. With RIYOA, there’s no need to scare customers with notifications about third-party data activities or changing partners: data is safely in the enterprise’s own cloud account.

The is an opinion piece based on the author’s POV and does not necessarily reflect the views of HackerNoon.

Running Open Source Data Technologies in Your Own Cloud Account

Too Long; Didn't Read

@anilinamdar

Credibility

RELATED STORIES