Adaptable Databases and Effective Data Integration in Modern DevOps Environments- DEVOPS 193

All right, what's going on, y'all? Welcome to another episode of Adventures in dev Ops. I'm your host for today, Will Button and joining me for his second attempt, which is always exciting because you know, I wasn't sure he was going to come back. I actually had a job one time where at the end of my first day, my boss said, hey, thanks for showing up. It was great working with you. Hope to see you tomorrow, but if not, enjoy your new laptop. But welcoming back

to the studio my new co host, Warren. Hey, Warren, what's going on? Oh? Thanks? Well, you know, I definitely plan on being here for at least one more session after this. I think i'll have I think i'll have, you know, beat by maybe a couple of days. But you know, thanks for welcoming me. Yeah, for sure. I like that you put a commitment out there, but not a huge commitment. You're like, I'll be here for at least one more episode and then we'll reevaluate. You know. I have a whole talk on this,

but I think achievable goals are really important. Also joining us in the studio today, I'm looking forward to this. I have Mike Bauer's chief architect at Faircom Corporation, and he he's got quite the background here. We were talking before I hit the record button. He's actually got a little bit more experienced in this industry than I do, which is rare when you get to my age. So I'm excited about that. He works on high performance no SQL,

SQL databases, IoT platforms. He's the author of pro cs s and HTML design patterns and this is super cool. A member of the i n C I t S Technical Technical Committee that develops the standards for SEQL and GQUL the graph Querry language, and that's super cool. And then if we have time, one thing I do want to get into here, just from looking at your background. You are the principal architect at the LDS Church, and I just think that's got to be a super cool, fascinating job where you

get like those two industries melding together. But anyway, rambling aside, welcome Mike, glad to be here. Yeah, it's it's fun. You guys are blast already cool. Well, like I tell my wife, if nothing else, I'm entertaining, No thanks for thanks for being on the show. So let's talk a little bit about your background. You know, like I mentioned, you've been doing this for a a minute or two, and you you appear to have built a lot of your expertise in the domain of databases.

So tell me a little bit about how you got to that point. Hey, folks, this is Charles Maxwell. I've been talking to whole bunch of people that want to update their resume and find a better job, and I figure, well, why not just share my resume. So you if you go to top endevs dot com slash resume, enter your name and email address, then you'll get a copy of the resume that I use that I've used through freelancing through most of my career, as I've kind of refined it

and tweaked it to get me the jobs that I want. Like I said, topendevs dot com slash resume, we'll get you that and you can just kind of use the formatting. It comes in word and pages formats and you can just fill it in from there. Yeah. I started out as a software developer and did that over twenty years and had a variety of experience is writing software for consulting firms, and then moved into manufacturing and built software solutions

and integrated factories like in the silicon industry. I wore the buddy suit going into the fabs, you know, like the Intel commercial they're dancing that was. I'm not in the commercial, but I was in the I was definitely in the fabs, integrating these expensive million dollars pieces of equipment and learning all their protocols. And then from there I moved into working like at Freightliner and

helping them automate their systems. You know the sprinter van that everybody gets and either rebuilds it so they can do campers out of it, and they're like, this's the Mercedes van and the Mercedes Freightliner van. That van has a computer in it. And I wrote the program that the compiler and the system

that programs that whole thing. So that was that was really fun. That's cool, And that's got to be some interesting constraints there, just knowing that once that thing leaves the factory, you've got limited options for getting updates or communication to in front it. Right. Oh yeah, you got to take it back into the service system and they'll plug it in and then then you

can update it with the new electronic parameters. But that's actually a real computer with it's completely The engineer that designed it wanted it to be one hundred percent programmable, which is unusual. Usually you just have these little parameters, turn on, the heated mirrors, turn on, you know this other feature. But he wanted it completely programmable, and so I had to write a compiler, a true compiler that compiles down to buy machine code to program that thing.

That's one of those things that I feel like you'd be able to look back later and be like that was either a really great idea or that was a really bad idea. Right, Well, I think the spinner bands still doing well, so I guess it was a good idea. But my fear was, you know, I would have a bug in there, and people's lives would be at risk because you know, if there's a bug, bands can crash, So that was kind of scary. But no, it's been

really good. There's the vehicle's great. And it was hard the electrical engineers who were his peers. I was in the meetings with them and they were criticizing him like crazy because they couldn't understand what he was doing. Because he made the thing programmable. No one does that. But he wanted flexibility. He wanted a system that would last forever. That you, of course, if you're programmable, you can then make it do anything in the future.

And so in the meetings they were killing the project because no one could understand it. But I was getting what he was saying, and I thought, I can do this. I can write the competitor to program this thing. And so he talked to him and I switched my role from building the system that the web system that would actually send down the electronic parameters. I built most of that already, and then we switched gears to writing the compiler, and I spent a year on that and got that going. So yeah,

I think it was good. Beach did talk to Freightliner see if they thought it it's still good. That's a good question, you know, because they had to pay another firm to take over when I left, I was a consultant, and so that firm has to maintain it, so we'll see.

I don't know. But then from there I went to I was watching all these people that were DBAs making a lot of money at the time, right back in the two thousand era, the DBAs made more money than developers, and I was also frustrated that Microsoft had shifted their whole tool set and I had become an expert in certain tools and they completely pulled us out from under me, and I was frustrated, and I thought, Okay, more money.

I love databases. I love data. So I kind of decided I wanted to become an Oracle DBA because they made the most money for sure, And so then I decided to switch careers and move into that area. And

then is from there that I got employed at the Eldis Church. And I started out as an Oracle DBA and the person who hired me wanted me to do that for a little bit and then become a manager of the team, and I went from and I did that, and then I I was a dB Oracle DBA for about a year and I managed the Oracle DBA team that the core team that supported cour teams with twelve engineers, and we supported over sixty database engineers, so DBAs south through organization, we had on thousands of

databases. And then from there I became the data architect for the entire organization, which is a multi billion dollar international organization, so it's very large with thousands of developers. You think the church, but it's it's an international organization

that builds lots of software for its members to do membership like things. Like one of these systems was an international banking system because the church brings in tithing from all over the world and they need they it's very important to keep this money safeguarded. Right there is no international banking system that you can just buy. You just can't. You know, that doesn't exist, So we had

to build it. So I was the lead on the data side for that whole project to build a brand new international banking system from the ground up. So that's the kind of stuff I did there. And while I was there, I looked into these no SQL databases, so we brought in everyone you

could think of. This was right during the whole revolution between the sequel and the no sequel, and so I was right in the middle of all that, and I became an expert in mark Logic, Mango dB Cassandra, and then we had a bunch of and of course the Oracle sequel server and then mark Logic, which is an XML database, and so those databases were on my team, and I was the architect for helping people decide which databases to

choose. So I became really good at each of those technologies and supporting them as a developer. Right as a developer, why would you choose one of these databases that I invised the whole you know, Like I said, we had a several thousand developers, so I was advising them on which database do you want to choose for your next project? So that was that's where I

became. I went to conferences, I started presenting a conferences, and that's where Faircom saw me and they go, well, we want you to become our chief architect because Faircom builds as for forty years has built a database product and they are the Fundamentally, Faircom is a no SQL database, but it has SQL capabilities, and they wanted to make their no SQL features more modern. They had a forty year old ISAM technology which is actually amazingly fast and

efficient but very hard to program, and they wanted to modernize that. So I was brought on board to turn Faircom dB into a JSON database and a SQL database and an M database at the same time on the same data. So you could have three APIs that are completely different on the same data and give you three advantages like the sequel as universal standardized works with everything, and the M is super fast, bare metal. A record on disc is a

record in memory in your process, no layers in between. Nothing can beat the performance of that layer. It's just you have to program it. You have a lot of programming to do. And then I added a JSON layer, so you can create with JSON and get data back as JSON and it's the same data we get in SQL, the same data we get in the

ICM. So that's what for the last five years, that's what I've been working on, and we're delivering here in March a brand new version that has full Jason capabilities like Mango or couch Base plus these other two layers, which the other with couch Base has a SQL plus plus, so they have a

sequel like solution we treat. We have true ant CI squel solution Faircom does with the Jason with this low level API, so when your queries can't get fast enough, you can go inside the machine, inside the engine with that ISM layer and get incredible performance. And I'm not exaggerating when I say faster than anything else on the market. I got a machine doing a million inserts per second, and Oracle would and I twoed Oracle database. I built Oracle

exit data replacements at the Ilias Church. I design those and built them faster than Oracle exit data runs using an Oracle database. So I know what speed is and how fast the Oracle can go. And this blows Oracle away. It's just the level of programming you have to do is about four or four times harder at that ISM layer than sequel is. So the underlying data is the same in any case, it's just you choose which of those three options you want to use to get the data exactly. Wow, that's pretty good.

Yeah, so fun. The Jason is. I love the document database world. You know, I as a developer. I was. I was a developer first before I became a DBA and before I became a data architect. So I love building software. I love doing it quickly, and I know I don't hate. I hate to spend days on the low level stuff twiddling, you know, finding reading this spec and figuring out okay, well that bit, oh yeah, that bit's the one that makes it work.

You know. The Jason changes everything. You get up and running in no time. You're building solutions so fast. It's so simple, and and it still has the core engine speed of our core ISAM. It's just it has the translation layer tuned from Jason. So it's fast and it's easy and it's fun. So yeah, Jason is one of my favorites, so of course, but I love SQL. Like I'm on the Insights Committee, like you said, I part of the Equal Standards Group. The sequel is a great

language, and we're enhancing it, like to do more things. And GQUL is a graph queer language, right, so we're enhancing that and so those are so I really am a fan of those technologies. But it's not It shouldn't be one game in town. Your database shouldn't lock you into just I'm a SQL database, that's all I do. Or I'm a even stranger, I'm an ISAM database, which is what fair Come has been for until the last until now. And then of course the Jason is like, well we're

