Screaming in the Cloud - “Liqui”fying the Database Bottleneck with Robert Reeves

Episode Date: December 16, 2021

About RobertR2 advocates for Liquibase customers and provides technical architecture leadership. Prior to co-founding Datical (now Liquibase), Robert was a Director at the Austin Technology Incubator. Robert co-founded Phurnace Software in 2005. He invented and created the flagship product, Phurnace Deliver, which provides middleware infrastructure management to multiple Fortune 500 companies.Links:Liquibase: https://www.liquibase.comLiquibase Community: https://www.liquibase.orgLiquibase AWS Marketplace: https://aws.amazon.com/marketplace/seller-profile?id=7e70900d-dcb2-4ef6-adab-f64590f4a967Github: https://github.com/liquibaseTwitter: https://twitter.com/liquibase

Hello, and welcome to Screaming in the Cloud, with your host, Chief Cloud Economist at the Duckbill Group, Corey Quinn. This weekly show features conversations with people doing interesting work in the world of cloud, thoughtful commentary on the state of the technical world, and ridiculous titles for which Corey refuses to apologize. This is Screaming in the Cloud. It seems like there's a new security breach every day. Are you confident that an old SSH key or a shared admin account isn't going to come back and bite you?

If not, check out Teleport. Teleport is the easiest, most secure way to access all of your infrastructure. The open source Teleport access plane consolidates everything you need for secure access to your Linux and Windows servers. And I assure you, there is no third option there. Kubernetes clusters, databases, and internal applications like AWS Management Console, Yankins, GitLab, Grafana, Jupyter Notebooks, and more. Teleport's unique approach is not only more secure, it also improves developer productivity. To learn more, visit goteleport.com. And no, that's not me telling you to go away. It is goteleport.com. You know how Git works, right? Sort of. Kind of. Not really.

Please ask someone else. That's all of us. Git is how we build things, and Netlify is one of the best ways I've found to build those things quickly for the web. Netlify's Git-based workflows mean that you don't have to play slap and tickle with integrating arcane nonsense and webhooks, which are themselves about as well understood as Git. Give them a try and see what folks ranging from my fake Twitter for pets startup to global fortune 2000 companies are raving about. If you end up talking to them, because you don't

have to, they get why self-service is important, but if you do, be sure to tell them that I sent you and watch all of the blood drain from their faces instantly. You can find them in the AWS marketplace or at www.netlify.com. N-E-T-L-I-F-Y dot com. Welcome to Screaming in the Cloud. I'm Corey Quinn. This is a promoted episode. What does that mean in practice? Well, it means the company who provides the guest has paid to turn this into a discussion that's much more aligned with the company than it is the individual. Sometimes it works, sometimes it doesn't, but the key part of that story is I get paid. Why am I bringing this up? Because today's guest is someone I met in person at Monktoberfest,

which is the Red Monk Conference in Portland, Maine. One of the only reasons to go to Maine, speaking as someone who grew up there. And I spoke there, I met my guest today, and eventually it turned into this, proving that I am the envy of developer advocates everywhere because now I can directly tie me attending one conference to making a fixed sum of money. And right now they're all screaming and tearing off their headphones and closing this episode. But for those of you who are sticking around, thank you. My guest today is the CTO and co-founder of Liquibase. Please welcome Robert Reeves. Robert, thank you for joining me. And suffering the slings and arrows,

I'm about to hurl directly into your arse as a warning shot. Oh, man. Thanks for having me. Corey, I've been looking forward to this for a while. I love hanging out with you. One of the things I love about the Monctoberfest conference, and frankly, anything that Redmonk gets up to, is forget what's on stage, which is uniformly excellent.

Forget the people at Redmonk who are wonderful, and I aspire to do more work with them in different ways. They're great, but the people that they attract are invariably interesting. They are invariably incredibly diverse in terms of not just demographics, but interests and proclivities. It's just a wonderful group of people. And every time I get the opportunity to spend time with those folks, I do. And I've never once regretted it because I get to meet people like you. Snark and cynicism about sponsoring this nonsense aside, for which I do thank you, you've been a fascinating person to talk to because you're better at a lot of the database-facing things

than I am. So I shortcut to, instead of forming my own opinions, I just skate off of yours in some cases. You're going to get letters now. Well, look, it's occupational hazard, right? Releasing software, it's hard. So you have to learn these platforms and part of it includes the database.

