Screaming in the Cloud - Couchbase and the Evolving World of Databases with Perry Krug

Episode Date: November 28, 2022

About PerryPerry Krug currently leads the Shared Services team which is focused on building tools and managing infrastructure and data to increase the productivity of Couchbase’s Sales and Field organisations.  Perry has been with Couchbase for over 12 years and has served in many customer-facing technical roles, helping hundreds of customers understand, deploy, and maintain Couchbase's NoSQL database technology.  He has been working with high performance caching and database systems for over 15 years.Links Referenced:Couchbase: https://www.couchbase.com/Perry’s LinkedIn: https://www.linkedin.com/in/perrykrug/

Hello, and welcome to Screaming in the Cloud, with your host, Chief Cloud Economist at the Duckbill Group, Corey Quinn. This weekly show features conversations with people doing interesting work in the world of cloud, thoughtful commentary on the state of the technical world, and ridiculous titles for which Corey refuses to apologize. This is Screaming in the Cloud. This episode is brought to us in part by our friends at Pinecone. They believe that all anyone really wants is to be understood, and that includes your users. AI models combined with the Pinecone Vector Database let your applications understand and act

on what your users want without making them spell it out. Make your search application find results by meaning instead of just keywords. Your personalization system make picks based on relevance instead of just tags. And your security applications match threats by resemblance instead of just regular expressions. Pinecone provides the cloud infrastructure that makes this easy, fast, and scalable. Thanks to my friends at Pinecone for sponsoring this episode. Visit pinecone.io to understand more. InfluxDB is the smart data platform for time series. It's built from the ground up to handle the massive volumes and countless sources of timestamp data produced by sensors, applications, and systems.

You probably think of these as logs. InfluxDB's programmable and performant has a common API across the platform and handles high granularity data at scale and with high availability. Use InfluxDB to build real-time applications for analytics, IoT, and cloud-native services, all in less time and with less code. So go ahead, turn your apps up to 11 and start your journey to awesome for free at influxdata.com slash screaming in the cloud. That's influxdata.com slash screaming in the cloud. Welcome to Screaming in the Cloud. I'm Corey Quinn. Today's episode is a promoted guest episode brought to us by our friends at Couchbase. Now, I want to start off by saying that this week is AWS reInvent, and there is Last Week in AWS swag available at their booth.

More on that to come throughout the next half hour or so of conversation, but let's get right into it. My guest today is Perry Krug, Director of Shared Services over at Couchbase. Perry, thanks for joining me. Hey, Corey. Thank you so much for having me. It's a pleasure. So we're recording this before reInvent, so the fact that we both have, you know, personality and haven't lost our voices yet should probably be a bit of a giveaway on this. But I want to start at the very beginning because unlike people who are academically successful, I tend to suck at doing the homework across the board. Couchbase has been around for a long time. We've seen the company do a bunch of different things,

most importantly and notably sponsoring my ridiculous nonsense, for which I thank you. But let's start at the beginning. What is Couchbase? Yeah, you're very welcome, Corey. And again, it's a pleasure to be here. So Couchbase is an enterprise database company at the very top level. We make database software and we distribute that to our customers. We have two flavors, two ways of getting your hands on it. One is the kind of legacy, what we call self-managed, where you, the user, the customer, downloads the software, installs it themselves, sets it up, manages the cluster, monitoring, scaling, all of that. And that's a big part of our business.

Over the last few years, we've identified, and certainly others in the industry have as well, the desire for users to access database and other technology in a hosted software as a service, pay-as-you-go, cloud-native, buzzword, et cetera, et cetera, vehicle. And so we've released the Couchbase Capella, which is our fully managed, fully hosted database as a service running in currently Amazon and Google now come to and consume as developers and build their applications while leaving all the operational and administration, monitoring, managing, failover, expansion, all of that to us as the experts. So you folks are a non-relational database, NoSQL in the common parlance, which is odd because they call it NoSQL, yet they keep making more of them. So I feel like that's sort of the Hollywood model where, okay, that was so good, we're going to do it again.