Manga, says well, I'm a Jason database. That's all I really do. So yeah, you have the best of all worlds for sure. Yeah, because each one has its own strengths and weaknesses that our gun to one of those is going to line up with what you're trying to achieve better and and that just help shore. It has the potential to help you build more quickly and actually focus on what you're delivering to your customers rather than focusing on

the technology limitations. Yes, you get that scenario where Okay, I want SQL for most of my stuff because I can write those queries fast, I can join my data, have flexibility. I know I could achieve any kind of functionality in sequel, it just may not be super fast. And then you go, but what about that one query. There are times when I'm been in an oracle in that big banking system I was talking about. We had a query that ran for two weeks because they had so many billions and

billions of records turning through them and making reports. The thing ran for two weeks, and so I had to go in there and I write low level functions to really tune this and that. We spent weeks tuning that query. Finally we got it to run in four hours, but it was a massive effort. And I was thinking about this. If I would have had the ISAM engine, that would have been that would have been a day of work, and I would had total control and I would have gotten ten times faster.

It'd have been forty minutes there instead of forty four hours, you know, from two weeks. So that's that's the kind of when you need to get under into the engine and say, I know how to make this fast. I know what I need to do. Just get out of my waist. Sequel, let me do it. And it's really hard in these SQL databases to go down there and do that. So yeah, you use the right tool for the right job on the same data makes a big difference.

What I'm hearing is you left the Oracle world and went to the no sequel world and it's better. Yes, well but yeah, that's true. But I the sequel that does things that the no squel can't do, and that's really important. The nosequel world threw the baby out with the bathwater when they said we don't need we don't need acid consistency. Well, actually, I know the president of Mango dB, not the current one but the one previous one, and you know, we've be met a lot and talked and and

he says, you know, by the way, don't tell anyone. I guess. I guess I'm telling everyone now because he's gone. But they go, you know, we know we need to be acid compliant, we know we need to build. It's just hard, it's really hard, and it slows us down, and so we're just telling everybody you don't need that stuff. It's eventually consistent. It's awesome, and it's you know, eventually good in terms of consistency. But eventual consistency is a euphemism for never consistent.

And if your data is not consistent, that's not a good thing. It means you write a lot of code to compensate. There are some use cases where it is good, So don't get me wrong, there are some use cases eventually consistence perfect. Those are the exceptions. Most of the time you need consistent data your customers expect when they put something into query it and it comes back. And Mango wrote all kinds of workarounds to make a lot of

illusions happen. I'm not saying it's a bad product. I'm just saying that when you need consistency, it's really hard to get it in a no SQL database. Now fair comes different. We have our engine is at its core consistent, and then if you want to relax that and go inconsistent, I'm going to use the less fun term inconsistency of less. Is it eventually consistent, then you can and then you know your trade offs. So I think it's good to have an engine that you really can tune to go where you

needed to go. But the other thing about seql that they threw out was the ad hoc query ability, and the Mango kept a lot of it, but a lot of other databases threw that one out, and then they said, well, we don't need joints. Well, that's the dumbest thing I've ever heard. You can't denormalize your data to put everything that you ever possibly could to query and put it into one thing. If you did, you'd

have the tired database in one Jason document. You know, let's just make a whole database on one joy and we could carry the heck out of it anybody want. Yeah, but that won't perform you to have a whole database level locks like Mongo used to have, you know it just you need to

break your data into pieces. You need customers to be separate from orders because customers are not orders, and orders are separate from products because they're not the same thing, and you need so you need to break them apart as soon as you break them apart, then you have to join them. And so SEQL is fantastic. It joins, It has all these great join technologies to bring the data back together at high speed, and developers have forgotten that.

They forgot because it's under the hood, it's invisible in the sequel engines. They just think, oh, yeah, you just go loop through and join it by hand. You really how much code you have to write to do that? And then it's slow because you don't get the cool algorithms like the merge join the index, the hash joins the index, joints, all these really cool technologies that speed things up that sequel engines have built in over forty

years of two those things. Developers don't even know what they are for the most part, so they don't even realize what they're missing. And so what you need it You need SQL for those kind of things because it's good at those, but you need no SQL for other kinds of things like JSON for the simplicity and development and for the flexibility. You know, Jason is not so rigid. You can add new things as you go, but there's always

a caveat with you add new things as you go. Let's say you put them in some documents, some properties in some documents and leave them out of others, and you run a query. If the property is not there, the document doesn't show up. And now your queries aren't useful because you're not getting everything. So you need some schema level protection to Jason and say,

you know, I'm queering on this property. You better have it there and you better index it, you know, And so you need It's more than just let's just throw everything in a bit bucket and hope it works, which is how no SQL markets itself. I can't just do that and expect your app to work. So that's why I'm a big passionate person. And it's not because I work at Faircom. I came to work at fair Com because I'm passionate about you need multiple models. You need when you need consistency,

you need it. When you need less consistency or eventual consistency, you need it. When you need SQL and joins, you know you can't get with that. You need that technology, and when you need Jason, you need flexibility, you need it. So why not have an engine in a model that can do all of those things? And that's my dream because I wasn't finding it really anywhere, and when Faircom recruited me five years ago, this

is what I wanted to build. I've been wanting to build my own nose SQL database for the last fifteen years, and so I went, oh, this is my dream job. I get to design and build my dream database. So and releasing the first version of that database, like I said in March, so I'm super excited about that. I'm thinking to like the cloud providers and what they're offering as far as no SQL and cloud providers databases and SQL ones, and I get the sense that the no sqle ones are always

cheaper and easier to get up and running and start integreeting with. And I'm wondering how much that encourages developers around the board engineering departments, even startup companies that grow to eventually make them the primary use case for whatever sort of data they need to store. And I keep thinking, well, maybe if we want SQL to still have a world like where is the cheap to run, very very easy to spin up straight away? Like where is that? Yeah?

Yeah, and Oracle is the most complicated, hard to learn technology ever invented in the universe. I'm not exaggerating that. You know, single servers easy, you know, Microsoft SQL servers a beautiful easy piece of cake. And Postcress is kind of in between Oracle and siql server because it's some source and they have all these PhD students at Berkeley just adding new features and it's ad hoc and it's not reorganized as well. So Postcress has is harder than

SQL server. Oracle though, is just a nightmare. I've never seen things so complicated. So, yeah, where is the easy SQL database that you could just stand up in the cloud? I mean, you could argue SQL server might be that database, but then what about the no sequel? Right that the no SQL databases are so specialized with a few exceptions, Like you take Amazon they have there, they have Dynamo dB, and Dynamo dB is

really a key value store that it's all about the key. You can have a hierarchical key, and you can if you can segment your key properly, you can query down inside your key and get subsets of data. You can have secondary indexes, but that's really just another database under the hood with with doubling your cost for every secondary index, and you know, by the time you look at really doing that for real, Like, you know, how many indexes do I have a real database like a Oracle or single server.

I have thousands of indexes in a real application. Well let's see to imagine the cost of at a thousand copies of my data in Dynamo dB just to try to do the same kind of thing. It's just ridiculous. So Dynamo dB is a good example in my mind, of a specialized database that's good for certain use cases like use your profiles. If you want to get use your profile data fast and you want guaranteed response times. I want to look up Warren, I want to get your data app Boom, it's there.

You know it will boom it's there. So that's Dynamo dB. That's why they admitted it for their own Amazon dot Com. You know, it's good for those use cases. But that's not what you build an app on. I need an app that needs to grow with the company. I have yet to see an app that said, oh yeah, here's the specs. They're perfect. You build it in six months, will never change, it will

never evolve it, We'll never have another use case. You know, it's you know, the exact opposite right, you're tweaking that thing forever and you go. Then the customer comes back, Oh, I didn't think about this.

How do you get customer? I want to go around a career that gives me all the customers that made these orders, where the customers were over forty years old, and the products were oreos, and the orders are made last month, and you got to join that data together and you got to filter those three take those three pieces of data and bring it all together in a filtered way. And you're like, uh, I can't do that in Dynamo dB. I didn't. I didn't denormalize my data properly to answer that

question. Sorry, let me go copy all my data and then put it over here and that other specialized database. And now the customers do this. I teams do this. Like there's a one of our customers built a cloud solution. They had five database technologies in Amazon that they thought this would be great. We'll use these specialized databases and we'll build each one. We'll spread the data across them. The cost of that application is so high no one

will buy it. So their product uses fair Com and it's super fast. The cloud version with all these databases is way slower, so expensive, no one will buy it. They're they're looking at putting Faircom in the cloud cloud just to run their product in the cloud because you don't have the complexity or they and the costs is so simple and inexpensive. So yeah, I think it's important to keep all those things in mind when you build a product.

Complexity is your enemy, and that's what the cloud makes you do. It's complex solutions. I'm not anti cloud. I'm just saying the cloud, the salesman and the cloud wants you to buy five databases. They want you to spend up all this because they make a fortune off of you and they don't and they think that's the way to go because it it's their financial you know,

it makes them rich, so it's great for them. But yeah, and not only do you have like the cost of maintaining those five instances, but like the the ETL and the data transformation for replicating that data is not a trivial task. You know, you have to hold the data, make sure you're getting the last the correct data and making the right transformations to it, and then writing it to that new data source and verifying that it's there.

And like the the maintenance and overhead of just keeping that process alive is a dedicated team. It is just to write it. But then I love the DevOps angle. The dedicated team to keeping that alive is people are so expensive. You know, you don't want to hire me to go build your systems, and as you're gonna put me on a very productive environment because I'm super expensive. And now you're going to say, now, Mike, you're you are in DevOps. You need to keep this complex five database system alive.

