Do-It-Yourself (DIY) — From Scratch
When faced with database challenges such as reliability, availability and application performance, engineering leadership sometimes consider building a custom solution in-house, such as the “Manhattan” project at Twitter described here:
Over the years, we have used and made significant contributions to many open source databases. But we found that the real-time nature of Twitter demanded lower latency than the existing open source products were offering. We were spending far too much time firefighting production systems to meet the performance expectations of our various products, and standing up new storage capacity for a use case involved too much manual work and process. Our experience developing and operating production storage at Twitter’s scale made it clear that the situation was simply not sustainable. So we began to scope out and build Twitter’s next-generation distributed database, which we call Manhattan. We needed it to take into account our existing needs, as well as put us in a position to leapfrog what exists today.
Do-It-Youself (DIY) — Not From Scratch
If building a custom database in-house is not feasible, engineers usually look to the landscape of independent tools that they can assemble and manage themselves. After pulling it together, they may get a system up and running, but it is not fully integrated or self-aware, often there’s little to no automation, and there may be limited fail-safes to protect the data. In the event of a problem, it can become a chaos that results in downtime and extreme manual labor, often in the middle of the night or at peak hours. Hence the old adage, better to prevent a problem than to fix one.
Migrate Away from MySQL
Besides DIY, sometimes engineers consider switching to a different database, as that may solve the current set of problems; but after the migration, they often find that the new database solved some of the old problems and introduced new ones too. I heard a joke that Uber switched from MySQL to PostgreSQL and back to MySQL (I don’t know if this is true, but here is a blog about why Uber switched from PostgreSQL to MySQL). The point is migrating to a new database is a pretty big change, and every database has its pros and cons, so the payoff may turn out not to be as great as it seemed.
The Continuent Approach
I'm writing this because I'm interested in learning more about what others are doing to achieve next-generation database tech with MySQL. My company enables highly available, reliable, and scalable MySQL for organizations such as Adobe, Carfax, Garmin, and Riot Games.
Without the enormous overhead, infrastructure change, cost, and risk that DIY or database migration require, Tungsten solves many of the same problems as Twitter’s custom Manhattan project; almost every aspect of Tungsten can be customized to meet a customer’s unique needs; no two deployments are identical, yet all are based on integrated, fully-tested, proven components for connectivity (proxy), replication and management (orchestration).
One customer said they love Continuent because it “just works”... “out-of-the-box” which they’re surprised by because theirs is a completely customized solution. Another customer said Tungsten was one “of the better software choices made in the last 3-4 years.”
Tungsten enables greater application performance especially across WAN, it saves tons of manual labor and headache, it’s backed by premium 24/7/365 support, and it enables all sorts of new freedom and possibilities for data infrastructure including multi-cloud, hybrid-cloud, and advanced, real-time analytics.