PlanetScale: GitHub for databases or stateless storage in the cloud?

Lilli (00:06): That's our favorite feature, actually. Johannes and I really like to talk about it as traveling back in time. When you think about Harry Potter movies, Hermione has this like a time-traveling device where you can go back.

Andy (00:25): Hello again, this week we're talking to PlanetScale. We had a great discussion with Lilli and Johannes. And it was very, very fun and really, eye-opening.

Marc (00:39): Yeah, there's new things that are happening in the industry all the time, but seeing things like major changes in the way we work with databases after many, many, many years of working with databases. I love to see the enthusiasm of people when they know that they're onto something. Lilli and Johannes were excited about this. The people working on it are excited.

Andy (01:06): Yeah, when Lilli was saying she likes to introduce PlanetScale as a database which is cool. I kind of eye rolled and I go like, "Okay, come on." By the end, I was convinced, I think it's cool too.

Marc (01:17): Fun even. Without any further ado, please tune in to the DevOps Sauna podcast on PlanetScale.

Marc (01:30): Hello, and welcome to DevOps Sauna. My name is Marc, I'll be your host today. As usual, I have my cohort, Andy Allred. Today, it's really exciting. We've got a couple of guests, Lilli and Johannes from PlanetScale.

Johannes (01:46): Hi ho!

Lilli (01:47): Hi!

Marc (01:48): PlanetScale, what is it? This has been something that's been trending lately, we've been really excited about, is it GitHub for databases or stateless storage in the cloud? But I think it's the next great leap for databases. Lilli, Johannes, can you tell us what is PlanetScale?

Lilli (02:06): Sure. I always like to say it's a cool database and then people look really strangely at me. <laughs> And they're like, "What do you mean by cool database?" This is literally something that would never be used together in one sentence. I would really say it's a cool database because it's the first database, at least that comes to my mind that developers actually really like to work with. Because it's developed by people who either have been in the MySQL space for a while or the database space for a while, and they're getting a bit sick of what is around because it just doesn't fit everything else that they're working with, or, and that's the other part of things we all develop. Developers themselves, who, for instance, came from developing GitHub, and working with that and being super surprised that there wasn't anything easier out there to work with databases. It basically combines the possibility to do branching and merging as you do for your code changes-now with databases-and then also giving the possibility to scale almost infinitely. That's the cool part about it. I think the more boring descriptive part is it's a MySQL-based database as a service that we run for you and manage for you.

Marc (03:26): Excellent. I'm not sure that I've heard very many people getting excited about cool databases, except Andy actually. <laughs> I heard that you mentioned GitHub, and there's a connection there. Can you tell us a little bit what is that connection with PlanetScale?

Lilli (03:45): Sure. I can start and maybe Johannes wants to fill in. One connection is we have a lot of people who came over from GitHub, really, and started working on PlanetScale. And the big part, as I mentioned just now is the branching and merging that became very popular with GitHub for code changes, connected to the pull request. And this is something that we've now implemented in the database world as well so that you can do your schema changes with database branching and merging.

Johannes (04:22): Sure. I guess PlanetScale is the tale of at least two former companies. One of those former companies is GitHub, but it was not the first one. Where it really started was at YouTube, after they got acquired from Google in 2010. Our founders of PlanetScale, they were still working at YouTube as site reliability engineers with a task to manage MySQL for YouTube. And during that time after YouTube got bigger and bigger, one single MySQL node didn't cut it anymore, they needed to scale horizontally. And MySQL was originally not designed to do that. They built a horizontal scaling layer on top of MySQL. Initially, this was running (on) bare metal, but after a certain while Google asked them to put this into Borg, the predecessor of Kubernetes. And open source the result as an open-source framework called Vitess. Vitess is the technical foundations of PlanetScale. It's a CNCF project that makes you run MySQL, in Kubernetes, horizontally scalable for up to millions of transactions per seconds, and petabytes of data used by companies like Etsy, Square, GitHub, Roblox, and so on. That's the first company, YouTube, that is the foundations of PlanetScale. It was nice technology battle tested for many years, but still hard to use, not as slick as GitHub from the workflow perspective. And then many folks from GitHub joined, including our new CEO, Sam Lambert, Lilli and myself to have the same user experience, which you have in ordinary DevOps tools in the database world as well, which means branching merging, reverting changes, bisecting, and all the good stuff.

