How to simplify your software architecture

Modernizing database infrastructure can solve more than just data problems. It can also simplify your software architecture and the way your engineering organization works.

In this episode, David sits down with technical evangelist, Rob Reid from Cockroach Labs,  to discuss the importance of architectural simplification through proven patterns, real-world examples, and practical use cases. 

Join as we discuss:

• The benefits of simplifying your data architecture

• Why you should think of regulations as part of your architecture

• How in some cases, running a database across three data centers can be cheaper than two

• What to know about selecting the right database for your use case

David Joy:

What is up everyone? And welcome to the Big Ideas in App Architecture podcast. Today, we have a different episode from our regular programming, because today I have one of my favorite people in the company at Cockroach Labs coming on to talk to us about some really interesting stuff that he has been working on. And the person on the podcast today, his name is Rob Reid, and before I butcher his introduction, I'll let him talk to you about what he does and who he is. Welcome to the podcast, Rob.

Rob Reid:

Hi, everyone. I'm Rob Reid. I'm a technical evangelist at Cockroach Labs, and essentially that means I get paid to talk about a database that I already loved long before I joined the company.

David Joy:

So tell the people a little bit, what made you fall in love with doing what you do on a day-to-day basis? Was there something, when you were growing up, you felt like I needed to be a technical evangelist? But how did you fall into this? Yeah.

Rob Reid:

There was never a point at which I thought, I'm going to work with databases. I need to work with databases at some point in my life. No, I fell into this role. So I was a customer of CockroachDB for quite a long time, and I developed some really lovely and lasting relationships with the Cockroach Labs team. Before I'd met them, I'd already used the database for personal projects and I realized the importance of it. So for me, joining a company with whom I shared a lot respect for the people, and I already love the technology, I've got a tattoo of it on my body, it was a no brainer. I think I was always going to end up at Cockroach Labs.

David Joy:

Very cool. So is this a trend that every company you work at? You put a tattoo of that company or a technologies you love? Okay.

Rob Reid:

No, I get a tattoo of the company so that they can't say no.

David Joy:

That's really awesome. So what I love about your story, obviously something that I could relate with myself is that the whole idea, and, okay, for everyone listening, this is going to be a shameless plug about how amazing CockroachDB is, okay? That's what we are going to be talking about in today's episode. But genuinely, we want to get into some of the things that Rob's worked on to understand why it is so good. But to come back to what, Rob, you were sharing your own story, I could relate a lot with that. So what happened was about two years ago, I was trying to do a personal project, and I was working on Cassandra, which I was using for about five years. And I was even part of selling Cassandra for a long time. And I love the database, I love the people in the community. Some of the people I just spoke to recently as well, things are looking very interesting on that side.

But what happened was the kind of use case I was working on, I needed scale, obviously, but I also needed consistency. Data should be consistent, and I needed to do some joins and certain things that Cassandra wouldn't do for me. So I naturally started looking for the answer, and ended up, it's something in CockroachDB. At first I thought it's like a meme, it's like some meme database or something. I don't know if you're following this. Apparently, Redis, which is one of the open source projects that turned into a company recently, somebody made a meme database out of it called Radish. So it's basically called Radish. And I thought initially this probably is a meme database called CockroachDB.

So I wasn't really particularly interested in it, but then I started going to Stack Overflow at the time before ChatGPT, right? We would go in and start asking questions. And I ended up at a situation where I would see so many CockroachDB references. I'm like, maybe this is something serious. So I started using it and completely realized that this was what I probably needed for a decade, and I went the NoSQL route, or at least Cassandra route, because that was the only best option. So it's like the story of what we kind of want comes a little later in life and just have to be patient with it.

Rob Reid:

And I don't think either of us would want to slight on any of these other databases. I think given the right use case, every database is fantastic. It just so happens that CockroachDB is fantastic for the use cases that we had, and also fantastic for relational transactional workloads that just can't fail, but for other workloads, Cassandra is fantastic.

David Joy:

Yeah, I agree. Yeah. And so how long have you been in tech, been doing this yourself?

Rob Reid:

So I've been in tech since 2006,

David Joy:

Wow.

Rob Reid:

... professionally, at least. My passion for tech was ignited when I wrote my first naughty software at college. But I mean UK College, not US College. And I wrote a macro into word whereby wherever you closed an instance of word, two more instances of word would open. So I installed it on some of the computers at my college and then sat back and watched.

David Joy:

That's very cool. I love that idea that everybody kind of falls into tech, and [inaudible 00:05:05].

Rob Reid:

You're either bitten by the bug or you're not. And I think if you're bitten by the bug, you're bitten hard, and you have a lifelong passion for it.

David Joy:

You were mentioning some of the things that you're working on, some really interesting ideas around the way you look at the architecture, the way customers have been talking to us about why they love CockroachDB. So why don't we get into that a little bit and kind of start from there?

Rob Reid:

So it all started, this architectural simplification project last year. We were talking with our customers, our customers were talking, actually, at an event called RoachFest. And we have RoachFest every year. This time it was in New York, but we have it yearly, and now it's on the road. So it's going to be in, shameless plug, it's going to be in New York, San Francisco, and London this year, in June, where our customers come, they talk, they share stories, they share knowledge. It's not just customers. People who are interested in getting to grips with CockroachDB can also learn from the experts, and the people who are using it in production workloads.

But anyway, there was a theme, last year's 2023 RoachFest. There was a theme, and that was one of architectural simplification. So customers aren't just replacing a database or databases with CockroachDB, they're simplifying their architecture as a result of onboarding distributed system into their architecture. And actually, for the majority of our customers as well, that's not just an architectural simplification, but it's an organizational simplification. They can change their engineering organization as a result of a database, which I think as a technology is a huge thing. It's a massive feather in our cap that we cannot just replace most if not all databases, obviously depending on the use case. But to simplify an architecture is one thing, but for the organization then to be able to modify itself after having onboarded us is huge.

David Joy:

I think that's what I've been noticing of late as well. Some recent conversations that I have had with customers, I'm realizing many of them are trying to modernize. And this has been going on for a while. Everybody wants to modernize. They're like, "Well, we are using old systems. We are trying to get off the mainframe." And then while they get introduced to CockroachDB, the CockroachDB promise is essentially the same promise of, say, a mainframe system, that is, highly available fault tolerance, can handle the OLTP transaction. But now it's also catering to this cloud-native capability, your application modernization. Anything and everything that the company who has been on this old system wants to do, now you can do it in CockroachDB. And they're like, "Well, this is good," because they were like, "Well, I can do an apples to apples here, obviously, but in a completely new paradigm."

Rob Reid:

Exactly. And if you're doing a straight apples to apples, you're not necessarily going to get the benefits of a distributed system. I think your mindset needs to change in order to get the most out of the power of the technology that's available to you. And that's what the project is. What we want to achieve with this is to help unlock these simplifications for not only other customers, but for anyone who wants to dip their toes into the warm waters of distributed SQL.

David Joy:

So tell the listeners a little bit and kind of expand that as to why is this part of architectural simplification important for them? Is there something that you have experienced in these conversations that you feel can immediately help people?

Rob Reid:

Being the technical evangelist, I visit conferences. I talk with a lot of people, and of the hundreds and hundreds of people that I've spoken to at various conferences, AWS, GCP, et cetera, invariably, the problem that people are coming to me as someone on a booth with are "I'm trying to solve this problem, and I'm not able to do it with my database." And that's, I think, symptomatic of using or perhaps even contorting a traditional SQL database. And that might be something like Postgres and MySQL, those kinds of databases, maybe Oracle, or even some of the cloud service provider databases, maybe Aurora or DynamoDB.

They're using a database that is fairly traditional in the sense that there might be one right node or one single instance of the database, and they're trying to do modern with it. They're trying to write a modern application with this kind of legacy or traditional, maybe it's fairer to say, piece of software, and they're running into issues, be that the issue of right scaling, they hit a complete ceiling and then they're no longer able to scale for writes, or they're worried about their uptime. They're worried that I have this huge single point of failure, and now I need to somehow remove that risk from my system. And it's really difficult to remove the risk of a single instance or a single point of failure if that piece of software was never designed to be anything more than a single point of failure.