But I tell you, you're spot on about Monctoberfest. I left that conference so motivated, really opened my eyes, certainly injecting empathy into what I do on a day-to-day basis, but it spurred me to action. And there's a lot of programs that we've started at Liquibase that the germination for that seed came from Monctoberfest. And certainly, you know, we were bummed out that it's been canceled two years in a row, but we can't wait to get back and sponsor it. No end of love and affection for that team. They're also really smart and write about 100% of the time. That's the most amazing part is that they have opinions that generally tend to mirror my own, which, you know, confirmation bias, which is awesome, but they almost never get it wrong.

And that is one of the impressive things is when I do it, I'm shooting from the hip, and I already have an apology half-written and ready to go. Whereas when dealing with them, they do research on this, and they don't have the, I'm a loud, abrasive shit poster on Twitter defense to fall back on to defend opinions. And if they do, I've never seen them do it. They're right.

And the fact that I am as aligned with them as I am, you'd think that one of us was cribbing from the other. I assure you that's not the case. But every time Steve O'Grady or Rachel Stevens or Kelly, I forget her last name. My apologies is all Twitter, but she studied medieval history. I remember that. Or James Governor writes something. I'm uniformly looking at this and I feel the sense of dismay and damn it, I should have written this. It's so well written, and it makes such a salient point. I really envy their ability to be so consistently on point. Well, they're the only analysts we pay money to, so we vote with our dollars with that one. Yeah, I'm only an analyst when people have analyst budget. Other than that,

I'm whatever the hell you describe me. So let's talk about that thing you're here to show, you know, that little side project thing you founded under the CTO of. I wasn't super familiar with what Liquibase does until I looked into it and then had this, I got to say, it really pissed me off because I'm looking at it and it's, how did I not know that this existed back when the exact problems that you solve are the things I was careening headlong into? I was actively annoyed. You're also an open source project, which means that you're effectively making all of your money by giving things away and hoping for gratitude to come back on you in the fullness of time, right? Well, yeah, there's two things there, the open

source component, but also where was this when I was struggling with this problem? So for the folks that don't know, what Liquibase does is automate database schema change. So if you need to update a database, don't care what it is, as part of your application deployment, we can help. Instead of writing a ticket or manually executing a SQL script or generating a bunch of docs in a NoSQL database, you can have Liquibase help you out with that. And so I was at a conference years ago at the booth, my booth thing. And a managing director of a very large bank came to me, like, hey, hey, what do you do? And saw what we did and got angry, started yelling at me. Where were you three years ago when I was struggling with this problem, like spitting bad? And I was like, dude, we just started. This was a while ago. It's like, we just started the company two years ago. We got

here as soon as we could. But I struggled with this problem when I was a release manager. And so I've been doing this for years and years and years. I don't even want to talk about how long. Getting bits from dev to test to production. And the database was always, always, always the bottleneck. Whether it was things didn't run the same in test as they did eventually in production, environments weren't in sync. It's just really hard. And we've automated so much stuff. We've

automated application deployment, lowercase a, compiled bits. We're building things with containers. So everything's in that container. It's not a J2EE app anymore. Yay. But we haven't done a damn thing for the database. And what this means is that we have a whole part of our industry, all of our database professionals, that are frankly struggling. I always say we don't sell software at Liquibase. We sell piano recitals, date nights, happy hours, all the stuff you want to do, but you can't because you're stuck dealing with the database. And that's what we do at Liquibase.

Well, you're talking about database people. That's not how I even view it. I would never call myself that for very good reason, because, you know, Route 53 remains the only database I use. But the problem I always had was that, great, I'm doing a deployment. Oh, I'm going to put out some changes to some web servers. Okay, what's my rollback? Well, we have this other commit we can use.

Oh, we're going to be making a database schema change. What's your rollback strategy? Oh, I've updated my resume and made sure that any personal files I had on my work laptop and backed up somewhere else when I immediately leave the company when we can't roll back. Because there's not really going to be a company anymore at that point. It's one of those, everyone sort of holds their breath and winces when it comes to anything that resembles a schema change or an alter table, as we used to call it, because that is the mistakes will show territory. And you can hope and plan for things in pre-prod

environments, but it's always scary. It's always terrifying because production is not like other things. That's why I always call my staging environment theory, because things work in theory, but not in production. So it's how do you avoid the mess of winding up, just creating disasters when you're dealing with the reality of your production environments. So let's back up here. How do you do it? Because it sounds like something people would love to sell me, but doesn't exist.

Well, it's real simple. We have a file. We call it the changelog. And this is a ledger. So databases need to be evolved. You can't drop everything and recreate it from scratch. So you have to apply changes sequentially. And so what Liquibase will do is it connects to the database.