I think of all the break points. You've got network connections between five different systems. Each of those systems, typically in the cloud, is sharded, so it scales horizontally. That means multiple servers in each database that have to be kept running. And you say, well, Amazona will do all that for me, Well they do, and they don't. They keep it up, they patch it for you. But making it work, troubleshooting the problems in your application across all the systems, oh, DevOps the developer can

do all that. Well. The last thing I want to do is a developer, is maintain infrastructure. Is I don't want to support that stuff. I want to throw it over the wall and let those guys do it. But now nope, DevOps developer, you are on call. You're gonna go fix it. You're going to go maintain it. And that's we're going to do that to you because we want you to build a simple, maintainable solution.

That's not possible in the cloud unless you switch your paradigm to something like a Aircom database where you say I'm going to do I'm going to get a tool that gives me the it's not just a Swiss Army knie because it gives you the wrong idea. It's like a bunch of tools. It's like, we don't even have the right analogy. It's three APIs over the same engine. It's not like three hammers like cosmocbs is five hammers. There are if

you think you're buying five one one database engine with five APIs. No, every time you put data in one of those engines, like there're no SEQL engine or their SEQL engine, it's completely separate engine with the data separate. It's a marketing gimmick to say it's one database. No, it's a bunch of different databases or your data spread out all over the place. So having a real database with multiple APIs on it is. It's sort of like a

Swiss Armony knife. You get the best of all the above, but it's one engine, which Swiss Armon Knife's not that way, you know. So it's a bad analogy. But so you know you mentioned earlier that earlier in your career, like the DBA was the the highest paid member in engineering, and I remember those days. Everyone wanted to be a DBA and the DBAs

had this almost limitless power. They could stop a production release and its tracks and not tell you when they're going to release it, and the entire company was like, oh, well, okay, you know, but they did a lot of work. You know, they did add value because they they were answering and designing for a lot of these problems we've been talking about so far. But when I look around today, I don't see DBAs anymore.

And I know that there are still some out there and some companies still have them, but for the most part, there are no DBAs, but those problems still exist. So what are the what are the things that as DevOps and as software developers, what are the things that we should be thinking about, or what are like the high level thumb rules we should be using to avoid making us really wish we had hired DBAs. Yeah, I think that no sequel moment was really the no DBA movement at this right, I totally

get it because when I was at Freightliner, we had a DBA. This person she was the how I would say, she's the Nazi DBA. I mean, it was just a nightmare. You try to go and you give her your schema and she goes, nope, nope, nope, go fix it. What do you want when you make it right, I'll approve it. Well, why do you when you make it right? Like see, then you go, well, what is right to you? Because right that because it was right to me, you know, So I go tweak it

again. Finally, at one point I said, you know what, she's disapproving every single thing I'm doing. And I know I'm not doing a bad job here. I know the rules of normalization, I know all this stuff, and I had normalized it beautifully and I also tuned it for performance. And then she got Then I realized, you know what she is wanting simple. She wants one bulletproof schema that will work for any kind of data, anywhere, at any time, and I'm like, I know how to do

this. I'm going to build a database within a database. So I designed five tables that if you use it just right, you can put any data without ever calling her again. I showed this model to her and she goes perfect approved because I would never have to go back to her again, and she didn't have to talk to me again. And it was like, this is the but this most horrible thing ever created. This is the anti pattern

of all data designs. So yeah, so this is an example of why developers like, Okay, this is a dumb DBA creating really bad designs, fall breaking all the rules because she doesn't know any better, and and it was really sad. But that's the kind of stuff like I'm free now, I don't have I'm a developer. I can just build my app. No DBA to get in my way. But to your point, we lost a

lot of things. For one, the developer lost a DBA to take the heat because the DBA sits between infrastructure and the developer, and the first thing an app has a problem, the developer just points to the DBA as your fault. They always do that, and then DBA points to infrastructure. It's your fault, right, and so it's usually it is infrastructure's fault because they

have storage goes out or some network thing went wrong. But sometimes it's the database, and a lot of times it's the app itself, you know. So it's it could be anywhere, but the DBA is right in the middle. You take the DBA away to what happens to developers on the hook for everything except for the infrastructure, and the infrastructure guys are worse than DBAs to do it. It's not my storage system. I don't have any problems.

I had a one time it was I had. I had so many storage problems at one place I was working that we had to hire ten thousand dollars per consultant to come in and run in scripts on the system to prove it was the storage rate because the storage r egg. I kept saying, no, it's not my problem. I knew it was the storage. So we paid ten thousand dollars to prove it was a storage to get the problem fixed, to get to get our solution built. So yeah, now the developer

has to do that. The developer doesn't even know what I ops are. The developer doesn't even know what latency is. I mean, how in the heck are you supposed to get a developer even talk the lingo of the infrastructure folks to figure out a problem. So you take the DBA away, You're you're asking for all kinds of headaches and problems. And then there's data. Data requires some structure, it requires some forethought, and a developer lives in the now. It says, how can I get this feature out the door

today? How can I crank this code out as fast as possible? Let QA get the bugs out? You know, Well, that last thing they want to think about is how do I structure my data to survive the test of time? Is my application ages I'm going to I'm going to really have to rewrite everything if I don't design this data well a good DBA. A good DBA not the one that a head of Fredeliner would come back and say, how do how do we make it bulletproof? But not overdesigned? You

know, it's that sweet spot. And then most developers don't understand that, and so they just crank it out, and then they're rewriting and rewriting and rewriting. Their companies pay a fortune for these developers to rewrite it. Because they didn't have forethought and so, and Agile just makes that worse because Agile is like crank the teacher out this week, our sprint's done, get it

out the door, show the demo, show the UI. Absolutely, the uh I doesn't have the data structure and it so no one sees that or cares about it. Now, before the Agile people get angry at me, they would say, well, that's not true agile, and I agree with them, except for every company I've worked for that does agile, doesn't do true agile. They do what I just said, crank it out, get it out the door, show the UI. So there's reality here. Yeah.

I think if the excuse is is always well that's not the pure implementation we designed, then maybe maybe that's a problem with the purity of your design. Yeah exactly, Yeah, yeah right, I'm just you know, I keep going on with my head like I wonder if something regarding how we treat databases today and the separation of ownership maybe in this regard, has devofs failed

us. Yeah. I think we need balance again. I think Agile and DevOps and some of these new and then no Squl trends which threw the DBA out with the bathwater. You know, I think that is went too far. I think I'm not And in fact, some companies are bringing back debas for some database like Mango, DBA and Cassandra are so hard to maintain they hire full time people. They don't call them DBAs as much, but they're administrators to keep the system running because Mango is pretty hard to keep running,

and so is Cassandra. In fact, my last job, we hired a full time person just to reboot the Cassandra database every week because and it's not just the database is a whole bunch of servers. By the way, Cassandra is super expensive. If you're going to go down to the cass you better really know what you're doing. Because that's my least favorite database of all time for because it dev ops as a nightmare in it and it's so complicated to

design. It takes you ten times longer to build anything because you have to denormalize everything because you can only query data in one table, so or you have multiple tables. They're white column tables. But if you can't join so you're basically saying all my possible careers I could ever do have to match one table and you and you you know, we just talked about that earlier. You have to join, but because you can't at Cassandra, you do you

just it drives you crazy. It took us five years to build an application that you could have built in six months in some of the night fair com dB because Cassandra's limitations and in that database, we had a hard just to reboot all these servers in the cluster once a week. He just his job was to write, you know, run these scripts to reboot them, make

sure they came back up. And nothing went down on that overall cluster database, but the servers themselves were going down and back up because Java has garbage collection and casoder's written in Java, and so when that hits your database performance just takes so you have to you have to reboot the server to clear out the Java Java, the garbage collection engineer Java, just to make the thing

run. So I was like, oh my gosh. You know, that's why there's so much marketing high ground no sequel, which is the promise of a developer owns their world. Well, when you own the world, like you're saying, Warren, you know, it's kind of the death of DevOps because developers don't want to be that involved in the ops side, in the administration side of anything, and so they don't and it's pulling teeth to get them involved. So yeah, I think it's a real problem for DevOps to

not have database specialists. So like we have front end in the developer where we have frontend specialists and back in specialists, your back in specialists are now the DBAs they need or really know your data. So I think I think that's good too, but you got to realize your back in specialists really need to know your data engine and think about data and if you do that, I think you're going to be fine as a company. And then the front

end guys will never do DevOps because they're just the front end app. So the back end you're backing engineers are your DBAs, they're your DevOps people. So hire data savvy back in engineers and you'll be fine as a companycause they'll make good decisions. I feel like this is a hot tag, but maybe it's if we're always using a database where we need to hire an additional person in order to figure out and run it effectively. Has that database technology failed

us? Like no one to be using Cassandra, if it really is true that we have to hire people to manage that. And I feel like the promise of the no squel, as you pointed out, is that you can have the usage of those databases by engineers and run them without hiring an additional

person. I mean, how do we rectify that in the world where we stop using these technologies where you have to hire a DBA or whatever the new term is system administrator for our database type, Because as long as we have them, people are going to keep falling to the trap of maybe we can use that database of what it promises on the marketing website, but then find out later that we need to hire a really high paid specialist in order to

come in in order to actually utilize the technology effectively. Yeah, I think I think that's what the whole no sequel moment was about. Was more high you know, they were it's a good thing to compete with SQLQ SQL databases were kind of sitting on their laurels, not innovating enough in real ways that that developers need. So no SQL was great and is great for that, but it doesn't you can't hide the reality that work needs to be done. In fact, I had a really wise engineer once told me, you know,

