 So thank you for inviting me over and for this. And so far, I've been listening to the other speakers, and the content is amazing. I've learned a lot, and I hope you enjoy learning a little bit about Vitesse today also. And let's get started. So first of all, let's connect. My name is Alken. I am joining from Istanbul, Turkey. And I'm a senior technical manager, developer advocate, and I wear some other hats as a Vitesse maintainer. And I have been evangelist for the open source database projects before, worked at Parcona, Petion, and I also have a very long list of enterprise background working in very large corporations, like Bank of America, AT&T, and so on and so forth. And I'm also one of the MySQL SMEs. And I am also an avid sailor. And if you want to talk, if anybody wants to talk about sailing, please do find me. And hope to sail one day to Africa also. That would be an amazing trip. So I'm on LinkedIn and Twitter for my business accounts. And if you want to connect, ask questions before or after during later, and any ideas later on. And you can connect and ask questions or interact with me. A little bit about my employer. It was founded by the co-creators of Vitesse. So our subject is Vitesse. The project is Vitesse. And the planet scale was founded by co-creators of Vitesse at YouTube. And YouTube became Google, and we became a planet scale. So we're a little over 50 employees, maybe a little over that, and located in California, in the United States. But with the pandemic, we are 100% remote team. As you can see, I'm from Istanbul. And we provide services on cloud database offering. So today's agenda will be I want to introduce Vitesse. OK. So we were going to talk about Vitesse architecture basics. And then we're going to put together the puzzle together. OK. And basically, Vitesse wants to enable transparent database infrastructure for the applications that you're actually going to point. And it has its own terminology, which is slightly different because it's a different than the database in the back end. It's a framework that sits on top of a database. In this case, MySQL. So we call it a database, logical database, the key space. And then the reason for that is we're not going to go in too much detail. But because this is a sharded implementation or designed for sharding of the database, it actually has a key space concept with a key space ID. There's a primary Vindex and the Vindex settings into that. So there's a VtGate, and that's a proxy server, VtTablet. And then we have a topology manager. So we're going to look into these a little bit. So consider a common replication cluster. You have a replicated cluster. Usually, it's actually one primary and then multiple replicas behind it. So VtTablet sits into this very common scenario of MySQL implementation with a primary and replicas around it. So VtTablet is like a demon, a side car. And it controls the MySQL server. It interacts with the MySQL server. And usually, we place them on the same server where the MySQL sits. But in large-scale database implementations, you will have multiple clusters. And then to be able to drive these multiple clusters, you will actually have some sort of a proxy server. So VtTest comes with a built-in proxy server that is called VtGate. And it's a stateless proxy. It is stateless, but it's smart. It speaks to MySQL protocol. Also, it does connection pooling, caching, and some other stuff. And it acts like a monolith MySQL database in the back end. Basically, you connect to the VtGate. You connect it like to a database standalone database in the back end. But in reality, you will have n number of customer clusters and n number of servers that are acting as primary and replicas behind the scenes. So it relates the queries to VtTablet. So in very, very large implementation, then you will have multiple VtGates pointing to the multiple clusters behind the scenes. And this is how the very large shops like GitHub or we'll get to that. So to get to the VtGate, you also have the application that's pointing to the VtGate. And it needs to know where the data sits. So the idea behind this is, as you can see in this example, we have a commerce database, which is sharded. It's probably sharded by a customer ID or a product ID. It depends on the scenario. We'll talk about that a little bit. But then you can also have an internal, unsharded database. So the application pointing to the VtGate knows where the shard is. So this is the Vitesse. So this is what we can achieve with Vitesse architecture, given the simple example of select order ID price from orders and equals to four, it knows where that shard is. So usually, sharding is a very complex terminology in the databases. But usually, you shard by the key ID, which is, in this case, customer ID. And then you split up, depending on how big is your cluster. And then you have smaller set of clusters behind the scenes instead of having the largest host or largest instances of the implementation that's going to serve your database traffic. So also, there is another component called, we call it the Topo, but it's a topology server. It's a distributed key value store. And usually, it's implementations that we have is HCD, console or zookeeper. So these are also other open source utilities that you can integrate into Vitesse with the topology manager. And then topology is required for keeping this information about, OK, where is the shard is? Where is this schema sits? And then Vitesse knows that information. It exchange that information with the topology server. And then it actually makes it serving. So the key value store is another data store, of course. Why are we keeping that? Because these are known and proven technologies to keep this type of information. They keep this type of data. So they are redundantly served within the same data center or other data centers that is distributed. So there is another component in the Vitesse architecture. It's called the VTCTLD, which actually controls the topology in overall. So you have multiple components that controlling the architecture. But basically, it allows this operation of the tablets and the topology server keeping a consistent state of things how things are. So it sounds a little bit complex, but it's pretty straightforward when we come to that. So Vitesse knows what's happening with your schemas, shards, and clusters, including the server roles. When we say a server role, I mentioned about behaving the primary and the replicas. So some of the replicas are read-only. Some of the replicas are for serving for other purposes. Then you can actually set those readable or writable flags, and then Vitesse will know what to do about those. So if you look at it in summary, Vitesse's control plane includes a proxy server, a backup and recovery operations. It does an integrated failover. It can use the third-party tool by another open-source tool like Orchestrator. It does the sharding. Of course, that's one of the strengths of it. But it also comes with an advanced replication called Vreplication or VStream. So what that means is you can migrate data within or outside of the Vitesse cluster using the Vreplication technologies. This is like binary logging and streaming, and then it's actually applying to correct nodes. So why this is important for Vitesse? It is because of the bullet point about it. It's a sharding scheme because normally if you shard, it's you're stuck with that sharding. And then when you start serving traffic off of that, those sharding methodology, you can't actually change that with Vitesse. You can. You can do the resharding. Let's say your key change, your schema change, your application has changed, and you can actually reshard and then change. And maybe you actually scale for 16 clusters and you wanna do 32 clusters because your business is booming. You can actually do this live with a very small like split second failover using Vitesse. So you serve the traffic, you reshard while applying the changes to the new shard. And then you say, okay, cut over. It'll cut over with a minimal effect to the application. May or may not even notice that. So you can also do an online DDL management. This is very hot topic in the database world because when you do a locking operation, then your replicas get behind and then you have other issues. And we're talking about very large implementations like YouTube, GitHub and other places. So these are even more problematic. So Vitesse can actually help you overcome these obstacles. And there's more. So in a picture, just to remind everyone and hopefully we're doing very good on time to show you. So we have an application server that's pointing to a load balancer and then load balancer points to VT gates. And that's actually serving sharded or uncharted clusters. In the meantime, Vitesse actually owns a topology server and topo server and then VTCTLD component to do the cluster management. So this is a summary of Vitesse architecture. Again, this is completely open source. All these components on the right-hand side over here, you can actually see the code in GitHub. And again, this code is owned by CNCF basically. And then you can read what's actually behind the scenes. So I'm stoked about that. Support backend databases. We do support MySQL. Vitesse is very MySQL-centric implementation. We can say that clearly. And adopters are very MySQL focused shops. So MySQL 5.7, 8.0 are supported. MariaDB were support until 10.3. And we don't have extensive experience or user-based in MariaDB just as a site. There are no implementations pointing Vitesse into Postgres. But it's not on the roadmap for this year. Maybe it will come depending on the contributions coming up from that, those communities. It may be a possibility, but at this point that is not the case. So we're gonna talk about a little bit very briefly about the use cases. So when I have a Vitesse, do I actually have this chart? No, you don't have the actual chart. You can still do uncharted implementation. And if you think you will, you will get some sort of a scaling issues in the future that will prepare you for scaling. And so management of MySQL topology, yes. If you put it behind Vitesse, Vitesse does its own management with the VT tablets, topology, it knows where things are. It gives you other tooling, other command line tools to do, let's say you want to do re-parenting. Normally you have to do like change master to and then type in commands, find the coordinates of the master and then fail over to that and cut over the application. This all of that, you can contain it with a simple command with maybe simple shortcut within Vitesse world. So because Vitesse knows which one is a primary, which one is a replica and the primary is no good or you wanna do a maintenance on it, you wanna assign one of the replicas as a primary on that cluster. You can give one command just with their tablet ID and it'll be done. So Vitesse also is very open source friendly as an open source tool. We mentioned about backup and recovery. So extra backup is online hot backup utility very known by the Percona toolkit. It's part of the Percona toolkit and it's supported by Vitesse. So large databases having to backup and restore and implement it. It will be a very wise thing to do. PT online schema change again is a Percona toolkit utility to do the online schema changes and GitHub online schema transfers is a ghost utility by GitHub. These are all already built into Vitesse. So you actually can just set the DDL strategy and then run it. It'll basically drive these open source utilities along with the Vitesse operation. So see the other one is an orchestrator. That's a high availability and a failover cluster management utility. VTALK, we call it is still in progress. It's experimental. It works. I have a talk in Percona live in May 12th and 13th if I'm not mistaken by the date and then there's going to be some representation of that also. So we talked about online schema change utilities but also there is a way to do this in migration style within the Vitesse. So we are very excited about this technology because this V replication can actually make schema changes while you're serving the data and then you can flip over to that schema when you're ready. So there's a link over here. I will share the slides. So do some reading about if you think you have a large cluster and you will hit some scalability issues and how do I do online schema changes? We test maybe your option to help over there. So the other thing is VTALK. It's an experimental. There's a development ongoing but the orchestrator itself is an amazing tool. If you haven't heard about it managing as an SRE or a DBA it's a very de facto utility for topology management and a high availability solution. So it has smart settings and it can failover if it detects lags or other flags and it's useful. So we are actually planning to integrate more into this to the Vitesse. So who uses Vitesse? I mentioned, I happen to mention GitHub already but one of our early adopter is Slack. As you know, Slack is very popular and Slack needed to scale. During the pandemic they have grown extremely and they are like at the time of this slide maybe it was 99.9% or they migrated completely serving all traffic using Vitesse. So you think about Slack implementation. Every customer ID needs to behave its own space and then your scaling, you know that's a very good example. There's a square, it's an online transaction. There's Pinterest, there's GitHub HubSpots. There's more adopters in that. Some of them are very large shops and some of them are going to be growing into expecting an exponential growth in the coming months or years. So that is the case over here. All right, so we are doing good on time. So I want to touch base on data on Kubernetes. So every DBA including myself maybe like when the Kubernetes came or the cloud came while the cloud is gonna add latency on it then the containers came while the containers aren't consistent data stores and they're not persistent. They're not meant to for serving production traffic. I remember reading, you know it was when Docker came out on the Docker's homepage do not use this in production and then now it's Kubernetes and the Kubernetes community is growing probably faster than anything else and data on Kubernetes is doable. So I am here to say it is doable and it's also growing community. There are other graduated projects. Check out the CNCF doing Kubernetes, data on Kubernetes actually. So who needs the data on Kubernetes? So if you're like what I'm hearing from the community and the prospects or the clients that we have today and in the past like whoever actually already migrated into microservices containers on premise or in the cloud. So this is, they are already becoming a Kubernetes shop and they want to keep it Kubernetes aside by side with their data. So that actually makes sense. But how do we do that? So in MySQL in Kubernetes itself is if you look at outside of the box MySQL wasn't designed for this type of operation because it's a very consistent asset data store. So you actually, MySQL internally actually keeps a very consistent data and it serves the data if only it's consistent. And so MySQL provides high availability and works with persons in storage. It does backup and recovery. So you can do, you can all orchestrate this in Kubernetes using with MySQL. But with tests on Kubernetes actually predates the Kubernetes. So this is an interesting fact over here that the release of Vitesse because this all born in Google and the release of Vitesse was, you know, and initial release of Kubernetes came so by nature Vitesse is actually very Kubernetes friendly implementation from day one even, you know, T minus day before day one. And the mindset of the framework, the skeleton, the code set code base is actually a Kubernetes friendly. So, well, how do I run Vitesse on Kubernetes if that's my next question, right? You could either build your own because it's a go product, right? You can compile and embed it into your Kubernetes orchestration. Initially, we've heard a lot of the hand charts. There are still shops using hand charts. I don't have any personal opinion against hand charts but there's a caveat using hand charts because they're very specific to individual implementation. So when we first implemented hand charts for Vitesse even for testing, it quickly became obsolete. It became outdated very quickly. So if you were to do hand charts your own, Vitesse will still work in Kubernetes. But what I think is the best option is the operator. So Vitesse has its own open source operator by plan scale and that is the best place to start with. So what other MySQL implementations are doing for the Kubernetes, there's a Parcona implementation. This is not included with test but that's more extra DB cluster implementation. It's a consistent cluster, keeping multiple replicas consistent way. That's an extra DB. I don't know if you ever heard about it. There's a press labs implementation of the MySQL and there's a Vitesse operator and there are some others and more others are coming. If you look at the operators, operators world are the key for success in Kubernetes. And I also have Vitesse operator for Kubernetes blog post. And that is a good way if you're interested in Kubernetes, if you're interested in operators and you want to try some data source like MySQL and Vitesse. And this is a good example of representation and that's what I thought of giving an example over here because if I were to run this, we won't have enough time for it. So where do I get information about Vitesse? So we have Vitesse IO and there's like lots of docs, there are examples getting started pages. There's a contributor guide if you want to contribute for the Vitesse project. And we have a Vitesse Slack and that is the best place to ask questions specifically about Vitesse, your experience if you run into issues, understanding any issues because we have a maintainers in the Slack and watching this space. And then we get help around the community about the Vitesse. And thank you very much and my Twitter handle is over here. I'm also on GitHub, LinkedIn and that was my presentation about Vitesse. Hopefully we did good on time. Yeah, yeah, we are suddenly on time. Wow, that was an awesome presentation. Thanks a lot. Okay, and I'm glad you also added some useful links on the slides as well. So definitely we'll definitely share the slides if it pleases you. So share the slides with the attendees immediately after the session. So yeah, this is the time for Q&A. If you have any questions, please feel free to put it out there on the chat section. If you're streaming live, feel free to also ask your questions on Twitter. Chats as well, yeah, let's give you a minute and see if we get any questions from attendees. I think we have none. Okay, well, thank you very much for organizing and inviting us over and I appreciate all the time you put in and I appreciate all the great work that you did this community days in Africa. Hopefully I'll get to see you in Africa someday. Oh yeah, yeah, that would be amazing. After the pandemic, all right? Of course, of course, yeah, thanks a lot for coming. All right, thank you very much, I appreciate it. Yeah, see you some other time.