And it says, hey, what version are you? It looks at the change log and will see, eh, there's 10 change sets. That's what components of a change log, we call them change sets. There's 10 change sets in there, and the database is telling me that only five have been executed. Oh, great. Well, I'll execute these other five. Or it asks the database, hey, how many have been executed? And it says 10. And we've got a couple of

meta tables that we have in the database, real simple ANSI SQL compliant, that store the changes that happen to the database. So if it's a net new database, say you're running a Docker container with a database in it on your local machine, it's empty. You would run Liquibase and it says, oh, hey, it's got that new database smell. I can run everything. And so the interesting thing happens when you start pointing it at environments that you haven't updated in a while. So dev and test typically are going to have a lot of releases. And so there's going to be little tiny incremental changes. But when it's time to go to production, Liquibase will catch it up.

And so we speak SQL to the database. If it's a NoSQL database, we'll speak their API and make the changes requested. And that's it. It's very simple in how it works. The real complex stuff is when we go a couple of inches deeper. When we start doing things like, well, reverse engineering of your database. How can I get a changelog of an existing database? Because nobody starts out using Liquibase for a project. You always do it later.

No, no. It's one of those things where when you're doing a project, if it works, it's one of those, great, I'll run a database in some local Docker container or something just to prove that it works. And to-do, fix this later. And yeah, that to-do becomes load-bearing. That's scary. And so, you know, we can help like reverse engineering an entire database schema, no problem. We also have things called quality checks. So sure, you can test your liquid-based change against an empty database. And it will tell you if it's syntactically correct. You'll get an error if you need to fix something. But it doesn't enforce things like corporate standards. Tables start with T underscore.

Do not create a foreign key unless those columns have an ID already applied. And that's what our quality checks does. We used to call it rules, but nobody likes rules, so we call it quality checks now. How do you avoid the trap of enumerating all the bad things you've seen happen? Because at some point, it feels like that's what leads to process ossification at large companies where, oh, we had this bad thing happen once, like a disk filled up. So now we have a check that makes sure that all the disks are at least 20% empty, etc. Great. But you keep stacking those until you have thousands and thousands and thousands of those. And even a one-line code change

then has to pass through so many different tests to validate that this isn't going to cause the failure mode that happened that one time in a unicorn circumstance. How do you avoid the bloat and the creep of stuff like that? Well, let's look at what we've learned

from automated testing. We certainly want more and more tests. Look, DevOps algorithm is, all right, we had a problem here. Or SRE algorithm, I should say. We had a problem here. What happened? What are we going to change in the future

to make sure this doesn't happen? Typically, that involves a new standard. Now, ossification occurs when a person has to enforce that standard. And what we should do is seek to have automation, have the machine do it for us, have the humans come up and identify the problem, find a creative way to look for the issue, and then let the machine enforce it. O Osification happens in large organizations when it's people that are responsible, not the machine.

The machines are great at running these things over and over again, and they're never hung over day after Super Bowl Sunday. Their kid doesn't get sick. They don't get sick. But we want humans to look at the things that we need, that creative energy, that brain power on, and then the rote drudgery, hand that off to the machine. Drudgery seems like sort of a job description for a lot of us who spend time doing operation stuff.

It's drudgery, and it's boring, punctuated by moments of sheer terror. On some level, you're more or less taking some of the adrenaline high of this job away from people. And you know, when it comes to databases, I'm kind of okay with that, as it turns out. Oh, yeah. We want no surprises in database land. And that is why over the past several decades, can I say several decades? It's 1979. Oh, it's many decades. I'm sorry to burst your bubble on that.

Thank you, Corey. Five, being honest. Go ahead. So it has evolved over these many decades where change is the enemy of stability. And so we don't want change. And we want to lock these things down. And our database professionals have become changed from sentinels of data into traffic cops

and TSA. And as we all know, some things slip through this. Sometimes we speed, sometimes things get snuck through TSA. And so what we need to do is create a system where it's not the people that are in charge of that, that we can set these policies and have our database professionals do more valuable things instead of that adrenaline rush of, oh my god, how about we get the rush of solving a problem and saving the company millions of dollars? How about that rush? How about the rush of taking our old busted on-prem databases and figure out a way to scale these up in the cloud and also provide quick dev and test environments for developer and test friends. These are exciting things. These are more fun, I would argue.

