In late winter of 2013, less than a year ago today, we set out to build Orchestrate. We knew a gap existed in the NoSQL database market and we wanted to understand it, quantify it. Document it.

We decided to start by writing down some basic concepts for the design of a system we wanted to build. Some ideas were newly discovered insights arising out of the swirl of dozens of excited and often contentious excited, energetic, passionate, drunk, alive conversations first between Ian, Matt, and me and soon our present teammates.

But most of what we came up with had been hitting us over the head for at least a few years. And hitting us over the head. And hitting us over the head.

I wish that most of the ideas we came up with were eureka moments, like Kekulé and his ouroboros. In fact it was more like Homer Simpson, trying to decide if he should support a labor deal with a dental plan when he had just learned his daughter Lisa needed expensive braces.

orchestrate-dental-plan

We knew a big gap existed in the database market between the expectations of the market and available technology. We had spent the last six years at Basho Technologies, makers of NoSQL key/value store Riak. Over that time, we collectively saw what hundreds of developers were building and what drove their decisions.

NoSQL databases proliferated, offering niche tools optimized for specific queries. Companies often ran three, four, even more databases in production. Many of these databases were scalable and fault tolerant but hard to use. The ones that were easy to use experienced widespread adoption.

Users also increasingly showed interest in on-demand services rather than owning and maintaining software. Amazon Web Services, SendGrid, Urban Airship, Twilio, PagerDuty all replace a key part of traditional enterprise infrastructure with a service accessible through a public API. The market was speaking to us…. and had been for several years.

Developers used multiple databases. Easy-to-use databases proliferated much faster than complex but feature-rich databases. Users wanted to consume services, not install and maintain software.

Many databases. Easy-to-use. As-a-Service.

I don’t know what you call it when dozens of people over half a dozen years tell you the same thing over and over again and the message finally penetrates your skull.

Many databases. Easy-to-use. As-a-Service. Dental plan. Lisa needs braces.

Finally we heard what the market was saying. We sat down and wrote a list.

And now, in no particular order, the original design concepts for Orchestrate almost a year since we came up with them and after years of being told them.

This, then, is our Dental Plan Manifesto:

  • Easy-to-use beats lots-of-features every single day.
  • Time-to-use is the key metric. Measure time to productivity in seconds.
  • Hide all the distributed systems complexity from users. They don’t care as much as system designers do. If you are talking about CAP theorem you have already lost.
  • Polyglot. Users already know what database vendors refuse to admit: No one database can do everything.
  • X-as-a-S will replace X, whatever X may be.
  • Pay-as-you go pricing. Don’t make a user guess at their peak usage
  • Cancel any time. No strings. Developers don’t want strings.
  • No lock-in. Users must be able to leave any time with their data.
  • Don’t sell access to your roadmap. Solicit advice early and from everyone, including free tier.
  • Don’t argue about cloud adoption. The question of whether enterprises will put data in the cloud is already answered. Avoid people who need convincing.
  • Usability scales. The notion one must make a trade-off between ease of use and robustness is a self-serving lie.
  • Relax a little. If everything is an experiment, you can’t make mistakes.

At the time, we didn’t think we were writing a manifesto. I think none of us took, or takes, ourselves seriously enough to be manifesto writers. We were simply capturing all the ideas for what would make a killer system in one place. But if one defines a manifesto as a statement not just of principles but of intentions, it became clear as Orchestrate took shape over the next several months that we were going to live and die by the ideas we set forth. (Definition: “a written statement declaring publicly the intentions, motives, or views of its issuer.”)

If you look at Orchestrate, you can see echoes of the Dental Plan manifesto almost everywhere.

In the coming weeks, we will cover the areas where we think it matters most to users. We will go into depth on pricing and how simple, clear usage pricing advantages users. We will go into depth on our roadmap. We will be releasing clients and new features meant to simplify and speed up use of the Orchestrate API. And we will answer a number of questions we’ve received from our users.

Most of all, we hope as you use Orchestrate’s Dashboard, documentation, and API, you reap the benefits from the lessons we eventually learned.