David Joy:

Right. Yeah. And I think that paradigm, those patterns exist in systems, and everybody's slowly trying to move away. You talked about organizational simplification that comes with this is that, well, when you have to design for tolerance, you then have to do blue-green deployments, and I know so many people who are on this environment, old system, they're like, "Oh, we'll just create another environment that meets... We replicate all of this data on another system, and then when a failure happens, we make sure we move or repoint the application," and everybody in the organization is running to make it happen. And then you have to do checks and everything to make sure, okay, we are back stable, and then when everything's back, we just flip the switch again. That's what happened.

Rob Reid:

I've worked in finance over the years, and that's particularly that model of disaster recovery mindset is very prevalent, and there are people hired to think about disaster recovery. So the idea of running typically on prem, a primary instance of their system, database applications, the whole stack, and then they're nursing a completely idle secondary infrastructure. Sometimes, with replication, I guess it would have to be with replication if you want any chance of surviving an outage. But then, yeah, as you say, you need to test the failover, and hope that that works, and test it as well and hope that it works. But then you need to failback, and the RPO, the recovery point objective, the amount of data that you lose has to be factored in both ways. And so it is a risky operation. So with distributed SQL, especially CockroachDB, you don't have to think about your system in terms of disaster recovery, because you've mitigated the disaster from happening in the first place.

Now, obviously, this doesn't alleviate the need for or obviate the need for backups and things like that. We would always recommend people have backups of their system. But knowing that there are, if you lose a database node, or, for example, last week, GCP accidentally deleted a customer account in its entirety, on Friday night. So for the whole weekend, this customer didn't have a GCP account, so they weren't online. They also deleted 40 networks. I don't know if they were for that customer, I'm guessing they were for other customers as well, but a portion of the internet went dark. If you're running across clouds, that wouldn't have happened, and you can't run a traditional database or a cloud service provider database in multiple clouds. So it all comes back to if you need the resilience and you need true resilience against failure, so disaster prevention mindset, then you need something like CockroachDB.

David Joy:

And when I was reading that story, I was completely flabbergasted and fascinated by how did GCP do it? And I work with GCP people. I'm like, "Why did you guys do that?" I have to ask them that question. But apparently they were able to recover it because they were multi-cloud, and had that backup. So that's what I heard.

Rob Reid:

Okay. Well, imagine if they hadn't been multi-cloud. The world was monolithic, single instance. Then it went to running maybe some parts of your application stack on one cloud, some parts in the other, and that was considered multi-cloud. But now, people are slowly moving towards single-application multiple clouds if they want true resilience. Obviously, it all depends on your risk appetite as an organization. But then these people I speak to at these conferences, it's not just the case of a traditional database in a modern world. It's the idea of solving complex data issues. So things like replication of data, partitioning of data, and I'm not talking about partitioning of a table in place. I'm talking about the geographic partition of data, data localization, being able to pin data to solve things like regional or regulatory compliance. You just can't do these things with a traditional database.

When I helped onboard CockroachDB at Lush, I didn't want the whole team to have to speak an esoteric database language in order to interact with the database, and I didn't want them to all become DBAs in order to keep the lights on. I wanted a database backbone, if you will, that you can trust, that will just keep the lights on. You throw data asset and it gives data back consistently, and you don't have to think about it.

David Joy:

The paradigm needs to shift for these enterprises, where they understand wholeness of this change that they're trying to make. And many times, what can happen is that there's a narrow vision, and they're thinking about, "Oh, I just need to fix this." But they don't realize how those other things that you're trying to do are also included in that. So for example, we were talking about the disaster recovery mindset. I remember, when I was working at a couple of companies before I was doing databases, we had to have DR days, man. We would have to make sure that, "Hey, we are going to do DR today and make sure everything is working," and they would do these, and they were very disruptive in two our regular routine where we are trying to do certain things.