Marc (06:10): Interesting, I know we're going to talk a lot about scaling, but something that came to mind was, this isn't just for big companies, and big databases.

Johannes (06:19): No, it's not. We also wanted to copy this idea of GitHub and many other developer tools that there should be a free tier. Anybody who would like to start with a database, that is just a megabyte large or even smaller can just do this for free on PlanetScale. And then we make sure that if it's growing to no matter what limits your business or hobby project is up to, we will just transparently provide the necessary resources to make that work so that if you are a startup, for instance, you don't have to wait until a certain point in your technology and market fit before you adopt a new database. You can just stick with one database and it will grow with you and your ambitions.

Andy (07:04): I was first introduced to this when I was trying to deploy MySQL inside of Kubernetes. I came across Vitess and how it scales inside Kubernetes. And I thought, "Oh, this is really, really cool. I love this. This is so exciting." And then when I was introduced to PlanetScale, I thought, "Oh, this is just like commercial support for Vitess. Yeah, that's cool. I want some, let's get it." But then started talking with you guys and finding out that well, it is all that. And we're adding all this other stuff on top of it. And then I was converted set and agree with Lilli that yeah, this is a really cool database.

Lilli (07:43): Yeah, we did do the test support for quite a while. It's just that we figured out first of all, often it doesn't really serve those somewhat smaller companies that start out and then need to grow into something, but changing your database setup in between is super hard. Migrating to a new database is not really something that you want to do when you're growing and you have other business priorities, so that's one thing. And then the other thing is also even just for big companies, managing Vitess is really, really hard. You need to have experts who can run your Kubernetes cluster. But you also need to have experts who really know what Vitessx is, how to operate it. And then still, there's probably a couple of questions that you're going to have. We really wanted to remove that barrier to working with the technology or being able to access that technology, but not having to have all of the expertise in-house yourself.

Andy (08:44): And then when you can bring in all the other stuff, which PlanetScale has, which we'll talk about soon into this. And then you have it available in this free model up to five gigabytes, I think it was. So then when you're a startup, you really get the cool benefits and you set up the really good workflows with branching and merging and all that good stuff from the beginning, instead of setting up something, getting used to it, putting all your tooling and processes in place, and then trying to shift it while you're running.

Johannes (09:16): Exactly. And there's many features where you will benefit from the very beginning, no matter whether you will ever need to scale, like reviewing schema changes together with your team, or finding out how your queries are performing and why they are performing. Not as great as you might have thought especially with new beginners who were just started in the database world, they often don't really know about indexes, or they set an index. But the index, they set is actually not being used because they, for instance, were mixing up the cardinality or for using combined indexes in the wrong order, so they thought their queries would be efficient, however, they were not. And then PlanetScale Insights, which is also free for our hobby tier chose them, not only how fast queries are performing, but also what kind of indexes are used, and what improvements can be done so that you can optimize your queries from the beginning, even if you're just in the megabytes size of storage, for instance.

Marc (10:23): Would you like to tell us a little more about PlanetScale Insights?

Johannes (10:27): Sure. There's many, many tools in the performance monitoring for databases: SolarWinds, all the APM tools, New Relic data, IDOC, and so on. What most of those have in common is that they instrument the application and find out how long certain queries or calls to Web Services take. With those technologies, you can find out exactly what calls are made and how long they take. But in many cases, you don't find out why they are taking that long. In order to do that, you would need to directly instrument the database. And as we have the MySQL experts, who previously did the same instrumentation, for Git when they were still working at GitHub, we can also find out, for instance, how many rows have been examined to fulfill a certain query, and what kind of indexes have been used and how many rows have been returned. Whether something was inefficient and what can be done in order to make it more efficient. It's basically directly changing the MySQL code to extract the necessary additional metrics and push them into a Kafka chain where we can then analyze them in almost real-time, and provide the results to the users in combination with the schema changes they have done. If you, for instance, figured out that your queries were getting slower than last week, you can directly pinpoint what kind of schema change or application change was responsible for it. Think about it similarly to Git bisect, where if you found a bug, you can find out when it did not happen, and when it started to happen. And then you can drill down and in this interval of changes when exactly the problem occurred the first time. And then you probably don't want to experiment in production, with the changes, in order to see whether your queries are performing better, he would instead create a new feature branch with our data branching feature, copy over the same data as you have in the production database, then run your new queries there, see whether they are performing better. And then after review, merge them back into the main production branch without write-locking any tables doing so. It's the DevOps world from pull requests in GitHub or merge requests in GitLab, applied to databases when until now you only had your main production database and some staging instances which were loosely connected to it, but we're not really on the very same scheme or very same production data. And with insights, you can safely troubleshoot and get information which is not available to external APM tools normally.