it doesn't matter where you put the work in a software project. The work needs to be done. So if you move all the work to the developer, great, but make sure that you're going to have to have specialized developers who know how to do the work. The work doesn't The data is

hard. You have to think about co locating data. You have to think about do I run the code on a separate server or on the database server, because if it's a batch job or bulk processing job, the code has to run near the data because network latency and network throughput is going to kill you. By moving the need to off the server somewhere else and bringing it back. You need to run the code on the server. So there's these specialists who know how data works, and you can pretend, oh, yeah,

we got rid of that. And that's what the no sequel movement did in the and the and the in Mango is the most successful of all of them, fifth most popular database in the world. Now, by pretending that these problems don't exist and the developers is fully in charge, it's a brilliant marketing play. Totally brilliant but the reality is now the developer is the DBA, so and that that work didn't go away, And as a developer, did you really want to be the DBA. That's that's the question you have

to ask yourself. If you're back in engine, if you're back in developer, now you're the hated DBA because you're gonna build a web service and the friend of the guys is going to give you this year and go, no, I've got to refracture my data. That's not going to work for me, and then then they're gonna hate you. So then there'll be a revolution against the back end engineer. It's all fronting the engineers. I don't know,

I'm joking on that, but it could happen. I don't mean it's a bit ridiculous, but actually there are plenty of products out there that claim that they are back ends as a service and from some company that is offering this and you don't have to worry about how your data even looks like or anything like. You just throw data at us and we'll store it and do the right thing. And I think the same probably can be said of all of those products as well. Right, totally, totally their work has to

be done. Somebody has to think about data and the structure and where you're going to process it. And it's a specialty. So figure out where as an organization, figure out where you want to be. I don't think no, I don't think SEQL databases are dead by any means, and I don't think the DBA for those are dead. I think we just need this. Seql is innovating and they're embracing Jason a little more. The secret databases. Do you have Jason support? Postgress is the best at Jason support, and

that's why it's becoming really popular. But you could choose a kitchen sink database like Postgress or Oracle, which has everything you can imagine in it, but none of them are really awesome except for the sqel engine. Or you could choose especially database like Mango that's really good at JSON technically Bison, you know, but then it and then but that's not really good at the joining of

data. So there's not there's really no perfect solution out there yet. That's why I'm working at Faircom because my goal is to build the right solution. And to your point, that's point warrant about. People just want a service. Right, that the data layer moved from a seqel layer, which traps the data behind SQL, the SQL career language, to a web service layer,

which frees the data in JSON. Right. So well, with fair coom dB, we have the seql air, we have the ISAM layer, which we need super speed, but now we have the Jason layer, and it is the Jason layer is the service. It's it's over HTTP. So you just send JSON requests over HTTP and then you get answers back and the JSON and the answer comes back to JSON. So your data is Jason, your query's or Jason. Everything's Jason. And it is a web service over

Https. So we provide that now and we and and like you said, everybody says, well now we need to transform the data. We need to reshape the Jason. So that's the next phase we're building here at Faircom is that is the VA JavaScript engine into our product to do all those fancy transforms on the server side, so you get the data shape to the way you

need it. But that doesn't even though that's to me, that's a game changer and and and potentially it could even replace a lot of back end development because we are a web service as well, But that doesn't mean it replaces all of the back end development just really simplifies their efforts. But you you still need to think about data. That doesn't change the fact you've got to think like a DBA, a developer DBA. Where you're where you are thinking

about our architecture DBA, How should the data be data? How should we organize the data? How shoul to be model the data? So we could build an application that can survive the test of time. Maybe eighty percent of the time. You'll never get one hundred percent, but eighty percent is pretty

awesome. But if you use something like if you don't do any of it, you're gonna be surviving twenty percent of the time on your current design and rewriting eighty percent of the time, and your company is as a developer, it's great job security, and developers actually think about those things. Oh yeah, this is great, I'll be employed here forever, you know, but

it's not good for the company. So any manager listening to this to really pay attention that developers are protecting themselves by cranking out stuff fast and they know they have to rewrite it and they're going to job security is there, and you're paying them the biggest bucks now to do all of that, you should think really carefully about data design and cutting, you know, really reducing costs.

Hey, there, this is Charles Maxwood. I'm excited because I wanted to let you know about this thing that I pulled together that I had just I've been dying to have this for years and I never felt like I could, and then I just realized that there's no reason why I can't. So I'm putting together a book club and we're going to read development focused books, career books, you know, technical books, whatever. The first book that we're going to do is going to be Clean Architecture by Uncle Bob Martin.

If you're not familiar with clean code or some of the other stuff that Bob has done, check that out. I've also talked to him on the Clean Coders podcast, which is on top end Devs. But yeah, we're going

to get on. He's going to show up to some of our meetings, and what I'm thinking is we'll probably have like five or six people part of the conversation along with Bob and I at the same time, and we'll just so somebody can come on, they can ask their question and then we'll just rotate people through, so we'll mute one person, unmute another person when it's their turn to come on and be part of the discussion. So we'll do

that for like an hour, hour and a half. And then the other part of it that I'm putting together is just kind of a meet and greet gather area on Gathered and so after the meetup and the call, we we'll do as we'll all go over to gather town and you can just log in, walk up to a group and have a conversation, and that way we can all kind of get to know each other and make friends and get to

know people across the world. One thing that I'm finding is that, yeah, the meetups are starting to come back, but a lot of people don't have the opportunity to go to a meetup. And I really want to meet you guys and talk to you. So we're gonna put all that together. We'll all be part of that book club. You can go to topendevs dot com slash book Club to be part of it, and I'm looking forward to

seeing you there. The first book club meeting will be in December, the beginning of December, we're starting the first week of December, and you'll also be part of the conversation about which book we do next. I have one in mind, but I want to see where everybody's at. So there you go for sure they're doing Yeah, they're doing exactly what you've asked them to

do. Yeah, yeah, exactly. So I want to get your opinion on this because to me, whenever a lot of the companies I've worked with, you know, they're spending fifty sixty one hundred thousand dollars a month on Looker and Snowflake, and not for the visualization part of those tools, but for the ETL transformation. That's where all the money gets spent. And to me, that's not a product. That's a symptom of not having your database

design well thought out to serve your business. What are your thoughts on that? Yeah, well, it may be a symptom of not thinking it through for sure, right, and it also may be a symptom of specialization. So and when you write an online transaction application and you're trying to service transactions with low latency, right, you're going to design your data model and optimize it for that use case. That's the exact opposite of the opposite optimization you

have to do for a data warehouse. A data warehouse, you're going to completely design it a different way. You're going to go into I like the Kimball model. There's two major warehousing philosophies Inman and Kimball, and Kimball is more practical. Kimball says, denormalize your data into a fact table and dimensions. And basically what you're doing is you're saying, you asked the question what questions will our users ask? What answers do they need from our data?

And so you build those answers into the dimensions that we build the filters for the answers and the dimensions, and then you put the facts in the fact table. So the facts could be like the order costs. You know, if you're ordering a product, what was the order cost? The dimensions are when did you order it, who ordered it, where do they live? What time? All these all these you know, who win, what where, why how dimensions surrounding the fact table. You would never build a transaction

system of doing that because you're you'd be super duper slow. So what happens is you have to take the data out of your transaction system and then etil it over or e lt O over to your your data warehouse, which could be Snowflake or red Shift, or it could be Oracle Exit Data. Now there's all kinds of warehouse products out there, and and that's the one one

my roles at the LDS Church was the data architect. We had one hundred person b I t that I was the architect for so I have hands on experience with all this and these We had one hundred engineers pulling data out of these transactional databases, restructuring them to answer queries that the end the business users have so to make to write a database that can answer queries in a timey fashion for a business user, you have to restructure the data. So it's

actually it's a problem of optimization. It's but it's it's not it's not a bad optimization. It's that you're optimizing transactions for their things. Gardener, optimizing for two different use cases. Yeah, and that's and that's okay. Gardner. For a while, there was promoting this hybrid model where you'd have your operational and you're analytical in the same database. And the dream was you'd put you you'd optimize your data for transactional in the SEQUL side of the database,

but then you'd have in memory column stores. So use your your Calumn technology instead of road based transactional, you'd switch it to column based in memory, and then you have a Calumner view of your road data, but the columns in memory. So then you can create the Calumner data sort of like Kimball's

model of facts and dimensions, but you really have But that doesn't. The Kimball model works only when you ask, ay, what are the questions our customers you're asking, and then you organize the data to answer those questions. Think of it this way, Kimball says, I'm going to pre define my reports as data, so all you have to do is just I want this on my report, this report. You're just selecting I want this, this,

and this this on my report done well. You're not going to take a transactional system and put it in a Columner store in memory and expect that to perform well because you're not tuning it to answer the exact questions your users have. So it's more fantasy than reality to say I can have a database do everything without data modeling. Gotcha, But could you simplify the process of getting data to those data warehouses because ETL is about is about getting the data

extracting it, and that actually is harder than you think. The E part is one of the hardest parts. The transforming part is pretty straightforward once you know what you want, and then the loading it is super easy. So the E part is where the problem is. So if you can get the data, if you can get a database to automatically extract this data for you and push it where it needs to go, then the solution becomes way better.

So I build a system at Faircom to do that because I know this problem and I wanted to solve it, and so we build a what we call it dB Notify, and what it does is every time there's a change in the source system, we automatically send a JSON message over and our We have an MPTT broker product as well, so it's a high it's a mission

critical MPTTT broker, so it's a message que broker. So we what we do is every time a data change occurs in the database, we send a Jason message over our message broker, which guarantees delivery and and I guarantees delivery wants, because you you've got to have that guaranteed in order to get your