So you go away from, well, you're thinking you're doing customer focus, but you're so distracted because what if you can get away from all of that, right? And that's what you're kind of talking about. And I love that story. Again, data locality is an amazing feature. Let's dive a little bit more into when you talk about the architectural simplification project, and that's just at a high level, what were the main focuses of the project in terms of the ideas that you wanted to drive specifically?

Rob Reid:

So the first thing we did was identify the customer stories, because we wanted it to be real-world. So I worked on the brief for the project with a bunch of other people, and we identified six high level themes. And we didn't want to just throw a bunch of architectural patterns at the wall and see which one stuck. We identified six themes. One was hyper-specialized databases, and that is the very specific... or a database that's great at a very specific thing. You always want to use the best tools for the job, but a side effect of doing that is you end up with more databases than you might otherwise need, all of which need maintenance, all of which might require a specific type of dialogue in which to interact with it. So that's a lot more knowledge that needs to be known within the team.

And that's a lot of, then you get into the world of, well, if I write to this database, how long is it before I can then read it from another, and potentially split brain? If you talk to any one of those databases at any time, which is giving you the correct answer? Then we've got failover. So this is the differentiation between the traditional mindset of disaster recovery, primary, secondary kind of infrastructure, and distributed SQL, and multi-active with CockroachDB.

Then we have the microservice data integration theme of patterns, which is all to do with the flow of data through microservices. Obviously, microservices solves a big problem, and that is develop productivity. Obviously, some would have reasons against that, but data productivity, being able to work in isolation on something where the data is isolated to that microservice in a bounded context. But there's lots of problems that arise from that and lots of complications.

For example, if you're writing to multiple places, you are in the dual right scenario, or if you're maintaining caches or having to get data or having to make the decision of "Do I introduce an aggregator and tightly couple my services, or do I duplicate data and then have to maintain duplicate data?" That's where the transactional outbox pattern comes in with CockroachDB and using things like CDC. So that's the next one.

The next one we have is caching. So the umbrella under everything of right performance bottlenecks. How do I alleviate read performance bottlenecks on my application? Traditionally, if you had one instance of a database, the solution was a cache. Now, when I was a customer of Cockroach Labs, I asked the question to the sales engineers that I was working with at the time, do I need a cache for CockroachDB? And the answer was, "No. Try it without and scale it." If you hit a wall, you can scale it. You're not locked into that single-database mindset anymore. And obviously, with caches, then you run into cache incoherence. Is the database saying the same as the cache? Typically, if you're doing dual writes, no. So, again, split-brain.

David Joy:

Separation. Yeah.

Rob Reid:

Yeah, exactly. The next one's data warehousing. And that is we don't recommend CockroachDB as an OLAP, an analytical workload database. If your sole purpose is to generate analytics, CockroachDB might not be the best fit. There are other great databases that you could use instead. OLTP, transactional workloads, perfect, the ideal workload for CockroachDB. But in order to get data to data warehousing systems, you potentially end up with split-brain again. You've got a delay between inserting data and being able to generate insights from that data. So for some queries, you can use CockroachDB for those kind of data warehouse workloads.

But again, there are examples in the code that one of the outputs of this project is video demonstrations of the before and after scenario and a bunch of code demos for the before and after. And I talk about the kinds of workloads that you might want to consider for data warehousing, because you run into things like data triplication. If you want to get data from a database, like Postgres, for example, but then you want to get it into something like BigQuery, in GCP. You might be looking at having all that data, which might be hundreds of terabytes in Postgres, and then duplicating it to something like, well, let's say S3, I don't know where you'd put it into AWS before taking it over to GCP. Let's say you put it in Google's blob storage before moving it into BigQuery, and that's triplicating the data and triplicating your storage costs, in effect.

And the final one is, and something that is close to my heart because I've been bitten by this in the past... I've been bitten by all of them, actually, but this one particularly, is application silos for data domiciling. So I've worked somewhere whereby we organically grew the system into multiple regions, but in so doing, we had multiple copies of the stack in each location, and that helped to an extent with regional compliance. But the operational headache that introduced was monumental. We had 17 different installations of the same stack, all with different CVEs or with different versions of the software, of the database, or with different payment provider integrations. There comes a point at which that set up is no longer scalable.

