Subscribe
Share
Share
Embed
Screaming in the Cloud with Corey Quinn features conversations with domain experts in the world of Cloud Computing. Topics discussed include AWS, GCP, Azure, Oracle Cloud, and the "why" behind how businesses are coming to think about the Cloud.
Announcer: 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.
Corey: 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 application networking. They brought you Gloo Gateway, the lightweight and ultra-fast gateway built for modern API management, and Gloo 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’s got your back with networking for applications, not infrastructure. Embrace zero trust security, GitOps automation, and seamless multi-cloud networking, all with Solo.io.
And 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 Gloo by Solo.io.
DevOps and Platform Engineers, your journey to a seamless cloud-native experience starts here. Visit solo.io/screaminginthecloud today and level up your networking game.
Corey: 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 Doguin is the Director of Developer Relations and Strategy at Couchbase. First, Laurent, thank you for joining me.
Laurent: Thanks for having me. It’s a pleasure to be here.
Corey: 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 return 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?
Laurent: So, I’ve joined Couchbase in 2014. Spent about two or three years as a DA. And during those three years as a developer advocate, I’ve been advocating 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 you 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 to 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 be better app, how they use key-value, and those weird thing 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 people identify with, really. And so, didn’t happen. Left. Built a Platform as a Service company called Clever Cloud. They started about four or five years before I joined. We went from seven people to thirty-one LFs, fully bootstrapped, no VC. That’s an interesting way to build a company in this age.
Corey: 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.
Laurent: 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 Devoxx, 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, rehandling the way we do marketing at Couchbase. Why not have a conversation with our new CMO, John Kreisa?”
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 going to 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 [unintelligible 00:03:51], he actually changed, like, there was a—they were purposely going [against 00:03:55] developer, talking to developer. And that was not the case, necessarily, five, six years before that.
So, that’s why I came back. The product is still amazing, the people are still amazing. It was interesting to find a lot of people that still work there after, what, five years. And it’s a company based in… California, headquartered in California, so you would expect people to, you know, jump around a bit. And I was pleasantly surprised to find the same folks there. So, that was also one of the reasons why I came back.
Corey: 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, “Aw, 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.
Laurent: That’s the one we use internally, and there’s a couple. More than a couple.
Corey: 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 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.
Laurent: And also, I [unintelligible 00:05:34] to people that build these products because if we build the products, the user might be in the same position that we are right now. And so, we might be responsible for that experience [unintelligible 00:05:43] a developer, and that’s not a great feeling. So, I completely agree with you. I’ve tried to… always on software-focused companies, whether it was Nuxeo, Couchbase, Clever Cloud, and then Couchbase. And I guess one of the good thing about coming back to a developer-focused era is all the product alignments.
Like, a lot of people talk about product that [grows 00:06:08] and what it means. To me what it means was, what it meant—what 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 about it in front of the product. It goes through different things. We’ve recently revamped our Couchbase UI, Couchbase Capella UI—Couchbase Capella is a 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?”
Corey: That’s an interesting decision to make, just because historically, working with a bunch of tools, the folks who are building the documentation working with that tool, tend to generally be experts at it, so they tend to optimize for improving things for the experience of someone has 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, the worse the new user experience becomes because companies tend to grow and sprawl in different ways, the product 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.
On the other side of it, though, how are the folks who’ve been using it for a while respond 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?
Laurent: Yeah, it’s interesting. One of the first things that struck me when I joined Couchbase the first time was the size of the technical documentation team. Because the whole… well, not the whole point, but part of 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 [unintelligible 00:08:18] what the documentation or the product pitch or everything. Like, they really, really, really emphasize on this from the very beginning. So, that was interesting.
So, when you get that culture built into the products, well, the good thing is… when people try Couchbase, they usually stick with Couchbase. My main issue as a Director of the Developer Relations is not to make people stick with Couchbase 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 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 built because that’s even a bit further down the line, but you know, 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, well, that’s a good feeling.
Corey: 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 ass—even just assuming a binary of, “Okay, I’ve done this before a thousand times; this is the thousand and 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.
Laurent: 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 person, ops slash DBA slash the person that maintain this thing, and I wanted to talk to all the other people that built the application space in Couchbase. So, we broadly segment things into back-end, full-stack, and mobile because Couchbase is also a mobile database. Well, we haven’t talked too much about this, so I can explain you quickly what Couchbase 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 joins, ANSI joins, 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 cluster of databases together. So, great for multi-cloud, hybrid 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 it will sync automatically to the server. So, a general-purpose database that syncs and that’s quite modern.
We try to fit as much way of growing data as possible in our 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 word 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-offs 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 want 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 00:12:34] a lot of choices. And choices is maybe the enemy of a good developer experience.
And, you know, we can try to talk—we can talk for hours about this. The more services you offer, the more complicated it becomes. What’s the sweet spots? We did—our own trade-off was to have good documentation and good in-app help to fix that complexity problem. That’s the trade-off that we did.
Corey: Well, 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 incorrectly enough; that’s my entire shtick. But what is it exactly? Where does it start? Where does it stop?
Laurent: Oh, where does it start? That’s an interesting question. It’s a… 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 Damian Katz from Lotus Notes, and that was in 2006 or seven. That was before Node.js.
Let’s not care about the exact date. The point is, a JSON and REST API-enabled database before Node.js was, like, a strong [laugh] power move. And so, those two merged and created the first version of Couchbase. 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.
Corey: For what things is it not a great fit? This is always my favorite question to ask 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”—
Laurent: Yes.
Corey: —and very few databases can actually check that box.
Laurent: It’s a very interesting question because when I pitch like, “We do all the things,” because we are a platform, people say, “Well, you must be doing lots of trade-offs. Where is the trade-off?” The trade-off is basically the way you store something is going to determine the efficiency of your [growing 00:14:45]—or the way you [grow 00:14:47] it. And that’s one of the first thing you learn in computer science. You learn about data structure and you know that it’s easier to get something in a hashmap when you have the key than passing your whole list of elements and checking your data, is it 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 answer to the way you want to query data. We don’t have a graph service right now. You can still do recursive common table expression for the SQL nerds out there, that will allow you to do somewhat of a graph way of querying your data, but that’s not, like, actual—that’s not a great experience for people were expecting a graph, like a Neo4j or whatever was a 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 those features?” At the same time, that’s just, like, one SDK to learn for all of the features we’ve just talked about. So, that’s what we did. That’s a trade-off that we did.
It sucks to operate—well, [unintelligible 00:16:05] Couchbase Capella, which is a lot like a vendor-ish 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 00:16:26] and [unintelligible 00:16:27] DNS do, which is this weird DNS database thing that you like so much.
Corey: One thing that’s, 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 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?
Laurent: So, that’s the thing, like, who’s going to be the one that get their products out before the other? 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 does it works? The way most chatbot AI code generation work is there’s a big model, large language model that people use and that people fine-tune into in order to specialize it to the tasks that they want to do. The way we’ve built Couchbase iQ is we picked a very famous large language model, and when you ask a question to a bot, there’s a context, there’s a… 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 Couchbase Capella is we make sure that we preload that context as much as possible and fine-tune that model, that [foundation 00:18:19] model, as much as possible to do whatever you want to do with Couchbase, which usually falls into several—a couple of 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 do? It’s especially true for SQL queries.
And one of the questions that many people ask and are scared of with chatbot 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 00:19:03] right, but because that’s the example that people think most developer 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.
Corey: We spend a lot more time reading code than writing it, if we’re, you know—
Laurent: Yes.
Corey: Not completely foolish.
Laurent: 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 get—
Corey: Oh, even if you’re not, it can still be quite daunting, let me assure you.
Laurent: [laugh]. I think it’s an acquired 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 [unintelligible 00:19:48] 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 codebase 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 in a company that works pretty well and there’s a lot of legacy code and there’s a lot of new people coming in and they’ll have to learn all those things, and to be honest, sometimes we don’t document stuff as much as we should—
Corey: “The code is self-documenting,” is one of the biggest lies I hear in tech.
Laurent: Yes, of course, which is why people are asking retired people to go back to COBOL again because nobody can read it and it’s not documented. Actually, if someone’s looking for a company to build, I guess, explaining COBOL code with AI would be a pretty good fit to do in many places.
Corey: Yeah, it feels like that’s one of those things that would be of benefit to the larger world. The counterpoint to that is you 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, when they’re 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.
Laurent: 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 a hundred percent sure that this is the case.” And this is, 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 and might—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 chatbots, like, this, it feels so human. That’s why it get 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.
Corey: As you take a look through, I guess, the larger ecosystem now, as well as the database space, given that is where you specialize, what do you think people are getting right and what do you think people are getting wrong?
Laurent: There’s a couple of ways of seeing this. Right now, when I look at from the outside, every databases is going back to SQL, I think there’s a good reason for that. And it’s interesting to put into 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 language—there some language generation, so basically, the first innovation is assembly [into 00:23:03] in one and then you get more evolved languages, and 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 00:23:25] and [no-DMs 00:23:26], and you know, avoiding writing SQL as much as possible, are actually back to it. And that’s, for an old guy like me—well 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, and stuff because database like Couchbase that are schemaless 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 bits. What are people doing wrong in that space? I’m… I don’t want to say bad thing about other databases, so I cannot even process that thought right now.
Corey: That’s okay. I’m thrilled to say negative things about any database under the sun. They all haunt me. I mean, someone wants to describe SQL to me is 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.
Laurent: I think if I had something to say, so just like the XKCD about standards: like, “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 [laugh] lot of databases. Have you ever been on a website called dbdb.io?
Corey: Which one is it? I’m sorry.
Laurent: Dbdb.io is the database of databases, and it’s very [laugh] interesting website for database nerds. And so, if you’re into database, dbdb.io. And you will find Couchbase 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.
Corey: 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’s… 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—of should we use a general-purpose database, or a task-specific database for this thing that I’m doing remains largely unsolved.
Laurent: 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 the 2010s—well, basically with the cloud—were all about the distribution side of things and were all about distributed consensus, Zookeeper, etcd, all that stuff. Couchbase is using an 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 ten years, but between, basically, 20 or… 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 distributed world, maybe because Aphyr disappeared from Twitter. That might be one of the reason. He’s not here to scare people enough to be better at that.
Aphyr was the person behind the test called the Jepsen Test [shoot 00:27:12]. I think his blog engine was called Call Me Maybe, and he was going through every distributed system and trying to break them. And that was super interesting. And it feels like we’re not talking that much about this anymore. It really feels like database have gone back to the status of infrastructure.
In 2010, it was not about infrastructure. It was about developer empowerment. It was about serving JSON and developer experience and making sure that you can code faster without some constraint in a distributed world. And like, we fixed this for the most part. And the way we fixed this—and as you said, lack of innovation, maybe—has brought databases back to an infrastructure layer.
Again, it wasn’t the case 15 years a—well, 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, provides higher-level bricks, better developer experience to developer to build stuff faster. We’ve been trying to do this with Couchbase App Service and our sync gateway, which is basically a gateway on top of a Couchbase cluster that allow you to manage authentication, authorization, that allows you to manage synchronization with your mobile device or with websites. 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 all the cool stuff, new stuff happens on the layer above that.
Corey: 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?
Laurent: 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 7 letters. Ldoguin. That’s my handle on pretty much any social network. Ldoguin. So X, [BlueSky 00:29:21], LinkedIn. I don’t know where to be anymore.
Corey: I hear you. We’ll put links to all of it in the [show notes 00:29:27] 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.
Laurent: Thanks for having me.
Corey: Laurent Doguin, 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.
Corey: If your AWS bill keeps rising and your blood pressure is doing the same, then you need The Duckbill 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.