data somewhere reliably. Of course. Yeah. So then and then any system, whether it's a Java program putting it into a cash, whether it's a SQL database retrieving you know, for warehousing, can can subscribe to these messages and get the data automatically. So the e part, the hard e part of extracting the data goes away, and you just simply say give me Jason and and the data just flows and you have Jason and now with a JSON

you can you can now manage the the T and the L trivially. Yeah, because there is a huge trouble that actually a lot of companies, I feel like, run into where they have a lot of individual teams with each of their own databases, and then they overinvest in setting up a complex technology like Kofka to varying messages from those individual databases to align it and push it into whatever their data warehouse is. Coff is a great example what Kafka's advantage

is, It's like it's like a combination of a message que plus a log, right, so you can so you can query the message log and see everything that's happened, and it's distributed to at scales and all that. But it's complicated, hard to use and all that. Well, what I did is I looked at that and I said, no way, can't it be simple? So I said, what is the simplest message queue technology on the

market as a protocol. And the answer is MQTT. It's it's because taking over a MQP, because a MQP is complicated as the Advanced Message q protocol and that's used in Rabbit, mqqubit and other products and active mq it's a technology, it's just complicated. M qtt's taken over the IoT world by storm because it's simple. You can embed it in a little device, a little sensor, you can, you can put it in big machines and it's it truly pushes data sou as an event happens, it pushes it to all the

subscribers. All the subscribers get it. It's super easy to use. So we took m QTT and then we said, Hakka Kafka has a log, but it's not really a queriable log, but the logs that secret sauce because it's it's like a streaming serve event server with a with a log on disc. So we took the fair Comm database, edit it to our own message, que MPTT broker, merge the two together. They're one thing. Added a transform feature to it so we could transform the data on the way in

and on the way out of that thing. And now you have a full data integration platform that does et L super easily, and I like Cofka, you can go back and query all the changes. But now it's Seql database. Number of Faircom has the sequel, the JSON and the ICE and layers, so you can get the data out through Seql queries. You can get the data out. You see, can queer your transaction log or your log of events, your event log with Seql or with JSON, and it's queriable

and filterable on the flight and you can index parts of it. And so you have a real time not real time is but a very near time dynamic dynamic query system on top of Kafka. Imagine if you could have Kafka with a real database instead of was just a static log that you could query and filter and you have real time push events through PGT. That's what we built a broker. So many words there that I just get triggered on. I can't. Sorry, I'm just geeking out here because I just love this stuff.

You said something really interesting a little while ago about basically needing to hire a DBA specialist, and I'm trying to figure out, like you know, I'm if you have a company or were under twenty people like that still feels too early. But if you don't hire them early enough, then you end up with a lot of the problems you talked about. So like when when in your view do you actually mean it's not at three people? Right?

Maybe that's yours, that's what you were suggesting. It's like, oh, yeah, you know one of your first few engineers, like after your founding engineer, you need to have some sort of database specialist. What do you think? Yeah, I think you need to have a data expert. Now if they are your back end engineer who's a data but truly data expert understands how the long term implications of data design not so obsessed that they stop production.

That's what the other old school DBAs did, Right, you can't do anything. You can't touch my database. And the hard part is you've got to hire a person who really knows what they're doing, because like Freightliner hired this one czar that was blocking everything and making bad decisions. Right, So you've got to It's hard because you have to know enough about data to hire the right person. But it could be a back end engineer, it could

be a that's what it probably would recommend these days. Instead of hiring a DBA, hire a back end engineer who specializes in a number of data technologies. And on their resume they can demonstrate or an interview, they demonstrate to you scenarios where they designed the data one way using this technology and it caused them problems. They designed it another way and another technology caused them problems. They or they didn't design at all and it caused them problems. And they

can tell you what those problems are. And they learned their lessons from the school of hard knocks, and then they can say, you know what, I'm not going to do that ever again. We're gonna up front, we're gonna we're gonna be practical. We're not going to over engineer, over design because you'll never get out the door. But we're gonna we're going to protect you eighty percent of the time from those problems that you're going to have and

if he could demonstrate that through experience, then you've got a winner. Okay, that's good advice. You know, I'm actually thinking down that path, like there must be aspiring uh, you know database administrators out there, uh, and they want to hear like, well, you know what, what's the first thing to go down this path? Right? You know, how do I learn more about becoming the database specialist back end for a burning company? You know what? What do I need to know realistically? Yeah?

And I and I think there has been a market shift, a good one from there's another DBA. There's a DBA is you know, stands for several things database administrator, database architect, and then there's developer DBAs they're all lumped together in DBAH. The administrator person is the one that I'm glad that we're shifting away from. I think it's the cloud is removed a lot of the

need for that low level back up your database. I used to Actually in the cloud, you have to configure your own backups, but the technology to do it, the cloud provides upgrades. You don't have to do the upgrades. The cloud do the upgrades for you. So that's good. So the cloud is now if you if you get a aviation product that does this for you, or you go into the cloud like the fair Com does this for you. We don't require DBA in our product, but we can run on

premise or the cloud. But not Oracle requires a DBA just to just to keep it up and running. So getting an Oracle Cloud instance of Oracle would be good for you because you're going to save a ton of money and the trivial stuff you don't want to. So if I, if I give recommendation for a newbie, don't become the administrator that is just knows how to run

the script that the books said to run to back up the database. That kind of administrator is not the value add and that and that's the kind they're having to add like Mango and Cassandra. You have to hire those kind of administrators because that's the systems are so poorty designed. You got to got to have a local level guy just to keep it lights wrong. But that's a

dead end career. The value is in the data, so the data arket, the dB architect, the guy who So you're back in a minute, you're back in developer who really understands how to architect the data so that your application will perform well and grow well over time. That's that's gold. And so if you have a mind to do that, you have to have kind of a mathematical mind. I don't mean you have to like coakyas or something. I just mean you have to have a very logical mind. Then you

have to look at things logically and systematically and understand practically. You have to be practical. You have to say, Okay, this technology does X, if I do if I do X with this technology, I'll be successful. But I know I need a little bit of why over here to make the to grow the system. How can I how can I make this X system do why? I need a multipurpose system so I can do X and Y, but it needs to do both well. You know, you have to

make a lot of decisions. And that's where a really experience. So if you hire a good back inagy with like thirty years of experience, twenty years of experience with lots of data work, you're you're going to be in good shape. So don't skimp on that back end engineer who does these data architecture. That's going to be gold for you in the long run, as long as they have a good personality, as long as they're not like the no

guy. Don't hire those guys. They'll block your whole company and you'll die. They need to be the yes guy who says yes but think about this and this and this, and I will help you achieve the goal. I will overcome the problems. I won't just be no. We'll solve this together. No. I think that's pretty good spot on advice, irrelevant of the special specialty that someone would normally go into, Like I think, relevant of whether it's databases or UI's or other back end services, graft culi databases,

you know, whatever, whatever have you. Actually, you know, this really got me thinking. And I've dabbled in a bunch of different database technologies over the years, and one thing that keeps coming up for me, and maybe this is specific because I always pay attention to security, is it just feels like security plus databases is like oil and water. Yeah. Well,

first off, it's super hard. I think that's why because because you're your data is the thing you're protecting the most that you are protecting its intrusion. So that's where you know front hackers can get into a system. But what are the hackers trying to do when they get in, Well, they're going to either encrypt your data and ransom you, or they're going to encrypt your data and steal it. And of course what are all the breaches about data?

Right, So you've got to encrypt your data at rest, you got encrypted at transit. You've got to prevent the injection attacks to give you backdoors into the database. So then take it over. Security. A good database product, security should be number one in the APIs and in the system. It should be secure by default. Oracle has a common password that has been that's well known. I'm not going to say it because I don't want to promote this, but you know, and half your dba's in the world don't

change it it is. You know. Sometimes these are more administrative DBAs and just run the scripts as if. They drive me crazy because they don't know what they're doing and and and they don't make it secure, so they don't change things. I had. I remember one database we stalled. I stalled this database product over fifteen years ago at at this organization, and they kept the same password I used in that database for fifteen years. Finally, I

think it was just a year ago they finally changed it. I'm like, really, I left that company five years ago and you're still using my password. My son works there now, and so I actually happened to know. I got a job on my old team and happened to know they actually never changed it when I left it. I'm trustworthy of but it was a good password. But still, so this is the Yeah, you're worried it will break something, right if you change the password, you know, production will

go down. So I really should be careful. Someone could be using that, you know, in a way that wasn't intended. Totally true, and then the DBAs are lazy. Everybody's lazy, right, So, like I memorized this stupid, horrible password, I'm never changing this one. But yeah, right, we rotate passwords in apike every time the Roman Empire falls.

Well, you know what's good that the updated nest whatever eight hundred is now no longer, suggesting that rotation actually prevents a certain category of attacks, because the need to rotate means people will forget and have to write it down. So now, luckily now there is written documentation that may suggest that even doing so doesn't have a positive long term impact. Yeah, and password managers are super huge. Get one that does crypto random passwords. You'll never remember it.

You don't write it down because it's in your password manager and you just use it. And another thing that's a really cool trick that the older databases did not do. Because they didn't they wasn't well known at the time, was how do you encrypt data at risk? Well, they all can encrypt it, they can use as standards and they can encrypt at risk. But where do you put the keys? That's the big question. And the model that I love the most is you have a master key that encrypts all the

keys that encrypt everything else. So that level of indirection is awesome because the customer can can change the master key when they need to. The database is constant. A good one, a good back of database will automatically rotate it's internal keys and re encrypt data in files. When they optimize the file, you rotate that internal key so that your data that the customer could change it

