Screaming in the Cloud - How Couchbase is Using AI to Enhance the User Experience with Laurent Doguin

Episode Date: November 14, 2023

Laurent Doguin, Director of Developer Relations & Strategy at Couchbase, joins Corey on Screaming in the Cloud to talk about the work that Couchbase is doing in the world of databases and developer relations, as well as the role of AI in their industry and beyond. Together, Corey and Laurent discuss Laurent’s many different roles throughout his career including what made him want to come back to a role at Couchbase after stepping away for 5 years. Corey and Laurent dig deep on how Couchbase has grown in recent years and how it’s using artificial intelligence to offer an even better experience to the end user.About LaurentLaurent Doguin is Director of Developer Relations & Strategy at Couchbase (NASDAQ: BASE), a cloud database platform company that 30% of the Fortune 100 depend on.Links Referenced:Couchbase: https://couchbase.comXKCD #927: https://xkcd.com/927/dbdb.io: https://dbdb.ioDB-Engines: https://db-engines.com/en/Twitter: https://twitter.com/ldoguinLinkedIn: https://www.linkedin.com/in/ldoguin/

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. Are you navigating the complex web of API management, microservices, and Kubernetes in your organization?

Solo.io is here to be your guide to connectivity in the cloud-native universe. Solo.io, the powerhouse behind Istio, is revolutionizing cloud-native universe. Solo.io, the powerhouse behind Istio, is revolutionizing cloud-native application networking. They brought you Glue Gateway, the lightweight and ultra-fast gateway built for modern API management, and Glue Mesh Core, a necessary step to secure, support,

and operate your Istio environment. Why struggle with the nuts and bolts of infrastructure when you can focus on what truly matters, your application? Solo.io has got your back with networking for applications, not infrastructure. Embrace zero trust security, GitOps automation, and seamless multi-cloud networking, all with Solo.io. Here's the real game changer, a common interface for every connection, in every direction, all with one API. It's the future of connectivity, and it's called Glue by Solo.io. DevOps and platform engineers, your journey to a seamless cloud-native experience

starts here. Visit Solo.io slash Screaming in the Cloud today to level up your networking game. Welcome to Screaming in the Cloud. I'm Corey Quinn. This promoted guest episode is brought to us by our friends at Couchbase. And before we start talking about Couchbase, I would rather talk about not being at Couchbase. Laurent Duran is the Director of Developer Relations and Strategy at Couchbase. First, Laurent, thank you for joining me. Thanks for having me. It's a pleasure to be here. So what I find interesting is that this is your second time at Couchbase,

where you were a developer advocate there for a couple of years. Then you had five years of, we'll call it wilderness, I suppose. And then you returned to be the director of developer relations, which also ties into my personal working thesis of the best way to get promoted at a lot of companies is to leave and then come back. But what caused you to decide, all right, I'm going to go work somewhere else? And what made you come back? So I've joined database in 2014, spent about two or three years as DA. And during those three years as a developer advocate, I've been advocating a SQL database and I, at the time it was mostly DBAs and Ops I was talking to.

And DBA and Ops are well, recent modern Ops are writing code. But they were not the people I wanted to talk to when I was a developer advocate. I came from a background of developer. I've been a platform engineer for an enterprise content management company. I was writing code all day. And when I came at Couchbase, I realized I was mostly talking about Docker and Kubernetes, which is still cool, but not what I wanted to do. I wanted to talk about developers, how they use database to build better apps,

how they use key value and those weird things like MapReduce. At the time, MapReduce was still like a weird thing for a lot of people and probably still is because now everybody's doing SQL. So that's what I wanted to talk about. I wanted to engage with the people I identify with, really. And so it didn't happen. Left, built a platform as a service company called CleverCloud. They started about four or five years before I joined. We went from seven people to 31 when I left.

Fully bootstrapped, no VC. That's an interesting way to build a company in this age. Very hard to do because it takes a lot of upfront investment to build software, but you can sort of subsidize that via services, which is what we've done here in some respects. But yeah, that's a hard road to walk. That's the model we had.