Where did NoSQL come from? Because back when I was learning databases, when dinosaurs roamed the earth, it was all about relational models. Like, we're going to use a relational database because when the only tool you have is an ax, every problem looks like hours of fun. What gave rise to this, I guess, Cambrian explosion that we've seen of NoSQL options that proliferate over the land? Yeah, really, really good question. And I like the axe throwing metaphor. So sure, 20, 30, 40 now years ago, as digital applications needed a place to store their data, the world invented relational databases. And those were used and continue to be used very well for what they were designed for,

for data that follows a very strict structure that doesn't need to be served at significant scale, does not need to be replicated geographically, does not need to handle data coming in from different sources and those sources changing their formats of things all the time. And so I'm probably as old as you are and been around when the dinosaurs were there. We remember this term called Web 2.0. Kids, you're going to have to go look that up in the dictionary or TikTok it or something. But Web 2.0 really was the turning point when websites became web applications. And suddenly, there was the introduction of MySpace and Facebook and Amazon and Google and LinkedIn and a number of others. And they realized that relational databases were not going to meet their needs, whether it be performance, whether it be flexibility, whether it be

changing of data models, whether it be introducing new features at a rapid pace. They tried, they stretched them, they added a bunch of different databases together, and really was not going to be a viable solution. So 10, now maybe 15 years ago, you started to see the rise of these tech giants, although we didn't call them tech giants back then, but they were the precursors to today's invent their own new databases. So Amazon had theirs, Google has theirs, LinkedIn, and a number of others. These companies had reached a level of scale and reached a level of user base and reached a level of user base, had reached a level of data requirement, had reached a level of expectation with their customers. These customers, us users, us consumers, we expect

things to be fast. We expect them to be always available. We expect Facebook to give us our news feed in milliseconds. We expect Google to give us our website or our search results in immediate with more and more information coming along with them. And so it was these companies that hit those requirements first. The only solution for them was to start from scratch and rewrite their own databases. Fast forward five, six, seven years, and we as consumers turned around and said, look, I really like the way Facebook does things. I really like the way Google does things. I really like the way Amazon does things where it's going to take me from one place to another. I want it to give me a receipt immediately after I finish my ride. Actually, I want to be able to change my payment method after I paid for that ride because I used the wrong one.

All of these are expectations that we as consumers have taken from the tech giants, Apple, LinkedIn, Facebook, and turned around to nearly every other service that we interact with on a daily basis. And all of a sudden, the requirements that Facebook had, that Google had, that no other company had, or outside of the top five, suddenly were needed by every single industry, nearly every single company, in order to be competitive in their markets. And there's no way to scale relational to get to a point where it can wind up handling those type of workloads efficiently? Correct, correct. And it's not that the technology cannot do it. Everything is technically feasible, but the cost, both

financially and time-to-market-wise, in order to do that in a relational database was untenable. It either cost too much money, or it costs too much developers time, or cost too much of everybody's time to try to shoehorn something into it. the rise of cloud and containers, which relational databases never even had the inkling of a thought that they might need to be able to handle someday. And so these requirements that consumers have been placed on everything else that they interact with really led to the rise of NoSQL as a commodity or as a database for the masses, where LinkedIn is not in the business of developing a database and then selling it to everybody else to use as a database, right? They built it for themselves, they made their service better. And so what you see is some of those founding fathers created databases, but then had no desire to sell them to others. And then after that followed the rise of companies like Couchbase, and a number of others who said, look, we think we can provide those capabilities.

We think we can meet those requirements for everybody. And thereby rose the plethora of NoSQL databases because everybody had a little bit different of an approach to it. If you ask 10 people what NoSQL is about, you're going to get 11 or 12 different answers. But you can kind of distill that into two categories. One is performance and operation. So I need it to be faster, I need it to be scalable, I need it to be replicated geographically. And that's what NoSQL is to me. And that's the right answer. And so you have things like Cassandra and Redis that are meant to be fast and scalable and replicated.

You ask another group and they're going to tell you, no, no, no, NoSQL needs to be flexible. I need to get rid of the rigid database schemas. I need to bring JSON or other data formats in and munch all this data together and create something cool and new out of it. And thereby you have the rise of things like MongoDB who focused on nearly exclusively on the developer experience of working with data. And for a long time, those two were in opposite camps, where you had the databases that did performance and the databases that did flexibility. thing, but we've certainly tried to approach both of those challenges together so that you can have