and own their master pastor. But you don't have to worry about at rest your keys are Your data is encrypted in a very secure way and then that's very maintainable. So the best databases do that technique. Some of the older ones don't. So that's keep that in mind. If a database has been around a long time and never really thought through these issues, they're going to have our time with security. Oracle or what does an okay job. I'm

not going to give away all those secrets. I don't want to, like, you know, help packers out here, but I'll just say one thing. If there was, I can't say it, but I'll just they don't give extra well, but it's okay. I think they're doing it pretty well all by themselves. Or yeah, Oracle did. Oracle did a terrible thing and was embedding secrets in places they never should have embedded them, and it was really obvious and it was like, really, are you kidding me?

And luckily hackers weren't super aware of this, but we were. And it's like, oh gosh, if they got a hold of this, they'd get the whole keys of the kingdom. I think Oracle latest releases they probably fixed it. I hope, but Oracle's so backwards cant pattle. They may not have. I haven't looked lately, so I'm not going to go any deeper into that. But like, there are so many holes in Oracle because it's

an old system and they never really thought it through. I would never use these utel not an Oracle fan, and it's not because it's just because it's so complicated and complicated means not secure. It was complicated. You can't cover all your bases and make it secure. So I'm much a bigger fan. If you're eqal database, you know, SQL server is much simpler and Microsoft has kept it that way and so it's easier to secure it easier to run

it. So from a DeVos perspective, Secret seqle server is really good. It's not as expensive as ourable, so it's not cheap. Postgress is, like I said, created by PhD grad students at Berkeley for the most part. And and the code, it's the code inside that thing is every you know, every developer rized different coastyles. Imagine over the last thirty years, every PhD student writing their own little module in Berkeley in the inside of Postgrass.

It's just a it's a code nightmare. So the complexity of that code base makes that system hard to secure and complicated. Do they not use route DPMs on the physical devices to encrypt the master key in some way, so it's not actually exposed to the database process, rather than having just some master key that it generates. You know, network if you're across platform database, that depends on your operating system and so on. The ones the database they

run on Windows that focus on Windows is a core platform. They do that like seql server. They can do that. Fair Coom does that. We use that technology running on Linux, though it's a little different. You have to it's a little harder because the OS doesn't support some of those things as well, and when you want to be a cross platform database, you have to work extra hard to figure out ways to to make things secure on Linux

versus Windows versus Mac. May be the first person that I've ever heard say that it's more difficult to secure things on Linux. I feel like the HSM with pks, you know eleven has no problem encrypting whatever you've got, whatever you need to throw at it. So you know that that's an interesting train of thought. There then is a new one that I'll have to consider. Well, it's not I didn't mean to say harder as much as different.

The harder part the harder part is if you're a company writing database software, you've got to use different technologies and test different technologies on each platform. So that's more of what it is. It's not that Linux is not secure. I'm not. I don't even want to begin to say that, because actually I like Linux a lot. But I will say securing Linux requires some specialty skills. That Windows is is well known as there for hacks and all that

stuff. They are trying. They try to simplify things for their customers, especially on Window. Server is a pretty good platform, but it's so expensive you got to go Linux. Everybody goes Linux. So I'm so yeah, we we it's just Linux is you're in the open source world and you say, okay, I want to use this feature. Now I'll go find open source. Well, how do I know if that open source is safe? How do I know that open source hasn't been hacked? How do I know

that that does a good job. Well, there's no company behind that open source. Typically, if you're talking about this kind of low level code, you're just bringing in some It was some developer who's going out there creating some thing. Then you bring it in, you run tons of tests on it. The work and cost of bringing that in can be really high if you want to make sure, if you want to guarantee it's secure, So companies don't do that. They just bring it in in hope because you can't afford

to go and let's go run. It's spent two years testing this open source piece, you know, a piece of code to make sure it really works well, so you hope. So I think adding to that is there's the different Linux distributions because what might be implemented in one Linux distribution might not be

implemented in another one, or it's implemented a different way. Yeah, and everybody runs on red hat because you could count on all those features being there and so or of course not everybody does completely on red hat, but the red hat is the one that every database spender is going to run on. And then do you support others? Fair Com has a history of running everywhere, so we build our software to run on every possible platform you can imagine.

At one point we supported over one hundred and twenty nine operating systems at the same time. Well, the world is luckily shrunk down, so now you know we we support we still support all the UXes that are out there, hp AI, x Q and X you name the you know, all the Unix stuff. But when primarily people want today it's Linux and Windows, and on the database world, not so much Mac. But we support Mac as well because developers have Mac laptops. So we yeah, we we support

and we run it are extremely portable. We have fantastic All we written in C and we wrote it in portable C code so that we can run on any operating system, real time orperating systems, you name it. And not every database can do that, so there's a real cost when they when you buy. For example, mark Logic is a database that was optimized for Linux. They did all their testing Linux, They coded on Linux, but then

a lot of their customers started buying it to run them Windows. They supported Window, but it was the step and so you're like, it's all kinds of problems on Windows because if you don't, if your juniors are all Linux e geniors, they know how to do it there, but they don't know

how to do it on Windows, and then you create problems. So for DevOps, it's really important for you to know is this is this database primarily of Windows or a Linux database or is it really do the engineers really know both really well and can support both really well, and your your code base

can run on all of them because it's designed that way. That's that's a huge issue for you, because so many times you buy the product and run on the wrong operating system for whatever reason, and and do you pay a cost bug costs and a support cost. That's a good point. I mean, I you know, I've been the Linux user for a long time, and I just pray that there's some sort of Open Container Initiative compatible container out there that I could just you know, pull it and run. And if

it's not, that I've add to the next technology. Yeah. Yeah, And you have to have containers for most of these products, like Oracle. I would never want install an Oracle without a container because that's just a nightmare. For my first first day on the job, I was sitting next to a guy and they said, what are you doing? He goes, oh, I'm installing Oracle And I go, oh, how's that going? Well, I'm on my third day, third day, third day, and like, what the what do you well? I mean, you know, can

it be ten minutes? Can't you just run a script? No? No, and it was just a I mean, Oracle's better than that today a little bit. But you know you used to the minutes. But a container you just pop in and rune. One thing about fair Calm, because we are real sensitive this. We unzip and run us like that. You download, unziped, run, you're going that's all there is. So we don't even need containers because containers do slow databases down by about twenty percent. And

the reason they slow databases down is because the storage. They containers don't totally virtualize the storage, but they they were out the storage through their subsystem and it causes a performance loss. So containers databases or a performance problem. So if you can run a database thats by unziped and run, and you can run multiple instances of the database on the same computer, then you don't need

containers. Well, fair com is one of the only databases that can run multiple instances on the same computer with an unzip and run out of the box story. So we can run hundreds of database instances on the same computer. Oracle takes over the whole machine. It assumes one instance one machine, single server takes over the whole machine. Postcuss takes over the whole machine. That

means you need containers, right, because you need that flexibility. That's why a fair Com I really like this core engine that we have because we don't have those limitations of these other databases. And it makes a difference for DevOps, especially like market logic took over the whole machine. You going to run

one instance on machine. And this is before container technology. This is about ten years ago, right, well more than that, about twelve years ago or thirteen anyway, we were looking at architecturally we wanted to run multiple instances on the same machine. We had to use VMS to do it, and that's even more of a HITD than containers, and it complicated our whole architecture.

If I could have run multiple instances on one machine, I could have simplified the entire architecture, saved us a ton of DevOps time, development time, engineering time, architecture time. But that limitation tied my hands. So something like Faircom no limits on the architecture, which as an architecture I like that I could just do what I need to do get the job done right. Well, there you go. That was a random stream of It was

fun. That was that was a lot to take in though, and I think it really it really highlights how much thought and effort and planning has to go into your database solution. It's not really it's not really and oh, by the way, task or it can be, but you're going to pay for that for a really long time if you're successful at all. That's a really important point because we at the last but I was working on this church,

that large organization. We had, we we had standardized, we had certain databases we supported, like we started supporting it, you know, and we had developers all the time they're bringing this under the hood. They would go sneak out and go get a Mango or get a Cassandra, get into the database that we weren't supporting it. And React was one of their favorites. That bring it in is start build their app on it, right,

and then they go to release the production. The manager and the and the infrastrut team goes, what is this, Oh, it's just a database, don't worry about it, just all it. No, we can't who's supporting it? Well we are, Well, no, you have to talk to the database team. We're supposed to support these technologies. So then they call me up and go, Mike, we're using this. Can you support it?

What we don't? What are you doing? And so like, no, we we don't have the people because every time you bring a database in, you're going to have to train people to read, to understand the technology, to give it the proper support. You just can't throw someone at and hope that they get their job. Then databases are kind of like a marriage, you know, and you're you have to be serious about this. You're gonna have that database for a long time for and you need to know how

to make that marriage work. And it's not just you're gonna get married, because if you don't, you're gonna get a divorce. And but you can't divorce the database. The problem is is still sitting there, it's still running. It's still causing you trouble because you can't just rewrite your app overnight. You can't just afford to do that. So this is a maybe it's worse than you know. Marriages are great. I've just been You're stuck with it

forever, right, I think therapy podcast? Yeah, so yeah, you're right. You just developers are sneaking these in and then no, it's no problem. And next thing you know you've got you've got a real problem in your organization. And we had to rewrite so many apps because the app couldn't be supported. And you think about, you're gonna have a core team. No matter what database you use, you're gonna have a core team that's going to give you twenty four to seven support on that thing. And so you're

going to and to do that. You can't just put one person on that team or you'll kill them off twenty four to seven, right, and even if they're a ATAG guy. Like that's the Marcologic database for example, it was like a Maytag database. It never went down, it never broke. So we had two people running over over six hundred instances of Marcologic supporting the whole thing throughout the entire organization. But they were still too because they were

