I recently had the opportunity to speak with Antony “Tony” Falco, CEO and Co-Founder of Orchestrate, about the idea of offering a database as a service (DBaaS) product and what it can mean to customers. The company's goal, Falco points out, it's offering customers a convenient way to access and update data that is stored in different databases, in different formats, while still offering good performance.
Who is Orchestrate?
Orchestrate uses the following narrative to describe itself:
We built Orchestrate so developers could tap into the power of NoSQL databases without having to run databases in production themselves.
We wanted to combine the developer-friendliness and ease of use of NoSQL databases like MongoDB and CouchDB with the reliability of distributed databases like Riak and Cassandra, all delivered as a service so users didn't need to worry about operations.
Individual developers increasingly shape innovations in infrastructure and tend to choose technology with low barriers to entry. For this reason, we wanted to make something accessible to everyone. Our free tier offers the same API features and performance as our Enterprise tier. Orchestrate is truly multi-tenant.
We consider our mission successful not when people tell us how easy to use or inexpensive they find Orchestrate, but when they tell us they have built something they could not build before.
What does Orchestrate do?
Here's how Orchestrate describes its product:
Orchestrate unifies multiple databases through a simple REST API. It runs as a service (you store your data with us!) and supports queries like full-text search, events, graph, and key/value.
Orchestrate handles security, monitoring, and daily backups with no licenses, no software, and no lock-in.
Falco described Orchestrate as an API company. That is, his company has developed a set of APIs and middleware that makes it possible for developers to access different types of databases that hold data in different ways and formats. That way they can build complex applications without having to deal with tools that extract data from a source, transform it and then load it into another database as part of the process.
Having been a database engineer earlier in my career, I remember extracting data from one source, such as the Online Computer Library Center (OCLC), transforming it into a different format and then populating a database that supported my company's library automation product.
What was a 32-character field in one database might have been a 20-character field the other database. What was a single field in one database might have been multiple fields in the other database. As the OCLC updated its database, formats or where data was stored would and could change. I was forced to "tinker" with the ETL tool I had built to keep it working for my company's customers.
If we fast forward to today, there are many more types of database engines that support many different types of data. Building an application that accesses and updates data using many different data sources can be quite a challenge for a developer. Furthermore, as each of the sources evolves over time, that application must be updated or things don't work any more.
Orchestrate hopes that by inserting their middleware into the mix of technology that developers are using, they can use the API to access different data sources rather than be forced to develop their own ETL code.
Instead of having to update their own code to keep up with changes in the source data, developers can rely on Orchestrate to change the code behind the API. Furthermore, if the back-end data source changes — for example, if it changes from an Oracle database to and EnterpriseDB PostgreSQL database — the developer's code might not need to be changed at all.
It appears that Orchestrate is onto something and the company could be of great help to developers.