You have a list of reference customers on your website that are awesome. In fact, we share a reference customer in the form of Ticketmaster. And I don't think that they will get too upset if I mention that based upon my work with them, at no point was I left with the impression that they played fast and loose with databases. This was something that they take very seriously, because for any company that, you know, sells tickets to things, you kind of need an authoritative record of who's bought what, or suddenly you don't really have a ticket-selling business anymore. You also reference customers in the form of UPS, which is important. Banks in a variety of different places. Yeah, this is stuff that

matters. And you support, from the looks of it, every database people can name except for Route 53. You've got RDS, you've got Redshift, you've got Postgresquille, you've got Oracle, Snowflake, Google's Cloud Spanner, lest people think that it winds up being just something from a legacy perspective, Cassandra, et cetera, et cetera, et cetera, CockroachDB. I could go on because you have multiple pages of these things. SAP HANA, whatever the hell that's supposed to be, YugaByte, and so on and so forth. And it's like some of these, like, now you're just making up animals territory. Well, that goes back to open source. You know, you were talking about that earlier. There is no way in hell we could have brought out support for all these database platforms

without us being open source. That is where the community aligns their goals and works to accommodate. So I'll give you an example. So case in point, recently, let me see, YugaByte, CockroachDB, AWS Redshift, and Google Cloud Spanner. So these are four folks that reached out to us and said either, A, hey, we want Liquibase to support our database, or B, we want you to improve the support that's already there. And so we have what we call, which is a super creative name, the Liquibase test harness, which is just genius because it's an automated way of running a whole suite of tests against

an arbitrary database. And that helped us partner with these database vendors very quickly and to identify gaps. And so there's certain things that AWS Redshift, certain objects that AWS Redshift doesn't support for all the right reasons, because it's data warehouse. Okay, great. And so we didn't have to run those tests, but there were other tests that we had to run. So we created new tests for them. They actually wrote some of those tests. Our friends at YugoBuy, CockroachDB, Cloud Spanner, they wrote these extensions and they came to us and partnered with us. The only way this works is with open source, by being open, by being transparent,

and aligning what we want out of life. And so what our friends, our database friends wanted, was they wanted more tooling for their platform. We wanted to support their platform. So by teaming up, we help the most important person, the most important person, and that's the customer. That's it. It was not about, oh, money and all this other stuff. It was, this makes our customers' lives easier. So let's do it. Oh, no brainer. There's something to be said for making people's lives easier. I do want to talk about that open source versus commercial divide. If I Google Liquibase, which, you know, I don't know how typing addresses in browsers works anymore because search engines are so fast. I just type in Liquibase. The first thing it spits me out to is Liquibase.org, which is the community open source version. And there's a link there to the

pro paid version and whatnot. And I was just scrolling idly through the comparison chart to see, oh, so community is just code for shitty and you're holding back advanced features, but it really doesn't look that way. What's the deal here? Oh, no. So Liquibase open source project started in 2006. And Liquibase, the company, the commercial entity, started after that, 2012, 2014, first deal. And so Nathan Voxlin started this. And Nathan was struggling. He was working at a company, and he had to have his application, of course, early 2000s, J2AA, support SQL Server and Oracle, and he was

struggling with it. And so he open sourced it and added more and more databases, certainly as open source databases grew, obviously added those, MySQL, Postgres. But we're never going to undo that stuff. There's rollback for free in Liquibase. We're not going to be jerks and either A, pull features out or B, even worse, make Steven O'Grady's life awful by changing the license so he has to write about it. He loves writing about open source license changes. We're Apache 2.0, and so you can do whatever you want with it. And we believe that the things that make sense for a paying customer, which is database-specific objects, that makes sense. But liquid-based community, the open source stuff, that is built so you can go to any database. So if you have a changelog that runs against Oracle, it should be able to run against SQL Server or MySQL or Postgres, as long as you don't use platform-specific

data types and those sorts of things. And so that's what community is about. Community is about being able to support any database with the same changelog. Pro is about helping you get to that next level of DevOps nirvana, of reaching those four metrics that Dr. Forsgren tells us are really important. Oh, yes.

You can argue with Nicole Forsgren, but then you're wrong. So why would you ever do that? Yeah. It's a sucker's bet. Don't do it. There's a reason why she's got a PhD in CS. She has been a recurring guest on this show, and I only wish she would come back more often. You and I are fun to talk to. Don't get me wrong. We want unbridled intellect that is couched in just a scintillating wit and someone who's great to talk to. Sorry, we're both outclassed. Yeah, you get entertained with us. You learn with her.

Exactly. And you're still entertained while doing it is the best part. That's the difference between community and pro. Look, at the end of the day, if you're an individual developer just trying to solve a problem and get done and away from the computer and go spend time with your friends and family, yeah, go use liquid-based community. If it's something that you think can improve the rest of the organization by teaming up and taking advantage of the collaboration features? Yeah, sure, let us know. We're happy to help. Now, if people wanted to become an attorney,