twenty four seven support and they even they weren't called. They had to carry the pager, they had to carry the cell phone, they had to be had their laptop with them. The stress of the support is always with you, and so you have to take that in consideration. When you bring in a technology, you're gonna have to get your support people to support it. That's like the secret conversation. It's like are you ready, like to the development team, are you ready to for the new database bringing in? And

they're like, yes, we know everything about it. And there were only response you can say to that as you're wrong, it's going to be okay here, but you have no idea what you're talking about. Yeah. Well, it was just to bring in mark Logical in my last organization, because I was in charge of that whole thing that so I bring it up. It took one hundred thousand dollars project to go bring it in and get it integrated into infrastructure, to get all the support processes in place, to establish

a high availability version and how we're going to support that thing. I ran that whole project and it was it was expensive and it was a real eye opener to me, like why can't you just run it? But no, it was a major project and because we did that, though we now have it grew like crazy throughout the organization and it's super successful to this day in that organization. Because deployments are just a piece of cake. The main the

maintenance is a piece of cake. Whole thing because because we brought it in correct, but then these other ones like React came in and not only did it come in surreptitiously and was never supported, the company went out of business. And you know, so you got to think about you know, if it's a long term relationship and your relationship dies, you know, you got to think about that. That's a big one life support. That's a new product. Right. I love that, But do you talk to developers.

I had so many arguments. They would say, well, it's open source, it'll live forever. It's open source is free, Like, okay, do you realize that there's a company that built this product and their entire goal, whether it's Manga or Cassandra or couch base or faircom. If you're open source, it's an illusion. It's a marketing strategy. It's totally an illusion. And and you're developing your you're completely in fantasyland thinking open source is is

the answer because that company has to support it. They have the engineers who built it. If that company goes under, it's not like the community will pick it back up and run. That code is too hard. Database code is way too detailed and hard for just anyone out of there. Oh, I just get your grandmother to come and go. Program you know, get

it from GitHub and go change this forget it. This takes specialized engineers that spent ten to twenty years of their life learning this code and learning how it works and learning all the internals. So when that company goes away and those developers are no longer there, they go to other companies. They're working on

other things. That database product is dead. So get another team. Like when Oracle bought my sequel and then the team that didn't want to work for Oracle left it built Maria dB, right they but the team left it built another company and they forked the code. Can you do that? Yeah? But will they do that? You know that's a big question and database software, but that you're basically becoming the database company, right Like you're like,

oh, you know, you have to be okay with that. You have to be willing to take that code, build it, run it, become the experts of it yourself. If you're if you're going to go down that route, yeah, for sure. And that's not realistic. It's just you know, that would be if you hired me, for example, I could go do something like that because that's the kind of guy I am. But

I'm kind of a Unicorn they're there. I mean, I'm not unique, but I'm just saying there the Unicorn herd is not huge that that loves to get to that level of code, understands what databases really are and what they should do, and knowing that kind of code and make that happen. And you can't replace people like me very easily, so and you don't want to

afford me, you know, I'm super expensive. So that's the other thing that just because it's open source doesn't mean that there's a huge pool of talent willing to work on that product for free. Yeah, oh yeah, and are even capable of working on it right, you know, if they're at the real engine level where you need to have where you need to fix bugs. So so it's the open source database world is an illusion. And I'm not being negative. I'm not anti open source. I don't want to come

across that way really not. It's just it's a marketing strategy. Get it in the hands of developers so that they can go build their next product, hopefully become the next Google or you know, and then and then they can start paying for stuff. You know. That's the whole marketing gimmick of it. But the reality is the open source versions are not secure. They don't scale. They they're they they don't provide the tons of the let's see,

the secure at scale are the big ones. But you're also getting tools, the tool sets for the backup, the recoveries, the management. Those are only enterprise versions and those you have to have in a database. The vendorsor is not stupid. They know you go open source for so long and then eventually you're going to pay them. But the developer, it's a it's a total marketing thing to suck the developer in because they get we all have dreams

of I'm gonna be the next Google. I'll use all this free software to get myself up and running. But in a production environment when the thing goes down, can you fix the bugs? No, you're gonna You're gonna immediately get a support contract with the vendor. So yeah, they know that story. So it's it's a game, a game. Yeah. The goal is to make it easier to purchase the subscription than to refactor your code to use something else. Oh yeah, which is not a hard goal to achieve,

right, And to me, I call it a trojan horse. You know you come in, it's free, it's open source, you know, and then it's in the organization. Next thing you know, Wow this is expensive. Wow this is hard while we're locked in. Oh too bad, so sad, And then the vendor is for happy. They're playing the long game. It takes a long time for this to happen. Was praying a really

long game here? Oh yeah, I mean you would think at this point people would start to realize that this is the pattern and maybe consider that when they're going after certain technologies. But it doesn't seem like that's the case. They're still deluded that the price tag for the source code is there, it's zero dollars or franks or yeah. I think that. I think that our industry is still so new, that we have so many new people coming into

it every year, that those lessons aren't being translated. There's too many people for people like us. There's too many people entering every year for us to share our stories with all of them, to keep repeating those to help them prevent repeating our mistakes. Well, and engineers are notoriously bad at making costs.

I mean, I know where it comes from. It's oh that money would come out of mind right, I don't want to pay that money for it, and they don't understand the business justification and what really goes into the total cost of ownership. Right. Yeah, engineers are not good business people, and it's it's a good thing because business people are not good engineers. I mean there's exceptions, of course, but the engineer is going to go, I could just build this myself. Why do I I can build my

own backup solution. I got build my own operations manager, you know, I could build my own security solutions. So the engineer goes, I could work my way around this problem. Well, as a company, you're like, I'm not paying you to do that. That's way more money than paying a vendor to do this for me. And how do I know you're going to do security? Right? How do I know you even know what a

backup solution is? I mean, how many software developers know the cycle that the backup schedule you should really follow on a database and how that really should work the best practices there? Well, ninety nine point nine percent developers have no clue, so they couldn't even begin to build that solution. So yeah, developers are it's not it's delusion, but it's more ignorance. And I don't mean that they're ignorant. I'm not saying that. I mean just lack

of knowledge, lack of experience. It's easy to imagine yourselves because the developers are awesome. I mean, I'm a developer macrot right, we could build anything, and you're like, I could build that. I love building that. Let me build that for you. But as a business decision, you've got to really think that through because you don't want your developers. You want your developers to build your product, your value added product that you're going to

sell, not build infrastructure, not build the lower level stuff. Yeah, and that's a lesson learned through time and experience, the difference between could I build it and should I build it? Oh? Yeah, for sure. That's hard because I want to build everything, right, I mean every day. And we have this problem at fair Com too because we are in a total engineering shop. So we want to build everything ourselves. And I have to say, you know what, let's get an open source for that one.

But let's bet it carefully, you know, Let's don't reinvent the wheel every time, because that's what we want to do in our nature. So let me go build that cool thing. So yeah, it's hard. Managing to engineers is hard to because you gotta say, nope, you can't do that, you can't do that, we're going to buy this, you know. But you really have to make those good decisions as a software company.

And I mean that's where the fallacy is though, right, Like we have some backlog of work and we can get through it, right like, you know, it's just it's just these three or four things and then we're done, and maybe we can move on to new things. And realizing that there's a whole list of other issues and tasks that are going to come up associated with managing that technology us as you start to build things out. It's so true when you're a naive about something, you think it at a ten thousand

foot level, it looks easy. Well, backup can't be that hard. Well then, you know, just call the data to a new location. Done right, done, done. That's that's what Mango said to do in the beginning. Yeah, just cop just just copy our data. But what if your data is in transition and it's half written a disc When you copy it, you're copying, you're copying broken data. You know, it's not you have to cuiesce that database, so it's not writing the disc while you're

copying it. But then what if your database is huge and you're trying to copy all that data all the time, you'll never get it copied in time. You know, you're right out of time. So so you need a copy what's changed? Well how do you do that? And you know once you go down this rabbit hole. But it's but that's foot levels. Just

copy the data, piece of cake. Is there is there actually a solution to this in the database base where writing to the journal and the actual table like can somehow be strongly consistent so that the backup being taken irrelevant like will always be one hundred percent consistent. Or it's just some small percentage chance that the journal will have data that's not actually in the database or something like that.

Well, in fact, you hit the nail on the head the the the ideas you cuiesce your data, which means stop writing to the data files, but keep writing to the journal, so the journal it gets ahead of the data files. But you could copy now the data files safely or make an incremental copy of what's changed in the data files quickly over somewhere else. Then then you unques the database at that point you mark in your journal. You've already marked in your journal where you started a backup, and then you

could copy the journal files over too. So the restoration, you're restoring the data files first, then you restore the journal from that point in time and now you and then you replay the journal to catch the database up. So that's the technique all the major databases use. But that no single databases start out ignoring the journal completely and just did dumb things like we'll just copy the

files over here. They've gotten better now, but you know, because they're customers who have told them your data is corrupt, so they they're gradually fixing stuff like that. But yeah, that's the difference between the database backup and the database restore. One doesn't care if it you corrupt. Yeah right, the backup doesn't care. Oracle spent a fortune on when they do their backup this. The Oracle is really good about not corrupting data that they're in.

So spare comp we built technologies designed to not lose the data because corrupt data is a big problem. So in Oracle is doing the backup, they're reading every block of data and validating it to make sure that the all the safeties they built into that block are there so they're not so if the field data is off or something that you could tell, they detect it and then they market. So you know when your backups have corrupted data in them, so

you can start dealing with the issue. Because if the worst thing in the world is you have a backup that's three months old and you just had ransomware and you got to restore and that all that data is corrupted somehow, and you're like, uh, what do I do? See, Yeah, these are these are the things that are real. The answer there is you polish up your LinkedIn profile. You're lucky you're not the business owner, right,