Marc (13:21): So, you can test schema changes on different branches merge for the ones you like, and then I suppose then once you're in production, can you revert schema changes?

Lilli (13:31): Yeah, that's like our favorite feature, actually. Johannes and I really like to talk about it as in traveling back in time. When you think about like Harry Potter movies, Hermine has this like time traveling device where you can go back. And then the cool thing about it is, of course, that you can make changes that are still reflected in the future. The way it works is, of course, imagine you've done your schema change, you've dropped a table that you didn't want to drop. And then you're sitting there with cold sweat in your face. And you're thinking like, "Oh, no, what have I done." And actually, it's something that happened to our CEO when he was working at GitHub. He could really feel the pain of that happening to him. And I think it was even in his first weeks or something at GitHub. He was like, "Oh, my God, I'm going to get fired." And he would have really wished to have the opportunity to revert that schema change. And what I find fascinating about it is that in PlanetScale, because we have the web interface, you can even do this with the click of a button. So right now, probably, you would have guessed, I'm not a developer, lifting the secret here, but I can even do the revert for a schema change because we allow you to do that for 30 minutes. That's how we implemented it in PlanetsScale right now. That time can be adjusted if it has to be, but usually, within the first 30 minutes, we figure out whether something went terribly wrong. You click the button, you can record your schema change, but the changes that you've done in between, so if you've written data to your database in the meantime, which of course usually happens because you don't just stall your business for 30 minutes, that data won't be lost.

Marc (15:20): Wow, so if the canary lives for 30 minutes. <laughs>

Andy (15:24): But dropping in production, does anybody ever really do that? I've never done that more than a handful of times.

Johannes (15:35): More than a handful.  <lots of laughs> It doesn't need to be dropping tables in production, it's also dropping columns, or just changing the type of a column, or even adding or removing indexes. These databases are still a fragile thing, like even an ordinary SELECT query can potentially bring down databases. No matter how much you test it, there's no place like production. And the reason why we are limiting it to 30 minutes, some listeners might wonder is that we're actually keeping shadow tables around with the original schema and the original data, and those shadow tables, they are still transparently updated with all the new data that is coming in. So that if you realize your problem, you can basically swap the shadow table with the new table atomically without any downtime. But that also means that during all this time, you have two parallel realities, the old present, and the new present and this just takes a lot of disk space. If you're talking about terabytes of data, you're having terabytes of additional data. That's why we're saying 30 minutes is the default and we're not going there infinitely.

Andy (17:05): And just this idea that you have something running in production, and you just change a column and whatever, the moment the first customer query comes in and changes your data. Now, any ability to revert is seriously diminished. Unless you have something like PlanetScale that you can then go back. These 30 minutes would really save a lot of things, more than just dropping tables.

Johannes (17:28): Absolutely, yeah, dropping tables. It happens, but in most cases, it happens because people didn't even realize its production. The incident Lilli was talking about it at GitHub, we learned our lessons out of this in two ways. One was that whenever you logged in to a production shell, it had a red background, that you knew this is production and not any kind of playground. In PlanetScale, we have a concept for those branches similar to GitHub-protected branches, meaning if you're in a production branch, you cannot even run any DDL statements like dropping tables or alter tables entirely. You're forced to go over a feature branch, test your changes first and then merge them in and then you can still rebind them but it's not possible to issue any direct Data Definition Language changes on top branches similar to protected branches. Yeah, so this exit cannot happen anymore.