And especially when your competition is AWS or Azure or GCP. So that was interesting. So entrepreneurship, it's not for everyone. I did my four years there and then I realized maybe I'm going to do something else. I met my former colleagues of Couchbase at a software conference called DevOx in France. And they told me, well, there's a new sheriff in town. You should come back and talk to us. It's all about developers.

We are repositioning, re-angling the way we do marketing at Couchbase. Why not have a conversation with our new CMO, John Krejcia? And I said, well, I mean, I don't have anything to do. I actually built a brewery during that past year with some friends that was great but that's not gonna feed me or anything so yeah let's have a conversation about work and so I talked to John I talked to a bunch of other people and I realized it actually changed like there was a they were purposely going against developer talking to developer and that was not

the case necessarily five six years before that so that's why i came back uh the product is still amazing people are still amazing uh it was interesting to find a lot of people that still work there after what five years and it's a company based in uh in california headquarters in california so you would expect people to, you know, jump around a bit. I was pleasantly surprised to find the same folks there. So that was also one of the reasons why I came back. It's always a strong endorsement when former employees rejoin a company because I don't know about you, but I've always been aware of those companies you work for, you leave like, oh, I'm never doing that again for love or money, just because it was such an unpleasant experience. So it speaks well when you see companies that do have a culture of

boomerangs, for lack of a better term. That's the one we use internally. And there's a couple, more than a couple. So one thing that seems to have been a thread through most of your career has been an emphasis on developer experience. And I don't know if we come at it from the same perspective, but to me, what drives me nuts is honestly, with my work in cloud, bad developer experience manifests as the developer in question, feeling like they're somehow not very good at their job. Like they're somehow not understanding how all this stuff is supposed to work. And honestly, it leads to feeling like a giant fraud. And I find that it's pernicious, because even when I intellectually know for a fact that I'm not the dumbest person ever to use this tool, when I don't understand how something works, the bad developer experience

manifests to me as, you're not good enough. At least that's where I come at it from. And also, I don't say to the people that build these products, because if we build a product, the user might be in the same position that we are right now. And so we might be responsible for that experience, someone's a developer, and that's not a great feeling. So I completely agree with you. I've tried to always join software-focused companies,

whether it was Nuxio, Couchbase, CleverCloud, and then Couchbase. And I guess one of the good things about coming back to a developer-focused era is all the product alignments. Like a lot of people talk about products like growth and what it means. To me, what it means was what it meant, or it still means. Building a product that developer wants to use, and not just want to, sometimes it's imposed to you, but actually are happy to use. And as you said, don't feel completely stupid in front of that product. It goes through different things.

We've recently revamped our Cache-based UI, Calibris Capella UI. Calibris Capella is our managed cloud product. And so we've added a lot of in-product getting started guidelines, snippets of code to help developers getting started better and not have that feeling of what am I doing? Why is it not working and what's going on? That's an interesting decision to make, just because historically working with a bunch of tools the folks who are building the documentation and working with that tool tend to generally be

experts at it so they tend to optimize for improving things that for the experience of someone who's been using it for five years as opposed to the newcomer so i find that the longer a product is in existence in many cases cases, the worse the new user experience becomes because companies tend to grow and sprawl in different ways. The product goes does likewise. And if you don't know the history behind it, oh, your company, what does it do? And you look at the website and there's 50 different offerings that you have, like the AWS landing page, it becomes overwhelming very quickly. So it's neat to see that emphasis throughout the user interface

on the new developer experience. How are, on the other side of it though, how are the folks who've been using it for a while responding to those changes? Because it's frustrating for me, at least, when I log into a new account, which happens periodically within AWS land, and I have this giant series of onboarding pop-ups

that I have to click to make go away every single time. How are they responding to it? Yeah, it's interesting. One of the first things that struck me when I joined Catalyst the first time was the size of the technical documentation team. Because the whole, well, not the whole point, but part of that, the reason why they exist is to do that, to make sure that you understand all the differences and that it doesn't feel like the co-engineering wrote the documentation or the product pitch or everything. They really, really,