That's that's where you're Yeah. DBAs get fired over that kind of thing, or or at least depending on what's going on, you know, sometimes they

do sometimes down. But I mean, I've mortified that database company could be walking around out there without having a backup strategy that is actually paying attention to live data streams that are still coming in in a high throughput, high volume environment Like that just seems for me, like, who are you that you think you can just run a database, uh and as a service and and you know walk away like this just seems like a promise that's by default being

needs to be made. Yeah, totally. Here's an example. We Firkom also has another product called RTG, which is our Cobal modernization solution. Turns out that Cobyl writes data the exactly way I M does. So what we is we stuck our database, which is that highly available mission critical database underneath a Cobyl program, and we and the Cobyl file handling routines just go to our product directly. Well, the vendors are buying our products to go out

of their Cobyl apps because they can't rewrite the Cobyl app. It's the means of loes of code, millions of dollars. It's just too risky. Their whole business, the financial industry wrote everything in cobyl s little snow secret.

All your favorite banks you know, are are running Cobyll programs for all your data because it's at is a controversial word there, Yeah, well yes, or all you're hated or whatever, then yeah, all the your So the one of the one of these big financial companies is coming to us and they can service all their current customers. But they want to go to tier one. They sell baking software to Tier one to Tier two and three systems.

They want to go to tier one, and they're the largest baking software system in the world. But there are certain huge customers they can't service because they run a Cobyl and the filesystem can't scale to what they need. So they're putting our product right underneath the COBAL which is a plug and play. Our tg stets were ready to go because you just plug us right in under the

Cobyl engine. You don't change a line of Cobyl code. It just works, and then our database scales it so all the things you're talking about backup recovery. Cobyl can't do any of that stuff. They back up corruptive files all the time. But what we could do is we now bring the technology to the table to create a storage system, to create the database. Create a storage system snapshot, which these are huge, multi terabyte you know,

like eighty terabyte databases. They're huge. You can't back those up by copying files, so you have to do storage snap shots of those things, and then you can then uncreates your database and then copy the transaction logs over too. Startur snapshot the transaction logs, and then the storage system snap shot can restore your data. You save the snapshots, and then if you want to restore it, you just revert to the snap shot, apply the transaction logs.

You're back up and running, and Cobalt files can't do any of that system. But you put the Faircom database underneath it, you instantly transform that these legacy Cobol systems into modern systems. The only reason COBAL is dying is because it's not the language. Language isn't bad. It's the data systems was where the data was built into the data processing was built into the language. You open files, you write the files that they didn't. They didn't do

what c did and separate data from the language. They kept data in the language together. So the answer is put a real mission critical database underneath your COBOL system. And now your Cobol system rocks and rolls just like every other system in the world. And you know, whether it's Java or c Sharp or Go or whatever. Language, that's all COBAL is is a language. Now the data system modernized instantaneously because we have all the mission critical scalable features

that COBAL needs that centered the hood. So that's the power of having a real mission critical database under your in your solution. Wow. Yeah, Well we could go on forever. Maybe we could come back and talk some more, because there's the IoT world is exciting and there's an IoT and I really,

just for my own personal curiosity, I want to dig in. I want to have you back on the show and dig in to the LDS work that you're doing, because you've already mentioned that you had like a team of like sixty DBAs and like a thousand engineers and that transmitting money around the globe was too slow using existing systems, so you built your own money transfer system.

Like, to me, that's just fascinating. And the fact is it's like the overlap between the church and technology there, I think is just really really fascinating. So I want to have you back on just to talk about that. Oh cool, Yeah, it was. It was an awesome place because they are so technology focused and cutting edge in the technology world because it's all about the members and making their lives better and so using technology to do that super important. So yeah, and the church, Yeah, we talked

about that the other the next episode. That'll be good, right on, right on. Have you ever wished that you had a group of people that were just as passionate about writing code as you are. I know I did. I did that for most of my career. I'd go to the meetups, I try and create other opportunities, and it was just really hard,

right the meetups. I got some of that, but they were only like once or twice a month, and it was just really hard to find that group of people that I connected with and really wanted to, you know, talk about code a lot, right, I mean, I love writing code. I think it's the best. And so I've decided to create this community and create a worldwide community that we can all jump in and do it.

So we're going to have two workshops every week. One of those or two of those every month are going to be Q and A calls right where you can get on you can ask me or me and another expert questions. The rest of them are going to be focused on different aspects of career or programming or things like that. Right, So it'll go anywhere from like deployments and containers all the way up to managing your four oh one K and negotiating your benefits package. Well, we'll cover all of it. Okay, and then

we're also going to have meetups every month for your particular technology area. So we have shows about JavaScript, to react, angular view, and so on. We're going to have meetups for all of those things. I'm going to revive the freelancer show. We'll have one about that right so you can get started freelancing or continue freelancing if that's where you're at. And I'm working on finding authors who can actually do weekly video tutorials on some thing for ten minutes.

This relate again to those technology areas so that you can stay current, keep growing. So if you're interested, go to toppendevs dot com, slash sign up and you can get in right now for thirty nine dollars. When we're done, that price is going to go up to seventy five dollars, and the thirty nine dollars price gets you access to two calls per week. The full price at one hundred and fifty dollars, which is going to be

seventy five dollars over the next few weeks. That price is going to get you access to all of the calls and all of the tutorials and everything else that we put out from top endevs along with member pricing for our remote conferences that are coming up next year. So go check it out topendevs dot com slash sign up. So let's move on to picks or In last week we talked about movies, Did you bring anything anything new this week? I'm working

on it, you know. I of course had to spend all my time since last episode actually thinking about what my pick is going to be this time, which is not a movie, so it's slightly more interesting. I think my pick this time is going to be a local stack, which is a technology that takes AWS offline so you can do local development work. And I think they're doing a lot of interesting things there and trying to build parity for what is running an AWS I can see is a huge challenge. I mean,

obviously it's not mission critical level of stuff. But one of the reasons I bring this up is because we just create my company it just completed a collaboration with them super successful where we released an authorist extension for local stack to amp up the security on the authentication authorization side. So I think great team, awesome stuff that they're doing. If you don't know what local stack is and you're using aws, you definitely have to check it out right on.

Very cool. All right, Mike, what you bring for us this time? Well, you said something kind of personal. Whatever. So I'm a I got my PhD in music theory and my bachelor's in music composition. So I'm a musician at heart. I work technology because that's where the money is, and my mind thinks that way too. That I love it. But I played the piano, and so one of my favorite piano pieces, the Rockmando off Piano Concectial number two. I like so many, but that is

just an amazing piece of music. And when I listen to music like that, I actually it's like programming. Now. It sounds weird, but I see structure everywhere. It's layers upon layers of If you think of objectority programming, that's what a music composition is. Is like an objectorated program with layers upon layers of objects nesting with each other in real time, with beautiful sounds. And so I love I love bridging the world of computers and music.

That's just kind of way my brain works. That's cool. I've never thought of it that way, but yeah, that makes a lot of sense. Do you have like specific background music that you use when you're working. Uh. Yeah, none. If I turned on music, my braid goes straight into the music, forget everything else because I'm I, like I said, I got a PhD music theory, so my brain's an analytical brain. I don't just right here music. My braid is analyzing music, and so it

takes over my whole braid. So no, I can't, you know, in the exact same way. Like there are so many times I used to listen to music while I was doing things and I would have to take my headphones off so I could think, and I think there's nothing to this, Like people who are driving cars, which are super common, turning down the radio so they know where to pull over on the side of road. So you know there's something there for sure. Yeah, no, I agree.

The The only exception, like, the only thing I can listen to in the background and stay focused on work for me is Pink Floyd's Dark Side of the Moon. And I don't know why that is continuously Yeah, yeah, yeah, it's one of my playlist and I just repeat it and and it just plays, but it puts me in flow state. But any any other song and I'm paying attention to the music. Yeah, there's something like just

white noise in general, all that it can be used to stimulate. So you know, maybe this for you, you know, with your brain waves, is just how to get you in that state. I you know, it can be anything, and for you it's this one. Yeah. Cool. Well, I brought two picks to the show today. The first one the same one that I picked last week. Platform Con coming up. I think it's coming up in May, five day virtual conference about platform engineering and

all the aspects of that. Luca who's been a previous guest on the show, he'll be back on the show in March to talk about platform Con. But it's really great speakers lined up there, so at platform con dot com

check that out. Totally free, five day virtual event. And then the other thing not technical related at all, but recently I put on a throttle body space or a cold air intake and a mass airflow sensor on my truck to improve the performance of it. Bought all of them from American Trucks dot com and it was super cool because you tell it which vehicle you have and the website re updates itself to only show stuff that is compatible with your exact

vehicle, so you don't buy something that's not going to work. But then they also have on every product page they have videos showing you, you know, how to install it, what the performance is going to be like before and after where they'll put the truck on the dino and show you the output. But just a really well done website. So yeah, American Trucks dot com. Does it come with the vision pro you know that you can put that on. Cool note, but that's actually a pretty cool idea. Cool

All right, Well, I believe we have an episode. Mike, thanks so much for being on the show. This has been there's been information overload in every positive aspect of the term. Yeah you really you did a great job of the highlighting the role that DBAs have had and the fact that that that need still exists. Yeah for sure. So thank you for thank you for coming on, and we'll check in and have you back up back on the show because I want to have that follow up conversation with you. Cool.

I have some burning questions in that area. All right, Larren, thanks for joining me, love having you on the show. Man, looking forward to many many future episodes and everyone listening. Thank y'all for listening, and we'll see y'all next week.