Matty: [00:00:00] The nice way of saying it is, you know, you and I have had storied careers, which is a nice way of saying we are getting old, you know, and we’ve seen some shit. It’s time for Arrested DevOps, the podcast that helps you achieve understanding, develop good practices, and operate your team and organization for maximum DevOps awesomeness. I’m Matty Stratton. We are going to be digging into data again because we just can’t get enough of that around here. But you’re going to have to wait for just one second so we can hear from our lovely sponsors. Let’s talk about one of the most exciting events in the DevOps community, DevOps World 2023. If you’re someone who’s passionate about learning, networking, and staying up to date on the latest trends, then attending DevOps World is an absolute must. So what can you expect from DevOps World? The list is endless. First off, get ready to hear from some of the most inspiring and innovative speakers in the industry. The sessions will cover everything from AI automation, cloud-native architecture, security and risk management, to continuous delivery. And the best part is that DevOps World Tour 2023 is coming to 5 cities across the globe: New York City area, Chicago, Silicon Valley, Singapore, and London. Find a city near you and register today at arresteddevops.com/devopsworld. Thanks to our sponsor Gliffy, the leading diagramming solution for teams using Atlassian products like Jira and Confluence. Drag and drop shapes to quickly build a diagram capturing anything from code structure to a simple concept. You can start your free evaluation by visiting gliffy.com/arrestedevops and signing up via the Atlassian Marketplace. That’s gliffy.com/arresteddevops. Get started today. So Uffizzi is a platform for platform teams. You can stand up your developer platform in minutes, not months. What I like about Uffizzi is that it gives platform teams control and dev teams autonomy. It’s Kubernetes native and extensible. So you can customize it with tooling that meets your team’s evolving requirements. And these clusters, they spin up fast, like super fast. Out of the box, Uffizzi combines a great dev experience, secure multi-tenancy, and cost efficiency. But try it out for yourself at Uffizzi.com. Download their CLI and you can spin up your first sandbox cluster in under a minute on their free starter tier. That’s uffizzi.com, uffizzi.com. I am really looking forward to this conversation we’re about to have. I have a guest joining me who was on our show. I was looking back and it was almost 10 years ago, so it was December of 2014, and we were talking about databases and especially talking about how the principles of DevOps and continuous delivery and all these wonderful things, and how do they apply to databases, and are we doing it right? And I’m really pleased to welcome back to the show Grant Fritchie. And Grant, welcome back to ADO. Before we dig into the meat of nostalgia and retrospective, tell our listeners a little bit about yourself, like what you’ve been up to, and then we’re gonna get into this here.
Grant: [00:03:33] Sure, no problem. Well, I’m still with Redgate Software 10 years later, or almost 10 years later, and loving it. Redgate has expanded quite a bit as a company and as an organization. We’ve moved into multi-platform stuff. So I myself personally have moved on into picking up PostgreSQL as a skill set. So I’ve been spending a lot of time learning that. I’ve been— I’ve gone to a few events. I’ve gotten to present PGConf Chicago, or sorry, sorry, PGDay Chicago and PGDay Med in Malta, which was pretty cool. But other than that, it’s kind of, I’m kind of dull. I’ve just been, I’m doing more database automation, database DevOps. So that’s, I, I, I love the topic. I’ve been doing it for a long time and it’s my favorite thing to talk about.
Matty: So I, I’ll put a link into the show notes for the last time we had when Grant was, was with us and the episode is called The database, the elephant in the room. And again, we, we, this was, this was December 8th, 2014. And, and we had, had Grant on and I’m looking at the show notes and it just says, if software is eating the world, then data is the maître d’. And I don’t even know who wrote that. And maybe it was me, maybe it was, I’m going to blame Trevor for that one. But we said, how do we, you know, we started doing this and I, I, I didn’t listen to the show recently and I should have, because ’Cause I’m very curious. And so, it’s gonna be a little bit hard for us to say, well, what’s changed? But honestly, if we put our Wayback Glasses on and we think back to those halcyon days of 2014, when DevOps was a mere maybe 5 years old, and, you know, we’re doing a lot of, we’ve had a bunch of episodes lately and we’re sort of looking back and saying, what’s changed? And did we get it right? And did we not? One of the problems that we talked about, I’m sure, and thinking about that was a lot of this stuff makes sense when you’re thinking about shipping code. A lot of the things when we think about moving the code around, because that is kind of artifacted, right? Like, it’s not continually adjusting. You’re almost— it’s almost immutable, right? Your code is, right? If you think about it, just so we talk about immutable infrastructure where we say we blow it away and we put out new ones, that’s kind of our code. We don’t really do that with data. Data is living and constantly there. And we talked about this a little bit, had an episode a while ago with Francesco Tiziot. You know, we talked about data, and that was one of our things, like, it’s constantly moving. And we think about rollbacks and all those things that are real easy. And I’m thinking, you know, we had this conversation about continuous delivery, and now we look about today, and we think about things like Kubernetes and orchestration and all this, you know, kind of places, and they all work real well until we start talking about data, and then it gets hard, right? Like, how many places are like, oh, it’s cool, we’ll just do a bunch of K8s here and blah, blah, blah. And you’re like, well, what about the data? And they’re like, that’s somebody else’s problem. So maybe that’s sort of a thing. Like, what do you feel like you’ve seen get better and worse maybe in the last ways when we think about data and DevOps?
Grant: [00:06:29] Well, I think, I mean, I think the really interesting thing is 10 years ago, I had to explain to every data person what DevOps was. And just the very concept of, well, no, you can actually automate your deployments. And people would just look at me like I had problems more severe than I actually have, and God knows I have my own. But, and now, you know, you don’t have to talk about or explain what DevOps is anymore. Everybody is aware of it now, which is, it’s a huge move, right? It really is. It’s whether or not people are implementing it. And the fact is, is that there’s still a very healthy chunk of the populace out there that are not implementing any kind of DevOps-style approach with data management, they at least know what it is now. So it’s no longer this, okay, well, let me first educate you in what the heck I’m talking about, and then I can start educating you on how to do it. Now we can just start talking about how to do it, which makes a huge difference. At the very least, it cuts a half hour off of my presentation time where I’m spending all this time explaining what DevOps is, why it’s important, why you should be using it. All of that has gone away. And now I can just start focusing on, all right, here’s how we can get it done. And, you know, and focus on the people, focus on the process, you know, and then focus on products. I mean, and I always like to think of it that way. I mean, Donovan Brown’s definition has always worked really well for me. People, process, products, and, you know, in that order. So, you know, it’s great now because we don’t have to explain everything.
Matty: [00:08:10] And when we think about one of the core things, and I did an episode recorded recently with Adam Jacob, and we kind of were doing it as another little retrospective looking back about what we got right and got wrong in DevOps. But we said, you know, again, sort of the key part being about collaboration, and we know we maybe over-rotated on culture. We’ll talk about that. Go listen to the other episode from Adam if you want to hear about that one. But again, we’re talking about this collaboration, and like, I know one of the things like data and people people running data systems and the part of the organization was one that was always kind of in its own little place. And I’m wondering if we got better about that. And I’m gonna give kind of an interesting example that’s very relevant. I was at the AWS Summit in New York and for listeners may or may not know if you’re paying attention to where I work. So I work for a company called Aiven now and we’re a data platform. So I was talking to a lot of people at an AWS Summit about a data platform where they could do hosted Kafka and Postgres and all these kinds of things. Of course, you know, people who are attending AWS Summit are from all walks of tech life. And there was a fair number of folks who were infrastructure folks that I would look at as being similar to my background, who we started talking about, okay, well, how are you handling things like your operational database? If it’s MySQL or Postgres, are you doing event streaming with Kafka? You know, open source, oh, that’s a different team, right? You know, so I’m interested, like, kind of in your case, like, are we getting better at that? Or are we, as we go into this, like, platform engineer world that people are wanting to talk about, like, Where’s the data coming into all this, like organizationally? Like, did we, are we still just siloed that way or maybe getting worse?
Grant: [00:09:44] No, I mean, my, my understanding of how it goes and, and from, this is from talking to lots of people around the world is we’re getting better. We’re getting way better. The, I think the interesting thing though, is that there, there is becoming a very distinct split. And the, the split is, is, is companies who are sort of building and embracing DevOps as a fundamental operational thing of how they work, and companies who are adding DevOps later. And the ones who are kind of fundamentally building DevOps as part of everything that they do just from the start, interestingly enough, they incorporate data and data management directly into their DevOps processes, and they’ve been really good at it. And I’ve talked to a whole bunch of people who I’m kind of jealous of, you know, the how great their environment is and the way that they’re incorporating everything. But interestingly enough is, is that there’s terms that are going away and one of the terms going away is database administrator. And I had someone who was saying, oh, you know, I work in databases, I do this, I do that. And I’m like, oh, you’re a DBA? And they’re like, oh no, I’m a data engineer. And I’m like, oh, okay, cool. You know, well, who handles the backups? Oh, that’s my problem. Who handles availability? That’s my problem. Well, are you doing query tuning? Yeah, I’m doing query tuning. Sounds a lot like you’re doing a DBA’s job. Oh, no, no, no, don’t say that. I am a data engineer. I’m like, okay, cool, you’re a data engineer. But funny enough, I’ve seen that from multiple people now that there’s, well, you know, I’m not a DBA. And it’s like, okay, well, what do you do? Well, I’m doing administration on databases. You know what I mean?
Matty: [00:11:24] I was gonna say, I feel like we had this conversation in other parts of DevOps and everything. And even if we flash back, I know, on the show back in the 2014 days, I would say things about like, I’m seeing an awful lot of job posts that are, you know, for a DevOps engineer. And I’m like, these sure look like what my job was as a system administrator. But then likewise, as we’ve talked about on the show before and said, you know, Pete Cheslock is being a big fan of this and saying, you know, we see that, you know, someone who changed, whose title goes from system administrator or operations person to DevOps engineer, it’s like a 30% pay bump. So we’re like, yeah, go get paid, right?
Grant: So hey, good.
Matty: You know, we will call you a database engineer, if that helps you get your bag. And, and again, if that’s a little bit— even if the job is very similar, it’s still evolving, you know. Maybe there is a way of leaving some of the baggage behind, even if it still contains a lot of that same other work, but with even more moving forward.
Grant: Yeah, well, and honestly, if, if, if changing the title just, you know, I mean, if most of the work is still the same but you’re changing the title and that helps you incorporate better into a team Change the title, for crying out loud. I mean, it, you know, I was a DBA for a long time, but also I was a database developer for a long time. Now, what did I do as a database developer? I was a DBA. It’s just they had, they had decided that they wanted to reorient a lot of our terminology. And so I was a database developer for a while. Okay. You know, I kind of don’t care as long as I’m getting the paycheck and as long as we’re doing the work that needs to get done to support the organization. Cool, right? My specialty is data management and, you know, high availability and query tuning and, you know, and then obviously automation, automation, automation. But I don’t care what my title is. I much more care about the work. And so, you know, it’s cool. But I think that split is really interesting because if, you know, just changing the wording a little bit allows people to, you know, embrace one another and bring them into the team, cool, let’s do that.
Matty: [00:13:26] So, think about that organizationally, and just, I wonder, have things changed? Are there ways that we reason about the technology of data that have, you know, we talk about tools influencing culture and culture influencing tools, you know, and as we’ve moved, you know, in other areas to, you know, about where containerization and sort of orchestration and things like Kubernetes and that changes the way that we reason about how we build and think about applications. What’s really kind of been some of the things that either have changed or need to change that will make us be able to be more nimble and more able to scale it these ways? Or are there places we’re still kind of like held back because we still reason about the world in a certain way?
Grant: I think, I mean, honestly, I mean, I am a very positive person in general, but I’m gonna be a bit of a negative Nelly on this one. We are still struggling. The concept of data and data management, especially when we start talking about automation, the one issue that’s always been prevalent, and we already talked a little bit about it, is the fact that data has to persist. You know, we can’t simply toss the database and put a new one in. Because there’s stuff in it that we want to keep. And that one aspect is still stepping on people embracing data and data management as part of DevOps because it’s hard, right? It’s the hard part of data management is the fact that we have to keep the database around, that sure, we can do a deployment, but we have to do a deployment in a way that it doesn’t take the server down. What do you mean we can’t take the server down for 3 hours? Well, you know, we’re getting paid as long as that thing is up and we’re not getting paid as long as it’s down. So you want to get paid, let’s keep it up. And that issue really reflects badly on the data management people because we haven’t communicated well enough to the dev teams what we need in order to support them better and do what they want us to do, which is move fast, you know, And I don’t want to say break stuff, but because we don’t want to break things in the database.
Matty: [00:15:42] I still probably don’t want to break things anyway. I think we’re over, I think we’re over move fast and break things. I mean, well, most of us are. I don’t think, I don’t think Elon is. I think he’s, he’s moving very fast and breaking a lot of Twitter, but yeah. Well, I mean, the rest of us have, we don’t want to break things anymore, but yeah.
Grant: I don’t object to the moving fast. It’s just breaking stuff is a problem. But, but I don’t think the, I don’t think the DBAs have done a good job of bringing the developers in and letting them know what, what, you know, what it is that we can do to help them. And I think developers are just, I think they look over at it and they go, oh, it’s scruffy and dirty and nasty and I don’t like it. And that’s sort of the end of the discussion. And, you know, I mean, there’s all kinds of jokes. I mean, it constantly comes around. I mean, I just saw some yesterday and it wasn’t from me, it was from other third-party people talking about, you know, data and data management, it’s like being a janitor. You know, I mean, it really is. You’re sweeping up behind the parade and, you know, and the parade’s full of elephants sometimes. There’s a lot to sweep up, but it does feel that way sometimes. But, you know, again, I love the job and it’s so much fun. There’s so many challenges to it. It’s a blast, you know, but, but boy, you can tell on teams that have been bitten by data problems, either, either they’ve, they’ve really embraced this whole automation thing and they’re, you know, oh my God, you know, we’re going to kill it and crush it. 300, or they’re, they’re like, data, what’s that? Never heard of it. And so, you know, it— that breakdown between the two is, is really interesting.
Matty: [00:17:21] If you were thinking— so I guess put on like 2 different kind of hats, because, right, you have kind of 2 different people listening to this. There’s someone who’s, who’s coming from the very core data background and thinking about how to evolve into, or just ways to improve. But if we were someone like— we’ll put that on, like I said, the person that would have come to me at the booth and said, is in the role where it’s like, okay, well, that’s fine. I’m the platform team. I run the Kubernetes here and do all this stuff. And we have a data team that does that. And I don’t do anything with it. Granted, we can talk about like organizationally, that’s probably just not great that you have no knowledge of how your data team works or anything. But I wonder when you’ve seen this, when we think about kind of a more modernized, more, you know, cloud-native approach to the world, like What are some of the, you know, we sort of have a lot of the traditional pieces when we think about operational databases like SQL Server, Postgres, or MySQL and stuff. And then we think about, and I would imagine for the majority of us, especially those of us that come from that like infrastructure, right? Like me, right? This has sort of been my thing, right? I mean, my background is old school sysadmin. You know, I was a Windows Server admin, Linux admin, all those pieces. And data was like, I was aware of it. We had some SQL Server somewhere, we had these things, but I didn’t really know a lot about it and that was fine. And then as I’ve come to work with Ivan and stuff like that, I’m like, oh, there’s all this more to it because we think about streaming, you know, event streaming and things like Kafka and like how do we reason about the different kinds of databases. And I did a little bit of— I’m gonna put a link in the show notes at the Toronto meetup in Toronto a little while ago. My friend Kat Cosgrove and I gave a talk that was the history of databases basically. It was sort of a historical context. We said, let’s sort of walk through how we got here, and that gives us some context and sort of going all the way back to the ’50s and some of those early things and going into the days of web scale and Mongo and those pieces. So, like, what are the things that you think people who are either more core app dev or infrastructure ops person that is like, just knows that there’s a data team and they do that, what are like some of the wild different things that are more than just rows and tables That’s part of data.
Grant: [00:19:24] Well, I think the biggest thing is the fact that we actually really can automate it. I mean, the argument, you can say this to developers and they kind of nod their heads but don’t get it. And you say it to DBAs and they get kind of freaked. Databases are code.
Matty: Just code.
Grant: They’re just code.
Matty: They’re just big code.
Grant: Yeah. I mean, there’s a lot to it, right? And it’s complicated and it’s deep and it’s dark and there’s all kinds of stuff. But I think that’s the one thing that can really shift people’s mentality if you say, look, it’s just code. It’s just code. Now, there are wrinkles to the code. It’s big, so we can’t move a whole lot of it fast. Like, you want self-provisioning for your development databases, we gotta look at either third-party tools or something to be able to make things move quickly, or we gotta give you empty databases, which, granted, aren’t useful. But it’s all code, right? It’s code. It’s all about code. And that’s the one message I would try to get to people, whether you’re a developer, admin, you know, you’re running K8s, I don’t care. The databases are just code and we can be treated the same way as all the other code. We have wrinkles that we do have to take into account. You can’t ignore everything. You can’t say, okay, it’s code. Cool. Now we get to ignore it. Nah. There’s still special stuff, but that special stuff is all about persistence. Other than that, it’s code. I mean, and if you’re setting up availability groups, so you’ve got high availability, cloud or not, you’re setting up multi-platform so that you’re able to support and host across the planet, you’re doing something really cool in Azure, you’re running with Redshift in AWS, I don’t care, it’s all code. Right? It’s all code. And so if you can get that mentality in front of you, then managing this stuff through an automated process becomes a whole lot easier.
Matty: [00:21:19] What do you think is one of the biggest misconceptions that people have out there in the tech world about managing data and dealing with data and what this world looks like?
Grant: Biggest misconception. I was going to say the fact that DBAs are jerks, but we are. So kind of that’s not a misconception. I think the biggest misconception, it is sort of what I just alluded to, but I think the biggest misconception is that you literally can’t automate the database, that everything in the database has to be done manually, that there is no way to actually automate it. And that is just not true. I think it does require a bit more, and I don’t want to say a lot more, but a bit more discipline than automating development does because of the persistence, because of the fact that you’ve got to keep the data. You do have to kind of think through exactly how you’re going to do the automation and what exactly you’re going to automate. But beyond that bit of discipline, it’s fully automatable. You can do this. People do it. There are wildly successful organizations automating the hell out of their data management and database deployments and emulate them, right? You know, spot the people doing good work and then follow along with what they do. I mean, that’s just one of the best things you can do about anything. But it is fully automatable. And I think that is the one big misconception is people say, well, you just can’t automate it. And that’s just not true.
Matty: [00:22:55] So we talked a little bit as well, kind of before we were talking about some events and just sort of different ways things have evolved. And so like you’ve talked about, you know, like being involved in, you know, getting more involved in like the Postgres community and stuff like that. And by the way, I, you know, you were here in Chicago and you didn’t say anything, say hi to me. So I’m mad at you for at least another 20 minutes, but that’s okay. But kind of when you look at, you know, and again, I have a lot of my career at a certain point in my career, you know, was very heavily in the Microsoft and the Windows ecosystem even specifically, because now we’re talking about the Microsoft ecosystem. It could mean all kinds of things, but sure, you know, we’ll talk, you know, hey, Windows, you know, NT, Server 2000, you know, SQL Server, BizTalk, all those. You know, I always, I was thinking about this the other day too. I was remembering when I first started getting involved in some of the more modern DevOps tools and things like that, I was like, how come like they have better names for stuff? I’m like, we have the very like, it is SQL Server, it is Small Business Server, and then it’s called like Kangaroo Hop or whatever, you know, is the project. So For good or for bad. What are, as you’ve sort of been involved in all these other, these other communities, like what, what are some of the interesting differences maybe even in like kind of the SQL Server community versus like the Postgres community? And if there are any, maybe there really aren’t that many.
Grant: [00:24:09] I don’t, I don’t think there are a lot of differences. I mean, I mean, I, I don’t, I’m not, I don’t, I don’t want to say anything bad about anybody.
Matty: Oh yeah. And maybe it’s nuance, right?
Grant: I’m not going to mention a couple of communities that I think are problematic. But the Postgres community, I think, is not problematic. They are, they are wonderful. I’ve— the interactions I’ve been having over the last couple of years as I’ve been digging into the Postgres community has been wonderful. They’ve been very welcoming and kind and lovely, much like the SQL Server community is most of the time. Every once in a while things get ugly, but you know, it’s family. Family has fights.
Matty: That’s how we do it.
Grant: But I think the one big difference I’ve seen from the Postgres community is— and there’s, there’s a bit of a split in the Postgres community. And it’s not radical and it’s not problematic, but it’s there and evident. And that’s the committers and the people doing a lot of the development are very oriented around academics and theory and science. And rightly so, by the way, they’re doing amazing stuff. But there’s everyone else who is consuming this thing going, oh my God, now what do I do? And the science people going, well, figure it out. What’s your problem? This is easy, right? We’ve done the hard work, we’ve done the heavy lifting. We’ve gotten you this neat data management tool with cool arrays and arrays on arrays and, you know, GIST indexes and all that, all that great stuff that Postgres has. We’ve got all this stuff, we’ve given it to you. Now go handle it. And there’s just a lot of people more and more because it’s growing like mad. Who are like going, yeah, but I’m not that smart, please help. And I think that that split in the community needs to be addressed better. Not that there are problems in the Postgres community, there are not, they are wonderful people. But I think that there is a bit of an orientation thing there that is different. And I see that in other communities as well, that there is frequently sort of a split between the people who do stuff and the people who design it. And you really do kind of have to get those 2 groups to kind of get together. It’s similar to some of the issues we used to have with DevOps, with the idea of saying, you know, look, everyone’s involved in this and we all have to get together. We all have to talk. You can’t just say, you know, here’s Peggy, Peggy does DevOps. Now we’re a DevOps company because we’ve got Peggy. There’s more to it than Peggy. And I think that I’m seeing that in the communities too, that there’s just still that bit of a split. Between, between the people who are making it and the people who have to use it. And so that’s, that’s the one thing I would bring up.
Matty: [00:26:52] It’s interesting too, because you kind of think maybe, maybe, maybe or not, but when you think even historically with, with Postgres, and I mean, the, the pedigree of Postgres is very, very long, very, very old, you know, that people might not be as aware of. Well, I mean, it all started in the ’70s, right? Like Michael Stonebraker and Eugene Wong with Ingress, right? You know, so like, so much foundational stuff became Postgres and became everything else, but it came from Berkeley, right? It was pro— it was student programmer stuff they were building to help to go to that. And, you know, yeah, Postgres was— came, you know, was like in the ’90s, right? You think about this, and that was, that was 20 years after, you know, Wong and Stonebraker were creating Ingres in 1973, right? And, and so when you have this sort of pedigree versus, again, something like SQL Server as an example, or one could make the argument with Oracle or something like where they start more business forward, you know, you sort of build your ecosystem a little bit differently. And so like the DNA of the way it’s reasoned about, and I know I have a colleague on my team who’s been doing, you know, was very involved in a lot of educational, you know, kind of collegiate educational things in the ’70s and places like that. And when I was working on this historical talk and he was like, oh, let me tell you about how, like when Postgres came out, and not like in that snarky way, but just like, there was this point, and this was— and it was how important these things became to, to thinking about it, and from universities and uni and things like that. And, and I wonder where that, that connection comes in. We know that, you know, Microsoft and other larger companies are getting— have, and I should say are getting better. It’s been true for decades. But how do you make these things accessible? But they don’t begin their life as academic, right? You know, and so even though folks involved in these communities today were not the ones doing it in 1985 or whatever, but it’s just, it’s sort of in the DNA of where that goes. And it’s interesting too, when you think about this, and this was why when Kat and I did this talk, this historical context, because it’s like a lot of times, and this is why, you know, you, you, I mean, the nice way of saying it is, you know, you and I have had storied careers, which is a nice way of saying we are getting old, you know, and we’ve seen some shit. But like, what we want to do with a lot of this is, you know, and, and, you know, my friend Kat, she’s given talks about config management stuff. The reason we want to give historical context is if you’re starting, and you’re starting, maybe you’ve been doing this work for 15 years, but there’s a lot of why we’re here comes from reasons, right? You know, and, and knowing that whether it’s right or wrong. And so when we think through our storied careers and stuff, and we sort of look at You know, it’s interesting to look at and say like how much of core of what we’re doing today is still, is still inherently based upon the way that data was reasoned about in 1975, right? Like rows and columns, right? Like we still do that. And as much as it like really, you know, like pissed off, you know, Edgar Codd, but that’s another fun thing, by the way. I’m just being a super giant nerd, but like Edgar Codd is basically the, the, the dude who kind of came up with relational databases, and he super hated that we call them rows and columns and tables, and they wanted it much more mathematical. Yeah, yeah, exactly, tuples, right? And it was like tuples, tuples. Yeah, thank, thank goodness that, you know, we, we talk about the way we do. But there’s that, and then we’ve tried a lot of other things. And so when we think about you know, document-oriented databases and all these, you know, pieces. Like, I don’t want to say why don’t they work, because they do. There’s places where they come in. But like, these core bones, like, they’re still there, right? We’re still doing a lot of this stuff the same way. And like, there’s a reason. I think maybe it’s not just inertia.
Grant: [00:30:38] Well, I mean, yeah, it’s, it’s not. I mean, and if you think about it like engineering, I mean, I mean, and granted, software and engineering are not same, right? They are not the same. But if you think about engineering, they are still doing rebar inside of concrete. The Romans did rebar inside of concrete.
Matty: Why?
Grant: Because it works. And so we’re still following a lot of fundamental principles that go back a couple of thousand years, you know. So you take a look at data and, you know, sure, yeah, we’re, we’re still using stuff from the 1970s, Why? Well, because it works. So why would we throw it away? I mean, I get that, you know, I mean, I’m all for new shiny. I mean, you don’t want to see my radio collection, but I am all in favor of new shiny. I love it. I’m behind it. I’m working on a LoRa project so I can gather information, go through the internet, throw it up onto IoT on Azure, And if that’s not new stuff and new shiny stuff, I don’t know what it is. I’m having a blast with it, but I’m going to a relational data storage for it. Why? Well, because the data I’m collecting, I’m not collecting it at volume. So something like Cosmos DB or something wouldn’t make any sense. Mongo, it wouldn’t help me because I’m not collecting at volume. I’m collecting a very limited amount of data and the data I’m collecting, It really does make sense relational, and relational works. I mean, so we’ve got all these foundations, rebar in the walls, right, that work. We’ve done experiments where we throw it all away, and funny enough, the building falls down. It is still back to foundational stuff. I mean, and that’s not throwing rocks at Mongo or any of the other databases. They all serve a real valid purpose.
Matty: [00:32:32] I don’t know if you know this, Grant, I don’t know if you know this, but MongoDB is web scale.
Grant: Is what? Oh, web scale. Yeah, it is web scale, absolutely.
Matty: But yeah, no, there’s, like I said, there’s places for it and there’s use cases. And I think that’s the wonderful thing is having these, because without something like a document store or a NoSQL or whatever we’re calling them, those types of things, we would be trying to do that with a SQL-oriented database and it won’t work very well, right? Like, yeah, yeah. I like—
Grant: I bought this special little tool. So it’s, it’s shaped like a little X and it’s, it’s got little sockets at the end and it’s just for taking off the tip of attachments for antenna. You could not ask for a more specialized tool.
Matty: Yeah.
Grant: If you don’t have that damn thing, it is a pain in the butt to take apart a radio. Same thing with, with Cosmos and some of these other databases. They serve a vital purpose. That’s not to say you still don’t need a hammer and nails, right? Hammer. You know, relational data structures have, have a long history because they’re functional. And so we’re going to keep using them. And because they’re functional, why would— why throw out something that works unless you got something better?
Matty: [00:33:52] And nobody has anything better. No one will ever do anything better, ever. What are you excited about these days, right? Like what’s some cool stuff that’s going on that maybe people don’t know about or should know about, or you wish people would stop talking about? I guess that’s the opposite of that. Let’s start with the cool stuff, then we can talk about—
Grant: I think the cool stuff that I’ve been seeing lately is the level of incorporation of open source everywhere. There was a long time where there were 2 camps. There were the open source camp and then there was the commercial camp. And I lived through that, and I was very much in the commercial camp because that’s where my paycheck was coming from. And so, you know, I wasn’t chasing open-source software a whole lot until about 5, 6 years ago. And then 5 or 6 years ago, I started chasing it because I saw that other people were chasing it. And sure enough, over time, now everyone and everyone— and I say that, I mean it intentionally— AWS, Azure, Microsoft, you know, GCP, everybody has got some open source in their stuff. Everybody’s incorporating open source, everyone’s supporting open source, and everyone’s taking advantage of using open source in whole or in part, right? It’s some people are doing it only a little, some people are doing a lot. But I think that that’s really fascinating because the divide that we used to have It’s either gone or going away rapidly for everyone. Whereas before, you know, that divide was big and huge, and it’s really cool that it’s going away because I missed probably a few opportunities to do some cool stuff because I wasn’t paying attention to open source back, you know, when I was younger. But I think that’s the one cool thing I can say is that, you know, it hasn’t taken over the world and I don’t think it’s going to. I think There’s gonna always be paid software and paid development and all the rest of that stuff because, you know, if the open source tool does what you want, great, but what if it doesn’t? You’ve gotta have enough skill to make all the changes yourself. Not everybody can do that. So, hey, look, here’s Red Hat, they’re helping you with Linux. Here’s Azure, they’ve got Postgres on there, but by the way, they incorporated what’s called Query Store into Postgres on Azure. And so now you’ve got query monitoring above and beyond what you would expect out of the box. So there’s, there’s a lot of reasons why you would be going after these kinds of services in addition to using all these open source tools. So it’s— I think, I think that’s the thing that fascinates me these days is how much that’s just a fundamental for everything we do, whereas before it wasn’t. I mean, and it really wasn’t.
Matty: [00:36:36] What do you think if someone’s like, okay, I, I, again, everyone’s in sort of different places and everything. So if someone is growing their career, they’re saying, I want to like become more specialized, or I want to become better, because the data part is important, right? We were saying it’s, it’s, it’s dismissed, but it’s also so critical. And someone says, okay, I want to focus on some things. Not saying like this is the most important thing to focus on.
Grant: No.
Matty: But what are some areas, some things to reason about, some things to get better at and to learn about?
Grant: Well, I mean, I would start with source control. Well, no, no, that’s not what I meant to say. What I meant to say was I would start with DevOps. Assume automation from the start. That’s, that’s really important. Assume automation from the start. It’s going to make your life easier if you, if you start from the idea that you automate everything. Okay, cool. I’ve got that idea down. Now what do I do? I would think about where your interests lie in terms of skill set. And the way I want to break that down is, is do you enjoy more figuring out why stuff does things or how stuff does things? If you’re more into the why stuff does things, you want to be looking at query tuning and database design and all that fun stuff. If you’re more interested in the how it gets done, You want to be looking at infrastructure, automation within Azure, automation within AWS, Kubernetes, certainly containers. But I would break it down into that why or how so that then you can orient your learning from that point forward. And then after that, well, I mean, you kind of pick your poison, right? Do a search in your area. I’m in Tulsa, Oklahoma. It’s very oil-oriented and there’s certain technologies that are used more than others. And a lot of the open source stuff isn’t used. So if you’re looking for a job here, you probably want to learn SQL Server. Whereas if you were on either of the coasts, I might look at Postgres. That’s probably going to be more of a growing thing. But, you know, it’s just down to get that how and why split in your own head first. And then you can figure out where you want to go from there.
Matty: [00:38:53] Very cool.
Grant: Very cool.
Matty: What are you looking forward to maybe with events or ways of learning or anything in the next year or so? Anything cool people need to know about?
Grant: Oh boy. I’ve submitted for PGConf Europe in Prague and oh man. Oh God, I want to go.
Matty: Have you been to Prague before?
Grant: No, I’ve never been to Prague. I’ve never been to Prague in December so I can skip the Christmas markets.
Matty: So I spoke at DevRelCon in Prague last December, and it was, it was so cool. It was a super cool event, but also just what a, like, really wonderful city. And I didn’t, I didn’t make it to, to the Christmas round. I was really disappointed just from a timing perspective, but a lot of my colleagues and friends who were there were just like, it was super fun and food was great. And so I— so fingers crossed for you.
Grant: Yeah. Oh yeah, well, I’m really excited about the event. I, I want to be at the event. Now I’m more excited about the event than I am about the city, but I’m very excited about the city too. So, I mean, that’s, those are the two immediately coming to mind. But beyond that, I think the, I think the thing I’m seeing a lot of lately is people are starting to try to figure out how to use like some of the AI stuff in anger. And by that, I mean, like productionize it. I don’t mean do bad things with it.
Matty: [00:40:06] Yes.
Grant: I think there, I think there’s some really interesting things coming out and, and I don’t have anything in mind. I don’t have anything in particular. But, but I’m, I’m eyeballing and watching what people are doing and, and you’re starting to see not simply nonsense or, or, you know, hey, we’re going to replace all the screenwriters, you know, and there’s arguments to be made. That might be a good thing, but I’m not sweating that stuff. I’m more interested in how they’re going to productionize it and put it into tooling and methodologies. I think there’s some interesting things going on there. And again, like I don’t have any details, but But, you know, I mean, it’s in the wind and I’m pretty excited about it.
Matty: This is very cool. Any kind of, when we kind of to wrap it up and think about the most important messaging, when we think about reasoning about data now, after looking back from 10 years, what’s like the most key thing you would say you wanna make sure people are thinking about and moving forward with?
Grant: I’m gonna go back to what I said earlier, and that’s that database is code. Right? Treat your database like code. Granted, with all the wrinkles around it, treat your database like code. You’re going to be a happier person at the end of it if you treat your database like code.
Matty: [00:41:14] There we go. Treat your databases like code and hopefully treat them better than the code that I write, because nobody treats that code well because it doesn’t deserve it. This has been super great. I love going down kind of the trip down memory lane and the forward or the future lane and all the things like that. And let’s not wait another 10 years before you’re on the show again. But that said, if you go to arresteddevops.com, you’ll be able to find this episode’s show notes. Go check out arresteddevops.com/itunes. Leave us a review in the iTunes store. That helps other people find the podcast. And yes, I know it’s not called iTunes anymore, but I’m too lazy to change the 301 redirect. You can hunt us down on Spotify, iHeartRadio, Audible, all those places that find and less find podcasts. Can be found. Grant, this has been a real treat. Thanks for joining me today.
Grant: Oh no, thank you for having me. I, I love the opportunity. You put on a great show and it’s, it’s really fun to get to take part. This has been Arrested DevOps, and remember, there is always DevOps in the banana stand.