really emphasize on this from the very beginning. So that was interesting. So when you get that culture built to the product, well, the good thing is when people try CacheBase, they usually stick with CacheBase. My main issue as a director of the preparation

is not to make people stick with CacheBase because that works fairly well with the product that we have. It's to make them aware that we exist. That's the biggest issue I have. So my goal as DevRel is to make sure that people get in the trial, get through the trial, get all that in-app context, all that helps, get that first sample going, get that first, I'm not going to say product build

because that's even a bit further down the line, but get that sample going. We have a code playground. So when you're in the application, you get to actually execute different pieces of code, different languages. And so we get those numbers and we're happy to see that people actually try that.

And that's a good feeling. I think that there's a definite lack of awareness, almost industry-wide, around the fact that as the diversity of your customers increases, you have to have different approaches that meet them at various points along the journey, because things that I've seen are, okay, it's easy to even just assuming a

binary of, okay, I've done this before a thousand times is the thousand first. I don't need the hello world tutorial versus, oh, I have no idea what I'm doing. Give me the hello world tutorial. There are other points along that continuum, such as, oh, I used to do something like this, but it's been three years. Can you give me a refresher? And so on. I think that there's a desire to try and fit every new user into a predefined persona. And that just doesn't work very well as products become more sophisticated. It's interesting. We actually have, we went through that work of defining those personas because there are many. And that was the origin of my departure.

I had one persona, ops, DBA, the person that maintained this thing. And I wanted to talk to all the other people that built the applications based on Couchbase. So we broadly segment things into backend, full stack,, because CacheBase is also a mobile database. Well, we haven't talked too much about this, so I can explain to you quickly what CacheBase is. It's basically a distributed JSON database with an integrated caching layer, so it's reasonably

fast, so it does cache, and when the key value is JSON, then you can create with SQL, you can do full-text search, you can do analytics, you can run user-defined function. You get triggers. You get all that actual SQL going on. It's transactional.

You get joints, ANSI joints. You get all those windowing function. It's modern SQL on the JSON database. So it's a general-purpose database. And it's a general-purpose database that syncs. I think that's the important part of Couchbase. We are very good at syncing clusters of databases together. So great for multi-cloud, Hebrew cloud, on-prem,

whatever suits you. And we also sync on the device. There's a thing called Couchbase Mobile, which is a local database that runs in your phone and that will sync automatically to the server. So general purpose database that syncs sync and that's quite modern we try to to fit as much way of querying data as possible in the you know database it's kind of a several in one database we call that a data platform it took me a while to warm up to the world platform because

i used to work for an enterprise content management platform and then i've been working for a platform as a service and then a data platform so it took me a bit of time to warm up to that term but it explained fairly well the fact that it's a several in one product and we empower people to do the trade-off that they want not everybody needs SQL. Some people just need key value. Some people need search. Some people need to do SQL and search in the same query, which we also allow people to

do. So it's about choices. It's about empowering people. And that's why the word platform, which can feel intimidating because it can seem complex, you know, for a lot of choices and choices is maybe the enemy of a good developer experience. And we can try to talk, we can talk for hours about this. The more choices you offer, the more complicated it becomes. What's the sweet spot? Our own trade-off was to have good documentation

and good in-app help to you know fix that complexity problem that's the trade-off that we did we should probably divert here just to make sure that we cover the basic groundwork for those who might not be aware what exactly is couchbase i know that it's a database which honestly anything is a database if you hold it in correctly enough. That's my entire shtick. But what is it exactly? Where does it start? Where does it stop? Oh, where does it start?

That's an interesting question. It's a merge, some people would say a fork, of Apache CouchDB and Membase. Membase was a distributed key value store, and CouchDB was this weird Erlang and C, JSON REST API database that was built by Damien Katz from Lotus Notes. And that was in 2006 or 2007. That was

