WEBVTT 1 00:00:14.599 --> 00:00:18.839 All right, what's going on, y'all? Welcome to another episode of Adventures 2 00:00:18.839 --> 00:00:23.480 in dev Ops. I'm your host for today, Will Button and joining me 3 00:00:23.719 --> 00:00:28.679 for his second attempt, which is always exciting because you know, I wasn't 4 00:00:28.679 --> 00:00:31.480 sure he was going to come back. I actually had a job one time 5 00:00:31.559 --> 00:00:36.039 where at the end of my first day, my boss said, hey, 6 00:00:36.079 --> 00:00:39.679 thanks for showing up. It was great working with you. Hope to see 7 00:00:39.679 --> 00:00:45.200 you tomorrow, but if not, enjoy your new laptop. But welcoming back 8 00:00:45.280 --> 00:00:49.200 to the studio my new co host, Warren. Hey, Warren, what's 9 00:00:49.240 --> 00:00:52.880 going on? Oh? Thanks? Well, you know, I definitely plan 10 00:00:52.960 --> 00:00:58.479 on being here for at least one more session after this. I think i'll 11 00:00:58.479 --> 00:01:03.079 have I think i'll have, you know, beat by maybe a couple of 12 00:01:03.159 --> 00:01:06.480 days. But you know, thanks for welcoming me. Yeah, for sure. 13 00:01:06.599 --> 00:01:11.239 I like that you put a commitment out there, but not a huge 14 00:01:11.239 --> 00:01:14.799 commitment. You're like, I'll be here for at least one more episode and 15 00:01:14.840 --> 00:01:18.920 then we'll reevaluate. You know. I have a whole talk on this, 16 00:01:19.000 --> 00:01:26.760 but I think achievable goals are really important. Also joining us in the studio 17 00:01:26.879 --> 00:01:33.159 today, I'm looking forward to this. I have Mike Bauer's chief architect at 18 00:01:33.400 --> 00:01:40.040 Faircom Corporation, and he he's got quite the background here. We were talking 19 00:01:40.079 --> 00:01:45.680 before I hit the record button. He's actually got a little bit more experienced 20 00:01:45.680 --> 00:01:49.799 in this industry than I do, which is rare when you get to my 21 00:01:49.959 --> 00:01:55.400 age. So I'm excited about that. He works on high performance no SQL, 22 00:01:55.439 --> 00:02:00.359 SQL databases, IoT platforms. He's the author of pro cs s and 23 00:02:00.640 --> 00:02:05.400 HTML design patterns and this is super cool. A member of the i n 24 00:02:05.560 --> 00:02:12.360 C I t S Technical Technical Committee that develops the standards for SEQL and GQUL 25 00:02:12.719 --> 00:02:16.639 the graph Querry language, and that's super cool. And then if we have 26 00:02:16.759 --> 00:02:21.879 time, one thing I do want to get into here, just from looking 27 00:02:21.919 --> 00:02:24.919 at your background. You are the principal architect at the LDS Church, and 28 00:02:24.960 --> 00:02:30.759 I just think that's got to be a super cool, fascinating job where you 29 00:02:30.800 --> 00:02:36.759 get like those two industries melding together. But anyway, rambling aside, welcome 30 00:02:36.800 --> 00:02:40.280 Mike, glad to be here. Yeah, it's it's fun. You guys 31 00:02:40.280 --> 00:02:46.639 are blast already cool. Well, like I tell my wife, if nothing 32 00:02:46.680 --> 00:02:53.879 else, I'm entertaining, No thanks for thanks for being on the show. 33 00:02:53.000 --> 00:02:58.280 So let's talk a little bit about your background. You know, like I 34 00:02:58.280 --> 00:03:02.479 mentioned, you've been doing this for a a minute or two, and you 35 00:03:02.840 --> 00:03:10.439 you appear to have built a lot of your expertise in the domain of databases. 36 00:03:10.719 --> 00:03:14.800 So tell me a little bit about how you got to that point. 37 00:03:15.039 --> 00:03:16.599 Hey, folks, this is Charles Maxwell. I've been talking to whole bunch 38 00:03:16.599 --> 00:03:22.360 of people that want to update their resume and find a better job, and 39 00:03:22.479 --> 00:03:24.159 I figure, well, why not just share my resume. So you if 40 00:03:24.199 --> 00:03:29.919 you go to top endevs dot com slash resume, enter your name and email 41 00:03:29.960 --> 00:03:32.719 address, then you'll get a copy of the resume that I use that I've 42 00:03:32.800 --> 00:03:38.439 used through freelancing through most of my career, as I've kind of refined it 43 00:03:38.479 --> 00:03:42.159 and tweaked it to get me the jobs that I want. Like I said, 44 00:03:42.199 --> 00:03:46.080 topendevs dot com slash resume, we'll get you that and you can just 45 00:03:46.120 --> 00:03:50.000 kind of use the formatting. It comes in word and pages formats and you 46 00:03:50.000 --> 00:03:53.479 can just fill it in from there. Yeah. I started out as a 47 00:03:53.520 --> 00:04:00.280 software developer and did that over twenty years and had a variety of experience is 48 00:04:00.639 --> 00:04:05.960 writing software for consulting firms, and then moved into manufacturing and built software solutions 49 00:04:06.080 --> 00:04:11.759 and integrated factories like in the silicon industry. I wore the buddy suit going 50 00:04:11.759 --> 00:04:15.160 into the fabs, you know, like the Intel commercial they're dancing that was. 51 00:04:15.480 --> 00:04:17.800 I'm not in the commercial, but I was in the I was definitely 52 00:04:17.839 --> 00:04:25.040 in the fabs, integrating these expensive million dollars pieces of equipment and learning all 53 00:04:25.079 --> 00:04:32.319 their protocols. And then from there I moved into working like at Freightliner and 54 00:04:32.480 --> 00:04:38.040 helping them automate their systems. You know the sprinter van that everybody gets and 55 00:04:38.360 --> 00:04:42.800 either rebuilds it so they can do campers out of it, and they're like, 56 00:04:42.800 --> 00:04:46.680 this's the Mercedes van and the Mercedes Freightliner van. That van has a 57 00:04:46.720 --> 00:04:50.879 computer in it. And I wrote the program that the compiler and the system 58 00:04:50.920 --> 00:04:58.160 that programs that whole thing. So that was that was really fun. That's 59 00:04:58.160 --> 00:05:01.959 cool, And that's got to be some interesting constraints there, just knowing that 60 00:05:03.399 --> 00:05:10.399 once that thing leaves the factory, you've got limited options for getting updates or 61 00:05:10.399 --> 00:05:13.839 communication to in front it. Right. Oh yeah, you got to take 62 00:05:13.839 --> 00:05:16.279 it back into the service system and they'll plug it in and then then you 63 00:05:16.319 --> 00:05:21.920 can update it with the new electronic parameters. But that's actually a real computer 64 00:05:23.120 --> 00:05:28.800 with it's completely The engineer that designed it wanted it to be one hundred percent 65 00:05:28.839 --> 00:05:31.319 programmable, which is unusual. Usually you just have these little parameters, turn 66 00:05:31.399 --> 00:05:34.399 on, the heated mirrors, turn on, you know this other feature. 67 00:05:34.879 --> 00:05:40.199 But he wanted it completely programmable, and so I had to write a compiler, 68 00:05:40.360 --> 00:05:45.480 a true compiler that compiles down to buy machine code to program that thing. 69 00:05:46.519 --> 00:05:48.160 That's one of those things that I feel like you'd be able to look 70 00:05:48.199 --> 00:05:51.480 back later and be like that was either a really great idea or that was 71 00:05:51.600 --> 00:05:58.319 a really bad idea. Right, Well, I think the spinner bands still 72 00:05:58.399 --> 00:06:01.399 doing well, so I guess it was a good idea. But my fear 73 00:06:01.600 --> 00:06:05.480 was, you know, I would have a bug in there, and people's 74 00:06:05.519 --> 00:06:09.360 lives would be at risk because you know, if there's a bug, bands 75 00:06:09.399 --> 00:06:14.480 can crash, So that was kind of scary. But no, it's been 76 00:06:14.560 --> 00:06:18.439 really good. There's the vehicle's great. And it was hard the electrical engineers 77 00:06:18.439 --> 00:06:23.000 who were his peers. I was in the meetings with them and they were 78 00:06:23.079 --> 00:06:28.519 criticizing him like crazy because they couldn't understand what he was doing. Because he 79 00:06:28.560 --> 00:06:32.040 made the thing programmable. No one does that. But he wanted flexibility. 80 00:06:32.040 --> 00:06:34.439 He wanted a system that would last forever. That you, of course, 81 00:06:34.480 --> 00:06:39.079 if you're programmable, you can then make it do anything in the future. 82 00:06:39.800 --> 00:06:43.959 And so in the meetings they were killing the project because no one could understand 83 00:06:43.959 --> 00:06:46.360 it. But I was getting what he was saying, and I thought, 84 00:06:46.439 --> 00:06:48.040 I can do this. I can write the competitor to program this thing. 85 00:06:48.680 --> 00:06:53.319 And so he talked to him and I switched my role from building the system 86 00:06:53.360 --> 00:06:59.000 that the web system that would actually send down the electronic parameters. I built 87 00:06:59.000 --> 00:07:00.959 most of that already, and then we switched gears to writing the compiler, 88 00:07:01.000 --> 00:07:03.439 and I spent a year on that and got that going. So yeah, 89 00:07:03.439 --> 00:07:09.160 I think it was good. Beach did talk to Freightliner see if they thought 90 00:07:09.199 --> 00:07:13.920 it it's still good. That's a good question, you know, because they 91 00:07:13.920 --> 00:07:15.319 had to pay another firm to take over when I left, I was a 92 00:07:15.360 --> 00:07:19.720 consultant, and so that firm has to maintain it, so we'll see. 93 00:07:20.399 --> 00:07:28.399 I don't know. But then from there I went to I was watching all 94 00:07:28.519 --> 00:07:32.639 these people that were DBAs making a lot of money at the time, right 95 00:07:32.680 --> 00:07:36.279 back in the two thousand era, the DBAs made more money than developers, 96 00:07:36.759 --> 00:07:42.800 and I was also frustrated that Microsoft had shifted their whole tool set and I 97 00:07:42.800 --> 00:07:46.040 had become an expert in certain tools and they completely pulled us out from under 98 00:07:46.079 --> 00:07:49.399 me, and I was frustrated, and I thought, Okay, more money. 99 00:07:49.680 --> 00:07:54.199 I love databases. I love data. So I kind of decided I 100 00:07:54.240 --> 00:07:57.759 wanted to become an Oracle DBA because they made the most money for sure, 101 00:07:57.800 --> 00:08:03.399 And so then I decided to switch careers and move into that area. And 102 00:08:03.439 --> 00:08:07.920 then is from there that I got employed at the Eldis Church. And I 103 00:08:07.959 --> 00:08:13.800 started out as an Oracle DBA and the person who hired me wanted me to 104 00:08:13.839 --> 00:08:16.360 do that for a little bit and then become a manager of the team, 105 00:08:16.839 --> 00:08:20.439 and I went from and I did that, and then I I was a 106 00:08:20.519 --> 00:08:24.439 dB Oracle DBA for about a year and I managed the Oracle DBA team that 107 00:08:24.519 --> 00:08:30.360 the core team that supported cour teams with twelve engineers, and we supported over 108 00:08:30.480 --> 00:08:35.519 sixty database engineers, so DBAs south through organization, we had on thousands of 109 00:08:35.639 --> 00:08:41.440 databases. And then from there I became the data architect for the entire organization, 110 00:08:41.879 --> 00:08:48.759 which is a multi billion dollar international organization, so it's very large with 111 00:08:50.440 --> 00:08:58.879 thousands of developers. You think the church, but it's it's an international organization 112 00:08:58.000 --> 00:09:03.440 that builds lots of software for its members to do membership like things. Like 113 00:09:03.480 --> 00:09:09.519 one of these systems was an international banking system because the church brings in tithing 114 00:09:09.639 --> 00:09:16.039 from all over the world and they need they it's very important to keep this 115 00:09:16.200 --> 00:09:20.960 money safeguarded. Right there is no international banking system that you can just buy. 116 00:09:22.799 --> 00:09:24.519 You just can't. You know, that doesn't exist, So we had 117 00:09:24.519 --> 00:09:28.000 to build it. So I was the lead on the data side for that 118 00:09:28.080 --> 00:09:33.799 whole project to build a brand new international banking system from the ground up. 119 00:09:33.879 --> 00:09:37.200 So that's the kind of stuff I did there. And while I was there, 120 00:09:37.240 --> 00:09:41.639 I looked into these no SQL databases, so we brought in everyone you 121 00:09:41.679 --> 00:09:46.759 could think of. This was right during the whole revolution between the sequel and 122 00:09:46.799 --> 00:09:48.039 the no sequel, and so I was right in the middle of all that, 123 00:09:48.519 --> 00:09:56.000 and I became an expert in mark Logic, Mango dB Cassandra, and 124 00:09:56.600 --> 00:10:01.759 then we had a bunch of and of course the Oracle sequel server and then 125 00:10:01.799 --> 00:10:05.679 mark Logic, which is an XML database, and so those databases were on 126 00:10:05.679 --> 00:10:11.679 my team, and I was the architect for helping people decide which databases to 127 00:10:11.799 --> 00:10:16.159 choose. So I became really good at each of those technologies and supporting them 128 00:10:16.440 --> 00:10:20.279 as a developer. Right as a developer, why would you choose one of 129 00:10:20.320 --> 00:10:22.559 these databases that I invised the whole you know, Like I said, we 130 00:10:22.600 --> 00:10:26.840 had a several thousand developers, so I was advising them on which database do 131 00:10:26.840 --> 00:10:31.559 you want to choose for your next project? So that was that's where I 132 00:10:31.600 --> 00:10:33.919 became. I went to conferences, I started presenting a conferences, and that's 133 00:10:33.919 --> 00:10:39.039 where Faircom saw me and they go, well, we want you to become 134 00:10:39.080 --> 00:10:45.559 our chief architect because Faircom builds as for forty years has built a database product 135 00:10:46.639 --> 00:10:50.200 and they are the Fundamentally, Faircom is a no SQL database, but it 136 00:10:50.240 --> 00:10:56.879 has SQL capabilities, and they wanted to make their no SQL features more modern. 137 00:10:56.960 --> 00:11:01.440 They had a forty year old ISAM technology which is actually amazingly fast and 138 00:11:01.600 --> 00:11:05.759 efficient but very hard to program, and they wanted to modernize that. So 139 00:11:05.840 --> 00:11:11.240 I was brought on board to turn Faircom dB into a JSON database and a 140 00:11:11.240 --> 00:11:16.559 SQL database and an M database at the same time on the same data. 141 00:11:18.639 --> 00:11:22.240 So you could have three APIs that are completely different on the same data and 142 00:11:22.320 --> 00:11:28.120 give you three advantages like the sequel as universal standardized works with everything, and 143 00:11:28.879 --> 00:11:31.320 the M is super fast, bare metal. A record on disc is a 144 00:11:31.399 --> 00:11:35.720 record in memory in your process, no layers in between. Nothing can beat 145 00:11:35.720 --> 00:11:39.960 the performance of that layer. It's just you have to program it. You 146 00:11:39.000 --> 00:11:43.480 have a lot of programming to do. And then I added a JSON layer, 147 00:11:43.759 --> 00:11:48.679 so you can create with JSON and get data back as JSON and it's 148 00:11:48.679 --> 00:11:50.120 the same data we get in SQL, the same data we get in the 149 00:11:50.320 --> 00:11:54.639 ICM. So that's what for the last five years, that's what I've been 150 00:11:54.639 --> 00:11:58.840 working on, and we're delivering here in March a brand new version that has 151 00:12:00.039 --> 00:12:05.000 full Jason capabilities like Mango or couch Base plus these other two layers, which 152 00:12:05.039 --> 00:12:07.120 the other with couch Base has a SQL plus plus, so they have a 153 00:12:07.120 --> 00:12:13.519 sequel like solution we treat. We have true ant CI squel solution Faircom does 154 00:12:13.600 --> 00:12:18.080 with the Jason with this low level API, so when your queries can't get 155 00:12:18.120 --> 00:12:22.159 fast enough, you can go inside the machine, inside the engine with that 156 00:12:22.240 --> 00:12:28.799 ISM layer and get incredible performance. And I'm not exaggerating when I say faster 157 00:12:28.000 --> 00:12:31.960 than anything else on the market. I got a machine doing a million inserts 158 00:12:33.000 --> 00:12:37.840 per second, and Oracle would and I twoed Oracle database. I built Oracle 159 00:12:37.879 --> 00:12:43.679 exit data replacements at the Ilias Church. I design those and built them faster 160 00:12:43.759 --> 00:12:48.200 than Oracle exit data runs using an Oracle database. So I know what speed 161 00:12:48.240 --> 00:12:50.320 is and how fast the Oracle can go. And this blows Oracle away. 162 00:12:52.440 --> 00:12:54.559 It's just the level of programming you have to do is about four or four 163 00:12:54.799 --> 00:13:01.559 times harder at that ISM layer than sequel is. So the underlying data is 164 00:13:01.600 --> 00:13:07.240 the same in any case, it's just you choose which of those three options 165 00:13:07.279 --> 00:13:11.039 you want to use to get the data exactly. Wow, that's pretty good. 166 00:13:11.080 --> 00:13:16.120 Yeah, so fun. The Jason is. I love the document database 167 00:13:16.200 --> 00:13:20.639 world. You know, I as a developer. I was. I was 168 00:13:20.679 --> 00:13:24.480 a developer first before I became a DBA and before I became a data architect. 169 00:13:24.279 --> 00:13:30.440 So I love building software. I love doing it quickly, and I 170 00:13:30.519 --> 00:13:33.879 know I don't hate. I hate to spend days on the low level stuff 171 00:13:33.919 --> 00:13:37.120 twiddling, you know, finding reading this spec and figuring out okay, well 172 00:13:37.120 --> 00:13:39.960 that bit, oh yeah, that bit's the one that makes it work. 173 00:13:39.000 --> 00:13:43.840 You know. The Jason changes everything. You get up and running in no 174 00:13:43.000 --> 00:13:48.159 time. You're building solutions so fast. It's so simple, and and it 175 00:13:48.200 --> 00:13:52.799 still has the core engine speed of our core ISAM. It's just it has 176 00:13:52.840 --> 00:13:58.039 the translation layer tuned from Jason. So it's fast and it's easy and it's 177 00:13:58.200 --> 00:14:01.919 fun. So yeah, Jason is one of my favorites, so of course, 178 00:14:01.960 --> 00:14:05.679 but I love SQL. Like I'm on the Insights Committee, like you 179 00:14:05.720 --> 00:14:09.120 said, I part of the Equal Standards Group. The sequel is a great 180 00:14:09.200 --> 00:14:13.159 language, and we're enhancing it, like to do more things. And GQUL 181 00:14:13.279 --> 00:14:18.120 is a graph queer language, right, so we're enhancing that and so those 182 00:14:18.159 --> 00:14:24.000 are so I really am a fan of those technologies. But it's not It 183 00:14:24.039 --> 00:14:28.639 shouldn't be one game in town. Your database shouldn't lock you into just I'm 184 00:14:28.639 --> 00:14:31.759 a SQL database, that's all I do. Or I'm a even stranger, 185 00:14:31.799 --> 00:14:35.080 I'm an ISAM database, which is what fair Come has been for until the 186 00:14:35.159 --> 00:14:39.480 last until now. And then of course the Jason is like, well we're 187 00:14:41.120 --> 00:14:43.080 Manga, says well, I'm a Jason database. That's all I really do. 188 00:14:46.159 --> 00:14:48.960 So yeah, you have the best of all worlds for sure. Yeah, 189 00:14:48.000 --> 00:14:54.360 because each one has its own strengths and weaknesses that our gun to one 190 00:14:54.360 --> 00:14:58.919 of those is going to line up with what you're trying to achieve better and 191 00:14:58.559 --> 00:15:05.440 and that just help shore. It has the potential to help you build more 192 00:15:05.519 --> 00:15:11.759 quickly and actually focus on what you're delivering to your customers rather than focusing on 193 00:15:11.879 --> 00:15:18.000 the technology limitations. Yes, you get that scenario where Okay, I want 194 00:15:18.039 --> 00:15:20.039 SQL for most of my stuff because I can write those queries fast, I 195 00:15:20.039 --> 00:15:26.440 can join my data, have flexibility. I know I could achieve any kind 196 00:15:26.480 --> 00:15:30.000 of functionality in sequel, it just may not be super fast. And then 197 00:15:30.039 --> 00:15:33.279 you go, but what about that one query. There are times when I'm 198 00:15:33.279 --> 00:15:37.000 been in an oracle in that big banking system I was talking about. We 199 00:15:37.039 --> 00:15:41.919 had a query that ran for two weeks because they had so many billions and 200 00:15:41.960 --> 00:15:46.679 billions of records turning through them and making reports. The thing ran for two 201 00:15:46.679 --> 00:15:50.840 weeks, and so I had to go in there and I write low level 202 00:15:50.919 --> 00:15:54.519 functions to really tune this and that. We spent weeks tuning that query. 203 00:15:54.639 --> 00:15:58.639 Finally we got it to run in four hours, but it was a massive 204 00:15:58.679 --> 00:16:03.879 effort. And I was thinking about this. If I would have had the 205 00:16:03.960 --> 00:16:07.480 ISAM engine, that would have been that would have been a day of work, 206 00:16:07.840 --> 00:16:11.279 and I would had total control and I would have gotten ten times faster. 207 00:16:11.320 --> 00:16:15.840 It'd have been forty minutes there instead of forty four hours, you know, 208 00:16:15.279 --> 00:16:18.720 from two weeks. So that's that's the kind of when you need to 209 00:16:18.759 --> 00:16:22.879 get under into the engine and say, I know how to make this fast. 210 00:16:22.039 --> 00:16:25.919 I know what I need to do. Just get out of my waist. 211 00:16:25.919 --> 00:16:29.840 Sequel, let me do it. And it's really hard in these SQL 212 00:16:29.919 --> 00:16:33.840 databases to go down there and do that. So yeah, you use the 213 00:16:33.879 --> 00:16:37.440 right tool for the right job on the same data makes a big difference. 214 00:16:38.080 --> 00:16:41.039 What I'm hearing is you left the Oracle world and went to the no sequel 215 00:16:41.080 --> 00:16:48.440 world and it's better. Yes, well but yeah, that's true. But 216 00:16:48.480 --> 00:16:52.080 I the sequel that does things that the no squel can't do, and that's 217 00:16:52.120 --> 00:16:57.840 really important. The nosequel world threw the baby out with the bathwater when they 218 00:16:57.879 --> 00:17:03.879 said we don't need we don't need acid consistency. Well, actually, I 219 00:17:03.919 --> 00:17:07.839 know the president of Mango dB, not the current one but the one previous 220 00:17:07.839 --> 00:17:11.079 one, and you know, we've be met a lot and talked and and 221 00:17:11.079 --> 00:17:14.720 he says, you know, by the way, don't tell anyone. I 222 00:17:14.759 --> 00:17:18.240 guess. I guess I'm telling everyone now because he's gone. But they go, 223 00:17:18.799 --> 00:17:21.720 you know, we know we need to be acid compliant, we know 224 00:17:21.799 --> 00:17:25.160 we need to build. It's just hard, it's really hard, and it 225 00:17:25.279 --> 00:17:30.359 slows us down, and so we're just telling everybody you don't need that stuff. 226 00:17:30.920 --> 00:17:34.799 It's eventually consistent. It's awesome, and it's you know, eventually good 227 00:17:36.920 --> 00:17:41.440 in terms of consistency. But eventual consistency is a euphemism for never consistent. 228 00:17:41.720 --> 00:17:45.519 And if your data is not consistent, that's not a good thing. It 229 00:17:45.519 --> 00:17:48.079 means you write a lot of code to compensate. There are some use cases 230 00:17:48.119 --> 00:17:51.160 where it is good, So don't get me wrong, there are some use 231 00:17:51.200 --> 00:17:55.240 cases eventually consistence perfect. Those are the exceptions. Most of the time you 232 00:17:55.319 --> 00:17:59.759 need consistent data your customers expect when they put something into query it and it 233 00:17:59.799 --> 00:18:03.880 comes back. And Mango wrote all kinds of workarounds to make a lot of 234 00:18:03.920 --> 00:18:07.319 illusions happen. I'm not saying it's a bad product. I'm just saying that 235 00:18:08.119 --> 00:18:11.960 when you need consistency, it's really hard to get it in a no SQL 236 00:18:12.039 --> 00:18:17.119 database. Now fair comes different. We have our engine is at its core 237 00:18:17.240 --> 00:18:21.960 consistent, and then if you want to relax that and go inconsistent, I'm 238 00:18:21.960 --> 00:18:26.319 going to use the less fun term inconsistency of less. Is it eventually consistent, 239 00:18:26.960 --> 00:18:30.119 then you can and then you know your trade offs. So I think 240 00:18:30.119 --> 00:18:32.880 it's good to have an engine that you really can tune to go where you 241 00:18:32.920 --> 00:18:37.279 needed to go. But the other thing about seql that they threw out was 242 00:18:37.839 --> 00:18:41.720 the ad hoc query ability, and the Mango kept a lot of it, 243 00:18:41.759 --> 00:18:45.079 but a lot of other databases threw that one out, and then they said, 244 00:18:45.119 --> 00:18:48.680 well, we don't need joints. Well, that's the dumbest thing I've 245 00:18:48.720 --> 00:18:55.279 ever heard. You can't denormalize your data to put everything that you ever possibly 246 00:18:55.279 --> 00:18:59.720 could to query and put it into one thing. If you did, you'd 247 00:18:59.720 --> 00:19:03.480 have the tired database in one Jason document. You know, let's just make 248 00:19:03.519 --> 00:19:04.920 a whole database on one joy and we could carry the heck out of it 249 00:19:04.960 --> 00:19:07.839 anybody want. Yeah, but that won't perform you to have a whole database 250 00:19:07.920 --> 00:19:14.680 level locks like Mongo used to have, you know it just you need to 251 00:19:14.720 --> 00:19:18.400 break your data into pieces. You need customers to be separate from orders because 252 00:19:18.400 --> 00:19:21.920 customers are not orders, and orders are separate from products because they're not the 253 00:19:22.039 --> 00:19:25.079 same thing, and you need so you need to break them apart as soon 254 00:19:25.119 --> 00:19:27.720 as you break them apart, then you have to join them. And so 255 00:19:27.880 --> 00:19:33.880 SEQL is fantastic. It joins, It has all these great join technologies to 256 00:19:33.960 --> 00:19:37.920 bring the data back together at high speed, and developers have forgotten that. 257 00:19:37.000 --> 00:19:41.759 They forgot because it's under the hood, it's invisible in the sequel engines. 258 00:19:41.200 --> 00:19:44.480 They just think, oh, yeah, you just go loop through and join 259 00:19:44.519 --> 00:19:47.279 it by hand. You really how much code you have to write to do 260 00:19:47.319 --> 00:19:49.680 that? And then it's slow because you don't get the cool algorithms like the 261 00:19:49.759 --> 00:19:53.480 merge join the index, the hash joins the index, joints, all these 262 00:19:53.519 --> 00:19:59.359 really cool technologies that speed things up that sequel engines have built in over forty 263 00:19:59.440 --> 00:20:02.359 years of two those things. Developers don't even know what they are for the 264 00:20:02.400 --> 00:20:07.319 most part, so they don't even realize what they're missing. And so what 265 00:20:07.440 --> 00:20:11.200 you need it You need SQL for those kind of things because it's good at 266 00:20:11.240 --> 00:20:15.359 those, but you need no SQL for other kinds of things like JSON for 267 00:20:15.400 --> 00:20:18.480 the simplicity and development and for the flexibility. You know, Jason is not 268 00:20:18.599 --> 00:20:23.720 so rigid. You can add new things as you go, but there's always 269 00:20:23.759 --> 00:20:27.000 a caveat with you add new things as you go. Let's say you put 270 00:20:27.000 --> 00:20:30.559 them in some documents, some properties in some documents and leave them out of 271 00:20:30.599 --> 00:20:33.920 others, and you run a query. If the property is not there, 272 00:20:34.039 --> 00:20:38.440 the document doesn't show up. And now your queries aren't useful because you're not 273 00:20:38.519 --> 00:20:42.920 getting everything. So you need some schema level protection to Jason and say, 274 00:20:42.960 --> 00:20:45.960 you know, I'm queering on this property. You better have it there and 275 00:20:47.000 --> 00:20:49.359 you better index it, you know, And so you need It's more than 276 00:20:49.559 --> 00:20:55.240 just let's just throw everything in a bit bucket and hope it works, which 277 00:20:55.279 --> 00:21:00.400 is how no SQL markets itself. I can't just do that and expect your 278 00:21:00.440 --> 00:21:03.480 app to work. So that's why I'm a big passionate person. And it's 279 00:21:03.519 --> 00:21:07.519 not because I work at Faircom. I came to work at fair Com because 280 00:21:07.559 --> 00:21:11.720 I'm passionate about you need multiple models. You need when you need consistency, 281 00:21:11.759 --> 00:21:15.319 you need it. When you need less consistency or eventual consistency, you need 282 00:21:15.359 --> 00:21:19.880 it. When you need SQL and joins, you know you can't get with 283 00:21:19.960 --> 00:21:22.880 that. You need that technology, and when you need Jason, you need 284 00:21:22.960 --> 00:21:26.480 flexibility, you need it. So why not have an engine in a model 285 00:21:26.720 --> 00:21:30.759 that can do all of those things? And that's my dream because I wasn't 286 00:21:30.799 --> 00:21:36.160 finding it really anywhere, and when Faircom recruited me five years ago, this 287 00:21:36.240 --> 00:21:37.240 is what I wanted to build. I've been wanting to build my own nose 288 00:21:37.240 --> 00:21:41.160 SQL database for the last fifteen years, and so I went, oh, 289 00:21:41.279 --> 00:21:45.400 this is my dream job. I get to design and build my dream database. 290 00:21:45.920 --> 00:21:51.079 So and releasing the first version of that database, like I said in 291 00:21:51.160 --> 00:21:56.400 March, so I'm super excited about that. I'm thinking to like the cloud 292 00:21:56.440 --> 00:22:02.839 providers and what they're offering as far as no SQL and cloud providers databases and 293 00:22:03.200 --> 00:22:06.519 SQL ones, and I get the sense that the no sqle ones are always 294 00:22:06.680 --> 00:22:08.920 cheaper and easier to get up and running and start integreeting with. And I'm 295 00:22:08.960 --> 00:22:15.200 wondering how much that encourages developers around the board engineering departments, even startup companies 296 00:22:15.240 --> 00:22:22.400 that grow to eventually make them the primary use case for whatever sort of data 297 00:22:22.440 --> 00:22:26.359 they need to store. And I keep thinking, well, maybe if we 298 00:22:26.400 --> 00:22:30.599 want SQL to still have a world like where is the cheap to run, 299 00:22:30.720 --> 00:22:34.119 very very easy to spin up straight away? Like where is that? Yeah? 300 00:22:34.640 --> 00:22:38.519 Yeah, and Oracle is the most complicated, hard to learn technology ever 301 00:22:38.599 --> 00:22:44.359 invented in the universe. I'm not exaggerating that. You know, single servers 302 00:22:44.400 --> 00:22:47.440 easy, you know, Microsoft SQL servers a beautiful easy piece of cake. 303 00:22:47.480 --> 00:22:51.160 And Postcress is kind of in between Oracle and siql server because it's some source 304 00:22:51.200 --> 00:22:55.079 and they have all these PhD students at Berkeley just adding new features and it's 305 00:22:55.119 --> 00:22:57.960 ad hoc and it's not reorganized as well. So Postcress has is harder than 306 00:22:59.000 --> 00:23:03.200 SQL server. Oracle though, is just a nightmare. I've never seen things 307 00:23:03.240 --> 00:23:07.279 so complicated. So, yeah, where is the easy SQL database that you 308 00:23:07.279 --> 00:23:08.559 could just stand up in the cloud? I mean, you could argue SQL 309 00:23:08.599 --> 00:23:14.599 server might be that database, but then what about the no sequel? Right 310 00:23:14.599 --> 00:23:19.240 that the no SQL databases are so specialized with a few exceptions, Like you 311 00:23:19.279 --> 00:23:26.839 take Amazon they have there, they have Dynamo dB, and Dynamo dB is 312 00:23:26.920 --> 00:23:30.920 really a key value store that it's all about the key. You can have 313 00:23:30.279 --> 00:23:37.160 a hierarchical key, and you can if you can segment your key properly, 314 00:23:37.240 --> 00:23:41.799 you can query down inside your key and get subsets of data. You can 315 00:23:41.880 --> 00:23:45.799 have secondary indexes, but that's really just another database under the hood with with 316 00:23:45.880 --> 00:23:49.640 doubling your cost for every secondary index, and you know, by the time 317 00:23:49.680 --> 00:23:52.160 you look at really doing that for real, Like, you know, how 318 00:23:52.160 --> 00:23:56.079 many indexes do I have a real database like a Oracle or single server. 319 00:23:56.359 --> 00:24:00.599 I have thousands of indexes in a real application. Well let's see to imagine 320 00:24:00.599 --> 00:24:03.920 the cost of at a thousand copies of my data in Dynamo dB just to 321 00:24:03.960 --> 00:24:07.599 try to do the same kind of thing. It's just ridiculous. So Dynamo 322 00:24:07.680 --> 00:24:12.680 dB is a good example in my mind, of a specialized database that's good 323 00:24:12.799 --> 00:24:17.640 for certain use cases like use your profiles. If you want to get use 324 00:24:17.640 --> 00:24:21.680 your profile data fast and you want guaranteed response times. I want to look 325 00:24:21.759 --> 00:24:23.759 up Warren, I want to get your data app Boom, it's there. 326 00:24:23.799 --> 00:24:27.680 You know it will boom it's there. So that's Dynamo dB. That's why 327 00:24:27.680 --> 00:24:32.400 they admitted it for their own Amazon dot Com. You know, it's good 328 00:24:32.400 --> 00:24:34.640 for those use cases. But that's not what you build an app on. 329 00:24:36.039 --> 00:24:38.799 I need an app that needs to grow with the company. I have yet 330 00:24:38.880 --> 00:24:41.319 to see an app that said, oh yeah, here's the specs. They're 331 00:24:41.319 --> 00:24:45.319 perfect. You build it in six months, will never change, it will 332 00:24:45.400 --> 00:24:48.680 never evolve it, We'll never have another use case. You know, it's 333 00:24:48.759 --> 00:24:52.000 you know, the exact opposite right, you're tweaking that thing forever and you 334 00:24:52.039 --> 00:24:53.519 go. Then the customer comes back, Oh, I didn't think about this. 335 00:24:55.400 --> 00:24:57.039 How do you get customer? I want to go around a career that 336 00:24:57.079 --> 00:25:00.799 gives me all the customers that made these orders, where the customers were over 337 00:25:00.880 --> 00:25:04.640 forty years old, and the products were oreos, and the orders are made 338 00:25:04.720 --> 00:25:07.119 last month, and you got to join that data together and you got to 339 00:25:07.160 --> 00:25:11.039 filter those three take those three pieces of data and bring it all together in 340 00:25:11.079 --> 00:25:15.599 a filtered way. And you're like, uh, I can't do that in 341 00:25:15.680 --> 00:25:19.519 Dynamo dB. I didn't. I didn't denormalize my data properly to answer that 342 00:25:19.640 --> 00:25:23.799 question. Sorry, let me go copy all my data and then put it 343 00:25:23.839 --> 00:25:29.920 over here and that other specialized database. And now the customers do this. 344 00:25:29.960 --> 00:25:33.200 I teams do this. Like there's a one of our customers built a cloud 345 00:25:33.200 --> 00:25:37.839 solution. They had five database technologies in Amazon that they thought this would be 346 00:25:37.839 --> 00:25:42.160 great. We'll use these specialized databases and we'll build each one. We'll spread 347 00:25:42.200 --> 00:25:47.319 the data across them. The cost of that application is so high no one 348 00:25:47.359 --> 00:25:52.400 will buy it. So their product uses fair Com and it's super fast. 349 00:25:52.799 --> 00:25:56.599 The cloud version with all these databases is way slower, so expensive, no 350 00:25:56.640 --> 00:26:00.039 one will buy it. They're they're looking at putting Faircom in the cloud cloud 351 00:26:00.160 --> 00:26:04.079 just to run their product in the cloud because you don't have the complexity or 352 00:26:04.519 --> 00:26:10.400 they and the costs is so simple and inexpensive. So yeah, I think 353 00:26:10.440 --> 00:26:14.039 it's important to keep all those things in mind when you build a product. 354 00:26:14.119 --> 00:26:17.880 Complexity is your enemy, and that's what the cloud makes you do. It's 355 00:26:18.160 --> 00:26:22.160 complex solutions. I'm not anti cloud. I'm just saying the cloud, the 356 00:26:22.200 --> 00:26:26.079 salesman and the cloud wants you to buy five databases. They want you to 357 00:26:26.119 --> 00:26:30.759 spend up all this because they make a fortune off of you and they don't 358 00:26:30.799 --> 00:26:34.240 and they think that's the way to go because it it's their financial you know, 359 00:26:34.279 --> 00:26:38.279 it makes them rich, so it's great for them. But yeah, 360 00:26:38.319 --> 00:26:44.599 and not only do you have like the cost of maintaining those five instances, 361 00:26:45.079 --> 00:26:51.160 but like the the ETL and the data transformation for replicating that data is not 362 00:26:51.440 --> 00:26:55.039 a trivial task. You know, you have to hold the data, make 363 00:26:55.039 --> 00:26:59.599 sure you're getting the last the correct data and making the right transformations to it, 364 00:26:59.640 --> 00:27:03.599 and then writing it to that new data source and verifying that it's there. 365 00:27:03.720 --> 00:27:10.559 And like the the maintenance and overhead of just keeping that process alive is 366 00:27:10.640 --> 00:27:15.359 a dedicated team. It is just to write it. But then I love 367 00:27:15.400 --> 00:27:18.920 the DevOps angle. The dedicated team to keeping that alive is people are so 368 00:27:19.039 --> 00:27:22.160 expensive. You know, you don't want to hire me to go build your 369 00:27:22.200 --> 00:27:26.000 systems, and as you're gonna put me on a very productive environment because I'm 370 00:27:26.559 --> 00:27:30.640 super expensive. And now you're going to say, now, Mike, you're 371 00:27:30.200 --> 00:27:36.359 you are in DevOps. You need to keep this complex five database system alive. 372 00:27:36.680 --> 00:27:40.160 I think of all the break points. You've got network connections between five 373 00:27:40.200 --> 00:27:44.559 different systems. Each of those systems, typically in the cloud, is sharded, 374 00:27:44.839 --> 00:27:48.920 so it scales horizontally. That means multiple servers in each database that have 375 00:27:48.000 --> 00:27:51.400 to be kept running. And you say, well, Amazona will do all 376 00:27:51.440 --> 00:27:53.240 that for me, Well they do, and they don't. They keep it 377 00:27:53.319 --> 00:27:57.079 up, they patch it for you. But making it work, troubleshooting the 378 00:27:57.079 --> 00:28:02.640 problems in your application across all the systems, oh, DevOps the developer can 379 00:28:02.680 --> 00:28:04.359 do all that. Well. The last thing I want to do is a 380 00:28:04.400 --> 00:28:08.640 developer, is maintain infrastructure. Is I don't want to support that stuff. 381 00:28:10.279 --> 00:28:11.680 I want to throw it over the wall and let those guys do it. 382 00:28:12.039 --> 00:28:17.200 But now nope, DevOps developer, you are on call. You're gonna go 383 00:28:17.279 --> 00:28:18.759 fix it. You're going to go maintain it. And that's we're going to 384 00:28:18.799 --> 00:28:22.759 do that to you because we want you to build a simple, maintainable solution. 385 00:28:22.400 --> 00:28:26.799 That's not possible in the cloud unless you switch your paradigm to something like 386 00:28:26.839 --> 00:28:30.559 a Aircom database where you say I'm going to do I'm going to get a 387 00:28:30.559 --> 00:28:34.480 tool that gives me the it's not just a Swiss Army knie because it gives 388 00:28:34.480 --> 00:28:37.039 you the wrong idea. It's like a bunch of tools. It's like, 389 00:28:38.160 --> 00:28:42.440 we don't even have the right analogy. It's three APIs over the same engine. 390 00:28:44.279 --> 00:28:48.720 It's not like three hammers like cosmocbs is five hammers. There are if 391 00:28:48.839 --> 00:28:53.640 you think you're buying five one one database engine with five APIs. No, 392 00:28:53.839 --> 00:28:56.839 every time you put data in one of those engines, like there're no SEQL 393 00:28:56.880 --> 00:29:02.480 engine or their SEQL engine, it's completely separate engine with the data separate. 394 00:29:02.920 --> 00:29:06.079 It's a marketing gimmick to say it's one database. No, it's a bunch 395 00:29:06.119 --> 00:29:11.000 of different databases or your data spread out all over the place. So having 396 00:29:11.039 --> 00:29:15.559 a real database with multiple APIs on it is. It's sort of like a 397 00:29:15.559 --> 00:29:17.880 Swiss Armony knife. You get the best of all the above, but it's 398 00:29:17.920 --> 00:29:22.519 one engine, which Swiss Armon Knife's not that way, you know. So 399 00:29:22.799 --> 00:29:33.599 it's a bad analogy. But so you know you mentioned earlier that earlier in 400 00:29:33.640 --> 00:29:38.599 your career, like the DBA was the the highest paid member in engineering, 401 00:29:38.599 --> 00:29:42.200 and I remember those days. Everyone wanted to be a DBA and the DBAs 402 00:29:42.759 --> 00:29:49.400 had this almost limitless power. They could stop a production release and its tracks 403 00:29:51.000 --> 00:29:53.200 and not tell you when they're going to release it, and the entire company 404 00:29:53.319 --> 00:29:56.839 was like, oh, well, okay, you know, but they did 405 00:29:56.880 --> 00:30:00.119 a lot of work. You know, they did add value because they they 406 00:30:00.119 --> 00:30:04.119 were answering and designing for a lot of these problems we've been talking about so 407 00:30:04.319 --> 00:30:10.279 far. But when I look around today, I don't see DBAs anymore. 408 00:30:10.319 --> 00:30:11.920 And I know that there are still some out there and some companies still have 409 00:30:12.039 --> 00:30:17.920 them, but for the most part, there are no DBAs, but those 410 00:30:18.000 --> 00:30:23.279 problems still exist. So what are the what are the things that as DevOps 411 00:30:23.279 --> 00:30:29.440 and as software developers, what are the things that we should be thinking about, 412 00:30:29.680 --> 00:30:33.960 or what are like the high level thumb rules we should be using to 413 00:30:33.240 --> 00:30:40.480 avoid making us really wish we had hired DBAs. Yeah, I think that 414 00:30:40.599 --> 00:30:45.960 no sequel moment was really the no DBA movement at this right, I totally 415 00:30:47.000 --> 00:30:51.680 get it because when I was at Freightliner, we had a DBA. This 416 00:30:51.759 --> 00:30:56.960 person she was the how I would say, she's the Nazi DBA. I 417 00:30:56.960 --> 00:30:59.839 mean, it was just a nightmare. You try to go and you give 418 00:30:59.880 --> 00:31:03.240 her your schema and she goes, nope, nope, nope, go fix 419 00:31:03.279 --> 00:31:07.279 it. What do you want when you make it right, I'll approve it. 420 00:31:07.599 --> 00:31:10.440 Well, why do you when you make it right? Like see, 421 00:31:10.519 --> 00:31:11.839 then you go, well, what is right to you? Because right that 422 00:31:11.920 --> 00:31:15.720 because it was right to me, you know, So I go tweak it 423 00:31:15.720 --> 00:31:18.839 again. Finally, at one point I said, you know what, she's 424 00:31:18.880 --> 00:31:22.599 disapproving every single thing I'm doing. And I know I'm not doing a bad 425 00:31:22.680 --> 00:31:25.839 job here. I know the rules of normalization, I know all this stuff, 426 00:31:25.880 --> 00:31:27.720 and I had normalized it beautifully and I also tuned it for performance. 427 00:31:29.079 --> 00:31:33.000 And then she got Then I realized, you know what she is wanting simple. 428 00:31:33.359 --> 00:31:36.799 She wants one bulletproof schema that will work for any kind of data, 429 00:31:36.839 --> 00:31:38.000 anywhere, at any time, and I'm like, I know how to do 430 00:31:38.039 --> 00:31:42.160 this. I'm going to build a database within a database. So I designed 431 00:31:42.240 --> 00:31:47.039 five tables that if you use it just right, you can put any data 432 00:31:47.160 --> 00:31:51.319 without ever calling her again. I showed this model to her and she goes 433 00:31:51.680 --> 00:31:56.200 perfect approved because I would never have to go back to her again, and 434 00:31:56.240 --> 00:31:59.359 she didn't have to talk to me again. And it was like, this 435 00:31:59.480 --> 00:32:02.640 is the but this most horrible thing ever created. This is the anti pattern 436 00:32:02.680 --> 00:32:06.720 of all data designs. So yeah, so this is an example of why 437 00:32:06.759 --> 00:32:12.119 developers like, Okay, this is a dumb DBA creating really bad designs, 438 00:32:12.799 --> 00:32:15.759 fall breaking all the rules because she doesn't know any better, and and it 439 00:32:15.799 --> 00:32:20.279 was really sad. But that's the kind of stuff like I'm free now, 440 00:32:20.519 --> 00:32:22.480 I don't have I'm a developer. I can just build my app. No 441 00:32:22.599 --> 00:32:27.359 DBA to get in my way. But to your point, we lost a 442 00:32:27.400 --> 00:32:30.759 lot of things. For one, the developer lost a DBA to take the 443 00:32:30.799 --> 00:32:37.079 heat because the DBA sits between infrastructure and the developer, and the first thing 444 00:32:37.119 --> 00:32:39.880 an app has a problem, the developer just points to the DBA as your 445 00:32:39.880 --> 00:32:44.079 fault. They always do that, and then DBA points to infrastructure. It's 446 00:32:44.119 --> 00:32:46.960 your fault, right, and so it's usually it is infrastructure's fault because they 447 00:32:47.000 --> 00:32:51.519 have storage goes out or some network thing went wrong. But sometimes it's the 448 00:32:51.599 --> 00:32:53.759 database, and a lot of times it's the app itself, you know. 449 00:32:53.839 --> 00:32:58.400 So it's it could be anywhere, but the DBA is right in the middle. 450 00:32:58.559 --> 00:33:01.160 You take the DBA away to what happens to developers on the hook for 451 00:33:01.200 --> 00:33:06.720 everything except for the infrastructure, and the infrastructure guys are worse than DBAs to 452 00:33:06.759 --> 00:33:08.920 do it. It's not my storage system. I don't have any problems. 453 00:33:09.759 --> 00:33:15.119 I had a one time it was I had. I had so many storage 454 00:33:15.119 --> 00:33:19.319 problems at one place I was working that we had to hire ten thousand dollars 455 00:33:19.359 --> 00:33:22.279 per consultant to come in and run in scripts on the system to prove it 456 00:33:22.359 --> 00:33:25.599 was the storage rate because the storage r egg. I kept saying, no, 457 00:33:25.680 --> 00:33:29.559 it's not my problem. I knew it was the storage. So we 458 00:33:29.680 --> 00:33:32.160 paid ten thousand dollars to prove it was a storage to get the problem fixed, 459 00:33:32.599 --> 00:33:37.200 to get to get our solution built. So yeah, now the developer 460 00:33:37.200 --> 00:33:39.599 has to do that. The developer doesn't even know what I ops are. 461 00:33:40.039 --> 00:33:44.240 The developer doesn't even know what latency is. I mean, how in the 462 00:33:44.279 --> 00:33:47.319 heck are you supposed to get a developer even talk the lingo of the infrastructure 463 00:33:47.359 --> 00:33:51.759 folks to figure out a problem. So you take the DBA away, You're 464 00:33:52.079 --> 00:33:55.640 you're asking for all kinds of headaches and problems. And then there's data. 465 00:33:57.240 --> 00:34:04.240 Data requires some structure, it requires some forethought, and a developer lives in 466 00:34:04.240 --> 00:34:07.079 the now. It says, how can I get this feature out the door 467 00:34:07.200 --> 00:34:09.480 today? How can I crank this code out as fast as possible? Let 468 00:34:09.559 --> 00:34:15.000 QA get the bugs out? You know, Well, that last thing they 469 00:34:15.039 --> 00:34:19.679 want to think about is how do I structure my data to survive the test 470 00:34:19.719 --> 00:34:22.480 of time? Is my application ages I'm going to I'm going to really have 471 00:34:22.519 --> 00:34:27.920 to rewrite everything if I don't design this data well a good DBA. A 472 00:34:27.960 --> 00:34:31.400 good DBA not the one that a head of Fredeliner would come back and say, 473 00:34:31.519 --> 00:34:37.039 how do how do we make it bulletproof? But not overdesigned? You 474 00:34:37.079 --> 00:34:40.400 know, it's that sweet spot. And then most developers don't understand that, 475 00:34:40.599 --> 00:34:44.639 and so they just crank it out, and then they're rewriting and rewriting and 476 00:34:44.639 --> 00:34:49.440 rewriting. Their companies pay a fortune for these developers to rewrite it. Because 477 00:34:49.440 --> 00:34:53.400 they didn't have forethought and so, and Agile just makes that worse because Agile 478 00:34:53.480 --> 00:34:57.039 is like crank the teacher out this week, our sprint's done, get it 479 00:34:57.039 --> 00:35:00.280 out the door, show the demo, show the UI. Absolutely, the 480 00:35:00.400 --> 00:35:04.360 uh I doesn't have the data structure and it so no one sees that or 481 00:35:04.400 --> 00:35:07.760 cares about it. Now, before the Agile people get angry at me, 482 00:35:07.760 --> 00:35:10.039 they would say, well, that's not true agile, and I agree with 483 00:35:10.079 --> 00:35:14.480 them, except for every company I've worked for that does agile, doesn't do 484 00:35:14.559 --> 00:35:15.920 true agile. They do what I just said, crank it out, get 485 00:35:15.920 --> 00:35:22.599 it out the door, show the UI. So there's reality here. Yeah. 486 00:35:22.679 --> 00:35:30.320 I think if the excuse is is always well that's not the pure implementation 487 00:35:30.400 --> 00:35:35.239 we designed, then maybe maybe that's a problem with the purity of your design. 488 00:35:36.239 --> 00:35:42.039 Yeah exactly, Yeah, yeah right, I'm just you know, I 489 00:35:42.159 --> 00:35:45.679 keep going on with my head like I wonder if something regarding how we treat 490 00:35:45.719 --> 00:35:51.800 databases today and the separation of ownership maybe in this regard, has devofs failed 491 00:35:51.880 --> 00:35:55.960 us. Yeah. I think we need balance again. I think Agile and 492 00:35:57.000 --> 00:36:00.920 DevOps and some of these new and then no Squl trends which threw the DBA 493 00:36:01.039 --> 00:36:06.880 out with the bathwater. You know, I think that is went too far. 494 00:36:07.079 --> 00:36:09.199 I think I'm not And in fact, some companies are bringing back debas 495 00:36:09.239 --> 00:36:14.719 for some database like Mango, DBA and Cassandra are so hard to maintain they 496 00:36:14.800 --> 00:36:17.360 hire full time people. They don't call them DBAs as much, but they're 497 00:36:17.480 --> 00:36:22.559 administrators to keep the system running because Mango is pretty hard to keep running, 498 00:36:22.559 --> 00:36:25.360 and so is Cassandra. In fact, my last job, we hired a 499 00:36:25.400 --> 00:36:31.239 full time person just to reboot the Cassandra database every week because and it's not 500 00:36:31.320 --> 00:36:35.719 just the database is a whole bunch of servers. By the way, Cassandra 501 00:36:35.800 --> 00:36:38.079 is super expensive. If you're going to go down to the cass you better 502 00:36:38.119 --> 00:36:42.519 really know what you're doing. Because that's my least favorite database of all time 503 00:36:42.840 --> 00:36:45.599 for because it dev ops as a nightmare in it and it's so complicated to 504 00:36:45.639 --> 00:36:49.519 design. It takes you ten times longer to build anything because you have to 505 00:36:49.559 --> 00:36:53.760 denormalize everything because you can only query data in one table, so or you 506 00:36:53.840 --> 00:36:59.320 have multiple tables. They're white column tables. But if you can't join so 507 00:36:59.480 --> 00:37:02.719 you're basically saying all my possible careers I could ever do have to match one 508 00:37:02.800 --> 00:37:07.800 table and you and you you know, we just talked about that earlier. 509 00:37:07.880 --> 00:37:09.880 You have to join, but because you can't at Cassandra, you do you 510 00:37:10.360 --> 00:37:15.519 just it drives you crazy. It took us five years to build an application 511 00:37:15.559 --> 00:37:17.239 that you could have built in six months in some of the night fair com 512 00:37:17.320 --> 00:37:22.079 dB because Cassandra's limitations and in that database, we had a hard just to 513 00:37:22.119 --> 00:37:25.599 reboot all these servers in the cluster once a week. He just his job 514 00:37:25.719 --> 00:37:28.679 was to write, you know, run these scripts to reboot them, make 515 00:37:28.679 --> 00:37:31.559 sure they came back up. And nothing went down on that overall cluster database, 516 00:37:31.599 --> 00:37:36.360 but the servers themselves were going down and back up because Java has garbage 517 00:37:36.360 --> 00:37:40.719 collection and casoder's written in Java, and so when that hits your database performance 518 00:37:42.159 --> 00:37:45.039 just takes so you have to you have to reboot the server to clear out 519 00:37:45.039 --> 00:37:49.719 the Java Java, the garbage collection engineer Java, just to make the thing 520 00:37:49.800 --> 00:37:52.000 run. So I was like, oh my gosh. You know, that's 521 00:37:52.039 --> 00:37:57.519 why there's so much marketing high ground no sequel, which is the promise of 522 00:37:57.559 --> 00:38:01.679 a developer owns their world. Well, when you own the world, like 523 00:38:01.760 --> 00:38:05.400 you're saying, Warren, you know, it's kind of the death of DevOps 524 00:38:05.400 --> 00:38:08.880 because developers don't want to be that involved in the ops side, in the 525 00:38:08.880 --> 00:38:15.400 administration side of anything, and so they don't and it's pulling teeth to get 526 00:38:15.440 --> 00:38:21.480 them involved. So yeah, I think it's a real problem for DevOps to 527 00:38:21.480 --> 00:38:24.880 not have database specialists. So like we have front end in the developer where 528 00:38:24.880 --> 00:38:29.840 we have frontend specialists and back in specialists, your back in specialists are now 529 00:38:29.920 --> 00:38:34.519 the DBAs they need or really know your data. So I think I think 530 00:38:34.519 --> 00:38:37.840 that's good too, but you got to realize your back in specialists really need 531 00:38:37.880 --> 00:38:42.480 to know your data engine and think about data and if you do that, 532 00:38:42.639 --> 00:38:45.280 I think you're going to be fine as a company. And then the front 533 00:38:45.360 --> 00:38:47.639 end guys will never do DevOps because they're just the front end app. So 534 00:38:47.679 --> 00:38:53.159 the back end you're backing engineers are your DBAs, they're your DevOps people. 535 00:38:53.800 --> 00:39:00.360 So hire data savvy back in engineers and you'll be fine as a companycause they'll 536 00:39:00.360 --> 00:39:02.880 make good decisions. I feel like this is a hot tag, but maybe 537 00:39:02.920 --> 00:39:07.960 it's if we're always using a database where we need to hire an additional person 538 00:39:08.039 --> 00:39:12.920 in order to figure out and run it effectively. Has that database technology failed 539 00:39:13.000 --> 00:39:15.400 us? Like no one to be using Cassandra, if it really is true 540 00:39:15.400 --> 00:39:19.599 that we have to hire people to manage that. And I feel like the 541 00:39:19.639 --> 00:39:22.920 promise of the no squel, as you pointed out, is that you can 542 00:39:22.039 --> 00:39:28.159 have the usage of those databases by engineers and run them without hiring an additional 543 00:39:28.199 --> 00:39:30.719 person. I mean, how do we rectify that in the world where we 544 00:39:30.800 --> 00:39:37.039 stop using these technologies where you have to hire a DBA or whatever the new 545 00:39:37.119 --> 00:39:42.239 term is system administrator for our database type, Because as long as we have 546 00:39:42.320 --> 00:39:44.840 them, people are going to keep falling to the trap of maybe we can 547 00:39:44.960 --> 00:39:47.719 use that database of what it promises on the marketing website, but then find 548 00:39:47.719 --> 00:39:52.519 out later that we need to hire a really high paid specialist in order to 549 00:39:52.559 --> 00:39:55.760 come in in order to actually utilize the technology effectively. Yeah, I think 550 00:39:57.199 --> 00:40:00.000 I think that's what the whole no sequel moment was about. Was more high 551 00:40:00.639 --> 00:40:06.079 you know, they were it's a good thing to compete with SQLQ SQL databases 552 00:40:06.079 --> 00:40:10.719 were kind of sitting on their laurels, not innovating enough in real ways that 553 00:40:10.719 --> 00:40:15.119 that developers need. So no SQL was great and is great for that, 554 00:40:15.840 --> 00:40:21.679 but it doesn't you can't hide the reality that work needs to be done. 555 00:40:21.760 --> 00:40:23.800 In fact, I had a really wise engineer once told me, you know, 556 00:40:23.920 --> 00:40:27.760 it doesn't matter where you put the work in a software project. The 557 00:40:27.840 --> 00:40:30.920 work needs to be done. So if you move all the work to the 558 00:40:30.960 --> 00:40:34.159 developer, great, but make sure that you're going to have to have specialized 559 00:40:34.199 --> 00:40:37.719 developers who know how to do the work. The work doesn't The data is 560 00:40:37.760 --> 00:40:40.519 hard. You have to think about co locating data. You have to think 561 00:40:40.559 --> 00:40:44.840 about do I run the code on a separate server or on the database server, 562 00:40:44.920 --> 00:40:47.079 because if it's a batch job or bulk processing job, the code has 563 00:40:47.119 --> 00:40:52.320 to run near the data because network latency and network throughput is going to kill 564 00:40:52.320 --> 00:40:54.039 you. By moving the need to off the server somewhere else and bringing it 565 00:40:54.079 --> 00:41:00.199 back. You need to run the code on the server. So there's these 566 00:41:00.239 --> 00:41:06.159 specialists who know how data works, and you can pretend, oh, yeah, 567 00:41:06.239 --> 00:41:07.719 we got rid of that. And that's what the no sequel movement did 568 00:41:08.239 --> 00:41:13.360 in the and the and the in Mango is the most successful of all of 569 00:41:13.360 --> 00:41:16.840 them, fifth most popular database in the world. Now, by pretending that 570 00:41:17.079 --> 00:41:22.400 these problems don't exist and the developers is fully in charge, it's a brilliant 571 00:41:22.599 --> 00:41:28.719 marketing play. Totally brilliant but the reality is now the developer is the DBA, 572 00:41:29.400 --> 00:41:31.679 so and that that work didn't go away, And as a developer, 573 00:41:31.719 --> 00:41:37.679 did you really want to be the DBA. That's that's the question you have 574 00:41:37.679 --> 00:41:40.039 to ask yourself. If you're back in engine, if you're back in developer, 575 00:41:40.440 --> 00:41:45.000 now you're the hated DBA because you're gonna build a web service and the 576 00:41:45.039 --> 00:41:45.880 friend of the guys is going to give you this year and go, no, 577 00:41:46.239 --> 00:41:49.480 I've got to refracture my data. That's not going to work for me, 578 00:41:50.320 --> 00:41:52.760 and then then they're gonna hate you. So then there'll be a revolution 579 00:41:52.840 --> 00:41:55.800 against the back end engineer. It's all fronting the engineers. I don't know, 580 00:41:55.800 --> 00:42:00.840 I'm joking on that, but it could happen. I don't mean it's 581 00:42:00.880 --> 00:42:04.320 a bit ridiculous, but actually there are plenty of products out there that claim 582 00:42:04.400 --> 00:42:07.280 that they are back ends as a service and from some company that is offering 583 00:42:07.320 --> 00:42:12.199 this and you don't have to worry about how your data even looks like or 584 00:42:12.239 --> 00:42:15.119 anything like. You just throw data at us and we'll store it and do 585 00:42:15.199 --> 00:42:17.320 the right thing. And I think the same probably can be said of all 586 00:42:17.360 --> 00:42:22.079 of those products as well. Right, totally, totally their work has to 587 00:42:22.119 --> 00:42:25.199 be done. Somebody has to think about data and the structure and where you're 588 00:42:25.199 --> 00:42:31.480 going to process it. And it's a specialty. So figure out where as 589 00:42:31.519 --> 00:42:35.559 an organization, figure out where you want to be. I don't think no, 590 00:42:35.679 --> 00:42:37.559 I don't think SEQL databases are dead by any means, and I don't 591 00:42:37.559 --> 00:42:42.599 think the DBA for those are dead. I think we just need this. 592 00:42:42.760 --> 00:42:46.760 Seql is innovating and they're embracing Jason a little more. The secret databases. 593 00:42:46.800 --> 00:42:52.119 Do you have Jason support? Postgress is the best at Jason support, and 594 00:42:52.159 --> 00:42:57.280 that's why it's becoming really popular. But you could choose a kitchen sink database 595 00:42:57.360 --> 00:43:00.920 like Postgress or Oracle, which has everything you can imagine in it, but 596 00:43:00.960 --> 00:43:05.639 none of them are really awesome except for the sqel engine. Or you could 597 00:43:05.679 --> 00:43:10.079 choose especially database like Mango that's really good at JSON technically Bison, you know, 598 00:43:10.159 --> 00:43:15.320 but then it and then but that's not really good at the joining of 599 00:43:15.400 --> 00:43:19.880 data. So there's not there's really no perfect solution out there yet. That's 600 00:43:19.920 --> 00:43:22.880 why I'm working at Faircom because my goal is to build the right solution. 601 00:43:23.239 --> 00:43:27.400 And to your point, that's point warrant about. People just want a service. 602 00:43:27.760 --> 00:43:30.960 Right, that the data layer moved from a seqel layer, which traps 603 00:43:31.000 --> 00:43:37.000 the data behind SQL, the SQL career language, to a web service layer, 604 00:43:37.000 --> 00:43:39.840 which frees the data in JSON. Right. So well, with fair 605 00:43:39.840 --> 00:43:43.679 coom dB, we have the seql air, we have the ISAM layer, 606 00:43:43.679 --> 00:43:45.519 which we need super speed, but now we have the Jason layer, and 607 00:43:45.639 --> 00:43:51.960 it is the Jason layer is the service. It's it's over HTTP. So 608 00:43:52.039 --> 00:43:57.039 you just send JSON requests over HTTP and then you get answers back and the 609 00:43:57.119 --> 00:44:00.440 JSON and the answer comes back to JSON. So your data is Jason, 610 00:44:00.599 --> 00:44:05.199 your query's or Jason. Everything's Jason. And it is a web service over 611 00:44:05.480 --> 00:44:09.800 Https. So we provide that now and we and and like you said, 612 00:44:09.800 --> 00:44:13.639 everybody says, well now we need to transform the data. We need to 613 00:44:13.639 --> 00:44:16.800 reshape the Jason. So that's the next phase we're building here at Faircom is 614 00:44:16.840 --> 00:44:23.199 that is the VA JavaScript engine into our product to do all those fancy transforms 615 00:44:23.239 --> 00:44:27.000 on the server side, so you get the data shape to the way you 616 00:44:27.079 --> 00:44:30.360 need it. But that doesn't even though that's to me, that's a game 617 00:44:30.440 --> 00:44:35.920 changer and and and potentially it could even replace a lot of back end development 618 00:44:37.480 --> 00:44:40.119 because we are a web service as well, But that doesn't mean it replaces 619 00:44:40.159 --> 00:44:46.320 all of the back end development just really simplifies their efforts. But you you 620 00:44:46.400 --> 00:44:51.159 still need to think about data. That doesn't change the fact you've got to 621 00:44:51.199 --> 00:44:54.719 think like a DBA, a developer DBA. Where you're where you are thinking 622 00:44:54.719 --> 00:44:58.960 about our architecture DBA, How should the data be data? How should we 623 00:44:59.039 --> 00:45:01.519 organize the data? How shoul to be model the data? So we could 624 00:45:01.519 --> 00:45:07.159 build an application that can survive the test of time. Maybe eighty percent of 625 00:45:07.199 --> 00:45:10.400 the time. You'll never get one hundred percent, but eighty percent is pretty 626 00:45:10.400 --> 00:45:13.960 awesome. But if you use something like if you don't do any of it, 627 00:45:14.000 --> 00:45:15.639 you're gonna be surviving twenty percent of the time on your current design and 628 00:45:15.719 --> 00:45:21.440 rewriting eighty percent of the time, and your company is as a developer, 629 00:45:21.440 --> 00:45:25.360 it's great job security, and developers actually think about those things. Oh yeah, 630 00:45:25.360 --> 00:45:30.159 this is great, I'll be employed here forever, you know, but 631 00:45:30.960 --> 00:45:32.760 it's not good for the company. So any manager listening to this to really 632 00:45:32.800 --> 00:45:38.800 pay attention that developers are protecting themselves by cranking out stuff fast and they know 633 00:45:38.840 --> 00:45:42.599 they have to rewrite it and they're going to job security is there, and 634 00:45:42.599 --> 00:45:45.599 you're paying them the biggest bucks now to do all of that, you should 635 00:45:45.840 --> 00:45:52.920 think really carefully about data design and cutting, you know, really reducing costs. 636 00:45:53.480 --> 00:45:57.480 Hey, there, this is Charles Maxwood. I'm excited because I wanted 637 00:45:57.480 --> 00:46:00.039 to let you know about this thing that I pulled together that I had just 638 00:46:00.360 --> 00:46:05.440 I've been dying to have this for years and I never felt like I could, 639 00:46:05.719 --> 00:46:07.119 and then I just realized that there's no reason why I can't. So 640 00:46:07.480 --> 00:46:12.039 I'm putting together a book club and we're going to read development focused books, 641 00:46:12.199 --> 00:46:15.760 career books, you know, technical books, whatever. The first book that 642 00:46:15.760 --> 00:46:20.159 we're going to do is going to be Clean Architecture by Uncle Bob Martin. 643 00:46:20.320 --> 00:46:22.719 If you're not familiar with clean code or some of the other stuff that Bob 644 00:46:22.760 --> 00:46:25.239 has done, check that out. I've also talked to him on the Clean 645 00:46:25.280 --> 00:46:30.000 Coders podcast, which is on top end Devs. But yeah, we're going 646 00:46:30.079 --> 00:46:31.119 to get on. He's going to show up to some of our meetings, 647 00:46:31.320 --> 00:46:36.119 and what I'm thinking is we'll probably have like five or six people part of 648 00:46:36.159 --> 00:46:39.239 the conversation along with Bob and I at the same time, and we'll just 649 00:46:39.679 --> 00:46:44.280 so somebody can come on, they can ask their question and then we'll just 650 00:46:44.679 --> 00:46:47.679 rotate people through, so we'll mute one person, unmute another person when it's 651 00:46:47.719 --> 00:46:52.480 their turn to come on and be part of the discussion. So we'll do 652 00:46:52.559 --> 00:46:53.760 that for like an hour, hour and a half. And then the other 653 00:46:53.800 --> 00:46:58.159 part of it that I'm putting together is just kind of a meet and greet 654 00:46:58.239 --> 00:47:04.679 gather area on Gathered and so after the meetup and the call, we we'll 655 00:47:04.679 --> 00:47:07.800 do as we'll all go over to gather town and you can just log in, 656 00:47:07.880 --> 00:47:10.119 walk up to a group and have a conversation, and that way we 657 00:47:10.119 --> 00:47:15.039 can all kind of get to know each other and make friends and get to 658 00:47:15.039 --> 00:47:17.079 know people across the world. One thing that I'm finding is that, yeah, 659 00:47:17.119 --> 00:47:20.719 the meetups are starting to come back, but a lot of people don't 660 00:47:20.719 --> 00:47:22.480 have the opportunity to go to a meetup. And I really want to meet 661 00:47:22.480 --> 00:47:24.920 you guys and talk to you. So we're gonna put all that together. 662 00:47:25.000 --> 00:47:28.559 We'll all be part of that book club. You can go to topendevs dot 663 00:47:28.599 --> 00:47:30.719 com slash book Club to be part of it, and I'm looking forward to 664 00:47:30.760 --> 00:47:36.159 seeing you there. The first book club meeting will be in December, the 665 00:47:36.239 --> 00:47:39.800 beginning of December, we're starting the first week of December, and you'll also 666 00:47:39.840 --> 00:47:44.440 be part of the conversation about which book we do next. I have one 667 00:47:44.440 --> 00:47:46.480 in mind, but I want to see where everybody's at. So there you 668 00:47:46.519 --> 00:47:52.360 go for sure they're doing Yeah, they're doing exactly what you've asked them to 669 00:47:52.400 --> 00:47:58.280 do. Yeah, yeah, exactly. So I want to get your opinion 670 00:47:58.320 --> 00:48:02.719 on this because to me, whenever a lot of the companies I've worked with, 671 00:48:04.159 --> 00:48:08.119 you know, they're spending fifty sixty one hundred thousand dollars a month on 672 00:48:08.719 --> 00:48:16.599 Looker and Snowflake, and not for the visualization part of those tools, but 673 00:48:16.679 --> 00:48:22.840 for the ETL transformation. That's where all the money gets spent. And to 674 00:48:22.960 --> 00:48:28.440 me, that's not a product. That's a symptom of not having your database 675 00:48:28.760 --> 00:48:32.000 design well thought out to serve your business. What are your thoughts on that? 676 00:48:32.719 --> 00:48:37.239 Yeah, well, it may be a symptom of not thinking it through 677 00:48:37.360 --> 00:48:42.280 for sure, right, and it also may be a symptom of specialization. 678 00:48:42.559 --> 00:48:45.679 So and when you write an online transaction application and you're trying to service transactions 679 00:48:45.679 --> 00:48:51.360 with low latency, right, you're going to design your data model and optimize 680 00:48:51.400 --> 00:48:55.519 it for that use case. That's the exact opposite of the opposite optimization you 681 00:48:55.599 --> 00:49:00.000 have to do for a data warehouse. A data warehouse, you're going to 682 00:49:00.639 --> 00:49:02.840 completely design it a different way. You're going to go into I like the 683 00:49:02.920 --> 00:49:08.400 Kimball model. There's two major warehousing philosophies Inman and Kimball, and Kimball is 684 00:49:08.599 --> 00:49:15.440 more practical. Kimball says, denormalize your data into a fact table and dimensions. 685 00:49:15.119 --> 00:49:20.159 And basically what you're doing is you're saying, you asked the question what 686 00:49:20.519 --> 00:49:23.719 questions will our users ask? What answers do they need from our data? 687 00:49:23.880 --> 00:49:29.480 And so you build those answers into the dimensions that we build the filters for 688 00:49:29.559 --> 00:49:31.119 the answers and the dimensions, and then you put the facts in the fact 689 00:49:31.119 --> 00:49:34.639 table. So the facts could be like the order costs. You know, 690 00:49:34.840 --> 00:49:37.920 if you're ordering a product, what was the order cost? The dimensions are 691 00:49:37.119 --> 00:49:39.840 when did you order it, who ordered it, where do they live? 692 00:49:40.000 --> 00:49:44.000 What time? All these all these you know, who win, what where, 693 00:49:44.079 --> 00:49:49.599 why how dimensions surrounding the fact table. You would never build a transaction 694 00:49:49.679 --> 00:49:53.159 system of doing that because you're you'd be super duper slow. So what happens 695 00:49:53.239 --> 00:49:58.519 is you have to take the data out of your transaction system and then etil 696 00:49:58.559 --> 00:50:01.679 it over or e lt O over to your your data warehouse, which could 697 00:50:01.679 --> 00:50:06.639 be Snowflake or red Shift, or it could be Oracle Exit Data. Now 698 00:50:06.679 --> 00:50:08.960 there's all kinds of warehouse products out there, and and that's the one one 699 00:50:09.280 --> 00:50:13.280 my roles at the LDS Church was the data architect. We had one hundred 700 00:50:13.320 --> 00:50:17.280 person b I t that I was the architect for so I have hands on 701 00:50:17.360 --> 00:50:22.280 experience with all this and these We had one hundred engineers pulling data out of 702 00:50:22.360 --> 00:50:30.840 these transactional databases, restructuring them to answer queries that the end the business users 703 00:50:30.880 --> 00:50:35.119 have so to make to write a database that can answer queries in a timey 704 00:50:35.239 --> 00:50:38.760 fashion for a business user, you have to restructure the data. So it's 705 00:50:38.800 --> 00:50:44.760 actually it's a problem of optimization. It's but it's it's not it's not a 706 00:50:44.760 --> 00:50:50.840 bad optimization. It's that you're optimizing transactions for their things. Gardener, optimizing 707 00:50:50.920 --> 00:50:55.039 for two different use cases. Yeah, and that's and that's okay. Gardner. 708 00:50:55.039 --> 00:50:59.280 For a while, there was promoting this hybrid model where you'd have your 709 00:50:59.280 --> 00:51:05.519 operational and you're analytical in the same database. And the dream was you'd put 710 00:51:06.000 --> 00:51:08.920 you you'd optimize your data for transactional in the SEQUL side of the database, 711 00:51:08.920 --> 00:51:15.880 but then you'd have in memory column stores. So use your your Calumn technology 712 00:51:15.880 --> 00:51:20.280 instead of road based transactional, you'd switch it to column based in memory, 713 00:51:20.559 --> 00:51:23.840 and then you have a Calumner view of your road data, but the columns 714 00:51:23.840 --> 00:51:30.400 in memory. So then you can create the Calumner data sort of like Kimball's 715 00:51:30.440 --> 00:51:35.480 model of facts and dimensions, but you really have But that doesn't. The 716 00:51:35.559 --> 00:51:38.079 Kimball model works only when you ask, ay, what are the questions our 717 00:51:38.159 --> 00:51:43.360 customers you're asking, and then you organize the data to answer those questions. 718 00:51:43.519 --> 00:51:45.840 Think of it this way, Kimball says, I'm going to pre define my 719 00:51:45.920 --> 00:51:49.039 reports as data, so all you have to do is just I want this 720 00:51:49.079 --> 00:51:51.599 on my report, this report. You're just selecting I want this, this, 721 00:51:51.639 --> 00:51:54.440 and this this on my report done well. You're not going to take 722 00:51:54.440 --> 00:51:59.480 a transactional system and put it in a Columner store in memory and expect that 723 00:51:59.559 --> 00:52:04.559 to perform well because you're not tuning it to answer the exact questions your users 724 00:52:04.599 --> 00:52:07.719 have. So it's more fantasy than reality to say I can have a database 725 00:52:07.800 --> 00:52:15.360 do everything without data modeling. Gotcha, But could you simplify the process of 726 00:52:15.360 --> 00:52:21.320 getting data to those data warehouses because ETL is about is about getting the data 727 00:52:21.440 --> 00:52:25.559 extracting it, and that actually is harder than you think. The E part 728 00:52:25.880 --> 00:52:30.320 is one of the hardest parts. The transforming part is pretty straightforward once you 729 00:52:30.360 --> 00:52:32.559 know what you want, and then the loading it is super easy. So 730 00:52:34.079 --> 00:52:37.119 the E part is where the problem is. So if you can get the 731 00:52:37.239 --> 00:52:40.840 data, if you can get a database to automatically extract this data for you 732 00:52:40.880 --> 00:52:45.880 and push it where it needs to go, then the solution becomes way better. 733 00:52:46.440 --> 00:52:51.800 So I build a system at Faircom to do that because I know this 734 00:52:51.880 --> 00:52:54.840 problem and I wanted to solve it, and so we build a what we 735 00:52:54.880 --> 00:52:59.000 call it dB Notify, and what it does is every time there's a change 736 00:52:59.039 --> 00:53:04.920 in the source system, we automatically send a JSON message over and our We 737 00:53:04.960 --> 00:53:07.960 have an MPTT broker product as well, so it's a high it's a mission 738 00:53:07.960 --> 00:53:13.119 critical MPTTT broker, so it's a message que broker. So we what we 739 00:53:13.199 --> 00:53:16.159 do is every time a data change occurs in the database, we send a 740 00:53:16.239 --> 00:53:22.119 Jason message over our message broker, which guarantees delivery and and I guarantees delivery 741 00:53:22.199 --> 00:53:25.480 wants, because you you've got to have that guaranteed in order to get your 742 00:53:25.519 --> 00:53:30.760 data somewhere reliably. Of course. Yeah. So then and then any system, 743 00:53:30.920 --> 00:53:34.519 whether it's a Java program putting it into a cash, whether it's a 744 00:53:34.519 --> 00:53:39.800 SQL database retrieving you know, for warehousing, can can subscribe to these messages 745 00:53:40.199 --> 00:53:45.320 and get the data automatically. So the e part, the hard e part 746 00:53:45.360 --> 00:53:47.679 of extracting the data goes away, and you just simply say give me Jason 747 00:53:49.280 --> 00:53:52.440 and and the data just flows and you have Jason and now with a JSON 748 00:53:53.119 --> 00:54:00.280 you can you can now manage the the T and the L trivially. Yeah, 749 00:54:00.320 --> 00:54:02.239 because there is a huge trouble that actually a lot of companies, I 750 00:54:02.239 --> 00:54:06.559 feel like, run into where they have a lot of individual teams with each 751 00:54:06.599 --> 00:54:10.199 of their own databases, and then they overinvest in setting up a complex technology 752 00:54:10.559 --> 00:54:16.400 like Kofka to varying messages from those individual databases to align it and push it 753 00:54:16.440 --> 00:54:22.280 into whatever their data warehouse is. Coff is a great example what Kafka's advantage 754 00:54:22.280 --> 00:54:27.840 is, It's like it's like a combination of a message que plus a log, 755 00:54:28.360 --> 00:54:31.280 right, so you can so you can query the message log and see 756 00:54:31.320 --> 00:54:35.119 everything that's happened, and it's distributed to at scales and all that. But 757 00:54:35.159 --> 00:54:37.159 it's complicated, hard to use and all that. Well, what I did 758 00:54:37.199 --> 00:54:40.440 is I looked at that and I said, no way, can't it be 759 00:54:40.639 --> 00:54:45.000 simple? So I said, what is the simplest message queue technology on the 760 00:54:45.000 --> 00:54:50.280 market as a protocol. And the answer is MQTT. It's it's because taking 761 00:54:50.320 --> 00:54:54.679 over a MQP, because a MQP is complicated as the Advanced Message q protocol 762 00:54:54.920 --> 00:54:59.880 and that's used in Rabbit, mqqubit and other products and active mq it's a 763 00:55:00.239 --> 00:55:05.079 technology, it's just complicated. M qtt's taken over the IoT world by storm 764 00:55:05.159 --> 00:55:08.159 because it's simple. You can embed it in a little device, a little 765 00:55:08.199 --> 00:55:12.079 sensor, you can, you can put it in big machines and it's it 766 00:55:12.519 --> 00:55:15.480 truly pushes data sou as an event happens, it pushes it to all the 767 00:55:15.519 --> 00:55:19.679 subscribers. All the subscribers get it. It's super easy to use. So 768 00:55:20.639 --> 00:55:24.480 we took m QTT and then we said, Hakka Kafka has a log, 769 00:55:24.559 --> 00:55:30.119 but it's not really a queriable log, but the logs that secret sauce because 770 00:55:30.119 --> 00:55:35.119 it's it's like a streaming serve event server with a with a log on disc. 771 00:55:35.559 --> 00:55:38.159 So we took the fair Comm database, edit it to our own message, 772 00:55:38.199 --> 00:55:43.199 que MPTT broker, merge the two together. They're one thing. Added 773 00:55:43.239 --> 00:55:45.760 a transform feature to it so we could transform the data on the way in 774 00:55:45.880 --> 00:55:49.920 and on the way out of that thing. And now you have a full 775 00:55:50.280 --> 00:55:55.239 data integration platform that does et L super easily, and I like Cofka, 776 00:55:55.440 --> 00:56:00.719 you can go back and query all the changes. But now it's Seql database. 777 00:56:00.760 --> 00:56:04.400 Number of Faircom has the sequel, the JSON and the ICE and layers, 778 00:56:04.599 --> 00:56:07.480 so you can get the data out through Seql queries. You can get 779 00:56:07.480 --> 00:56:09.679 the data out. You see, can queer your transaction log or your log 780 00:56:09.719 --> 00:56:15.880 of events, your event log with Seql or with JSON, and it's queriable 781 00:56:15.960 --> 00:56:19.199 and filterable on the flight and you can index parts of it. And so 782 00:56:19.320 --> 00:56:22.599 you have a real time not real time is but a very near time dynamic 783 00:56:22.840 --> 00:56:28.000 dynamic query system on top of Kafka. Imagine if you could have Kafka with 784 00:56:28.039 --> 00:56:30.760 a real database instead of was just a static log that you could query and 785 00:56:30.800 --> 00:56:36.280 filter and you have real time push events through PGT. That's what we built 786 00:56:37.000 --> 00:56:45.159 a broker. So many words there that I just get triggered on. I 787 00:56:45.199 --> 00:56:50.239 can't. Sorry, I'm just geeking out here because I just love this stuff. 788 00:56:51.679 --> 00:56:55.199 You said something really interesting a little while ago about basically needing to hire 789 00:56:55.199 --> 00:56:59.159 a DBA specialist, and I'm trying to figure out, like you know, 790 00:56:59.320 --> 00:57:02.760 I'm if you have a company or were under twenty people like that still feels 791 00:57:02.800 --> 00:57:07.199 too early. But if you don't hire them early enough, then you end 792 00:57:07.239 --> 00:57:08.719 up with a lot of the problems you talked about. So like when when 793 00:57:08.760 --> 00:57:12.639 in your view do you actually mean it's not at three people? Right? 794 00:57:13.280 --> 00:57:15.000 Maybe that's yours, that's what you were suggesting. It's like, oh, 795 00:57:15.079 --> 00:57:19.159 yeah, you know one of your first few engineers, like after your founding 796 00:57:19.199 --> 00:57:22.000 engineer, you need to have some sort of database specialist. What do you 797 00:57:22.000 --> 00:57:24.880 think? Yeah, I think you need to have a data expert. Now 798 00:57:24.880 --> 00:57:30.599 if they are your back end engineer who's a data but truly data expert understands 799 00:57:30.440 --> 00:57:36.679 how the long term implications of data design not so obsessed that they stop production. 800 00:57:36.760 --> 00:57:38.440 That's what the other old school DBAs did, Right, you can't do 801 00:57:38.559 --> 00:57:44.320 anything. You can't touch my database. And the hard part is you've got 802 00:57:44.320 --> 00:57:47.920 to hire a person who really knows what they're doing, because like Freightliner hired 803 00:57:49.320 --> 00:57:53.320 this one czar that was blocking everything and making bad decisions. Right, So 804 00:57:53.840 --> 00:57:58.760 you've got to It's hard because you have to know enough about data to hire 805 00:57:58.800 --> 00:58:01.360 the right person. But it could be a back end engineer, it could 806 00:58:01.400 --> 00:58:06.159 be a that's what it probably would recommend these days. Instead of hiring a 807 00:58:06.239 --> 00:58:09.440 DBA, hire a back end engineer who specializes in a number of data technologies. 808 00:58:09.480 --> 00:58:14.199 And on their resume they can demonstrate or an interview, they demonstrate to 809 00:58:14.239 --> 00:58:19.320 you scenarios where they designed the data one way using this technology and it caused 810 00:58:19.360 --> 00:58:22.280 them problems. They designed it another way and another technology caused them problems. 811 00:58:22.679 --> 00:58:25.000 They or they didn't design at all and it caused them problems. And they 812 00:58:25.000 --> 00:58:29.079 can tell you what those problems are. And they learned their lessons from the 813 00:58:29.079 --> 00:58:30.239 school of hard knocks, and then they can say, you know what, 814 00:58:30.519 --> 00:58:34.239 I'm not going to do that ever again. We're gonna up front, we're 815 00:58:34.280 --> 00:58:37.159 gonna we're gonna be practical. We're not going to over engineer, over design 816 00:58:37.159 --> 00:58:40.280 because you'll never get out the door. But we're gonna we're going to protect 817 00:58:40.360 --> 00:58:45.000 you eighty percent of the time from those problems that you're going to have and 818 00:58:45.480 --> 00:58:52.559 if he could demonstrate that through experience, then you've got a winner. Okay, 819 00:58:52.840 --> 00:58:57.239 that's good advice. You know, I'm actually thinking down that path, 820 00:58:57.280 --> 00:59:00.760 like there must be aspiring uh, you know database administrators out there, uh, 821 00:59:00.960 --> 00:59:04.760 and they want to hear like, well, you know what, what's 822 00:59:04.760 --> 00:59:07.320 the first thing to go down this path? Right? You know, how 823 00:59:07.360 --> 00:59:14.719 do I learn more about becoming the database specialist back end for a burning company? 824 00:59:14.760 --> 00:59:16.880 You know what? What do I need to know realistically? Yeah? 825 00:59:16.920 --> 00:59:21.320 And I and I think there has been a market shift, a good one 826 00:59:21.519 --> 00:59:25.880 from there's another DBA. There's a DBA is you know, stands for several 827 00:59:25.880 --> 00:59:32.400 things database administrator, database architect, and then there's developer DBAs they're all lumped 828 00:59:32.400 --> 00:59:38.559 together in DBAH. The administrator person is the one that I'm glad that we're 829 00:59:38.559 --> 00:59:43.280 shifting away from. I think it's the cloud is removed a lot of the 830 00:59:43.320 --> 00:59:45.480 need for that low level back up your database. I used to Actually in 831 00:59:45.480 --> 00:59:49.679 the cloud, you have to configure your own backups, but the technology to 832 00:59:49.719 --> 00:59:53.119 do it, the cloud provides upgrades. You don't have to do the upgrades. 833 00:59:53.119 --> 00:59:57.679 The cloud do the upgrades for you. So that's good. So the 834 00:59:57.679 --> 01:00:00.159 cloud is now if you if you get a aviation product that does this for 835 01:00:00.239 --> 01:00:02.960 you, or you go into the cloud like the fair Com does this for 836 01:00:04.079 --> 01:00:07.519 you. We don't require DBA in our product, but we can run on 837 01:00:07.599 --> 01:00:12.960 premise or the cloud. But not Oracle requires a DBA just to just to 838 01:00:13.039 --> 01:00:16.360 keep it up and running. So getting an Oracle Cloud instance of Oracle would 839 01:00:16.360 --> 01:00:19.840 be good for you because you're going to save a ton of money and the 840 01:00:19.920 --> 01:00:22.679 trivial stuff you don't want to. So if I, if I give recommendation 841 01:00:22.800 --> 01:00:28.559 for a newbie, don't become the administrator that is just knows how to run 842 01:00:28.599 --> 01:00:32.679 the script that the books said to run to back up the database. That 843 01:00:32.800 --> 01:00:37.199 kind of administrator is not the value add and that and that's the kind they're 844 01:00:37.199 --> 01:00:40.119 having to add like Mango and Cassandra. You have to hire those kind of 845 01:00:40.159 --> 01:00:45.760 administrators because that's the systems are so poorty designed. You got to got to 846 01:00:45.800 --> 01:00:47.119 have a local level guy just to keep it lights wrong. But that's a 847 01:00:47.159 --> 01:00:52.559 dead end career. The value is in the data, so the data arket, 848 01:00:53.000 --> 01:00:57.960 the dB architect, the guy who So you're back in a minute, 849 01:00:57.960 --> 01:01:01.639 you're back in developer who really understands how to architect the data so that your 850 01:01:01.639 --> 01:01:08.559 application will perform well and grow well over time. That's that's gold. And 851 01:01:08.679 --> 01:01:12.639 so if you have a mind to do that, you have to have kind 852 01:01:12.639 --> 01:01:15.719 of a mathematical mind. I don't mean you have to like coakyas or something. 853 01:01:15.760 --> 01:01:19.000 I just mean you have to have a very logical mind. Then you 854 01:01:19.039 --> 01:01:22.400 have to look at things logically and systematically and understand practically. You have to 855 01:01:22.400 --> 01:01:25.920 be practical. You have to say, Okay, this technology does X, 856 01:01:27.320 --> 01:01:30.639 if I do if I do X with this technology, I'll be successful. 857 01:01:30.639 --> 01:01:32.119 But I know I need a little bit of why over here to make the 858 01:01:32.440 --> 01:01:37.519 to grow the system. How can I how can I make this X system 859 01:01:37.559 --> 01:01:40.199 do why? I need a multipurpose system so I can do X and Y, 860 01:01:42.119 --> 01:01:44.559 but it needs to do both well. You know, you have to 861 01:01:44.599 --> 01:01:50.159 make a lot of decisions. And that's where a really experience. So if 862 01:01:50.199 --> 01:01:53.159 you hire a good back inagy with like thirty years of experience, twenty years 863 01:01:53.159 --> 01:01:57.679 of experience with lots of data work, you're you're going to be in good 864 01:01:57.719 --> 01:02:01.079 shape. So don't skimp on that back end engineer who does these data architecture. 865 01:02:01.079 --> 01:02:04.559 That's going to be gold for you in the long run, as long 866 01:02:04.599 --> 01:02:06.800 as they have a good personality, as long as they're not like the no 867 01:02:07.320 --> 01:02:12.679 guy. Don't hire those guys. They'll block your whole company and you'll die. 868 01:02:14.119 --> 01:02:16.880 They need to be the yes guy who says yes but think about this 869 01:02:16.960 --> 01:02:20.880 and this and this, and I will help you achieve the goal. I 870 01:02:20.920 --> 01:02:23.440 will overcome the problems. I won't just be no. We'll solve this together. 871 01:02:23.719 --> 01:02:27.360 No. I think that's pretty good spot on advice, irrelevant of the 872 01:02:28.039 --> 01:02:31.599 special specialty that someone would normally go into, Like I think, relevant of 873 01:02:31.679 --> 01:02:38.880 whether it's databases or UI's or other back end services, graft culi databases, 874 01:02:38.920 --> 01:02:43.280 you know, whatever, whatever have you. Actually, you know, this 875 01:02:43.400 --> 01:02:47.320 really got me thinking. And I've dabbled in a bunch of different database technologies 876 01:02:47.320 --> 01:02:50.480 over the years, and one thing that keeps coming up for me, and 877 01:02:50.519 --> 01:02:53.320 maybe this is specific because I always pay attention to security, is it just 878 01:02:53.320 --> 01:03:00.000 feels like security plus databases is like oil and water. Yeah. Well, 879 01:03:00.199 --> 01:03:06.400 first off, it's super hard. I think that's why because because you're your 880 01:03:06.519 --> 01:03:10.599 data is the thing you're protecting the most that you are protecting its intrusion. 881 01:03:10.719 --> 01:03:14.840 So that's where you know front hackers can get into a system. But what 882 01:03:14.880 --> 01:03:16.239 are the hackers trying to do when they get in, Well, they're going 883 01:03:16.280 --> 01:03:20.079 to either encrypt your data and ransom you, or they're going to encrypt your 884 01:03:20.119 --> 01:03:22.119 data and steal it. And of course what are all the breaches about data? 885 01:03:22.239 --> 01:03:24.840 Right, So you've got to encrypt your data at rest, you got 886 01:03:24.920 --> 01:03:29.719 encrypted at transit. You've got to prevent the injection attacks to give you backdoors 887 01:03:29.760 --> 01:03:35.119 into the database. So then take it over. Security. A good database 888 01:03:35.159 --> 01:03:40.239 product, security should be number one in the APIs and in the system. 889 01:03:40.280 --> 01:03:46.320 It should be secure by default. Oracle has a common password that has been 890 01:03:46.679 --> 01:03:49.800 that's well known. I'm not going to say it because I don't want to 891 01:03:49.800 --> 01:03:52.599 promote this, but you know, and half your dba's in the world don't 892 01:03:52.719 --> 01:03:58.960 change it it is. You know. Sometimes these are more administrative DBAs and 893 01:03:59.000 --> 01:04:00.679 just run the scripts as if. They drive me crazy because they don't know 894 01:04:00.719 --> 01:04:05.960 what they're doing and and and they don't make it secure, so they don't 895 01:04:06.039 --> 01:04:09.960 change things. I had. I remember one database we stalled. I stalled 896 01:04:09.960 --> 01:04:14.679 this database product over fifteen years ago at at this organization, and they kept 897 01:04:14.679 --> 01:04:18.440 the same password I used in that database for fifteen years. Finally, I 898 01:04:18.480 --> 01:04:21.519 think it was just a year ago they finally changed it. I'm like, 899 01:04:23.119 --> 01:04:26.800 really, I left that company five years ago and you're still using my password. 900 01:04:26.840 --> 01:04:29.400 My son works there now, and so I actually happened to know. 901 01:04:29.880 --> 01:04:31.360 I got a job on my old team and happened to know they actually never 902 01:04:31.440 --> 01:04:35.199 changed it when I left it. I'm trustworthy of but it was a good 903 01:04:35.199 --> 01:04:40.679 password. But still, so this is the Yeah, you're worried it will 904 01:04:40.679 --> 01:04:43.079 break something, right if you change the password, you know, production will 905 01:04:43.079 --> 01:04:45.719 go down. So I really should be careful. Someone could be using that, 906 01:04:45.840 --> 01:04:47.719 you know, in a way that wasn't intended. Totally true, and 907 01:04:47.719 --> 01:04:50.519 then the DBAs are lazy. Everybody's lazy, right, So, like I 908 01:04:50.679 --> 01:04:57.719 memorized this stupid, horrible password, I'm never changing this one. But yeah, 909 01:04:57.960 --> 01:05:00.920 right, we rotate passwords in apike every time the Roman Empire falls. 910 01:05:02.800 --> 01:05:09.800 Well, you know what's good that the updated nest whatever eight hundred is now 911 01:05:10.079 --> 01:05:14.840 no longer, suggesting that rotation actually prevents a certain category of attacks, because 912 01:05:15.320 --> 01:05:18.159 the need to rotate means people will forget and have to write it down. 913 01:05:18.280 --> 01:05:23.599 So now, luckily now there is written documentation that may suggest that even doing 914 01:05:23.679 --> 01:05:28.519 so doesn't have a positive long term impact. Yeah, and password managers are 915 01:05:28.559 --> 01:05:32.079 super huge. Get one that does crypto random passwords. You'll never remember it. 916 01:05:32.559 --> 01:05:35.360 You don't write it down because it's in your password manager and you just 917 01:05:35.559 --> 01:05:42.000 use it. And another thing that's a really cool trick that the older databases 918 01:05:42.079 --> 01:05:45.039 did not do. Because they didn't they wasn't well known at the time, 919 01:05:45.719 --> 01:05:49.559 was how do you encrypt data at risk? Well, they all can encrypt 920 01:05:49.599 --> 01:05:53.599 it, they can use as standards and they can encrypt at risk. But 921 01:05:53.639 --> 01:05:57.920 where do you put the keys? That's the big question. And the model 922 01:05:57.920 --> 01:06:02.800 that I love the most is you have a master key that encrypts all the 923 01:06:02.880 --> 01:06:08.360 keys that encrypt everything else. So that level of indirection is awesome because the 924 01:06:08.360 --> 01:06:14.239 customer can can change the master key when they need to. The database is 925 01:06:14.320 --> 01:06:19.000 constant. A good one, a good back of database will automatically rotate it's 926 01:06:19.280 --> 01:06:24.400 internal keys and re encrypt data in files. When they optimize the file, 927 01:06:24.440 --> 01:06:30.519 you rotate that internal key so that your data that the customer could change it 928 01:06:30.519 --> 01:06:32.199 and own their master pastor. But you don't have to worry about at rest 929 01:06:32.519 --> 01:06:36.920 your keys are Your data is encrypted in a very secure way and then that's 930 01:06:38.000 --> 01:06:43.079 very maintainable. So the best databases do that technique. Some of the older 931 01:06:43.079 --> 01:06:46.119 ones don't. So that's keep that in mind. If a database has been 932 01:06:46.119 --> 01:06:49.480 around a long time and never really thought through these issues, they're going to 933 01:06:49.519 --> 01:06:54.679 have our time with security. Oracle or what does an okay job. I'm 934 01:06:54.679 --> 01:06:57.039 not going to give away all those secrets. I don't want to, like, 935 01:06:57.639 --> 01:07:00.559 you know, help packers out here, but I'll just say one thing. 936 01:07:00.880 --> 01:07:05.360 If there was, I can't say it, but I'll just they don't 937 01:07:05.360 --> 01:07:09.159 give extra well, but it's okay. I think they're doing it pretty well 938 01:07:09.159 --> 01:07:13.320 all by themselves. Or yeah, Oracle did. Oracle did a terrible thing 939 01:07:13.360 --> 01:07:16.559 and was embedding secrets in places they never should have embedded them, and it 940 01:07:16.599 --> 01:07:21.000 was really obvious and it was like, really, are you kidding me? 941 01:07:21.880 --> 01:07:26.679 And luckily hackers weren't super aware of this, but we were. And it's 942 01:07:26.760 --> 01:07:28.599 like, oh gosh, if they got a hold of this, they'd get 943 01:07:28.599 --> 01:07:31.199 the whole keys of the kingdom. I think Oracle latest releases they probably fixed 944 01:07:31.239 --> 01:07:34.280 it. I hope, but Oracle's so backwards cant pattle. They may not 945 01:07:34.360 --> 01:07:38.400 have. I haven't looked lately, so I'm not going to go any deeper 946 01:07:38.440 --> 01:07:41.880 into that. But like, there are so many holes in Oracle because it's 947 01:07:41.920 --> 01:07:45.679 an old system and they never really thought it through. I would never use 948 01:07:45.760 --> 01:07:49.760 these utel not an Oracle fan, and it's not because it's just because it's 949 01:07:49.800 --> 01:07:55.920 so complicated and complicated means not secure. It was complicated. You can't cover 950 01:07:55.960 --> 01:07:59.559 all your bases and make it secure. So I'm much a bigger fan. 951 01:07:59.599 --> 01:08:02.719 If you're eqal database, you know, SQL server is much simpler and Microsoft 952 01:08:02.760 --> 01:08:05.880 has kept it that way and so it's easier to secure it easier to run 953 01:08:05.920 --> 01:08:10.559 it. So from a DeVos perspective, Secret seqle server is really good. 954 01:08:11.239 --> 01:08:15.000 It's not as expensive as ourable, so it's not cheap. Postgress is, 955 01:08:15.000 --> 01:08:19.560 like I said, created by PhD grad students at Berkeley for the most part. 956 01:08:19.640 --> 01:08:24.319 And and the code, it's the code inside that thing is every you 957 01:08:24.359 --> 01:08:28.239 know, every developer rized different coastyles. Imagine over the last thirty years, 958 01:08:28.960 --> 01:08:32.479 every PhD student writing their own little module in Berkeley in the inside of Postgrass. 959 01:08:32.560 --> 01:08:36.439 It's just a it's a code nightmare. So the complexity of that code 960 01:08:36.479 --> 01:08:45.079 base makes that system hard to secure and complicated. Do they not use route 961 01:08:45.399 --> 01:08:50.199 DPMs on the physical devices to encrypt the master key in some way, so 962 01:08:50.239 --> 01:08:57.920 it's not actually exposed to the database process, rather than having just some master 963 01:08:58.000 --> 01:09:01.800 key that it generates. You know, network if you're across platform database, 964 01:09:03.119 --> 01:09:06.760 that depends on your operating system and so on. The ones the database they 965 01:09:06.800 --> 01:09:11.199 run on Windows that focus on Windows is a core platform. They do that 966 01:09:11.560 --> 01:09:15.319 like seql server. They can do that. Fair Coom does that. We 967 01:09:15.640 --> 01:09:19.039 use that technology running on Linux, though it's a little different. You have 968 01:09:19.079 --> 01:09:23.119 to it's a little harder because the OS doesn't support some of those things as 969 01:09:23.119 --> 01:09:26.560 well, and when you want to be a cross platform database, you have 970 01:09:26.600 --> 01:09:31.119 to work extra hard to figure out ways to to make things secure on Linux 971 01:09:31.199 --> 01:09:36.560 versus Windows versus Mac. May be the first person that I've ever heard say 972 01:09:36.680 --> 01:09:41.479 that it's more difficult to secure things on Linux. I feel like the HSM 973 01:09:41.520 --> 01:09:45.880 with pks, you know eleven has no problem encrypting whatever you've got, whatever 974 01:09:45.920 --> 01:09:48.920 you need to throw at it. So you know that that's an interesting train 975 01:09:48.960 --> 01:09:53.560 of thought. There then is a new one that I'll have to consider. 976 01:09:54.000 --> 01:09:57.439 Well, it's not I didn't mean to say harder as much as different. 977 01:09:58.520 --> 01:10:01.239 The harder part the harder part is if you're a company writing database software, 978 01:10:01.279 --> 01:10:06.840 you've got to use different technologies and test different technologies on each platform. So 979 01:10:06.880 --> 01:10:10.319 that's more of what it is. It's not that Linux is not secure. 980 01:10:10.359 --> 01:10:12.520 I'm not. I don't even want to begin to say that, because actually 981 01:10:12.479 --> 01:10:18.279 I like Linux a lot. But I will say securing Linux requires some specialty 982 01:10:18.319 --> 01:10:24.880 skills. That Windows is is well known as there for hacks and all that 983 01:10:24.880 --> 01:10:28.279 stuff. They are trying. They try to simplify things for their customers, 984 01:10:28.680 --> 01:10:32.840 especially on Window. Server is a pretty good platform, but it's so expensive 985 01:10:33.159 --> 01:10:36.399 you got to go Linux. Everybody goes Linux. So I'm so yeah, 986 01:10:36.399 --> 01:10:42.199 we we it's just Linux is you're in the open source world and you say, 987 01:10:42.239 --> 01:10:44.920 okay, I want to use this feature. Now I'll go find open 988 01:10:44.960 --> 01:10:46.079 source. Well, how do I know if that open source is safe? 989 01:10:46.079 --> 01:10:48.720 How do I know that open source hasn't been hacked? How do I know 990 01:10:48.760 --> 01:10:54.119 that that does a good job. Well, there's no company behind that open 991 01:10:54.119 --> 01:10:56.600 source. Typically, if you're talking about this kind of low level code, 992 01:10:56.600 --> 01:11:00.039 you're just bringing in some It was some developer who's going out there creating some 993 01:11:00.119 --> 01:11:01.840 thing. Then you bring it in, you run tons of tests on it. 994 01:11:01.920 --> 01:11:05.840 The work and cost of bringing that in can be really high if you 995 01:11:05.880 --> 01:11:10.520 want to make sure, if you want to guarantee it's secure, So companies 996 01:11:10.520 --> 01:11:15.039 don't do that. They just bring it in in hope because you can't afford 997 01:11:15.079 --> 01:11:17.560 to go and let's go run. It's spent two years testing this open source 998 01:11:17.640 --> 01:11:19.840 piece, you know, a piece of code to make sure it really works 999 01:11:19.840 --> 01:11:27.680 well, so you hope. So I think adding to that is there's the 1000 01:11:27.760 --> 01:11:32.720 different Linux distributions because what might be implemented in one Linux distribution might not be 1001 01:11:32.800 --> 01:11:39.239 implemented in another one, or it's implemented a different way. Yeah, and 1002 01:11:39.279 --> 01:11:44.119 everybody runs on red hat because you could count on all those features being there 1003 01:11:44.560 --> 01:11:48.399 and so or of course not everybody does completely on red hat, but the 1004 01:11:48.439 --> 01:11:51.560 red hat is the one that every database spender is going to run on. 1005 01:11:53.239 --> 01:11:57.880 And then do you support others? Fair Com has a history of running everywhere, 1006 01:11:57.960 --> 01:12:00.720 so we build our software to run on every possible platform you can imagine. 1007 01:12:00.760 --> 01:12:05.479 At one point we supported over one hundred and twenty nine operating systems at 1008 01:12:05.479 --> 01:12:09.880 the same time. Well, the world is luckily shrunk down, so now 1009 01:12:09.920 --> 01:12:13.880 you know we we support we still support all the UXes that are out there, 1010 01:12:14.079 --> 01:12:16.840 hp AI, x Q and X you name the you know, all 1011 01:12:16.880 --> 01:12:21.399 the Unix stuff. But when primarily people want today it's Linux and Windows, 1012 01:12:21.760 --> 01:12:25.479 and on the database world, not so much Mac. But we support Mac 1013 01:12:25.520 --> 01:12:30.680 as well because developers have Mac laptops. So we yeah, we we support 1014 01:12:30.720 --> 01:12:34.640 and we run it are extremely portable. We have fantastic All we written in 1015 01:12:34.720 --> 01:12:39.359 C and we wrote it in portable C code so that we can run on 1016 01:12:39.399 --> 01:12:43.560 any operating system, real time orperating systems, you name it. And not 1017 01:12:43.680 --> 01:12:48.359 every database can do that, so there's a real cost when they when you 1018 01:12:48.359 --> 01:12:53.119 buy. For example, mark Logic is a database that was optimized for Linux. 1019 01:12:53.159 --> 01:12:56.199 They did all their testing Linux, They coded on Linux, but then 1020 01:12:56.199 --> 01:12:59.640 a lot of their customers started buying it to run them Windows. They supported 1021 01:12:59.680 --> 01:13:03.079 Window, but it was the step and so you're like, it's all kinds 1022 01:13:03.079 --> 01:13:06.960 of problems on Windows because if you don't, if your juniors are all Linux 1023 01:13:06.960 --> 01:13:09.640 e geniors, they know how to do it there, but they don't know 1024 01:13:09.640 --> 01:13:11.800 how to do it on Windows, and then you create problems. So for 1025 01:13:11.840 --> 01:13:15.119 DevOps, it's really important for you to know is this is this database primarily 1026 01:13:15.119 --> 01:13:21.039 of Windows or a Linux database or is it really do the engineers really know 1027 01:13:21.119 --> 01:13:26.479 both really well and can support both really well, and your your code base 1028 01:13:26.560 --> 01:13:29.640 can run on all of them because it's designed that way. That's that's a 1029 01:13:29.760 --> 01:13:32.800 huge issue for you, because so many times you buy the product and run 1030 01:13:32.920 --> 01:13:36.520 on the wrong operating system for whatever reason, and and do you pay a 1031 01:13:36.600 --> 01:13:42.600 cost bug costs and a support cost. That's a good point. I mean, 1032 01:13:42.760 --> 01:13:45.000 I you know, I've been the Linux user for a long time, 1033 01:13:45.039 --> 01:13:48.760 and I just pray that there's some sort of Open Container Initiative compatible container out 1034 01:13:48.800 --> 01:13:51.720 there that I could just you know, pull it and run. And if 1035 01:13:51.720 --> 01:13:56.560 it's not, that I've add to the next technology. Yeah. Yeah, 1036 01:13:56.800 --> 01:13:59.560 And you have to have containers for most of these products, like Oracle. 1037 01:13:59.560 --> 01:14:02.239 I would never want install an Oracle without a container because that's just a nightmare. 1038 01:14:02.680 --> 01:14:04.960 For my first first day on the job, I was sitting next to 1039 01:14:04.960 --> 01:14:06.760 a guy and they said, what are you doing? He goes, oh, 1040 01:14:06.800 --> 01:14:10.760 I'm installing Oracle And I go, oh, how's that going? Well, 1041 01:14:10.800 --> 01:14:16.319 I'm on my third day, third day, third day, and like, 1042 01:14:16.359 --> 01:14:18.800 what the what do you well? I mean, you know, can 1043 01:14:18.920 --> 01:14:21.199 it be ten minutes? Can't you just run a script? No? No, 1044 01:14:21.319 --> 01:14:25.359 and it was just a I mean, Oracle's better than that today a 1045 01:14:25.359 --> 01:14:29.159 little bit. But you know you used to the minutes. But a container 1046 01:14:29.159 --> 01:14:31.479 you just pop in and rune. One thing about fair Calm, because we 1047 01:14:31.720 --> 01:14:36.680 are real sensitive this. We unzip and run us like that. You download, 1048 01:14:36.840 --> 01:14:41.840 unziped, run, you're going that's all there is. So we don't 1049 01:14:41.880 --> 01:14:46.199 even need containers because containers do slow databases down by about twenty percent. And 1050 01:14:46.199 --> 01:14:51.640 the reason they slow databases down is because the storage. They containers don't totally 1051 01:14:51.720 --> 01:14:57.199 virtualize the storage, but they they were out the storage through their subsystem and 1052 01:14:57.279 --> 01:15:03.119 it causes a performance loss. So containers databases or a performance problem. So 1053 01:15:03.199 --> 01:15:06.239 if you can run a database thats by unziped and run, and you can 1054 01:15:06.359 --> 01:15:11.479 run multiple instances of the database on the same computer, then you don't need 1055 01:15:11.520 --> 01:15:15.079 containers. Well, fair com is one of the only databases that can run 1056 01:15:15.159 --> 01:15:18.720 multiple instances on the same computer with an unzip and run out of the box 1057 01:15:18.760 --> 01:15:23.560 story. So we can run hundreds of database instances on the same computer. 1058 01:15:23.800 --> 01:15:28.119 Oracle takes over the whole machine. It assumes one instance one machine, single 1059 01:15:28.159 --> 01:15:31.399 server takes over the whole machine. Postcuss takes over the whole machine. That 1060 01:15:31.439 --> 01:15:36.159 means you need containers, right, because you need that flexibility. That's why 1061 01:15:36.560 --> 01:15:40.840 a fair Com I really like this core engine that we have because we don't 1062 01:15:40.880 --> 01:15:45.079 have those limitations of these other databases. And it makes a difference for DevOps, 1063 01:15:45.159 --> 01:15:48.840 especially like market logic took over the whole machine. You going to run 1064 01:15:48.840 --> 01:15:53.960 one instance on machine. And this is before container technology. This is about 1065 01:15:54.000 --> 01:15:56.800 ten years ago, right, well more than that, about twelve years ago 1066 01:15:57.199 --> 01:16:01.800 or thirteen anyway, we were looking at architecturally we wanted to run multiple instances 1067 01:16:01.840 --> 01:16:04.640 on the same machine. We had to use VMS to do it, and 1068 01:16:04.680 --> 01:16:11.039 that's even more of a HITD than containers, and it complicated our whole architecture. 1069 01:16:11.079 --> 01:16:13.640 If I could have run multiple instances on one machine, I could have 1070 01:16:13.680 --> 01:16:16.880 simplified the entire architecture, saved us a ton of DevOps time, development time, 1071 01:16:16.960 --> 01:16:24.039 engineering time, architecture time. But that limitation tied my hands. So 1072 01:16:24.119 --> 01:16:29.119 something like Faircom no limits on the architecture, which as an architecture I like 1073 01:16:29.199 --> 01:16:31.560 that I could just do what I need to do get the job done right. 1074 01:16:32.159 --> 01:16:40.760 Well, there you go. That was a random stream of It was 1075 01:16:40.840 --> 01:16:44.560 fun. That was that was a lot to take in though, and I 1076 01:16:44.560 --> 01:16:53.520 think it really it really highlights how much thought and effort and planning has to 1077 01:16:53.560 --> 01:17:00.399 go into your database solution. It's not really it's not really and oh, 1078 01:17:00.439 --> 01:17:02.520 by the way, task or it can be, but you're going to pay 1079 01:17:02.560 --> 01:17:09.439 for that for a really long time if you're successful at all. That's a 1080 01:17:09.560 --> 01:17:13.840 really important point because we at the last but I was working on this church, 1081 01:17:13.880 --> 01:17:17.319 that large organization. We had, we we had standardized, we had 1082 01:17:17.319 --> 01:17:20.359 certain databases we supported, like we started supporting it, you know, and 1083 01:17:21.920 --> 01:17:26.199 we had developers all the time they're bringing this under the hood. They would 1084 01:17:26.199 --> 01:17:29.399 go sneak out and go get a Mango or get a Cassandra, get into 1085 01:17:29.399 --> 01:17:32.039 the database that we weren't supporting it. And React was one of their favorites. 1086 01:17:32.079 --> 01:17:35.319 That bring it in is start build their app on it, right, 1087 01:17:35.560 --> 01:17:40.079 and then they go to release the production. The manager and the and the 1088 01:17:40.119 --> 01:17:43.279 infrastrut team goes, what is this, Oh, it's just a database, 1089 01:17:43.319 --> 01:17:45.279 don't worry about it, just all it. No, we can't who's supporting 1090 01:17:45.319 --> 01:17:48.439 it? Well we are, Well, no, you have to talk to 1091 01:17:48.479 --> 01:17:51.399 the database team. We're supposed to support these technologies. So then they call 1092 01:17:51.479 --> 01:17:54.920 me up and go, Mike, we're using this. Can you support it? 1093 01:17:55.479 --> 01:17:59.399 What we don't? What are you doing? And so like, no, 1094 01:17:59.479 --> 01:18:01.479 we we don't have the people because every time you bring a database in, 1095 01:18:01.520 --> 01:18:05.119 you're going to have to train people to read, to understand the technology, 1096 01:18:05.359 --> 01:18:09.479 to give it the proper support. You just can't throw someone at and 1097 01:18:09.560 --> 01:18:13.000 hope that they get their job. Then databases are kind of like a marriage, 1098 01:18:13.399 --> 01:18:15.159 you know, and you're you have to be serious about this. You're 1099 01:18:15.159 --> 01:18:19.920 gonna have that database for a long time for and you need to know how 1100 01:18:20.039 --> 01:18:24.399 to make that marriage work. And it's not just you're gonna get married, 1101 01:18:24.439 --> 01:18:27.399 because if you don't, you're gonna get a divorce. And but you can't 1102 01:18:27.399 --> 01:18:30.159 divorce the database. The problem is is still sitting there, it's still running. 1103 01:18:30.279 --> 01:18:32.399 It's still causing you trouble because you can't just rewrite your app overnight. 1104 01:18:32.760 --> 01:18:35.800 You can't just afford to do that. So this is a maybe it's worse 1105 01:18:35.840 --> 01:18:44.479 than you know. Marriages are great. I've just been You're stuck with it 1106 01:18:44.520 --> 01:18:50.439 forever, right, I think therapy podcast? Yeah, so yeah, you're 1107 01:18:50.520 --> 01:18:55.479 right. You just developers are sneaking these in and then no, it's no 1108 01:18:55.560 --> 01:18:59.039 problem. And next thing you know you've got you've got a real problem in 1109 01:18:59.079 --> 01:19:02.840 your organization. And we had to rewrite so many apps because the app couldn't 1110 01:19:02.880 --> 01:19:06.720 be supported. And you think about, you're gonna have a core team. 1111 01:19:06.800 --> 01:19:10.439 No matter what database you use, you're gonna have a core team that's going 1112 01:19:10.520 --> 01:19:15.039 to give you twenty four to seven support on that thing. And so you're 1113 01:19:15.039 --> 01:19:16.800 going to and to do that. You can't just put one person on that 1114 01:19:16.880 --> 01:19:20.880 team or you'll kill them off twenty four to seven, right, and even 1115 01:19:20.880 --> 01:19:25.560 if they're a ATAG guy. Like that's the Marcologic database for example, it 1116 01:19:25.600 --> 01:19:28.239 was like a Maytag database. It never went down, it never broke. 1117 01:19:28.680 --> 01:19:33.479 So we had two people running over over six hundred instances of Marcologic supporting the 1118 01:19:33.520 --> 01:19:38.640 whole thing throughout the entire organization. But they were still too because they were 1119 01:19:38.680 --> 01:19:42.079 twenty four seven support and they even they weren't called. They had to carry 1120 01:19:42.119 --> 01:19:44.199 the pager, they had to carry the cell phone, they had to be 1121 01:19:44.479 --> 01:19:47.520 had their laptop with them. The stress of the support is always with you, 1122 01:19:48.159 --> 01:19:51.239 and so you have to take that in consideration. When you bring in 1123 01:19:51.239 --> 01:19:55.359 a technology, you're gonna have to get your support people to support it. 1124 01:19:55.720 --> 01:19:58.640 That's like the secret conversation. It's like are you ready, like to the 1125 01:19:58.680 --> 01:20:00.720 development team, are you ready to for the new database bringing in? And 1126 01:20:00.720 --> 01:20:03.119 they're like, yes, we know everything about it. And there were only 1127 01:20:03.119 --> 01:20:09.279 response you can say to that as you're wrong, it's going to be okay 1128 01:20:09.359 --> 01:20:14.359 here, but you have no idea what you're talking about. Yeah. Well, 1129 01:20:14.359 --> 01:20:16.119 it was just to bring in mark Logical in my last organization, because 1130 01:20:16.119 --> 01:20:17.880 I was in charge of that whole thing that so I bring it up. 1131 01:20:19.359 --> 01:20:25.199 It took one hundred thousand dollars project to go bring it in and get it 1132 01:20:25.239 --> 01:20:30.760 integrated into infrastructure, to get all the support processes in place, to establish 1133 01:20:30.800 --> 01:20:33.880 a high availability version and how we're going to support that thing. I ran 1134 01:20:33.920 --> 01:20:39.359 that whole project and it was it was expensive and it was a real eye 1135 01:20:39.359 --> 01:20:42.439 opener to me, like why can't you just run it? But no, 1136 01:20:42.600 --> 01:20:46.640 it was a major project and because we did that, though we now have 1137 01:20:47.399 --> 01:20:53.439 it grew like crazy throughout the organization and it's super successful to this day in 1138 01:20:53.479 --> 01:20:58.880 that organization. Because deployments are just a piece of cake. The main the 1139 01:20:58.920 --> 01:21:01.880 maintenance is a piece of cake. Whole thing because because we brought it in 1140 01:21:02.079 --> 01:21:05.479 correct, but then these other ones like React came in and not only did 1141 01:21:05.479 --> 01:21:10.079 it come in surreptitiously and was never supported, the company went out of business. 1142 01:21:11.479 --> 01:21:15.600 And you know, so you got to think about you know, if 1143 01:21:15.600 --> 01:21:19.000 it's a long term relationship and your relationship dies, you know, you got 1144 01:21:19.000 --> 01:21:23.840 to think about that. That's a big one life support. That's a new 1145 01:21:23.880 --> 01:21:31.159 product. Right. I love that, But do you talk to developers. 1146 01:21:31.199 --> 01:21:33.359 I had so many arguments. They would say, well, it's open source, 1147 01:21:33.640 --> 01:21:39.199 it'll live forever. It's open source is free, Like, okay, 1148 01:21:39.439 --> 01:21:43.680 do you realize that there's a company that built this product and their entire goal, 1149 01:21:43.760 --> 01:21:48.680 whether it's Manga or Cassandra or couch base or faircom. If you're open 1150 01:21:48.800 --> 01:21:54.720 source, it's an illusion. It's a marketing strategy. It's totally an illusion. 1151 01:21:54.800 --> 01:22:00.520 And and you're developing your you're completely in fantasyland thinking open source is is 1152 01:22:00.840 --> 01:22:04.279 the answer because that company has to support it. They have the engineers who 1153 01:22:04.319 --> 01:22:08.800 built it. If that company goes under, it's not like the community will 1154 01:22:08.840 --> 01:22:12.840 pick it back up and run. That code is too hard. Database code 1155 01:22:12.920 --> 01:22:15.760 is way too detailed and hard for just anyone out of there. Oh, 1156 01:22:15.880 --> 01:22:18.680 I just get your grandmother to come and go. Program you know, get 1157 01:22:18.680 --> 01:22:23.840 it from GitHub and go change this forget it. This takes specialized engineers that 1158 01:22:23.840 --> 01:22:27.720 spent ten to twenty years of their life learning this code and learning how it 1159 01:22:27.760 --> 01:22:30.520 works and learning all the internals. So when that company goes away and those 1160 01:22:30.560 --> 01:22:34.760 developers are no longer there, they go to other companies. They're working on 1161 01:22:34.800 --> 01:22:41.760 other things. That database product is dead. So get another team. Like 1162 01:22:42.159 --> 01:22:45.640 when Oracle bought my sequel and then the team that didn't want to work for 1163 01:22:45.680 --> 01:22:49.079 Oracle left it built Maria dB, right they but the team left it built 1164 01:22:49.079 --> 01:22:51.920 another company and they forked the code. Can you do that? Yeah? 1165 01:22:53.239 --> 01:22:59.960 But will they do that? You know that's a big question and database software, 1166 01:23:00.800 --> 01:23:04.199 but that you're basically becoming the database company, right Like you're like, 1167 01:23:04.279 --> 01:23:06.479 oh, you know, you have to be okay with that. You have 1168 01:23:06.560 --> 01:23:10.960 to be willing to take that code, build it, run it, become 1169 01:23:10.960 --> 01:23:13.800 the experts of it yourself. If you're if you're going to go down that 1170 01:23:13.880 --> 01:23:17.119 route, yeah, for sure. And that's not realistic. It's just you 1171 01:23:17.159 --> 01:23:20.319 know, that would be if you hired me, for example, I could 1172 01:23:20.359 --> 01:23:23.560 go do something like that because that's the kind of guy I am. But 1173 01:23:24.239 --> 01:23:26.880 I'm kind of a Unicorn they're there. I mean, I'm not unique, 1174 01:23:26.920 --> 01:23:31.199 but I'm just saying there the Unicorn herd is not huge that that loves to 1175 01:23:31.199 --> 01:23:35.800 get to that level of code, understands what databases really are and what they 1176 01:23:35.800 --> 01:23:39.479 should do, and knowing that kind of code and make that happen. And 1177 01:23:39.560 --> 01:23:43.439 you can't replace people like me very easily, so and you don't want to 1178 01:23:43.479 --> 01:23:46.359 afford me, you know, I'm super expensive. So that's the other thing 1179 01:23:46.439 --> 01:23:51.760 that just because it's open source doesn't mean that there's a huge pool of talent 1180 01:23:51.880 --> 01:23:58.600 willing to work on that product for free. Yeah, oh yeah, and 1181 01:23:58.720 --> 01:24:01.199 are even capable of working on it right, you know, if they're at 1182 01:24:01.199 --> 01:24:05.000 the real engine level where you need to have where you need to fix bugs. 1183 01:24:05.000 --> 01:24:11.920 So so it's the open source database world is an illusion. And I'm 1184 01:24:11.960 --> 01:24:14.159 not being negative. I'm not anti open source. I don't want to come 1185 01:24:14.159 --> 01:24:16.399 across that way really not. It's just it's a marketing strategy. Get it 1186 01:24:16.439 --> 01:24:19.880 in the hands of developers so that they can go build their next product, 1187 01:24:19.960 --> 01:24:25.119 hopefully become the next Google or you know, and then and then they can 1188 01:24:25.199 --> 01:24:28.319 start paying for stuff. You know. That's the whole marketing gimmick of it. 1189 01:24:28.800 --> 01:24:31.359 But the reality is the open source versions are not secure. They don't 1190 01:24:31.399 --> 01:24:39.680 scale. They they're they they don't provide the tons of the let's see, 1191 01:24:40.720 --> 01:24:44.520 the secure at scale are the big ones. But you're also getting tools, 1192 01:24:44.840 --> 01:24:48.000 the tool sets for the backup, the recoveries, the management. Those are 1193 01:24:48.039 --> 01:24:54.159 only enterprise versions and those you have to have in a database. The vendorsor 1194 01:24:54.239 --> 01:24:57.479 is not stupid. They know you go open source for so long and then 1195 01:24:57.520 --> 01:25:00.640 eventually you're going to pay them. But the developer, it's a it's a 1196 01:25:00.680 --> 01:25:04.880 total marketing thing to suck the developer in because they get we all have dreams 1197 01:25:05.199 --> 01:25:09.039 of I'm gonna be the next Google. I'll use all this free software to 1198 01:25:09.039 --> 01:25:13.199 get myself up and running. But in a production environment when the thing goes 1199 01:25:13.279 --> 01:25:16.800 down, can you fix the bugs? No, you're gonna You're gonna immediately 1200 01:25:16.800 --> 01:25:20.319 get a support contract with the vendor. So yeah, they know that story. 1201 01:25:20.359 --> 01:25:26.640 So it's it's a game, a game. Yeah. The goal is 1202 01:25:26.720 --> 01:25:30.880 to make it easier to purchase the subscription than to refactor your code to use 1203 01:25:30.880 --> 01:25:34.279 something else. Oh yeah, which is not a hard goal to achieve, 1204 01:25:34.560 --> 01:25:40.039 right, And to me, I call it a trojan horse. You know 1205 01:25:40.199 --> 01:25:43.439 you come in, it's free, it's open source, you know, and 1206 01:25:43.560 --> 01:25:46.159 then it's in the organization. Next thing you know, Wow this is expensive. 1207 01:25:46.520 --> 01:25:51.520 Wow this is hard while we're locked in. Oh too bad, so 1208 01:25:51.640 --> 01:25:58.199 sad, And then the vendor is for happy. They're playing the long game. 1209 01:25:58.239 --> 01:26:00.960 It takes a long time for this to happen. Was praying a really 1210 01:26:00.000 --> 01:26:04.079 long game here? Oh yeah, I mean you would think at this point 1211 01:26:04.159 --> 01:26:11.159 people would start to realize that this is the pattern and maybe consider that when 1212 01:26:11.199 --> 01:26:15.039 they're going after certain technologies. But it doesn't seem like that's the case. 1213 01:26:15.279 --> 01:26:18.520 They're still deluded that the price tag for the source code is there, it's 1214 01:26:18.960 --> 01:26:26.000 zero dollars or franks or yeah. I think that. I think that our 1215 01:26:26.039 --> 01:26:29.840 industry is still so new, that we have so many new people coming into 1216 01:26:29.960 --> 01:26:35.439 it every year, that those lessons aren't being translated. There's too many people 1217 01:26:35.520 --> 01:26:41.319 for people like us. There's too many people entering every year for us to 1218 01:26:42.840 --> 01:26:46.920 share our stories with all of them, to keep repeating those to help them 1219 01:26:47.000 --> 01:26:54.560 prevent repeating our mistakes. Well, and engineers are notoriously bad at making costs. 1220 01:26:56.239 --> 01:26:58.960 I mean, I know where it comes from. It's oh that money 1221 01:26:58.960 --> 01:27:01.399 would come out of mind right, I don't want to pay that money for 1222 01:27:01.479 --> 01:27:05.800 it, and they don't understand the business justification and what really goes into the 1223 01:27:05.800 --> 01:27:11.319 total cost of ownership. Right. Yeah, engineers are not good business people, 1224 01:27:11.359 --> 01:27:14.640 and it's it's a good thing because business people are not good engineers. 1225 01:27:14.680 --> 01:27:18.039 I mean there's exceptions, of course, but the engineer is going to go, 1226 01:27:18.079 --> 01:27:20.199 I could just build this myself. Why do I I can build my 1227 01:27:20.239 --> 01:27:25.039 own backup solution. I got build my own operations manager, you know, 1228 01:27:25.039 --> 01:27:27.600 I could build my own security solutions. So the engineer goes, I could 1229 01:27:27.600 --> 01:27:30.520 work my way around this problem. Well, as a company, you're like, 1230 01:27:30.680 --> 01:27:32.800 I'm not paying you to do that. That's way more money than paying 1231 01:27:32.840 --> 01:27:35.920 a vendor to do this for me. And how do I know you're going 1232 01:27:35.960 --> 01:27:39.479 to do security? Right? How do I know you even know what a 1233 01:27:39.520 --> 01:27:44.239 backup solution is? I mean, how many software developers know the cycle that 1234 01:27:44.279 --> 01:27:47.680 the backup schedule you should really follow on a database and how that really should 1235 01:27:47.680 --> 01:27:51.279 work the best practices there? Well, ninety nine point nine percent developers have 1236 01:27:51.359 --> 01:27:56.239 no clue, so they couldn't even begin to build that solution. So yeah, 1237 01:27:56.279 --> 01:28:00.239 developers are it's not it's delusion, but it's more ignorance. And I 1238 01:28:00.239 --> 01:28:03.119 don't mean that they're ignorant. I'm not saying that. I mean just lack 1239 01:28:03.159 --> 01:28:09.600 of knowledge, lack of experience. It's easy to imagine yourselves because the developers 1240 01:28:09.640 --> 01:28:12.159 are awesome. I mean, I'm a developer macrot right, we could build 1241 01:28:12.159 --> 01:28:15.319 anything, and you're like, I could build that. I love building that. 1242 01:28:15.520 --> 01:28:18.840 Let me build that for you. But as a business decision, you've 1243 01:28:18.880 --> 01:28:21.640 got to really think that through because you don't want your developers. You want 1244 01:28:21.640 --> 01:28:26.479 your developers to build your product, your value added product that you're going to 1245 01:28:26.520 --> 01:28:30.000 sell, not build infrastructure, not build the lower level stuff. Yeah, 1246 01:28:30.000 --> 01:28:36.640 and that's a lesson learned through time and experience, the difference between could I 1247 01:28:36.680 --> 01:28:41.039 build it and should I build it? Oh? Yeah, for sure. 1248 01:28:41.319 --> 01:28:46.880 That's hard because I want to build everything, right, I mean every day. 1249 01:28:47.960 --> 01:28:50.359 And we have this problem at fair Com too because we are in a 1250 01:28:50.479 --> 01:28:56.000 total engineering shop. So we want to build everything ourselves. And I have 1251 01:28:56.039 --> 01:28:58.239 to say, you know what, let's get an open source for that one. 1252 01:28:58.279 --> 01:29:00.399 But let's bet it carefully, you know, Let's don't reinvent the wheel 1253 01:29:00.479 --> 01:29:03.760 every time, because that's what we want to do in our nature. So 1254 01:29:03.840 --> 01:29:10.720 let me go build that cool thing. So yeah, it's hard. Managing 1255 01:29:10.720 --> 01:29:13.880 to engineers is hard to because you gotta say, nope, you can't do 1256 01:29:13.960 --> 01:29:15.520 that, you can't do that, we're going to buy this, you know. 1257 01:29:16.279 --> 01:29:20.039 But you really have to make those good decisions as a software company. 1258 01:29:21.760 --> 01:29:26.520 And I mean that's where the fallacy is though, right, Like we have 1259 01:29:26.560 --> 01:29:29.520 some backlog of work and we can get through it, right like, you 1260 01:29:29.560 --> 01:29:31.640 know, it's just it's just these three or four things and then we're done, 1261 01:29:31.760 --> 01:29:35.000 and maybe we can move on to new things. And realizing that there's 1262 01:29:35.079 --> 01:29:40.079 a whole list of other issues and tasks that are going to come up associated 1263 01:29:40.119 --> 01:29:45.960 with managing that technology us as you start to build things out. It's so 1264 01:29:45.039 --> 01:29:49.039 true when you're a naive about something, you think it at a ten thousand 1265 01:29:49.079 --> 01:29:53.279 foot level, it looks easy. Well, backup can't be that hard. 1266 01:29:53.840 --> 01:29:56.119 Well then, you know, just call the data to a new location. 1267 01:29:56.239 --> 01:30:00.119 Done right, done, done. That's that's what Mango said to do in 1268 01:30:00.159 --> 01:30:01.960 the beginning. Yeah, just cop just just copy our data. But what 1269 01:30:02.000 --> 01:30:05.279 if your data is in transition and it's half written a disc When you copy 1270 01:30:05.319 --> 01:30:11.079 it, you're copying, you're copying broken data. You know, it's not 1271 01:30:11.439 --> 01:30:14.760 you have to cuiesce that database, so it's not writing the disc while you're 1272 01:30:14.760 --> 01:30:16.960 copying it. But then what if your database is huge and you're trying to 1273 01:30:17.000 --> 01:30:20.479 copy all that data all the time, you'll never get it copied in time. 1274 01:30:20.840 --> 01:30:24.920 You know, you're right out of time. So so you need a 1275 01:30:25.000 --> 01:30:28.439 copy what's changed? Well how do you do that? And you know once 1276 01:30:28.479 --> 01:30:31.039 you go down this rabbit hole. But it's but that's foot levels. Just 1277 01:30:31.039 --> 01:30:35.239 copy the data, piece of cake. Is there is there actually a solution 1278 01:30:35.399 --> 01:30:40.640 to this in the database base where writing to the journal and the actual table 1279 01:30:41.239 --> 01:30:45.760 like can somehow be strongly consistent so that the backup being taken irrelevant like will 1280 01:30:45.760 --> 01:30:50.560 always be one hundred percent consistent. Or it's just some small percentage chance that 1281 01:30:50.600 --> 01:30:55.199 the journal will have data that's not actually in the database or something like that. 1282 01:30:55.600 --> 01:30:58.600 Well, in fact, you hit the nail on the head the the 1283 01:30:58.600 --> 01:31:01.319 the ideas you cuiesce your data, which means stop writing to the data files, 1284 01:31:02.359 --> 01:31:06.359 but keep writing to the journal, so the journal it gets ahead of 1285 01:31:06.359 --> 01:31:12.000 the data files. But you could copy now the data files safely or make 1286 01:31:12.000 --> 01:31:15.399 an incremental copy of what's changed in the data files quickly over somewhere else. 1287 01:31:15.800 --> 01:31:20.520 Then then you unques the database at that point you mark in your journal. 1288 01:31:21.359 --> 01:31:25.279 You've already marked in your journal where you started a backup, and then you 1289 01:31:25.319 --> 01:31:29.600 could copy the journal files over too. So the restoration, you're restoring the 1290 01:31:29.680 --> 01:31:33.680 data files first, then you restore the journal from that point in time and 1291 01:31:33.680 --> 01:31:38.399 now you and then you replay the journal to catch the database up. So 1292 01:31:38.520 --> 01:31:45.720 that's the technique all the major databases use. But that no single databases start 1293 01:31:45.760 --> 01:31:49.720 out ignoring the journal completely and just did dumb things like we'll just copy the 1294 01:31:49.720 --> 01:31:55.319 files over here. They've gotten better now, but you know, because they're 1295 01:31:55.359 --> 01:32:00.920 customers who have told them your data is corrupt, so they they're gradually fixing 1296 01:32:00.960 --> 01:32:05.319 stuff like that. But yeah, that's the difference between the database backup and 1297 01:32:05.359 --> 01:32:11.319 the database restore. One doesn't care if it you corrupt. Yeah right, 1298 01:32:11.359 --> 01:32:15.800 the backup doesn't care. Oracle spent a fortune on when they do their backup 1299 01:32:15.840 --> 01:32:17.760 this. The Oracle is really good about not corrupting data that they're in. 1300 01:32:17.880 --> 01:32:24.640 So spare comp we built technologies designed to not lose the data because corrupt data 1301 01:32:24.640 --> 01:32:28.079 is a big problem. So in Oracle is doing the backup, they're reading 1302 01:32:28.159 --> 01:32:32.720 every block of data and validating it to make sure that the all the safeties 1303 01:32:32.720 --> 01:32:36.840 they built into that block are there so they're not so if the field data 1304 01:32:36.880 --> 01:32:41.079 is off or something that you could tell, they detect it and then they 1305 01:32:41.079 --> 01:32:45.640 market. So you know when your backups have corrupted data in them, so 1306 01:32:45.680 --> 01:32:49.319 you can start dealing with the issue. Because if the worst thing in the 1307 01:32:49.319 --> 01:32:54.359 world is you have a backup that's three months old and you just had ransomware 1308 01:32:55.000 --> 01:32:59.199 and you got to restore and that all that data is corrupted somehow, and 1309 01:32:59.239 --> 01:33:02.800 you're like, uh, what do I do? See, Yeah, these 1310 01:33:02.800 --> 01:33:08.439 are these are the things that are real. The answer there is you polish 1311 01:33:08.520 --> 01:33:12.399 up your LinkedIn profile. You're lucky you're not the business owner, right, 1312 01:33:12.439 --> 01:33:16.439 That's that's where you're Yeah. DBAs get fired over that kind of thing, 1313 01:33:16.600 --> 01:33:20.439 or or at least depending on what's going on, you know, sometimes they 1314 01:33:20.479 --> 01:33:26.720 do sometimes down. But I mean, I've mortified that database company could be 1315 01:33:26.880 --> 01:33:31.239 walking around out there without having a backup strategy that is actually paying attention to 1316 01:33:31.920 --> 01:33:36.560 live data streams that are still coming in in a high throughput, high volume 1317 01:33:36.640 --> 01:33:41.119 environment Like that just seems for me, like, who are you that you 1318 01:33:41.119 --> 01:33:45.439 think you can just run a database, uh and as a service and and 1319 01:33:45.640 --> 01:33:49.560 you know walk away like this just seems like a promise that's by default being 1320 01:33:49.760 --> 01:33:55.680 needs to be made. Yeah, totally. Here's an example. We Firkom 1321 01:33:55.680 --> 01:34:00.239 also has another product called RTG, which is our Cobal modernization solution. Turns 1322 01:34:00.279 --> 01:34:02.960 out that Cobyl writes data the exactly way I M does. So what we 1323 01:34:03.159 --> 01:34:09.399 is we stuck our database, which is that highly available mission critical database underneath 1324 01:34:09.439 --> 01:34:13.560 a Cobyl program, and we and the Cobyl file handling routines just go to 1325 01:34:13.640 --> 01:34:17.840 our product directly. Well, the vendors are buying our products to go out 1326 01:34:17.840 --> 01:34:21.520 of their Cobyl apps because they can't rewrite the Cobyl app. It's the means 1327 01:34:21.520 --> 01:34:24.760 of loes of code, millions of dollars. It's just too risky. Their 1328 01:34:24.760 --> 01:34:29.199 whole business, the financial industry wrote everything in cobyl s little snow secret. 1329 01:34:29.239 --> 01:34:32.199 All your favorite banks you know, are are running Cobyll programs for all your 1330 01:34:32.279 --> 01:34:39.199 data because it's at is a controversial word there, Yeah, well yes, 1331 01:34:39.920 --> 01:34:43.760 or all you're hated or whatever, then yeah, all the your So the 1332 01:34:43.800 --> 01:34:47.039 one of the one of these big financial companies is coming to us and they 1333 01:34:47.119 --> 01:34:50.880 can service all their current customers. But they want to go to tier one. 1334 01:34:51.199 --> 01:34:55.720 They sell baking software to Tier one to Tier two and three systems. 1335 01:34:55.720 --> 01:34:59.319 They want to go to tier one, and they're the largest baking software system 1336 01:34:59.359 --> 01:35:03.479 in the world. But there are certain huge customers they can't service because they 1337 01:35:03.560 --> 01:35:08.079 run a Cobyl and the filesystem can't scale to what they need. So they're 1338 01:35:08.079 --> 01:35:11.640 putting our product right underneath the COBAL which is a plug and play. Our 1339 01:35:11.720 --> 01:35:14.680 tg stets were ready to go because you just plug us right in under the 1340 01:35:14.800 --> 01:35:16.840 Cobyl engine. You don't change a line of Cobyl code. It just works, 1341 01:35:17.119 --> 01:35:21.640 and then our database scales it so all the things you're talking about backup 1342 01:35:21.880 --> 01:35:27.640 recovery. Cobyl can't do any of that stuff. They back up corruptive files 1343 01:35:27.680 --> 01:35:30.920 all the time. But what we could do is we now bring the technology 1344 01:35:30.960 --> 01:35:33.680 to the table to create a storage system, to create the database. Create 1345 01:35:33.720 --> 01:35:39.680 a storage system snapshot, which these are huge, multi terabyte you know, 1346 01:35:40.079 --> 01:35:44.840 like eighty terabyte databases. They're huge. You can't back those up by copying 1347 01:35:44.880 --> 01:35:48.279 files, so you have to do storage snap shots of those things, and 1348 01:35:48.359 --> 01:35:54.359 then you can then uncreates your database and then copy the transaction logs over too. 1349 01:35:54.439 --> 01:35:59.560 Startur snapshot the transaction logs, and then the storage system snap shot can 1350 01:35:59.600 --> 01:36:01.039 restore your data. You save the snapshots, and then if you want to 1351 01:36:01.039 --> 01:36:05.479 restore it, you just revert to the snap shot, apply the transaction logs. 1352 01:36:05.600 --> 01:36:10.920 You're back up and running, and Cobalt files can't do any of that 1353 01:36:10.960 --> 01:36:15.279 system. But you put the Faircom database underneath it, you instantly transform that 1354 01:36:15.680 --> 01:36:21.880 these legacy Cobol systems into modern systems. The only reason COBAL is dying is 1355 01:36:21.920 --> 01:36:26.760 because it's not the language. Language isn't bad. It's the data systems was 1356 01:36:26.960 --> 01:36:30.399 where the data was built into the data processing was built into the language. 1357 01:36:30.439 --> 01:36:32.960 You open files, you write the files that they didn't. They didn't do 1358 01:36:33.039 --> 01:36:38.920 what c did and separate data from the language. They kept data in the 1359 01:36:38.960 --> 01:36:45.000 language together. So the answer is put a real mission critical database underneath your 1360 01:36:45.000 --> 01:36:47.359 COBOL system. And now your Cobol system rocks and rolls just like every other 1361 01:36:47.399 --> 01:36:50.800 system in the world. And you know, whether it's Java or c Sharp 1362 01:36:51.239 --> 01:36:56.199 or Go or whatever. Language, that's all COBAL is is a language. 1363 01:36:56.479 --> 01:37:02.600 Now the data system modernized instantaneously because we have all the mission critical scalable features 1364 01:37:03.079 --> 01:37:09.079 that COBAL needs that centered the hood. So that's the power of having a 1365 01:37:09.159 --> 01:37:15.239 real mission critical database under your in your solution. Wow. Yeah, Well 1366 01:37:15.880 --> 01:37:17.359 we could go on forever. Maybe we could come back and talk some more, 1367 01:37:17.399 --> 01:37:25.159 because there's the IoT world is exciting and there's an IoT and I really, 1368 01:37:25.279 --> 01:37:30.159 just for my own personal curiosity, I want to dig in. I 1369 01:37:30.159 --> 01:37:34.960 want to have you back on the show and dig in to the LDS work 1370 01:37:35.039 --> 01:37:38.960 that you're doing, because you've already mentioned that you had like a team of 1371 01:37:39.000 --> 01:37:46.279 like sixty DBAs and like a thousand engineers and that transmitting money around the globe 1372 01:37:46.359 --> 01:37:53.079 was too slow using existing systems, so you built your own money transfer system. 1373 01:37:53.119 --> 01:37:55.760 Like, to me, that's just fascinating. And the fact is it's 1374 01:37:55.880 --> 01:38:02.840 like the overlap between the church and technology there, I think is just really 1375 01:38:02.880 --> 01:38:05.640 really fascinating. So I want to have you back on just to talk about 1376 01:38:05.680 --> 01:38:10.560 that. Oh cool, Yeah, it was. It was an awesome place 1377 01:38:10.920 --> 01:38:16.560 because they are so technology focused and cutting edge in the technology world because it's 1378 01:38:16.560 --> 01:38:21.680 all about the members and making their lives better and so using technology to do 1379 01:38:21.720 --> 01:38:27.760 that super important. So yeah, and the church, Yeah, we talked 1380 01:38:27.760 --> 01:38:30.760 about that the other the next episode. That'll be good, right on, 1381 01:38:30.880 --> 01:38:35.399 right on. Have you ever wished that you had a group of people that 1382 01:38:35.439 --> 01:38:39.960 were just as passionate about writing code as you are. I know I did. 1383 01:38:40.039 --> 01:38:42.640 I did that for most of my career. I'd go to the meetups, 1384 01:38:42.680 --> 01:38:45.600 I try and create other opportunities, and it was just really hard, 1385 01:38:45.800 --> 01:38:47.399 right the meetups. I got some of that, but they were only like 1386 01:38:47.479 --> 01:38:50.600 once or twice a month, and it was just really hard to find that 1387 01:38:50.640 --> 01:38:55.159 group of people that I connected with and really wanted to, you know, 1388 01:38:55.239 --> 01:38:58.760 talk about code a lot, right, I mean, I love writing code. 1389 01:38:58.800 --> 01:39:02.359 I think it's the best. And so I've decided to create this community 1390 01:39:02.880 --> 01:39:06.640 and create a worldwide community that we can all jump in and do it. 1391 01:39:06.680 --> 01:39:11.560 So we're going to have two workshops every week. One of those or two 1392 01:39:11.600 --> 01:39:14.279 of those every month are going to be Q and A calls right where you 1393 01:39:14.279 --> 01:39:17.079 can get on you can ask me or me and another expert questions. The 1394 01:39:17.119 --> 01:39:21.600 rest of them are going to be focused on different aspects of career or programming 1395 01:39:21.760 --> 01:39:26.319 or things like that. Right, So it'll go anywhere from like deployments and 1396 01:39:26.359 --> 01:39:30.640 containers all the way up to managing your four oh one K and negotiating your 1397 01:39:30.000 --> 01:39:33.439 benefits package. Well, we'll cover all of it. Okay, and then 1398 01:39:33.439 --> 01:39:38.760 we're also going to have meetups every month for your particular technology area. So 1399 01:39:38.800 --> 01:39:42.159 we have shows about JavaScript, to react, angular view, and so on. 1400 01:39:42.520 --> 01:39:44.800 We're going to have meetups for all of those things. I'm going to 1401 01:39:44.840 --> 01:39:47.319 revive the freelancer show. We'll have one about that right so you can get 1402 01:39:47.359 --> 01:39:51.760 started freelancing or continue freelancing if that's where you're at. And I'm working on 1403 01:39:51.840 --> 01:39:59.239 finding authors who can actually do weekly video tutorials on some thing for ten minutes. 1404 01:39:59.479 --> 01:40:02.000 This relate again to those technology areas so that you can stay current, 1405 01:40:02.079 --> 01:40:05.560 keep growing. So if you're interested, go to toppendevs dot com, slash 1406 01:40:05.640 --> 01:40:12.039 sign up and you can get in right now for thirty nine dollars. When 1407 01:40:12.079 --> 01:40:15.560 we're done, that price is going to go up to seventy five dollars, 1408 01:40:15.000 --> 01:40:19.880 and the thirty nine dollars price gets you access to two calls per week. 1409 01:40:20.720 --> 01:40:25.600 The full price at one hundred and fifty dollars, which is going to be 1410 01:40:25.600 --> 01:40:29.680 seventy five dollars over the next few weeks. That price is going to get 1411 01:40:29.720 --> 01:40:32.239 you access to all of the calls and all of the tutorials and everything else 1412 01:40:32.279 --> 01:40:38.359 that we put out from top endevs along with member pricing for our remote conferences 1413 01:40:38.399 --> 01:40:42.359 that are coming up next year. So go check it out topendevs dot com 1414 01:40:42.359 --> 01:40:50.319 slash sign up. So let's move on to picks or In last week we 1415 01:40:50.319 --> 01:40:56.600 talked about movies, Did you bring anything anything new this week? I'm working 1416 01:40:56.640 --> 01:41:00.439 on it, you know. I of course had to spend all my time 1417 01:41:00.840 --> 01:41:03.840 since last episode actually thinking about what my pick is going to be this time, 1418 01:41:04.960 --> 01:41:08.960 which is not a movie, so it's slightly more interesting. I think 1419 01:41:09.000 --> 01:41:12.640 my pick this time is going to be a local stack, which is a 1420 01:41:12.920 --> 01:41:16.439 technology that takes AWS offline so you can do local development work. And I 1421 01:41:16.439 --> 01:41:20.119 think they're doing a lot of interesting things there and trying to build parity for 1422 01:41:20.319 --> 01:41:23.840 what is running an AWS I can see is a huge challenge. I mean, 1423 01:41:23.840 --> 01:41:28.399 obviously it's not mission critical level of stuff. But one of the reasons 1424 01:41:28.439 --> 01:41:31.920 I bring this up is because we just create my company it just completed a 1425 01:41:31.920 --> 01:41:36.920 collaboration with them super successful where we released an authorist extension for local stack to 1426 01:41:38.479 --> 01:41:43.439 amp up the security on the authentication authorization side. So I think great team, 1427 01:41:43.520 --> 01:41:45.560 awesome stuff that they're doing. If you don't know what local stack is 1428 01:41:45.560 --> 01:41:49.640 and you're using aws, you definitely have to check it out right on. 1429 01:41:50.079 --> 01:41:55.199 Very cool. All right, Mike, what you bring for us this time? 1430 01:41:55.600 --> 01:41:59.880 Well, you said something kind of personal. Whatever. So I'm a 1431 01:42:00.039 --> 01:42:03.560 I got my PhD in music theory and my bachelor's in music composition. So 1432 01:42:03.600 --> 01:42:09.000 I'm a musician at heart. I work technology because that's where the money is, 1433 01:42:09.039 --> 01:42:12.760 and my mind thinks that way too. That I love it. But 1434 01:42:12.840 --> 01:42:15.479 I played the piano, and so one of my favorite piano pieces, the 1435 01:42:15.560 --> 01:42:20.479 Rockmando off Piano Concectial number two. I like so many, but that is 1436 01:42:20.600 --> 01:42:25.199 just an amazing piece of music. And when I listen to music like that, 1437 01:42:26.199 --> 01:42:30.960 I actually it's like programming. Now. It sounds weird, but I 1438 01:42:30.000 --> 01:42:35.359 see structure everywhere. It's layers upon layers of If you think of objectority programming, 1439 01:42:35.359 --> 01:42:40.199 that's what a music composition is. Is like an objectorated program with layers 1440 01:42:40.279 --> 01:42:44.680 upon layers of objects nesting with each other in real time, with beautiful sounds. 1441 01:42:45.760 --> 01:42:50.239 And so I love I love bridging the world of computers and music. 1442 01:42:50.319 --> 01:42:55.079 That's just kind of way my brain works. That's cool. I've never thought 1443 01:42:55.079 --> 01:42:58.520 of it that way, but yeah, that makes a lot of sense. 1444 01:42:59.239 --> 01:43:04.159 Do you have like specific background music that you use when you're working. Uh. 1445 01:43:04.239 --> 01:43:09.600 Yeah, none. If I turned on music, my braid goes straight 1446 01:43:09.600 --> 01:43:12.840 into the music, forget everything else because I'm I, like I said, 1447 01:43:12.840 --> 01:43:15.760 I got a PhD music theory, so my brain's an analytical brain. I 1448 01:43:15.760 --> 01:43:19.640 don't just right here music. My braid is analyzing music, and so it 1449 01:43:19.680 --> 01:43:24.600 takes over my whole braid. So no, I can't, you know, 1450 01:43:24.760 --> 01:43:27.399 in the exact same way. Like there are so many times I used to 1451 01:43:27.399 --> 01:43:30.720 listen to music while I was doing things and I would have to take my 1452 01:43:30.760 --> 01:43:32.960 headphones off so I could think, and I think there's nothing to this, 1453 01:43:33.199 --> 01:43:36.359 Like people who are driving cars, which are super common, turning down the 1454 01:43:36.439 --> 01:43:40.800 radio so they know where to pull over on the side of road. So 1455 01:43:41.039 --> 01:43:44.399 you know there's something there for sure. Yeah, no, I agree. 1456 01:43:44.479 --> 01:43:47.199 The The only exception, like, the only thing I can listen to in 1457 01:43:47.239 --> 01:43:54.239 the background and stay focused on work for me is Pink Floyd's Dark Side of 1458 01:43:54.279 --> 01:43:59.000 the Moon. And I don't know why that is continuously Yeah, yeah, 1459 01:43:59.039 --> 01:44:03.000 yeah, it's one of my playlist and I just repeat it and and it 1460 01:44:03.159 --> 01:44:08.880 just plays, but it puts me in flow state. But any any other 1461 01:44:08.960 --> 01:44:14.359 song and I'm paying attention to the music. Yeah, there's something like just 1462 01:44:14.439 --> 01:44:16.439 white noise in general, all that it can be used to stimulate. So 1463 01:44:16.520 --> 01:44:18.800 you know, maybe this for you, you know, with your brain waves, 1464 01:44:18.880 --> 01:44:21.239 is just how to get you in that state. I you know, 1465 01:44:21.359 --> 01:44:26.560 it can be anything, and for you it's this one. Yeah. Cool. 1466 01:44:26.640 --> 01:44:30.359 Well, I brought two picks to the show today. The first one 1467 01:44:30.399 --> 01:44:33.840 the same one that I picked last week. Platform Con coming up. I 1468 01:44:33.840 --> 01:44:39.960 think it's coming up in May, five day virtual conference about platform engineering and 1469 01:44:40.039 --> 01:44:44.560 all the aspects of that. Luca who's been a previous guest on the show, 1470 01:44:44.680 --> 01:44:47.439 he'll be back on the show in March to talk about platform Con. 1471 01:44:47.479 --> 01:44:53.720 But it's really great speakers lined up there, so at platform con dot com 1472 01:44:53.840 --> 01:44:57.399 check that out. Totally free, five day virtual event. And then the 1473 01:44:57.439 --> 01:45:05.199 other thing not technical related at all, but recently I put on a throttle 1474 01:45:05.199 --> 01:45:10.800 body space or a cold air intake and a mass airflow sensor on my truck 1475 01:45:10.920 --> 01:45:15.560 to improve the performance of it. Bought all of them from American Trucks dot 1476 01:45:15.600 --> 01:45:19.119 com and it was super cool because you tell it which vehicle you have and 1477 01:45:19.319 --> 01:45:28.199 the website re updates itself to only show stuff that is compatible with your exact 1478 01:45:28.279 --> 01:45:30.119 vehicle, so you don't buy something that's not going to work. But then 1479 01:45:30.159 --> 01:45:35.600 they also have on every product page they have videos showing you, you know, 1480 01:45:35.640 --> 01:45:39.319 how to install it, what the performance is going to be like before 1481 01:45:39.359 --> 01:45:43.000 and after where they'll put the truck on the dino and show you the output. 1482 01:45:43.079 --> 01:45:46.920 But just a really well done website. So yeah, American Trucks dot 1483 01:45:46.920 --> 01:45:50.520 com. Does it come with the vision pro you know that you can put 1484 01:45:50.560 --> 01:46:00.800 that on. Cool note, but that's actually a pretty cool idea. Cool 1485 01:46:00.960 --> 01:46:03.159 All right, Well, I believe we have an episode. Mike, thanks 1486 01:46:03.159 --> 01:46:09.800 so much for being on the show. This has been there's been information overload 1487 01:46:09.960 --> 01:46:16.800 in every positive aspect of the term. Yeah you really you did a great 1488 01:46:16.880 --> 01:46:24.520 job of the highlighting the role that DBAs have had and the fact that that 1489 01:46:24.520 --> 01:46:28.920 that need still exists. Yeah for sure. So thank you for thank you 1490 01:46:28.920 --> 01:46:32.079 for coming on, and we'll check in and have you back up back on 1491 01:46:32.119 --> 01:46:35.760 the show because I want to have that follow up conversation with you. Cool. 1492 01:46:35.960 --> 01:46:44.720 I have some burning questions in that area. All right, Larren, 1493 01:46:44.800 --> 01:46:46.520 thanks for joining me, love having you on the show. Man, looking 1494 01:46:46.520 --> 01:46:51.359 forward to many many future episodes and everyone listening. Thank y'all for listening, 1495 01:46:51.560 --> 01:46:53.920 and we'll see y'all next week.