And I think fundamentally, I think it's easier, as a rule, Rob's rule, is it's easier to go from two of something to three of something than it is to go from one of something to two of something. And I think that's where CockroachDB really comes into its own, because you can start, if you need to, multi-region. You don't have to start with one region and then develop a second region, because then you need to figure out, well, how do I route to both regions? And you need to build in abstractions in order to make the holistic system make sense. It's like kids, I would argue it's easier to go from one kid to two kids than it is to go from zero kids to one kid.

David Joy:

To one kid, yeah. I don't disagree with that.

Rob Reid:

And there's translations. If you build your system to be multilingual to start off with, adding a third language is easy, because you've done the hard work of making your system multilingual. So that last pattern, it's using a system that's been designed to help you run across multiple geographic locations.

David Joy:

Oh yeah. I mean I loved some of the thought that was put into this. When you guys worked on this, I mean you worked on it, really, is to kind of take into these very impactful things for businesses and look at these patterns to make sure that you are covering some of the essentials that everybody is trying to get to. I mean, it's not like we have not had planning or architectures for failover regions. It's not about not planning for data domiciling, but it's for how can you simplify that journey for organizations and especially going into the next decade. We have had databases in the industry for 50, 60 years, and what they do essentially is, to your point, is we store data, they store data. And that story has not changed, but the way you access the data and how you retrieve the data and those patterns, and the requirement of the customer experience has changed so much in the last 50 years.

So recognizing these six patterns that you mentioned is amazing. I'm glad that you worked on that. And actually, honestly for me personally too, that app silos for data domiciling, that particular pattern, is something really interesting, because I feel like that's where a database like CockroachDB shines through, because you're saying, "Hey, you don't need to manage 17, from your example, different stacks, and we don't have to monitor 17 ecosystems, send data to Prometheus for 17 stacks, switch between tabs and monitor if everything is up and running. You just have to monitor one cluster of CockroachDB that manages the 17 regions or 17 use cases. Yeah.

Rob Reid:

And that's a real hidden benefit of CockroachDB. It's the organizational simplification that it's going to give you is so profound that it is the difference between needing to geographically distribute your team in order to manage a very disparate system to being able to centralize the management of an inherently distributed system. You are managing a global thing from one place. And obviously, the needs of every organization are going to be different.

But from the customers I've spoken to, from the people I've spoken to at events, nine times out of ten, their aspirations are to scale. You don't start a company wishing to only serve your neighborhood. You have ambitions to go wider. And typically, that does involve, nine times out of 10, crossing borders. And that regulatory compliance has never been more stringent. I wouldn't want to be a data privacy specialist. Well, it would probably be amazing now. But the complexity of it, it's a science in and of itself. I think there's 140 GDPR-like regulations around the world. And that's not to mention inter-country regulations like the Federal Wire Act, which is one of the reasons one of our customers is using CockroachDB, because it allows them to pin data to different states.

David Joy:

This is only going to get more complex, with a lot of things happening with AI, and we want to secure our data as much as possible. And I'm seeing more and more data privacy rules coming up, more policies coming. I've been hearing that India is working on one too, where they're...

Rob Reid:

LP... What's it called? Yeah, it's got a four letter acronym.

David Joy:

I don't remember the name. Yeah, so I did read about it that India wants to work on a policy like that to keep India's data there. But obviously, China is anyways not sending anything out or in. It's just natural for the world to get to that point. But then they want to still serve customers across the globe, because that's where true scale and revenue is kind of hidden for everyone is across borders. So that happens too. So yeah. Go ahead.

Rob Reid:

Going back to one of the big ideas you held a little while ago with Joshua Prisman, an architect, I think he hit the nail on the head, because he talks about architecture as being not just the applications that you run within it, but the holistic. So you've got to think of regulations as being part of your architecture. Because in effect, it's your responsibility to your customers to keep their data secure and to adhere to those complex geographic regulations. So bringing it in and being able to solve for it from within your own architecture is huge.