but law school was too expensive, out of reach, too much time, etc., but they did have a Twitter account, very often they'll find that they can scratch that itch by arguing online about open source licenses. So I want to be very clear, because those people are odious when they email me, that you are licensed under the Apache license. That is a bona fide OSI-approved open source license. It is not everyone except big cloud companies or service providers, which basically are people dancing around.

They mean Amazon. So let's be clear. One, are you worried about Amazon launching a competitive service with a dumb name? And or have you really been validated as a product if AWS hasn't attempted and failed to launch a competitor? Well, I mean, we do have a very large corporation that has embedded Liquibase into one of their flagship products, and that is Oracle. They have embedded Liquibase into SQL CL. We're tickled pink because that means that, one, yes, it does validate Liquibase is the

right way to do it, but it also means more people are getting help. Now, for Oracle users, if you're just an Oracle shop, great, have fun. We think it's a great solution. But there's not a lot of those. And so we believe that if you have Liquibase, whether it's open source or the pro version, then you're going to be able to support all the databases. And I think that's more important than being tied to a single cloud. Also, this is just my opinion, and take it for what it's worth.

But if Amazon wanted to do this, well, they're not the only game in town. So somebody else is going to want to do it too. And I would argue, even with Amazon's backing that Liquibase is a little stronger brand than anything they would come out with. This episode is sponsored by our friends at Oracle HeatWave, a new high-performance query accelerator for the Oracle MySQL database service,

although I insist on calling it MySquirrel. While MySquirrel has long been the world's most popular open-source database, shifting from transacting to analytics required way too much overhead and, you know, work. With HeatWave, you can run your OLAP and OLTP, don't ask me to pronounce those acronyms ever again, workloads directly from your MySquirrel database and eliminate the time-consuming data movement and integration work while also performing 1,100 times faster than Amazon Aurora and two and a half times faster than Amazon Redshift at a third the cost. My thanks again to Oracle Cloud for sponsoring this ridiculous nonsense. So I want to

call out, though, that on some level they have already competed with you, because one of databases that you do not support is DynamoDB. Let's ignore the Route 53 snub, because, okay. But the reason behind that, having worked with it myself, is that, oh, how do you do a schema change in DynamoDB? The answer is

that you don't, because it doesn't do schemas, For one, it is schemaless, which is kind of the point of it, as well as, oh, you want to change the primary or the partition or the sort key index? Great. You need a new table because those things are immutable. So they've solved this Gordian knot, just like Alexander the Great did, by cutting through it. Like, oh, how do you wind up doing this? You don't do this. The end. And that is certainly an approach, but there are scenarios where those were first. NoSQL is not an acceptable answer for some workloads. I know, Rick Horahan is going to yell at me for that as soon as he hears me, but okay. But there are some for which a relational database is kind of a thing and you

need that. So Dynamo isn't fit for everything, but there are other workloads where, okay, I'm going to just switch over. I'm going to basically dump all the data and add it to a new table. I can't necessarily afford to do that with anything less than maybe, you know, 20 milliseconds of downtime between table one and table two, and there are obnoxious and difficult ways to do it. But for everything else, you do kind of need to make alter table changes from time to time as you go through the build and release process. Yeah. Well, we certainly have plans for DynamoDB support. We are working our way through all the NoSQLs, started with Mongo. Well, back that out a second then for me, because there's something I'm clearly not grasping,

because to my understanding, DynamoDB is schemaless. You can put whatever you want into various arbitrary fields. How would Liquibase work with something like that? Well, that's something I struggled with. I had the same question like, dude, really? We're a schema change tool. Why would we work with a schema-less database? And so what happened was a soon-to-be friend of ours in Europe had reached out to me and said, I built an extension for MongoDB in Liquibase. Can we open source this? And can y'all take care of the care and feeding of this? And I said, absolutely.

What does it do? And so I looked at it and it turns out that it focuses on the collections and generating data for test. So you're right about schema lists because these are just documents and we're not going to go through every single document and change the structure. We're just going to have the application create a new doc in the new format. Maybe there's a conversion logic built into the app. Who knows? But it's the database professionals that have to apply these collections, you know, indices. That's what they call them in MongoLan, collections. And so being able to apply these across all environments,