Andy (18:17): Cool. We were talking earlier that this is MySQL interface. From the wire, it looks like MySQL, but is there any other guardrails in place around that specific interface?

Johannes (18:40): Yeah, Vitess is this open-source scaling layer running on Kubernetes to make MySQL scale. Under the hood, it's really using MySQL Oracle Community Edition, or whatever MySQL variant you want to use. It's not just the protocol, but also using MySQL, including InnoDB under the hood. However, during all the time at YouTube, but also GitHub and many other companies, I think there's more than 2000 contributors to be tested from open source, we learned about harmful or potentially harmful queries. Whenever there's a query going to MySQL, that, for instance, would give back more than 100.000 rows, or that would join in a very inefficient manner or would run more than 20 seconds, it will, by default, not be even executed, it will just return a warning that this is probably not a good idea. And that helps a lot if somebody from the marketing department or analytics department comes up with a very, very complex SQL query based generated by a tool and wants to run this on a Friday evening, and would affect the production database. You can fine-tune all of those guardrails, like row limits, parallel transactions, or what kind of joint operations are supported. But by default, they are not allowed so that you can't shoot yourself in the foot. That's the design.

Marc (20:20): Hi, it's Marc again. Eficode has been working with GitHub and other partners for a very long time. And we have a great deal of expertise, and we'd love to share it with you. Please have a look at the show notes, and you'll find links to some of our offering. Now back to the episode.

Andy (20:38): What about foreign key constraints?

Johannes (20:40): How often does this come up really, foreign key constraints? <laughs>

Lilli (20:45): Every conversation I feel like we have. I think it's a myth on the internet, that we do not support foreign keys. The reality is that we do support them. It's just that we don't support foreign key constraints. Basically, that is not a problem. The reason why we've very consciously decided or why also, basically, the maintainers of Vitess, have very consciously decided not to allow foreign key constraints is mainly that it's counterproductive to scaling your MySQL setup.

Johannes (21:21): We have seen cases in production where you had just 10 parent records. Think about artists for instance, you just want to delete artists that don't want to be on YouTube anymore. For instance, 10 of them. It looks like an innocent query, just deleting 10 records, what could possibly go wrong. But then there's a foreign key constraint to a cascading delete on all the albums or videos of that artists and then all the comments of that particular artists, which is potentially billions of records. You can do something like delete '*' from artists, by artists equals whatever 'foobar', limit 10 and think you're safe, but it's still triggering by cascading deletes, billions of records to be deleted. And during the time you have all kinds of nasty read and write locks on your database. And it could be that for the next couple of hours or even days, nothing else can effectively running on this database as long as the write locks are still in place. And how to scale this is basically not allowing cascading deletes, but rather marking those records you want to delete with a soft delete and then have background jobs which are for instance, deleting 500 rows per second, for instance. So, to not completely ruin the performance of your database with lock contention.

Johannes (22:45): So, it was a conscious design to do it. There's another reason when we are doing this fancy stuff like rewinding schema changes or doing non-blocking schema changes with those Shadow tables. At the moment, you have more than one table you want to change in the same time, then cascading deletes or foreign key constraints in that regard wouldn't work either because while we are creating those shadow tables, those constraints are not met in this moment for those shadow tables because we gradually build them up so that the main production database branch is not affected. When we're copying data over for new branches or for non-blocking schema changes, we'll always check that the main traffic of the production database gets priority, so we are yielding to production traffic. So those tables are only incrementally built. And while they've been built incrementally, it could be that certain foreign key constraints are not yet satisfied. There's the PlanetScale blog with a lot of expert content on the specific reasons, for instance, from Shlomi Nova who also build database infrastructure at GitHub before. Our recommendation is to read that blog if you want to learn about the nitty-gritty details.

Marc (24:03): Really cool stuff. Are there some new things that are coming about? As the time of recording, it is mid-August. You will probably be hearing this in a few weeks. But what's going on at PlanetScale that you'd like to tell us about or what's coming up next?