David Joy:

You've obviously spent a lot of time trying to identify these patterns and talk about the before and after. Where can people actually go and start reading what you have put together so they can actually make these changes themselves within their organizations?

Rob Reid:

So there's github.com, which is available via github.com/cockroachDB/architecturalsimplification. That's where all of the before and after code exists. I think there's about 12-and-a-half thousand lines of code dedicated to showing you the before and after. You can run it all locally on your computer. You might, in some cases, use local stack to spin up a simulated local AWS environment. It goes to that kind of level. There's also a YouTube playlist with, I think, 13 different videos. I can't remember the URL off the top of my head, because it's about 255 characters, but there's a YouTube playlist with all of the patterns before and after. You get to watch me absolutely suffer trying to horizontally scale a Postgres database. Anecdotally, I've always said, "Oh yeah, Postgres is really difficult to horizontally scale," because I've heard that is. But as a result of this project, I was able to try and horizontally scale it myself.

David Joy:

So you were able to experience it in real. Yeah.

Rob Reid:

I did, and it was so much harder than I was expecting. So it made me really glad for Cockroach. And the third thing is a webinar. I did a webinar with an amazing architect. His name is Scott Traver, and he works at Spreedly, and he worked with the Spreedly team to simplify their architecture and the patterns that they were using in advent of their adoption of CockroachDB. So we talk about their journey to simplification in that webinar.

So there's a bunch of different places, but we've also got a landing page. So if you go to cockroachlabs.com/architecturalsimplification, you'll also be able to get a load of information on simplification patterns there.

David Joy:

So what we are going to do for the listeners is we are going to tag all of that in the episode, and even when we send the information out for people to tag. This is some really amazing work that you have done, Rob. I really appreciate the amount of thought that goes into looking at problems, but not necessarily just your problems. You're looking at the world's problems and what people are working on, from experience, going into everything, condense everything into white paper or a document or videos. It takes a lot of work. And I'm glad that somebody like you has put that effort in and that's going to help all the customers and users of CockroachDB.

Rob Reid:

And hopefully non-users as well. Because I think before I knew about CockroachDB, I wasn't even asking the kinds of questions that would've enabled the company that I was at at the time. Because I was thinking locally, I was thinking a traditional database. I wasn't thinking in terms of distributed SQL and the problems that could solve for me. For example, when I was working at Lush, I'd never thought to ask the question, how many bath bombs do I have on this shelf in this store, on this floor? Then asking, "How many bath bombs do I have in this region of the country? How many bath bombs do I have in this country? How many bath bombs do I have of this type in the world?" And being able to answer that instantaneously from one place, it allowed me to then start asking different questions of the data. It showed me the art of the possible.

David Joy:

Right. And this was kind of segues into one of my questions that I was going to ask is that what have you learned in this process? What is it that people can learn from keeping their architecture simple? And you hit one really good point. Once you have the framework, once you have laid it out correctly, then that allows you to have the freedom to do so much more, right? So yeah, expand on that a bit.

Rob Reid:

So, the learnings, well, I learned that scaling Postgres was hard. That was my most painful learning. I didn't know, personally, that we were simplifying architecture before I joined this project, for so many people. I think knowing that we were solving or simplifying architecture was one thing, and then learning that we were solving the challenge of simplifying organizations on top of that, I had no idea because I didn't have the visibility into it, because I wasn't thinking about it. And when I talk about organizational simplification, I'm talking about things like given CockroachDB's resilience against failure, you move from having to think about disaster in terms of I need a backup database to the database I have is inherently resilient.

And weirdly, that makes it cheaper to run, because... And if I were to tell you that running a database across three data centers is cheaper than running that same database across two, previously, I would've said, "Well, no, that's not math, that's maths." But actually, it is. Because if you're running one database, you need to be able to satisfy a hundred percent of the workload on that one instance, and then you have to have an idle database that's capable of satisfying a hundred percent of the work in the event that that database goes away. So that's two times 100%. Whereas if you're running CockroachDB, each node is satisfying 33.3% of the workload. So you can have three smaller instances of the same thing. So I've learned that it can be cheaper. You think about distributed SQL and running across multiple places as being potentially more expensive, but it's really not. And then you couple that with the simplification it gives you, the ability to not have to write your own CDC integrations, the ability to pump changes directly from CockroachDB into Google Pub/Sub, S3, Kafka, simply because it's been built in, that's code you don't have to write.