something that scales and performs and can be flexible in data model. And everybody else is trying to do the same thing, right? All these databases are competing for that same nirvana of the best of both worlds. You know, it almost feels like there's a convergence play in a place where everything now is trying to go away from the idea, oh yeah, we started off as a purpose-built database, but you can use this for everything. And I don't necessarily know that that is going to be the path that a lot of companies want to go down. Where do you view Couchbase as, I guess, falling down? In other words, what workloads is Couchbase inappropriate for? Yeah, that's a good question. And my market is- Anyone who can't answer that one is a zealot.

And that's one of those, okay, let's be very careful and not take our eyes off you for one second while smiling and backing away slowly. Let's cut to commercial. No, I mean, there certainly are workloads that in the past we've not been good for that we've made improvements to address. There are workloads that we had not addressed well today that we will try to address in the future. And there are workloads that we've made improvements to address. There are workloads that we had not addressed well today

that we will try to address in the future. And there are workloads that we may never see as fitting in our wheelhouse. The biggest category group that comes to mind is Couchbase is not a archival database. We are not meant to have data put in us that you don't care about, that you don't want to, that you just need to keep around,

but you don't ever need to access. And there are systems that do that well. They do that at a solid total cost of ownership. And Couchbase is meant for operational data. It's meant for data that needs to be interacted with, read and or written at scale and at a reasonable performance to serve a user-facing or system-facing application. And we call ourselves a general purpose database. Mongo and others call themselves as well. Oracle calls itself a general purpose database, and yet not everybody uses Oracle for everything. So there are reasons to choose. Who could afford that?

Who could? Exactly. It comes down to cost, ultimately. So I'm not here to say that Couchbase does everything. We like to think and we're trying to target and strive towards an 80%. If we can do 80% of an application or an organization's workloads, there is certainly room for 20% of other workloads, other applications, other requirements that can be met or need to be met by purpose-built databases. But if you rewind four or five years, there was this big push towards polyglot persistence. It's a buzzword that came and kind of has gone out of fashion, but it presented the idea that everybody is going to use 15 different databases and everybody is going to pick the right one for exactly the workload. I mean, they're going to somehow stitch them all together. And that really hasn't come to fruition either. So I think

there's some balance where it's not one to rule them all, but it's also not 15 for every company. Some organizations just have a set of requirements that they want to be met, and our database can do that. Let's continue our tour of the competitive landscape here, now that we've handled the relational side of the world, the best database, as anyone who's listened to this show knows, is of course Amazon's Route 53, text records stuffed into DNS, especially in the NoSQL land. Clearly, you're all fighting for second place after that. How do you stack up against the idea of legitimately using that approach? And for those who are not in on the joke, please don't do this. It is not the right answer. But I'm curious to get your take as to why DNS text records are an inappropriate NoSQL option. Well, it's a joke, right? Let's be clear about that. But I have to say that because

otherwise someone tries it in production. I've gotten that wrong a few times historically. So I need to put a disclaimer in because, yeah, it's only funny so long as people are in on the joke. If not, and I lead someone down the Primrose path, the disaster, I feel bad. So let's be very clear. We're kidding. And I'm laughing. I'm laughing here behind the camera. I am. I am. Yeah. Though the element of truth that I think Couchbase is in a position or I'm in a position to kind of talk about is 12 years ago when Couchbase started, we were a key value database. And that's where we saw the best part of the market in those days, and where we were able to achieve the best scale and replication and performance and fairly quickly realized that simple key value, though extremely valuable and easy to manage was not broad enough in requirements meeting. And that's where we set our sights on and identified the larger kind of document database

group, which is really just a derivative of key value, where still everything is a key and a value. It's just now a document that you can reason about, that you can create an index on, that you can query, that you can run full text search on. You can do much more with the data. So at our core, we are still a key value database. When that value is JSON, enter into the document database market, they would need to be adding things that allowed you to introspect and ask questions of the data within that text, which you can't, right? Well, not with that attitude. But yeah, I agree with you. Moving up the stack, let's talk about a much more fearsome competitor here that I'm certain you see