Johannes (24:20): One exciting thing which will be launched when this podcast comes out is the ability to interact with our database from JavaScript over the HTTP protocol. That sounds like a given, like why is that something special to just use HTTP for any kind of service. But for databases, it's unique, most of them only support proprietary binary protocols over TCPIP, but not over HTTP. For things like Cloudflare workers for efficient caching, or just for any kind of technology that is gluing other technologies together, HTTP or HTTPS is the way to do this. And databases for a long time didn't play along. We will provide a JavaScript-based library that can be used to directly talk SQL to PlanetScale and with that to MySQL over HTTPS, and you don't have to worry about any binary protocols or middleware layers anymore.

Marc (25:34): Cool, and I think that we spoke in the pregame a little bit about the future database principles. I'd love to hear a bit more about that.

Lilli (25:45): Johannes, do you want to start?

Johannes (25:47): Yeah, I can. There's principles.planetscale.com, where we thought about how a future database should look like. And this is not so much about PlanetScale, as it will be about any other database, and could very well be that there's other databases who implement those things faster, or certain aspects of that faster. But without further ado, it's basically seven principles. I don't want to go through all of them here. But the feature we were just talking about, the ability to use HTTP for addressing our database and not a binary protocol. That is, for instance, the principle number four, interoperable, being consumable by any client. We believe that there's more and more devices in the internet of things that like to talk SQL or like to go to a data store, which only know how to talk in HTTPS, for instance, so it should be consumable by any client. We also believe that was Lilli's main point about being a cool database. It has to be easy to operate and should fit into any DevOps workflow. You should be able to create a new database within seconds. And every developer should be able to create such a feature branch, for instance, just with the CLI, just like any other tool, being able to revert doing canary deployments, copying data around, it can be very complex in the background, but you shouldn't be worried about it. But I guess the difference to other technologies in the DevOps cycle is databases always have to work. There's just one single point of truth, that's the database. And so, no matter what kind of features you add, it still has to be fundamentally reliable, no matter. Features are nice, but you can never trade them for the reliability and consistency of the database. And it should not really matter how much data you put into it. As we said in the beginning, it can be just a couple of megabytes. But let's imagine you get on Hacker News, one product, and somebody likes your software or your service and you double or triple (user base) every single day, then your database should just horizontally scale with you and provide you the intelligent tips, how you can improve your query so that your performance grows with your user base. There's more principles on principles.planetscale.com. That's it in a nutshell.

Andy (28:16): I really like this idea that make the database consumable by any client. You can just use HTTP like REST or Graph API or whatever else, but it's just another HTTP and you have your data available instead of always building some middleware layer in between to cache things. This is really intriguing. 

Johannes (28:39): Our VP of engineering, Nicholas Van Wiggeren, also said that he fundamentally believes that the decision whether a cache is still valid or not, that should go back into the database layer. We built so many caching layers on top of databases and some are great, but I guess the biggest challenge is always knowing when to invalidate data, and the database manages your data. It should know exactly when to do that for every single query or for every single request. Databases just didn't grow as fast as the internet, at least not until now. But once they can horizontally scale and be available anywhere, they should also be the authority knowing when to invalidate a cache and when not. Right? That's another thing we predict that there will be less need for complicated caching architectures on top of database in the future.

Andy (29:39): And we talked about some of the typical GitHub kind of ideas and mentality being brought over to databases, one of the popular ones lately is Dependabot where it just says, "Hey, here's some updates you need for your security and new versions." Is there anything like that for PlanetScale for running your database?