Spreedly removed three of their own code bases that maintained what they would call the data cycle that they had in their system. So that was less code for them to maintain. And they also removed databases. They removed the databases that they had in place. They removed the code, they removed the data cycle, they removed a lot of their architecture simply because they no longer needed it. So I think the implications, the cost implications of Cockroach and the positive cost implications were also kind of opaque to me, because I wasn't thinking about it.

David Joy:

Thinking about it, yeah.

Rob Reid:

Yeah, exactly. Then there's a lot of patterns that people solve. For example, you think about dual writes, that typically, if you ask someone who's familiar with Oracle, how do I solve for dual writes. They might think of XA or distributed transactions. When you are dealing with a distributed database that manages transactions in a distributed fashion, you don't need to worry about that anymore. Or you can pump messages out by way of CDC through a transactional outbox. There's lots of different ways you can achieve the same thing you would've by buying an Oracle bolt-on for millions of pounds.

David Joy:

One of the things I remember when you were saying this is a story of one of our customers talking about dual writes. They decided to test CockroachDB for one of their complex workloads that affects their customers. What was happening was they were writing to Oracle and they were writing to CockroachDB, and during one of their most important events, and again, transactions were running, and the Oracle stack, there was a network outage or something happened that affected the Oracle stack. Basically, Oracle went down. However, CockroachDB stayed on, and there was no issues, and they were Like, "What?"

For them, this was a big revelation, that when they changed the architecture to serve the customer experience in this way, there is a big transformation across the overall experience as well. So I felt like that's the time when I was talking to the customer. They said that's when they decided that they needed to move everything to CockroachDB and stop using Oracle. And again, Oracle has been in the space for a while and did some amazing things, but I think just where the industry is going and the position where these companies who are building these new experiences where customers requires a new thought process to how they architect everything, right?

Rob Reid:

And to go back to what you said before, you mentioned that you have to test failover and failback. One of our customers, they have a team. They do game days as a lot of big organizations should, and for the team that look after CockroachDB, it's a day off, essentially because they've been unable to take the thing down.

David Joy:

That's good for our support. I love that. I love that story. But there are so many stories like that. The more I talk to customers, the more I realize this is one really good point that you brought up, this understanding that I also didn't have when I started using CockroachDB, is that we are not just the database. We're not solving the database problem. We're also changing the organizational problem, like we are solving a much bigger problem for you, a organization, and that's what this architectural simplification project helps people understand. I'm glad that you also mentioned that it can help people who are not moving to CockroachDB, just the idea of where they can be from where they are.

Rob Reid:

Especially when you are calculating the total cost of ownership for any system, if you can take into consideration the fact that, yes, I'll be able to replace this database. Let's say you're replacing Postgres with CockroachDB because you need the additional scale, just for sake of argument, you'd look at Cockroach and think, "Well, I didn't need to pay for Postgres," but actually, you were paying for Postgres in terms of having to operate it. You are having to pay people who knew Postgres to scale it for you and to keep those lights on. You've got hidden cost that you are paying for. So you've got, yes, there's CapEx involved in the onboarding of any new paid for service, but there's also the OpEx that's going to be drastically reduced because of that.

David Joy:

CockroachDB, it's not for every use case in the world, right? There are certain use cases where you might not need to use CockroachDB, but again, knowing these six patterns, and if this is what you're trying to achieve, and of course there are more, then I feel like CockroachDB is a great database for consideration. And I think if anybody can take that back, I would say that's what you wanted. These six things that drop talked about or brought up is what you're thinking about, then there is an ideal scenario for you to go and check these material out and see if you can get a free support day in your life.

Rob Reid:

I was on a customer call a while back. They weren't a customer at the time, but the idea was that hopefully they would become a customer. We drew out their architecture on this whiteboard. So we drew out their architecture, and then we thought, well, how can CockroachDB help? And I was able to circle things that could simply be forgotten about. They were no longer a concern for that company. And I think it's a really powerful learning, for them because they could see, objectively, where CockroachDB could help.

David Joy:

That's the benefit, right? There are so many things that we can get into, where the same idea is getting repeated. So much so that you're going to be making a new video on patterns from conversations.

Rob Reid:

And the white paper you mentioned, I would love to do that, and it may be a book. So I think there's a lot of material here that needs to be shared.

David Joy:

I think a book would be definitely helpful. I would always encourage people. And especially if it's somebody who's done so much work on a particular topic, put it out there. It's going to be really, really helpful.

You brought up the idea of that last part where you talked about ETL. I think our CDC, the way it is has come a long way. There are so many new things that you can do recently, I think because you mentioned it, I'm going to mention it now. Recently we've worked on some really cool integrations where you can push data from CDC, and one of my teammates in the team, Arsh, has worked on integrating data from CockroachDB all the way to Big Query through pop sub. That's one route that you can take. If you're on AWS, AWS recently released during reinvent a feature called continuous ingestion. So what that means is if you can send data to S3, but again, it creates a problem of triplication, of data. It's like data is...

Rob Reid:

Sometimes it's unavailable. S3, a great product, and it's the gateway to a lot of the value that AWS provides from a data perspective.

David Joy:

I agree. And you get it to S3, and then from S3, you can directly send the data to Redshift, but it happens in a continuous ingestion way. Of course, there are certain challenges with it because of the pre-processing that needs to be done before it gets into Redshift has to be planned for. But again, it still works. That route still works, and there is Kafka and MSK and a bunch of those things. So those are important paradigm. Because to your point, I want to know how many bath bombs are there in this country and what types and everything. And you really get into, once you have the data available to go in and start talking about what story you want to tell with that data, right?

Rob Reid:

Yeah. And it comes down to the data warehousing theme of patterns, because it's all to do with minimizing the amount of time from getting the data or updating the data and seeing the value from that data, being able to get and derive insights from that data. And if you're operating against one database, that value is immediate. You can get it straight away.

David Joy:

It's been amazing talking to you, Rob. So before I let everyone go, I usually ask them these two questions. So you have no choice but to answer, is that how do you keep up? How do you keep up with all the madness in the tech space? Obviously as a tech evangelist, you need to know what you're talking about. There's CockroachDB, but then all of these other things that people come and ask you that you're like, "Oh, I didn't know about that particular thing." So how do you keep up? So what's your method?

Rob Reid:

In terms of news, I use Feedly, and this sounds like a... Now we're going to go into a paid segment from Feedly. I use Feedly because I'm too lazy to keep going to all of these different sources. So Ars Technica and The Verge and The Register all comes to me. So I'm lazy like that. But I think trying to be overly helpful within CockroachDB, it also benefits me, because I'm having to learn a lot more than I otherwise would if I was just to sit back and be a technical evangelist. If I was just to sit back and write demos and record videos, I wouldn't learn half as much as I do now. So being curious about what other people are doing in the organization and wanting to help forces me into learning a bit more about their role and a bit more about what they're working on in terms of the data space is great because it forces me to learn.

David Joy:

Where can people follow you, and know what you're working on?

Rob Reid:

Probably three places, I'd say. There's GitHub, github.com/codingconcepts. That's me. I work on a lot of open source projects in my spare time, like tools that kind of surround the CockroachDB ecosystem in terms of generating data, inserting data, data-y things. There's also LinkedIn where I am Rob-Reid, R-E-I-D. And there's also Twitter, where I am robreid_io.

David Joy:

All right. So Rob, thank you so much for hopping on today. It was great talking to you and getting into things. So once again, I hope we can have you again and talk about some other things as well.

Rob Reid:

If you'll have me back, I'd love to come. Thank you. Thank you very much for that, David.

David Joy:

All right. Thank you so much as well.

Rob Reid:

Take care.