in an awful lot of the deals that you wind up closing, specifically your own open source product. You historically have wound up selling software into environments I believe referred to as your legacy offering, where it's the hosted version of your commercial software. And now, of course, you also have Capella, your cloud-hosted version. But open source looks surprisingly compelling for an awful lot of use cases and an awful lot of folks. What's the distinction? Sure. Just to correct a little bit the distinction, we have Couchbase server, which we provide as a, what we call self-managed, where you can download it and install it yourself. Now you can do that with the open source version, or you could do that with our enterprise edition. What we've then done is wrapped that enterprise edition in a hosted model, and

that's Capella. So the open source version is something we've long been supporters of. It's been a core part of our go-to-market for the last 12 or 13 years or so, and we still see it as a strong offering for organizations that don't need the added features, the added capabilities, don't need the support of the experts that wrote the software behind them. Certainly, we contribute and support our community through our forums and Discord and other channels, but that's a very big difference than two o'clock in the morning, something's not working, and I need a ticket to track. We don't do that for our community edition. So we see lots of users downloading that, picking it up, building it into their applications,

especially applications that are in their infancy or are with organizations that they simply can't afford the added cost and therefore they don't get the added benefit. We're not here to gouge and carve out every dollar that we can. But if you need the benefit that we can provide, we think there's value in that. And that's what we're trying to run a business as. Oh, absolutely. It doesn't work when you're trying to wind up charging a license fee for something that someone is doing in their spare time project for funsies just to learn the technology. It's like, yep.

And then they show up. It's like, that'll be $700. Surprise. Yeah, that's sort of the AWS billing model approach. It's not a viable on-ramp for most folks. So the open-source direction down there makes sense. Counterpoint, if you're running a bank on top of it, well, we're running

it ourselves and really hoping for the best. We have access to the code and all. Great. But there are times you absolutely want some of the best minds in the world, with respect to that particular product, able to help troubleshoot so the ATMs start working again before best minds in the world with respect to that particular product able to help troubleshoot so the ATMs start working again before people riot in the streets. Yeah. And ultimately, it's a question of core competencies. Are you an organization that wants

to be in the database development market? Great. By all means, we'd love to support you in that. If you want to focus on doing what you do best, be it a bank or an e-commerce website, you worry about your application, you let us worry about the database and everybody gets along very well. There's definitely something to be said for outsourcing some of the pain, some of the challenge around an awful lot of it. There's a natural progression to the cloud for that and software as a service, database as a service, where you're now outsourcing even more by running on our hosted platform. No longer do you have to download the binary and install it yourself.

No longer do you have to set up the cluster and watch it in case it has a blip or the statistic goes up too far. We're taking care of that for you. So yes, you're paying for that service, but you're getting the value of not having to be a database manager, let alone database developer for that. Thank you. That's snark.cloud slash L-U-M-I-G-O. What is the point of distinction between Couchbase Server and Couchbase Capella? To be clear, you're self-hosted versus managed cloud offerings. When is one appropriate versus the other? Well, I'm supposed to say that Capella is always the appropriate choice,

but there are currently a number of situations where Capella is not available in particular regions or cloud providers. And so downloading and running the software yourself, certainly in your own, yes, there are people who still run their own data centers. I know it's taboo and we don't like to talk about that, but there are people who have on-premise. And so Couchbase Capella is not available for them. But Couchbase Server is the original Couchbase database, and it is the core of Couchbase Capella. So wrapping is not giving it enough credit. We use Couchbase Server to power Couchbase Capella. And so there's an enormous amount of value added around the core database. But ultimately, it's the behind the scenes of Couchbase Capella,

which gives us a nice, I think is a nice benefit in that when an application is connecting to either one, it gets the same experience. You can point an application at one versus the other. And because it's the same database running behind the scenes, the behavior, the data model, the query language, the APIs are all the same. So it adds a nice level of flexibility for customers that are either moving from one to another or have to have some sort of hybrid approach, which we see in the market today. Let's talk economics for a second. I can see scenarios where especially you have a high volume environment where you're sending tremendous amounts of data back and forth.

And as soon as that crosses an availability zone boundary or region boundary, or God forbid, goes out to the internet via standard egress fees over in AWS land, there's a radically different economic modeling that comes into play as opposed to having something in the same availability zone in the same subnet, just where that where all traffic back and forth is free. Do you see that in your customer base, that that is a model that is driving people towards self-hosting? No. And I'd say no, because Capella allows you to peer and run your application in the same

