From Borg to Kubernetes: Vitess’ Cloud Native MySQL Graduates CNCF
Vitess, the database clustering system for horizontal scaling of MySQL, has reached the graduate level of maturity at the Cloud Native Computing Foundation (CNCF), joining the seven projects to precede it, which include Kubernetes, Prometheus, Envoy, CoreDNS, containerd, Fluentd and Jaeger. The CNCF has been busy as of late, with Jaeger graduating, CloudEvents advancing from sandbox to incubation, and Rancher’s Longhorn joining the sandbox, all in the last week. At the same time, several other projects are currently making their way through CNCF’s technical oversight committee’s due diligence process and coming up for a vote for either admission, advancement, or graduation, including Falco, Harbor, Volcano and gRPC.
While Vitess first joined the CNCF just under two years ago, the project has cloud native chops that predate many other CNCF members; as noted in a CNCF statement, Vitess “supported Kubernetes since before Kubernetes reached 1.0, and it now integrates with and makes use of many other cloud native projects including etcd, gRPC, and Prometheus.” Sugu Sougoumarane, co-founder and CTO of Planetscale and Vitess co-creator, related the project’s early experiences dealing with cloud native infrastructure as part of its move from YouTube’s servers, where it was born in 2010, to run on Google’s Kubernetes-predecessor Borg in 2013.
“Vitess was one of the very few projects that was actually ported into Google’s Borg as if it was a stateless application, which means that Borg would reschedule you and if it rescheduled the process, your master database could be running there, and it’ll wipe all your data. We had to actually survive those types of reschedules and make sure that we never lost data,” explained Sougoumarane. “It took us about a year to reconfigure Vitess to be able to survive well in that environment, and it turned out that those things that we did are what made Vitess cloud native. We were actually ready for Kubernetes before it was even written. That is a historical reason why Vitess can call itself a cloud native database.”
“We were actually ready for Kubernetes before it was even written. That is a historical reason why Vitess can call itself a cloud native database.” — Sugu Sougoumarane, co-founder and CTO of Planetscale and Vitess co-creator.
A New Release Brings Focus to Usability
In addition to the project’s lengthy dealings with cloud native architectures, its maturity is shown with the release of Vitess 4.0 last week, alongside the news of its graduation. This release includes improvements to SQL query support, experimental support for VReplication, and usability improvements for onboarding new users. Maturity and age aside, Sougoumarane said that the due diligence process that leads up to graduation was a worthwhile experience that really assures a project is truly production-ready.
“It’s definitely something that one should go through because we have to make sure that a project is actually really healthy from all possible points of view. Due diligence really puts you through it,” said Sougoumarane. “We actually had to go back and fix a few things in the documentation and in our processes to call ourselves ready. So I think it’s really a very good and healthy process, to go through that process to get it to graduation.”
As for what will come next for the nine-year-old project, Sougoumarane said that onboarding and usability were two big focuses for the project, explaining that having catered to Google’s needs did introduce complexity that could make it difficult to use for new users.
“Over time, as we tuned Vitess, we introduced a large number of options and flags and a new person that is coming on board could find this slightly overwhelming. What we are now doing is simplifying everything and making sure that you can get up and running with us just like you would get up and running an extremely simple database. That is going to be our focus,” said Sougoumarane. “Another one is, because it’s a sharded system, there are some queries that would work if you sent it directly to MySQL, but if you go through Vitess, it will immediately reject them because those queries may not make sense in a sharded system. We want to make Vitess essentially a drop-in replacement.”
Right now, he explained, Vitess can handle upwards of 90% of an application unchanged, but they would like to get that number to 100%. As for adopting Vitess, he said there are currently two options: the open source project itself or the managed version, which is offered by PlanetScale.
The Cloud Native Computing Foundation is a sponsor of The New Stack.
Feature image via Pixabay.