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.