Johannes (29:57): I really much like your idea. When Lilli and I were still working at GitHub, Dependabot was a breakthrough, mostly because of the acceptance, how many of those security fixes were just were just merged. Whereas there has been security tools, which were telling you that you're vulnerable for many, many years. But there's a big difference between an abstract advice, you could fix this and that and you said, "Yeah, thank you, but I'm busy." Or here's an automated pull request that already does what we're suggesting and it's passing the tests. Right now, think about a similar approach for databases where, with insights, for instance, figured out that a query is getting slower and slower and examining more rows or even doing a full table scan. And you could propose an index or reversing some joint condition. Instead of giving some abstract advice to somebody who was not an expert there, just say, "This is the necessary schema change. You can test it out in isolation in a feature branch to even see whether it's giving you the results." You can also connect your application to that feature branch and run all your unit tests and system tests to see whether it introduces any regression, and if everything is green (then) boom, you just press the Merge button and instead of abstract, non-actionable advice, just prove already that the suggestion worked and then merging it. It also allows us to open the PlanetScale platform for partners. Similar to Dependabot, there's a large ecosystem of providers for those vulnerabilities and suggestions. Why not have the same for databases, they could imagine other companies who are just specialized in learning, how to improve certain queries, and then creating those pull requests. Obviously, this only works if you give access to a database or GitHub repositories. But it's making it possible to also benefit from community distributions. That's something very useful. Go ahead.

Andy (32:04): I was just going to say there's a very, very big difference between, you should think about an index and here's an index, would you like to merge it. And then just extending that to a wider ecosystem and community and getting more eyes on the same problem can only just make this even better?

Johannes (32:21): Collaboration for database is not there yet.

Marc (32:24): (for example) Here's three branches with different properties that we've tested. We found which one works the best and that's the one that we're going to merge. 

Johannes (32:31): Yeah, that's true. You can even go for multiple versions. That's the AB testing for performance and with auto-generated suggestions, that's pretty cool. You can also think about cherry-picking certain aspects like you you've seen in another project of your company, that a certain change helped them a lot. And then you just want to benefit from that particular change. So many of those: version control, metaphors are now coming to the database world as well.

Marc (33:02): It's funny we've had databases 50, 60 years now. It feels like this is the greatest feature set that I've seen in quite some time. I wonder why it took us so long to get here, but I'm glad we're here now.

Lilli (33:15): I guess people are just very reserved when it comes to dealing with their data, it's the heart of the business. When we talk about database migrations, for instance, is always that Johannes says it's like a heart transplant that you're putting in, it's very different.

Johannes (33:34): You only want to do it if there's a lot of pain. It's typicall new projects. My colleague Liz says it's 10% of the cases, it's really people who want to start with something new and fresh. And then 90%, the pains are just so big, they can't scale with a single node or couple of nodes anymore, and are forced to, but it's never been fun. And we hope to make it more fun. And we also have features to for instance, import other MySQL databases without any downtime. But still, it's nothing anybody would like to do voluntarily unless it's in completely new project.

Marc (34:10): Okay, it was hard enough to believe when you were talking about a cool database. Now you're talking about a fun database.

Lilli (34:21): I guess you can only find out if you try it.

Marc (34:25): Well, it's hard to resist. From some of the founders of big data and hyper scaling being able to create new databases as a developer in seconds going from community and free tier to managed services that fully scale in the cloud, be easy to operate, trying to be fun and cool for the developer experience. Enabling blue/green and canary and rollback, traveling back in time, I think is where we really start to get over the edge. I think planet skills really got a very interesting offering. Is there anything else that you guys would like to bring up before we close?

Lilli (35:10): I always like to say, since we are the database for developers, we also really want to make sure that we stay that way. Every feedback is appreciated. And we want to make sure that we iterate and that we stay as cool as we think we are at least. If anyone tries it out and thinks were not as cool as we were saying, then please let us know as well because we would love to hear it and we would like to change it.

Johannes (35:38): Many features or feedback from the community like the new feature to talk to our database from JavaScript directly over HTTP, that was basically just a tweet from somebody who was unhappy that he couldn't use Cloudflare workers with PlanetScale. I've rarely seen teams that can come up with new features within one or two weeks of development, but that's also the case because those folks or many of the engineers, they've been working together since five to eight years because they joined from companies like GitHub or YouTube, where they were already working together since many years. It's teams that know each other for that long. New features don't take that long anymore as also the designers joined with them.

Marc (36:24): I just have to give kudos again, it's like telling the story that PlanetScale is giving, essentially, I won't push zero-day delivery, but very fast turnaround from feedback to deliveries, so that other companies can do the same for their customers without the database being the bottleneck. It's like we have video on here, this is a podcast, but everybody's shaking their head up and down. <laughs> Yes, kudos. I'd like to thank again my guests from PlanetScale, Lilli and Johannes.