availability zone as the database. So as long as that's an option for you that we have our offering in the right region, in the right AZ, and you can put your application there, then that's not an issue. We did have a customer not too long ago that didn't set that up correctly. They thought they did. And we noticed some high data transfer charges. Again, the benefit of running a hosted service, we detected that for them. And we're able to turn around and say, you might want to change this to over there so that we all save some money in doing so. If we were not there watching it, they might not have noticed it themselves if they were running it self-managed. They might not have known what to do about it. And so there's a benefit to working

with us and using that hosted platform that we can keep an eye out and we can apply all of our learning and best practices and bug fixes. We give it to everybody rather than each person having to stumble across those hurdles themselves. That's one of those fun, weird, corner case trivia things about AWS data transfer. When you're transferring data within the same region between availability zones, it costs a penny on the sending side and a penny on the receiving side. Everything else is one side or the other that winds up getting the charge.

And what makes this especially fun is that when it shows up on your bill, if you transfer a petabyte, it shows as cross-AZ data transfer two petabytes. So it double counts, so they can bill it appropriately, but it leads to some really weird hunting it down, like, OK, well, we found half of it. But where's the other half hiding?

It's always obnoxious to trace this stuff down. The fact that you see it on your bill, well, that's testament to the fact that, yeah, they're using the service. Good for them and good for you. Being able to track it down on a per customer basis, that does speak to your level of insight into what exactly is going on in your environment and where. As someone who does this for a living, let me confirm that that is absolutely non-trivial. No, definitely non-trivial.

And we've learned over the last four or five years, we've learned an enormous amount about how cloud providers work, how AWS works. But guess what? Google does it completely differently. And Azure does it completely differently. And Azure does it completely differently. And so on the surface level, they're all just cloud providers and they give you a VM and you put some stuff on it, but integrating with the APIs, integrating

with the different systems and naming of things, and then understanding the intricacies and the ins and outs. And yeah, these cloud providers have their own bugs as well. And so sometimes you stumble across that for them. And it's been a significant learning exercise that I think we're all better off for having Couchbase gone through it for you. Let's get this a little bit more germane for this week. For those of you who are listening to this during reInvent, you folks are clearly here at the show.

It's funny talking about here, even though when we're recording this, it is not near here and we're actually home and enjoying ourselves, but welcome to Temporal Dislocation. Here we are. Here at the show, you folks are, among other things, being kind enough to pass out the last week in AWS swag from your booth, which thank you. So that is obviously the primary reason that you were at the show. What are the other reasons? What are the secondary reasons that you decided to come here? Yeah. Well, I guess I have to think about this now since you already called out the primary reason. Exactly. Wait, we can have more than one reason for things? My God. Can we? Can we? AWS has long been a huge partner of ours, even before Capella itself was released. I remember sometime in the, you know, five years or

so ago, some 30% of our customers were running Couchbase inside of AWS. And some of our largest were some of your largest at times, like Viber, the messaging platform. And so we've always had a very strong relationship with AWS. And the better that we can be presenting ourselves to your customers and our customers can feel that we are jointly supporting them, the better. And so coming to reInvent is a testament to that longstanding and very solid partnership. And also, it's meant to get more exposure for us to let it be clear that Couchbase runs very well on AWS. It's one of those areas where when someone says, oh yeah, this is a great service offering, but it doesn't run super well on AWS, it's like, okay, so are you bad at computers or

is what you have built so broken and Byzantine that it has to live somewhere else? Or occasionally, the use case is absolutely not supported by AWS. Not to beat them up some more on their egress fees, but I'm absolutely about to. If you're building a video streaming site, you don't want it living in AWS. It won't run super well there. Well, it'll run well,

it'll just run extortionately expensively. And that means that it's a non-starter. Yeah, why do you think Netflix raises their fees? Netflix, to their credit, has been rather public about this, where they do all of their egress via their OpenConnect custom-built CDN appliances that they drop all over the place. They don't stream a single byte from AWS, and we know this from the outside because they are clearly still solvent. I did the math on that, so if I'd been streaming at on-demand prices one month with my Netflix usage,