before Node.js. Let's not care about the exact date. The point is JSON and REST API enabled database before Node.js was like a strong power move. And so those two merged and created the first version of CacheBase. And then we've added all those things that people want to do. So SQL, full text search, analytics, user defined function, mobile sync, you know, all those things.

So basically a general purpose database. For what things is it not a great fit? This is always my favorite question to ask our database folks, because the zealot is going to say, it's good for every use case under the sun, use it for everything, start to finish. And very few databases can actually check that box. It's a very interesting question

because when I pitch, like we do all the things because we're a platform, people say, well, you must be doing lots of trade-offs. Where is that trade-off? The trade-off is basically the way you store something is going to determine the efficiency of the way you query it.

And that's one of the first things you learn in computer science. You learn about data structure, and you know that it's easier to get something in a hash map when you have the key than parsing a whole list of elements and checking if the ID is the right one. It's the same for databases. So our different services are different ways to store the data and to query it. So where is it not good? It's where we don't have an index or a service that answers to the way you want to query data. We don't have a graph service right now. You can still do recursive commentable expression

for the SQL nerds out there that allow you to do somewhat of a graph way of querying your data, but that's not a great experience. People are expecting a graph like a Neo4j or whatever other graph database experience. so that's the trade-off that we made we have a lot of things at the same place and it can be a little hard intimidating to operate and the developer experience can be a little oh my god what is this thing that can do

all of all of those features at the same time that's just like one sdk to learn for all of the features we just talked about so that's what we did that's the trade-off that we did it sucks to operate well there's a thing called kata base capella which is a lot like a vendorish thing to say but that's the value props of our managed cloud it's hard to operate we'll operate this for you we have a kubernetes operator if you are one of the few people that wants to do Kubernetes at home, that's also something you can do. So yeah, I guess what we cannot do is the thing that Route 53 and Unbound and PowerDNS do, which is this weird DNS database thing that you like so much.

One thing that I guess is a sign of the times, but I have to confess that I'm relatively skeptical around when I pull up couchbase.com as one does, you're publicly traded. I don't feel that your company has much of a choice in this, but the first thing it greets me with is couchbase Capella, which yes, that that is your hosted flagship product.

That should be the first thing I see on the website. Then it says announcing Capella IQ, AI powered coding assistance for developers, which, oh, great. Not another one of these. So, all right, give me the pitch. What is the story around? Ooh, everything that has been a problem before AI is going to make it way better because I've already talked to you about developer experience. I know where you stand on these things. I have a suspicion you would not be here to endorse something you don't believe in. How does the AI magic work in this context? So that's the thing.

Who's going to be the one that gets that product out before the author? And so we're announcing it on the website. It's available on the private preview only right now. I've tried it. It works. How it works, the way most chatbot AI code generation work is there's a big model, a large language model, that people use and that people fine-tune into in order to specialize it into the task that they want to do.

The way we've built CouchspaceIQ is we picked a very famous large language model. And when you ask a question to a bot, there's a context, there's the size of the window, basically, that allows you to fit as much contextual information as possible. The way it works and the reason why it's integrated into CacheBaseCapella is we make sure that we reload that context as much as possible

and fine-tune that model, that foundation model, as much as possible to do whatever you want to do with CacheBase, which usually falls into several, a couple categories really, well maybe three. You want to write SQL, you want to generate data, actually that's four, you want to generate data, you want to generate code, and if you paste some SQL code or some application code, you want to ask that model, what does it do? It's especially true for SQL queries. One of the questions that many people ask and are scared of with chatbots is, how does it work in terms of learning?

If you give a chatbot to someone that's very new to something and they're just going to basically use a chatbot like Stack Overflow and not really think about what they're doing, well, it's not great, right? But because that's the example that people think most developers will do is generate code. Writing code is like a small part of our job, like a substantial part of our job is understanding what the code does.

We spend a lot more time reading code than writing it if we're not completely foolish. Absolutely. And sometimes reading big SQL query can be a bit daunting, especially if you're new to that. And one of the good things that you can do... Even if you're not, it can still be quite daunting, let me assure you.