Lilli (36:57): Thank you so much for having us here. Yeah, exactly.

Marc (37:02): It's really been a joy. As always, my cohort, Andy Alred.

Andy (37:08): Thanks. It's been fun.

Marc (37:11): And before we go, I have two questions for each of you that we've been asking all of our guests. And I'd like to start with, Lilli, I have two questions. The first question is, can you remember back when you were a child, what is the first thing you wanted to be when you grow up?

Lilli (37:28): I can remember. I really, really wanted to be an actress very badly. <laughs>

Marc (37:39): Really cool. The second question is, can you look back in your life, your career and think was there a moment where the path that you're on really crystallized? Or was there a moment where you realized that you needed to change the path you're on?

Lilli (37:52): Yeah. I actually very much had a moment where it became clear to me that I didn't want to do what I studied for because I wanted to be in politics initially. And then eventually, I figured out that's not really going to be it for me because I started working in tech. I'm in sales, first I thought sales is really, really bad. You think of that person selling a car and just really wanting to get rid of it and sell it to you. But when I started in tech, I realized there's so many cool technologies out there and sometimes it's just that you're looking on buying as someone who's looking for a solution. And it's just really hard to figure out what really fits in and so I realized I'm not just like that person who tells you, "Hey, this is amazing. Buy it," but I'm really the person who is listening to you and looking into is this a good match? And that's when I realized, okay, actually sales isn't that bad. And then the second also, technology is evolving so much faster than politics is. It just seemed to be a better fit because it was faster moving.

Marc (39:06): Cool. I think we're all glad that you did as well. Johannes, can you remember the first thing that you wanted to be when you grow up?

Johannes (39:12): Yes, I wanted to drive a red locomotive, so a train and actually drive my grandmother around GDR. They're still telling me that I haven't done this dream yet. one day I have to buy this red locomotive.

Marc (39:30): That's one of the greatest answers I think I've ever heard. you're on this question too, then? Did you crystallize the path that you're on or was there a moment where you realized that you needed to change it?

Johannes (39:41): Yeah, until my early 20s, when I was still studying, my dream was always to become a professor in IT. I was studying, and already writing my bachelor thesis, and wanted to use a new term. I think it was tracker workflow. And my professors gave me the feedback that this term is not established. And there's not enough research papers to just use that term. I would rather use something already established or to do more research on terminology. And during that time, I was just doing an internship at CollabNet, the founders of Subversion. Branching and merging was always part of my career from the beginning, where I had the opportunity to work on SourceForge and TeamForge, and just edit this term tracker workflow into the product. And as this product was used by a couple million users, it just took off. And when I finished my master thesis, it was already an established term. And then I realized it's much easier to go into that open-source ecosystem, do something that is impacting the developer community and create facts as just observing passively the trends or not even trends, but the history of computer science and there I decided, I like to switch to the industry and not staying in academics.

Marc (41:18): Excellent story, thank you. This is Marc, DevOps Sauna, thank our guests again, and we're signing off.

Johannes (41:26): Hi, my name is Johannes Nicolai, I'm working as solutions engineer at PlanetScale, where we have a database with branching and merging capabilities, branching and merging seems to be the motto of my professional career. I started as a marketing intern at CollabNet, the founders of Subversion, and then went into Subversion Merge Tracking. I later decided to move to GitHub, where I was fascinated by the pull requests and all the branching and merging that goes with it. And since a year working for PlanetScale, working mostly with the European customers.

Lilli  (42:05): Hi, I'm Lilli Seyther-Besecke. I work at scale as an account executive for the European region. So basically, that means I'm here for everyone who wants to learn more about PlanetScale and help you in the progress of implementing it and or testing it as well work with us on the long term. I came over from GitHub, where I got very much used to the beautiful DevOps world and everyone who's in it, and I didn't want to leave it. just learnt that PlanetScale works really well together with GitHub as well and figured I'll move on to that, and so cool databases.

Johannes (42:43): It's all about that base! <laughs>

Lilli (48:24): What a closing sentence, Johannes.