dev, test, production, and have consistency, that's important. Now, what was really interesting is that this came from MasterCard. So this engineer had a consulting business and worked for MasterCard. And they had a problem. They said, hey, can you fix this with Liquibase? And he said, sure, no problem. And he built it. So that's why if you go to the MongoDB, the Liquibase-MongoDB repository in our Liquibase org, you'll see that MasterCard has the copyright on all that code.

Still Apache 2.0. But for me, that was the validation we needed to start expanding to other things, Dynamo, Couch. For a lot of contributors, there's a contributor license process you can go through to sign copyright. For everything else, there's MasterCard. Yeah, well, we don't do that. Look, we certainly have a code of conduct with our community, but we don't have a signing copyright and that kind of stuff because that's baked into Apache 2.0. So why would I want to take somebody's ability to get credit and magical internet points and increase their rep by taking that away? That's just rude. The problem I keep smacking myself into is just looking at how the entire database space across

the board goes. It feels like it's built on lock-in, it's built on, it is super finicky to work with, and it generally feels like, okay, great, you take something like Postgresquille or whatever it is you want to run your database on. Yeah, you could theoretically move it a bunch of other places, but moving databases is really hard. Back when I was at my last real job, quote unquote, years ago, we were a little late to the game. We migrated the entire site from EC2 Classic into a VPC. And the biggest pain in the ass with all of that

was the RDS instance, because we had to quiesce the database so it would stop taking writes. We would then snapshot it, shut it down, and then restore a new database from that RDS snapshot. How long does it take? At least in those days, that is left as an experiment for the reader. So we booked a four-hour maintenance window under the fear that it would not be enough. It completed in 45 minutes. So, okay, there's that. Sparked the thing up and everything else

was tested and good to go. And yay, okay. It took a tremendous amount of planning, a tremendous amount of work, and that wasn't moving it very far. It is the only time I've done a late night deploy where not a single thing went wrong. Until I was on the way home and the Uber driver sideswiped a city vehicle. So there we go.

That's the one. But everything else was flawless on this because we plan these things out. But imagine moving to a different provider. Oh, forget it. Or imagine moving to a different database engine. That's good. Tell another one. Well, those are the problems that we want our database professionals to solve. We do not want them to be like janitors at an elementary school cleaning up developer throw-up with sawdust. The issue that you're describing is a one-time event. This is something that doesn't happen very often.

You need hands on the keyboard. You want people there to look for problems. If you can take these database releases away from those folks and automate them safely, you can have safety and speed. Then that frees up their time to do these other Herculean tasks, these other feats of strength that they're far better at. There is no silver bullet panacea for database issues. All we're trying to do is take about 70% of a DBA's time and free it up to do the fun stuff that you described. There are people that really enjoy that, and we want to free up their time so they can do that. Moving to another platform, going from the data center

to the cloud, these sorts of things. This is what we want a human on. We don't want them updating a column three times in a row because dev couldn't get it right. Let's just give them the keys and make sure they stay in their lane. There's something glorious about being able to do that. I wish that there were more commonly appreciated ways of addressing those pains rather than, oh, we're going to sell you something big and enterprise-y and it's going to add a bunch of process and not work out super well for you. You integrate with existing CICD systems reasonably well, as best I can tell, because the nice thing about CICD, and by nice I mean awful, is that there is no consensus. Every pipeline you see in a release engineering process inherently becomes this beautiful bespoke unicorn. Mm-hmm, yeah.

And we have to. We have to integrate with whatever CICD they have in place. And we do not want customers to just run Liquibase by itself. We want them to integrate it with whatever is driving that application deployment. We're Switzerland when it comes to databases and CICD. And I certainly have my favorite of those, and it's primarily based on

who bought me drinks at the last conference. But we cannot go into somebody's house and start rearranging the furniture. That's just rude. If they're deploying the app a certain way, what we tell that customer is, hey, we're just going to have that CICD tool call Liquibase to update the database. This should be an atomic unit of deployment. And it should be hidden from the person that pushes that shiny button or the automation that does it.

I wish that one day that you could automate all of the button pushing, but the thing that always annoyed me in release engineering was the, oh, and here's where we stopped to have a human press the button. And I get it. That stuff's scary for some folks, but at the same time, it's also, this is the nature of reality. So you're not going to be able to technology your way around people, at least not successfully and not for very long. It's about trust. You have to earn that database professional's trust because if something goes wrong, blaming

Liquibase doesn't go very far. In that company, they're going to want a person who has a badge with a throat to choke. And so I've seen this pattern over and over again. And this happened at our first customer, major, major, big, big, big bank. And this was on the consumer side. They were doing their first production push. And they wanted us ready, not on the call, but ready if there was an issue they needed to escalate and get us to help them out. And so my VP of engineering and me, we took it. Great. Yeah,