I think it's in a quiet taste, let's be honest. Some people like to write assembly code, and some people like to write SQL. I'm sort of in the middle right now. You pass your SQL query and it's going to tell you more or less what it does. And that's a very nice superpower of AI. I think that's the one that interests me the most right now

is using AI to understand and to work better with existing pieces of code. Because a lot of people think that the cost of software is writing the software. It's maintaining the code base you've written. That's the cost of the software. That's our job as developers should be to write legacy code because it means you've provided value long enough. And so if you're in a company that works pretty well

and there's a lot of legacy code, there's a lot of new people coming in and they'll have to learn all those things. And let's be honest, sometimes we don't document stuff as much as we should. The code is self-documenting is one of the biggest lies I hear in tech. Yes, of course,

which is why people are asking retired people to go back to do COBOL again because nobody can read it and it's not documented. Actually, if someone is looking for a company to build, I guess explaining COBOL code with AI would be probably a good thing to do in many places. Yeah, it feels like that's one of those things that would be of benefit to the larger world.

The counterpoint, too, is that if you've got that many business processes wrapped around something running COBOL, and I assure you, if you don't, you would have migrated off of COBOL long before now. It's making sure that, okay, well, computers in the form of AI are very, very good at being confident-sounding when they talk about things, but they can also do that when they're completely wrong. It's basically a BS generator. And that is a scary thing when you're taking a look at something that broad. I mean, I'll use the AI coding assistance for things all the time, but those things look a lot more like, okay, I haven't written CloudFormation from scratch in a while. Build out the template just because I forget the exact sequence. And it's mostly right on things like that. But then you start getting into some of the real nuanced areas like race conditions and the rest, and often it can make things worse instead of better.

That's the scary part for me, at least. Most coding assistants are, and actually each time you ask its opinion to an AI, they say, well, you should take this with a grain of salt. And we are not 100% sure that this is the case. And it says, make sure you proofread that, which again, from a learning perspective, can be a bit hard to give to new students. Like you're giving something to someone that assumes is probably as right as Wikipedia,

but actually it's not. And it's part of why it works so well. Like the anthropomorphism that you get with a chatbot like this, if it's so human, that's why it gets people so excited about it. Because if you think about it, it's not that new. It's just the moment it took off was the moment it looked like an assertive human being.

As you take a look through, I guess, the larger ecosystem now, as well as the database space, given that that is where you specialize, what do you think people are getting right and what do you think people are getting wrong? There's a couple of ways of seeing this. Right now, when I look at from the outside,

every database has gone back to sql i think there's a good reason for that and and it's interesting to put in perspective with ai because when you generate something there's probably less chance to generate something wrong with sql than generating something with code directly and i think five generation was it four or five generation of language? There's some language generation. So basically the first generation is assembly and zero and one, and then you get more four languages. And then at some point you get SQL.

And SQL is a way to very shortly express a whole lot of business logic. And I think what people are doing right now is going back to SQL. And it's been impressive to me how even new developers that were all about ORMs and ODMs and avoiding writing SQL as much as possible

are actually back to it. And that's for an old guy like me. I mean, not that old. It feels good. I think SQL is coming back with a vengeance, and that makes me very happy. I think what people don't realize is that it also involves doing data modeling, right? It's not because

databases like CacheBase that are schema-less exist. You should store your data without thinking about it. You should still do data modeling. It's important. So I think that's the interesting bit. What are people doing wrong in that space? I don't want to say a bad thing

about all the databases, so I cannot even process that far. That's okay. I'm thrilled to say negative things about any database under the sun. They all haunt me. I mean, someone once described SQL to me as the chess of the programming world,

and I feel like that's very accurate. I have found that it is far easier in working with databases to make mistakes that don't wash off after a new deployment than it is in most other realms of technology. And when you're lucky and have a particular aura, you tend to avoid that stuff. At least that was always my approach. I think if I had something to say, it's just like the XKCD about standards. There's 14 standards.

I'm going to do one that's going to unify them all. And it's the same with database. There's a lot, a lot of databases. Have you ever been