I would have wound up spending four times my subscription fee just in their raw cost for data transfer. And I have it on good authority that it's not just data transfer that is their only bill in the entire company. They also have to pay people and content and the analytics engine and whatnot. And it's kind of a weird, strange world. Real estate. Yeah, because it's one of those strange stories, because they are absolutely a showcase customer for AWS. They've been a marquee customer, trotted out year after year to talk about what they're doing. But if you attempt to replicate their business purely on top of AWS, it will not work full stop. The economics preclude that

happening. What is your philosophy these days on what historically has felt like an existential threat to most vendors that I've spoken to in a variety of ways? What if Amazon decides to enter your market? I'll ask you the same thing. Do you have fears that they're going to wind up effectively taking your open source offering and turning it into Amazon basics couch base, for lack of a better term. Is that something that is on your threat radar, or is that not really something you concern yourselves about? So, I mean, there's no arguing, there's no illusion that Amazon and Google and Microsoft are significant competitors in the database space, along with Oracle and IBM and

Mongo and a handful of others. Anything's a database if you hold it wrong. This is true. The specific point of open source is something that we have addressed in the same ways that others have addressed. And that's by choosing and changing our license model so that it precludes cloud providers from using the open source database to produce their own service on the back of it. Let me be clear, it does not impact our existing open source users and anybody that wants to use the community edition

or download the software, the source code, and build it themselves. It's only targeted at Amazon because they have a track record of doing that to things like Elastic and Redis and Mongo, all of whom who have made similar to Gouchbase moves to prevent that via the licensing of the open source code. is, and I believe wholeheartedly this comes historically from a lot of AWS's requirements for vendors on the show floor that have become public through a variety of different ways, where for a long time you were not allowed to mention multi-cloud or reference the fact that you worked on any other cloud provider there. So there's been a theme of this is why for whatever it is we sell or claim to sell or hope one day to sell, AWS is the absolute best place for you to run it full stop. And in some cases, that's absolutely true because people build primarily for a certain

cloud provider. And then when they find customers in other places, they learn to run it over there too. If I'm approaching this from the perspective of I have a database problem because looking at my philosophy on databases, it's hard to imagine I don't have database problems, then is my experience going to be better or even materially different between any of the cloud providers if I become a Couchbase Capella customer? I'd like to say no. We've done our best to abstract and to leverage the best of all of the cloud providers underneath to provide Couchbase in the best form that they will allow us to.

And as far as I can see, there's no difference amongst those. Your application and what you do with the data, that may be better suited to one provider or another. But it's always been Couchbase's philosophy, so to say, strategy to make our software available to wherever our customers and users want to consume it. And that goes everything from physical hardware running in data center, virtual machines on top of that, containers, cloud, and different cloud providers, different regions, different availability zones, all the way through to edge and other infrastructures. We're not in a position to say, if you want Couchbase, you should use AWS. We're in a position to say, if you are using AWS, you can have Couchbase. I really want to thank you for being so generous with your time and, of course, your sponsorship dollars, which are deeply appreciated.

Once again, swag is available at the Couchbase booth this week at reInvent. If people want to learn more, and if for some unfathomable reason they're not at reInvent, probably because they make good life choices, where can they go to find you? Couchbase.com. Got to be the best place to land on. That takes you to our documentation, our resources, our getting help, our contact pages, directly into Capella. If you want to sign in or log in, I would go there. And we will, of course, put links to that in the show notes. Thank you so

much for your time. I really appreciate it. Corey, it's been a pleasure. Thank you for your questions and banter. And I really appreciate the opportunity to come and share some time with you. We'll have to have you back in the near future. Perry Krug, Director of Shared Services at Couchbase. I'm cloud economist Corey Quinn and this is Screaming in the Cloud. If you've enjoyed this podcast, please leave a five-star review on your podcast platform of choice. Whereas if you've hated

this podcast, please leave a five-star review on your podcast platform of choice along with an angry and insulting comment berating me for being nowhere near musical enough when referencing Couch Bass Capella. If your AWS bill keeps rising and your blood pressure is doing the same, then you need the Duck Bill Group.

We help companies fix their AWS bill by making it smaller and less horrifying. The Duckbill Group works for you, not AWS. We tailor recommendations to your business, and we get to the point. Visit duckbillgroup.com to get started. this has been a humble pod production stay humble