VP of engineering, CTO, right on. And so Kevin and I, we stayed home, stayed sober, you know, a lot of places to party in Austin. We fought that temptation. And so we stayed and I'm texting with Kevin back and forth. Did you get a call? No, I didn't get a call. It was Friday night. Saturday rolls around Sunday.

Did you get it? What's going on? Monday, we're like, hey, everything okay? Did you push to the next weekend? They're like, oh no, we did it. It went great. We forgot to tell you. But here's what happened.

The DBAs pushed the Liquibase make it go button. And then they said, uh-oh. What do you mean, uh-oh? They said, well, something went wrong. Well, what went wrong? Well, it was too fast. No way. And so they went wrong? Well, it was too fast. No way. And so they went through the whole thing.

That was my downtime when I was supposed to be compiling. Yeah. So they went through the whole thing to verify every single change set. Okay, so that was weekend one. And then they go to weekend two. They do it the same thing. All right. All right.

Build and trust. By week four, they called a meeting with the release team and they said, hey, process change. We're no longer going to be on these calls. You are going to push the Liquibase button. Now, if you want to integrate it with your CICD, go right ahead, but that's not my problem. Dev or the release team is tier one.

Dev is tier two. We, DBAs, are tier three support, but we'll call you because we'll know something went wrong. And to this day, it's all automated. And so you have to earn trust to get people to give that up. Once they have trust, and it's based on empathy, you have to understand how terrible they are sometimes treated, and to actively take care of them, realize the problems they're struggling with. And when you earn that trust, then, then, and only then will they allow automation. But it's hard, but it's something you got to do. You mentioned something a minute ago that I want to focus on a little bit more closely, specifically that you're in Austin. Seems like that's a popular choice lately. You've got companies that are relocating their headquarters there, presumably for tax purposes. Oracle's

there. Tesla's there. Great. I mean, from my perspective, terrific, because it gets a number of notably annoying CEOs out of my backyard. But what's going on? Why is Austin on this meteoric rise and how to get there? Well, a lot of folks, overnight success, 40 years in the making, I guess. But what a lot of people don't realize is that, one, we had a pretty vibrant tech hub prior to all this. It all started with MCC, Microcomputer Consortium, which in the 80s, we were afraid of the Japanese taking over. And so we decided to get a bunch of companies together and Admiral Bobby Inman, who is director, planted it in Austin. And that's where it started. You certainly have other folks that have a huge impact, obviously Michael Dell, Austin Ventures,

a whole host of folks that have really leaned in on tech in Austin. But it actually started before that. So there was a time where Willie Nelson was in Nashville and was just fed up with RCA Records. They would not release his albums because he wanted to change his sound. And so he had some nice friends at Atlantic Records that said, Willie, we got this. Go to New York, use our studio, cut an album, we'll fix it up. And so he cut an album called Shotgun Willie, famous for having Whiskey River,

which is what he uses to open and close every show. But that album sucked as far as sales. It's a good album. I like it. But it didn't sell except for one place in America, in Austin, Texas. It sold more copies in Austin than anywhere else. And so Willie was like, I need to go check this out. And so he shows up in Austin and sees a bunch of rednecks and hippies hanging out together, really geeking out on music. It was a great vibe. And then he calls, you know, Chris and Waylon and Merle and say, come on down. And so what happened here was a bunch of people really wanted to geek out on this new type of country music, outlaw country. And it started a pattern where people just geek out on stuff they really like. So same thing with Austin Film. You got Robert Rodriguez,

you got Richard Linklater, and Slacker, his first movie. That's why I moved to Austin. And I got a job at Laysa Me, a coffee shop that's closed because it had three scenes in that. There was a whole scene of people that just really wanted to make different types of films. And we see that with software. We see that with film. We see it with fashion. And it just seems that Austin is the place where if you're really into something, you're going to find somebody here that really wants to get into it with you, whether it's board gaming, D&D, noise punk, whatever. And that's really comforting. I think it's the community

that's just welcoming. And I just hope that we can continue that creativity, that sense of community, and that we don't have large corporations that are coming in and just taking from the system. I hope they inject more. I think Oracle's done a really good job. Their new headquarters is gorgeous. They've done some really good things with the city,

doing a land swap. I think it was 40 acres for nine acres. They coughed up 40 for nine, and it was nine acres that city wasn't even using. Great. So I think they're being good citizens. I think Tesla's being pretty cool with building that factory where it is.

