How many infrastructure providers do you use for your database? Probably one, maybe two. Every query, insert and update a negotiation with your jailer, the cloud service to whom your organization is utterly reliant. 

Adopting a multi-cloud strategy is obviously preferable for redundancy and for ideological concerns, but is hideously expensive in terms of technical debt, organic capital investment, and raw financial expense. Those who try to failsafe their operations through multiple providers often find themselves drowning in data transfers, application reconfiguration and even total re-architecture of their database, not to mention ratcheting price plans for core services you are by now simply unable to do without. 

Vendor lock is a serious concern that dominates C-suite discussions in organizations all over the world, directly affecting their bottom line, and the services they provide locked to a single provider's feature roadmap, service upkeep, and pricing.

Headaches in the Multi-Cloud

Database infrastructure may not be a technical monopoly, but when the choice is that or rebuilding your app functionality from the ground up, it sure can feel like one. Managing a database across multiple providers means a need for constant synchronizations, all of which can be prone to human or technical error. 

Different providers can also have different demands on your database, require different standards and formats, different security requirements, and may even be in different parts of the world. Ensuring the smooth operation of your service that relies on your database suffering from the latency and compliance issues that arise from using cloud infrastructures physically located worldwide is a constant problem. 

And, finally, even if you are extremely well financed, use every provider available, and have a whole team dedicated to keeping your database from being torn apart by wild horses, there is a very real chance that you’ve overprovisioned and are wasting a colossal amount of money and expertise just trying to do the right thing.

Ideological Imperatives

All this effort, and at the end of it, you are still at the whim of a host of centralized services, all of which have full overview and true control of the data your service uses, and all of which are practically and ideologically problematic. Practically, we’ve mostly covered.  Ideologically, it’s unconscionable that in a world where data is the most valuable resource that you and your team (the project doing the work) doesn’t truly own your own organization’s data. It’s hugely problematic that you’re not truly in charge of safeguarding it even though your customers rely on you and trust you to do just that. Furthermore, that your customers don’t own their own data either - when it’s more than possible them to do so and, if they did, your projects own safeguarding liabilities and headaches could be infinitely reduced as a result.

A world where your entire business can cease to operate because someone at AWS failed to update the DNS after a server outage, an invalid parameter was accepted, or you know, the weather. An outage might be correctable, but if you’ve launched a huge marketing campaign building up to one specific moment and you’re selling DTC through your website - and it suddenly stops working - years of work and decades of capital can be lost because of something that wasn’t your fault. And you have no recourse.

Unlock Your Database at the Source

Locking your database to one infra is wrong. Using multiple infras for your database is expensive, time-consuming, complex, and still wrong. Source Network’s tools are all about burning down the jails that keep innocent projects and individuals locked up by allowing them to have true ownership of their data. By letting them deploy multi-environment through a globally replicable and always available P2P database that enshrines privacy, ensures security, and which is deployable multi-environment  - including, yes, the traditional cloud-based centralized environments organizations. DefaDB effortlessly handles conflict resolutions through CRDTs using Merkle-DAGs, with the content addressability of IPLD. We also provide the trustlayer, the SourceHub blockchain, for the security, authentication, and maintenance of distributed databases deployed using DefraDB, as well as tools to translate existing schema into compatible data models. 

Source Network’s goal is both practical and ideological. Practically, using DefraDB to manage your organization's data means you can operate low-latency, fully compliant, and cryptographically secure databases trustlessly anywhere in the world. Ideologically, it stops the ever increasing specter of centralized control. Data is more important than ever, and more important daily, with advances in AI, command and control technology by nation states, and corporate harvesting of individual’s data for commercial purposes. Developers building services that let users own their data and never have to surrender it, whilst also ensuring the data that powers their organization is also kept safe - even in case of total disaster - is starting to come close to a moral obligation. 

Free Your Data, Free Your Mind

Developers, whether you’re already fully operational or building a new service from scratch, don’t just give your data away to your cloud jailer. Users, never give it away. Data sharing should always be a wilful act at every stage in a relationship, and paradigm that will bring great benefits to both teams engaged in enterprise and end-users engaged in life. Don’t trust your data with someone else who may not have your best interests at heart. Don’t just be a subject organization of some corporate zaibatsu, praying that they don’t jack their infrastructure rates again this year. Use Source Network’s tools to take back control, giving both you and your users the digital self-sovereignty that everyone in this world deserves.