on a website called dpdb.io? Which one is it? I'm sorry? dpdb.io is the database of databases. And it's a very interesting website for database nerds.

And so if you go into database dbdb.io, and you will find catchphrases, and you will find a whole bunch of other databases, and you'll get to know which database is derived from which other database. You get the history, you get all those things. It's actually pretty interesting. I'm familiar with DB engines,

which is sort of like the ranking databases by popularity, and companies will bend over backwards to wind up hitting all of the various things that they want in that space. The counterpoint with all of it is that it feels historically like there haven't exactly been an awful lot of, shall we say, huge innovations in databases for the past few years. I mean, sure, we hear about

vectors all the time now because of the joy that's AI, but smarter people than I are talking about how, well, that's more of a feature than it is a core database. And the continual battle that we all hear about constantly is, and deal with ourselves, should we use a general purpose database or a task-specific database for this thing that I'm doing remains largely unsolved. Yeah, what's new? And when you look at it,

it's like we are going back to our roots and bringing SQL again. So is there anything new? I guess most of the new stuff, all the interesting stuff in 2010, well, basically with the cloud, we're all about the distribution side of things and we're all about distributed consensus.

So Keeper, etcd, all that stuff. Couchbase is using a raft-like algorithm to keep every node happy and under the same cluster. I think that's one of the most interesting things we've had for the past, well, not for the past 10 years, but between basically 20, between the start of AWS

and, well, let's say seven years ago. I think the end of the distribution game was brought to us by the people that have Atomic Clock in every data center because that's what you use to synchronize things. So that was interesting things. And then suddenly there wasn't that much innovation in the in the distributed world maybe because a fear disappears from twitter that might be one

of the reason it's not here to scare people enough to be better at that i fear was the person behind the test called the jepson test shoot i think his blog engine was called uh call me maybe and he was going through every distributed system and trying to break them. That was super interesting. It feels like we're not talking that much about this anymore. It really feels like databases have gone back to the status

of infrastructure. In 2010, it was not about infrastructure. It was about developer empowerment. It was about storing JSON and developer experience and making sure that you can code faster without some constraint in a distributed world. And we fixed this for the most part.

And the way we fixed this, and as you said, the lack of innovation maybe, has brought databases back to an infrastructure layer. Again, it wasn't the case 15 years ago, or 2023, 13 years ago. And that's interesting. When you look at the new generation of databases, sometimes it's just a gateway on top of a well-known database.

And they call that a database, but it provides higher-level services. It provides higher-level bricks, better developer experience to developers to build stuff faster. We've been trying to do this with Cache-based app service and our SYNG gateway, which is basically a gateway

onto the Cache-based cluster that allows you to manage authentication, authorization, that allows you to manage synchronization with a mobile device or with a website. And yeah, I think that's the most interesting thing to me in this industry is how it's been relegated back to infrastructure and how all the cool stuff, new stuff happens on the layer above that.

I really want to thank you for taking the time to speak with me. If people want to learn more, where's the best place for them to find you? Thanks for having me and to speak with me. If people want to learn more, where's the best place for them to find you? Thanks for having me and for entertaining this conversation. I can be found anywhere on the internet with these six letters, L-D-O-G-U-I-N. That's actually seven letters. L-D-O-G-U-I-N, that's my handle

on pretty much any social network. L-D-O-G-U-I-N. So X, Blue Sky, LinkedIn. I don't know where to be anymore. I hear you. We'll put links to all of it in the show notes and let people figure out where they want to go on that. Thank you so much for taking the time to speak with me today. I really do appreciate it. Thanks for having me. Laurent Doulon, Director of Developer Relations and Strategy at Couchbase. I'm cloud economist Corey Quinn, and this episode has been brought to us by our friends at Couchbase. If you enjoyed this episode, 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 comment that you're not going to be able to submit properly because that platform of choice did not pay enough attention to the experience of typing in a comment. 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 Duck Bill Group works for you, not AWS. We tailor recommendations to your business, and we get to the point. Visit duckbillgroup.com to get started.