I hope more come. I hope they catch what is ever in the water and the breakfast tacos in Austin. I certainly look forward to this pandemic ending. I can come over and find out for myself. I'm looking forward to it. I always enjoyed my time there. I just wish I got to spend more of it.

How many folks from Duckbill Group are in Austin now? One at the moment, Tim Banks. And the challenge, of course, is that if you look across the board, there really aren't that many places that have more than one employee. For example, our operations person, Megan, is here in San Francisco, and so is Jesse DeRose, our manager of cloud economics. But my business partner is in Portland. We have people scattered all over the country. It's kind of fun having a fully distributed company. We started this way back when that was easy, because, all right, travel's easy. We'll just go and visit

whenever we need to. But there's no central office, which I think is sort of the dangerous part of full remote. Because then you have this idea of second-class citizens hanging out in one part of the country. And then they go out to lunch together. And that's where the real decisions get made. And then you get caught up to speed. It definitely fosters a writing culture. Yeah, when we went to remote work, our lease was up. We just didn't renew. And now we have expanded hiring outside of Austin. We have folks in the Ukraine, Poland, Brazil, more and more coming. We even have folks that are moving out of Austin to places like Minnesota and Virginia, moving back home where their family's located. And that is wonderful. But

we are getting together as a company in January. We're also going to, instead of having an office, we're calling it a Liquibase Lounge. So there's a number of retail places that didn't survive. And so we're going to take one of those spots and just make a little hangout place so that people can come in. And we also want to open it up for the community as well. But it's very important. And we learned this from our friends at GitLab and their culture. We've really studied how they do it and how they've

been successful. And it is an awareness of those lunch meetings where the decisions are made. And it is saying, nope, this is great. We've had this conversation. We need to have this conversation again. Let's bring other people in. And that's how we're doing it at Liquibase. And so far, it seems to work. I'm looking forward to seeing what happens once this whole pandemic ends and how things continue to thrive. We're long past due for a startup center that isn't San Francisco.

The whole thing is based on the idea of disruption. Oh, we're disruptive. Yes, we're so disruptive. We've taken a job that can be done from literally anywhere with internet access and created a land crunch in eight square miles located in an earthquake zone. Genius. Simply genius.

It's a shame that we had to have such a tragedy to happen to fix that. Isn't that the truth? It really is. But toothpaste is out of the tube. You ain't putting that back in. But my bet on the next tech hub, Kansas City. That town is cool. It has 100% Google Fiber all throughout. Great university. Kauffman Fellows, I believe, is based there. So VC folks are trained there. I believe so. I hope I'm not wrong with that. I know Kauffman Foundation is

there. But look, there is something happening in that town. And so if you're a buy low, sell high kind of person, come check us out in Austin. I'm not trying to dissuade anybody from moving to Austin. I'm not one of those people. But if the housing prices, you don't like them, check out Kansas City and get that two gig fiber for peanuts. Well, $75 worth of peanuts. Robert, I want to thank you for taking the time to speak with me so extensively about Liquibase, about how awesome RedMonk is,

about Austin and so many other topics. If people want to learn more, where can they find you? Well, I think the best place to find us right now is in AWS Marketplace. So just- Hang on a second. When you say the best place to find us right now is in AWS Marketplace. Hang on a second. When you say the best place for anything being the AWS Marketplace, I'm naturally a little suspicious. Tell me more.

Well, best is, you know, it's... It is a place that is there and people can find you through it. All right, then. I have a list. I have a list. But the first one I'm going to mention is AWS Marketplace. And so that's a really easy way, especially if you're taking advantage of the EDP, Enterprise Discount Program. That's helpful. Burn down those dollars, get a discount,

et cetera, et cetera. Now, of course, you can go to Liquibase.com, download a trial, or you can find us on GitHub, github.com slash Liquibase. Of course, talking smack to us on Twitter is always appreciated. And we will, of course, include links to that in the show notes. Robert Reeves, CTO and co-founder of Liquibase. I'm cloud economist Corey Quinn, and this is Screaming in the Cloud. If you've enjoyed this podcast, please leave a five-star review on your podcast platform of choice, along with an angry comment complaining about how Liquibase

doesn't support your database engine of choice, which will quickly be rendered obsolete by the open source community. If your AWS bill keeps rising and your blood pressure is doing the same, then you need the Duck Bill Group. We help companies fix their AWS bill by making it smaller and less horrifying.

The Duck Bill Group works for you, not AWS. We tailor recommendations to your business and we get to the point. Visit duckbillgroup.com to get started. This has been a humble pod production stay humble