Screaming in the Cloud - How Dynobase Makes DynamoDB Easier with Rafal Wilinksi

Episode Date: May 31, 2022

About RafalRafal is Serverless Engineer at Stedi by day, and Dynobase founder by night - a modern DynamoDB UI client. When he is not coding or answering support tickets, he loves climbing and tasting whiskey (not simultaneously).Links Referenced:Company Website: https://dynobase.dev

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 sponsored by our friends at Revelo. Revelo is the Spanish word of the day, and it's spelled R-E-V-E-L-O.

It means I reveal. Now, have you tried to hire an engineer lately? I assure you it is significantly harder than it sounds. One of the things that Ravello has recognized is something I've been talking about for a while, specifically that while talent is evenly distributed, opportunity is absolutely not. They're exposing a new talent pool to basically those of us without a presence in Latin America via their platform. It's the largest tech talent marketplace in Latin America with over a million engineers in their network, which includes but isn't limited to talent in Mexico, Costa Rica, Brazil, and

Argentina. Now, not only do they wind up spreading all of their talent on English ability as well as, you know, their engineering skills, but they go significantly beyond that. Some of the folks on their platform are hands down the most talented engineers that I've ever spoken to. Let's also not forget that Latin America has high time zone overlap with what we have here in the United States. So you can hire full-time remote engineers who share most of the workday as your team. It's an end-to-end talent service. So you can find and hire engineers in Central and South America

without having to worry about, frankly, the colossal pain of cross-border payroll and benefits and compliance because Revelo handles all of it. If you're hiring engineers, check out revelo.io slash screaming to get 20% off your first three months. That's R-E-V-E-L-O dot I-O slash screaming. The company 0x4447 builds products to increase standardization and security in AWS organizations,

and they do this with automated pipelines that use well-structured projects to create secure, easy to maintain, and fail-tolerant solutions. One of those is their VPN product, built on top of the popular OpenVPN project, which has no license restrictions. You're only limited by the network card in the instance. To learn more, visit snark.cloud slash deploy and go.

That's snark.cloud slash deploy and go, all one word. Welcome to Screaming in the Cloud. I'm Corey Quinn. It's not too often that I wind up building an episode here out of a desktop application. I've done it once or twice, and I'm sure that the folks at Microsoft Excel are continually hoping for an invite to talk about things. But we're going in a bit of a different direction today. Rafal Vilinski is a serverless engineer at Steady, and in apparently what is a job requirement at Steady, he also has a side project that manifests itself as a desktop app.

Rafal, thank you for joining me today. I appreciate it. Yeah. Hi, everyone. Thanks for having me, Corey. I first heard about you when you launched DinoBase, which is awesome. It sounds evocative of dinosaurs, unless you read it, then it's D-Y-N-O. And it's, ah, this sounds a lot like DynamoDB, let me see what it is, and sure enough, it was. As much as I love misusing things as databases, DynamoDB is actually a database that is decent and good at what it does, and please correct me if I get any of this wrong, but Dynobase is effectively an electron app that you install,

at least on a Mac in my case, I don't generally use other desktops, so that's other people's but Dynobase is effectively an Electron app that you install, at least on a Mac in my case. I don't generally use other desktops, so that's other people's problems. And it provides a user-friendly interface to DynamoDB that is not actively hostile to the customer. Yeah, exactly. That was the goal. That's how I envisioned it, and I hope I executed it correctly. It was almost prescient in some ways because they recently redid the DynamoDB console in AWS to actively make it worse, to wind up working with individual

items, to modify things. It feels like they are validating your market for you by, oh, we really like Dynabase. How do we drive more traffic to it? We're going to make this thing worse. But back then when you first created this, the console was in its previous version. What was it that inspired you to say, you know what, I'm going to build a desktop application for a cloud service? Because on the surface, it seems relatively close to psychotic, but it's brilliant. Yeah, sure. So a few years ago, I was freelancing on AWS. I was jumping between clients and my side projects. That also involved jumping between regions. And AWS doesn't have a good out-of-the-box solution

for switching your accounts and switching your regions. So when you wanted to work on your client table in Australia and simultaneously on my side project in Europe, there was no other solution than to have two browser windows open or two even browsers open. So, and it was super frustrating. So I was like, hey, DynamoDB has SDK. Electron is this thing that allows you to make a desktop application using HTML and JS and some CSS. So maybe I can do something with it. And I was so naive to think that it's going to be a trivial task because it's going to be, come on, it's like a couple of SDK calls

displaying some lists and tables, and that's pretty much it, right? Right. I use Retool as my system to build my newsletter every week. And that is the front end I use to interact with DynamoDB. And it's great. It has a table component that just, I run a query that, believe it or not, is a query, not a scan. I know. Imagine that. I did something slightly right this one time. And it populates things for the current issue into it. And then I basically built a CRUD API around it and have components that let me update, delete, remove the usual stuff. And it's great. It works for my purposes and it's fine. And that's what I use most of the time

until I hit an edge case or a corner case because it turns out, surprise everyone, I'm bad at programming. And I need to go in and tweak the table myself manually. And that's where DinoBase, at least for my use case, really comes into its own. Good to hear. Good to hear, yeah.

That was exactly the same case why I built it. Because, yeah, I was also, a few years ago, I started working on some project, which was really crazy. It was before AppSync times. We wanted to have GraphQL serverless API using single table design and testing principles where and there. So we've been verifying many things

by just looking at the contents of the table and sometimes fixing them manually. So that was also the thing that motivated me to make the editing experience a little bit better. One thing I appreciate about the application is that it does things right. I mean, there's no real other way to frame that. When I fire up the application myself and I go to the account that I've been using it with, because in this case, there's really only one account that I have that contains the data that I spend my time working with. And I get access to it when on my machine via Granted, which because it's a federated SSO login. And it says, ah, this is an SSO account. Click here to open the browser tab and do the

thing. I didn't have to configure Dynabase. It is automatically reading my AWS config file in my user directory. It does a lot of things right. There's no duplication of work from my perspective. It doesn't freak out because it doesn't know how SSO works. It doesn't have run into these obnoxious edge case problems that so many early generation desktop interfaces for AWS things seem to. Wow, it seems like it works for you even better than for me. Again, how I get into accounts has always been a little weird. I've ranted before about Granted, which is something that CommonFate puts out. It is a binary utility that winds up logging into different federated SSO accounts,

opens them in Firefox containers. So you could have, you know, two accounts open side by side. It's some nice affordances like that. And, but it still uses the standard AWS profile syntax, which Dynobase does as well. There are a bunch of different ways I've logged into things and I've never experienced friction when I'm using Dynobase for this. To be clear, you haven't paid me a dime. In fact, just the opposite. I wind up paying my monthly Dynabase subscription with a smile on my

face. It is worth every penny just because on those rare moments when I have to work with something odd in DynamoDB, it's great having the tool. I want to be very clear here. I don't recall what the current cost on this is, but I know for a fact it is more than I spend every month on DynamoDB itself, which is fine. You pay for utility, not for the actual raw cost of the underlying resources on it. Some people tend to have issues with that, and I think it's the wrong direction to go in. Yeah, exactly. So my logic was that it's a productivity improvement and a lot of programmers are simply obsessed with productivity, right? We tend to write those obnoxious, nasty bash and Python scripts to automate boring tasks in our day jobs. So if you can eliminate this chore of logging to different AWS accounts and trying to find them,

and even if it takes like five or 10 seconds, if I can shave that five or 10 seconds every time you try to do something, that over time accumulates into a big number and it's a huge time investment. So even if you save like, I don't know, maybe one hour a month or one hour a quarter, I think it's still a fair price. Your pricing is very interesting. And

the reason I say that is you do not have a free tier as such. You have a free seven-day trial, which is great. That is the way to do it. You can sign up with no credit card, grab the thing, and it's awesome. dinobase.dev, for folks who are wondering. And you have a solo yearly plan, which is what I'm on, which is $9 a month, which means that you wind up, I think, charging me $108 a year billed annually. You have a solo lifetime option for $200, and I'm going to fight with you about that one in a second. We're going to come back to it. Then you have a team plan that is for, I think for 10 licenses,

it's 79 bucks a month. And for 20 licenses, it's 150 bucks a month. Great. And then you have an enterprise option for 250 a month, the end billed annually. And I have problems with that too. So I like arguing with pricing. I like about pricing with people just because I find that that is one of those underappreciated aspects of things. Let's start with my own decisions on this, if I may. The reason that I go for this solo yearly plan instead of the lifetime subscription of I buy this and I get to use it forever in perpetuity is I like the tool, but like the AWS service that underlies it, it's going to have to evolve in the fullness of time.

It is going to have to continue to support new DynamoDB functionality. Like the fact that they have infrequent access storage classes now for tables, as an example. I'm sure they're coming up with other things as well. Like, I don't know, maybe a sane query syntax someday. That might be nice if they ever built one of those. Some people don't like the idea of a subscription software.

I do just because I like the fact that it is a continual source of revenue. It's not the, well, five years ago, you paid me that one-off thing, and now you expect feature enhancements for the rest of time. How do you think about that? So there are a couple of things here. First thing is that the lifetime support, it doesn't mean that I will be always implementing to my death all the features that are going to appear in DynamoDB.

Maybe there's going to be some feature and I'm not going to implement it. For instance, it's not possible to create global tables via Dynabase right now, and it won't be possible because we think that the majority of people dealing with cloud are using infrastructure as a code, and creating tables via Dynabase is not a super useful feature. And we also believe that it's not going to break, even without support. I know it sounds bad. It sounds like I'm not going to support it at some point, but don't worry, there are no plans to discontinue support.

We all get hit by buses from time to time, let's be clear. And I want to also point out as well that this is a graphical tool that is a front end for an underlying AWS service. It is extremely convenient. There is tremendous value in it, but it is not critical path. As if suddenly I cannot use Dynabase, my production app is down. It doesn't work that way

in the sense of a SaaS product. It is a desktop application and huge fan of it as well. So please continue. I just want to make sure that I'm not misleading people into thinking it's something it's not here. Well, that sounds dangerous if that's critical. Yeah, it's not designed to be, I imagine at least. If so, it seems like a very strange use case. Yeah. Also, you have to keep in mind that AWS isn't basically introducing breaking changes, especially in a service that is so popular as DynamoDB.

I cannot imagine them announcing, like, hey, in a month, we are going to deprecate this API, so you'd better start using this new API because this one is going to be removed. I think that's not going to happen because of the millions of clients using DynamoDB actively. So I think that makes Dynabase safe. It's built on a rock-solid foundation that is going to change only additively.

No features are going to be just being removed. I think that there's a direction in a number of at least consumer offerings where people are upset at the idea of software subscriptions. The idea of why should I pay in perpetuity for a thing? And I want to call out my own bias here. For something like this, where you're charging $9 a month, I do not care about the price. Truly, I don't. I am a price inflexible customer. It could go probably as high as $50 a month, and I would neither notice nor care. That is probably not the common case customer, and it's certainly not over in consumer land.

I understand that I am significantly in a privileged position when it comes to being able to acquire the tools that I need. It turns out that compared to the AWS bill I have to deal with, I don't have to worry about the small stuff comparatively. Not everyone is in that position. So I am very sympathetic to that, which is why I want to deviate here a little bit because somewhat recently, DinoBase showed up on the AWS marketplace. And I can go into the marketplace now and get a yearly subscription for a single seat for $129. It is slightly more than buying it directly through your website, but there are some advantages for many folks in getting it on the marketplace. AWS is an approved vendor, for example, so there's no procurement dance. It counts toward your committed spend on contracts if someone is trying to wind up hitting certain levels of spend on their EDP. It provides a

centralized place to manage things as far as those licenses go when people are purchasing it. What was it that made you decide to put this on the marketplace? So the decision was pretty straightforward. It's just yet another distribution channel for us. So imagine you're a software engineer that works for a really, really big company, and it's super hard to approve some kind of expense using traditional credit card. You basically cannot go to my site and check out with a company credit card because of the processes,

or maybe it takes two years. But maybe it's super easy to click just subscribe on your AWS account. So yeah, we thought that, hey, maybe it's going to unlock some engineers working at those big corporations. And maybe this is the way that they are going to start using Dynabase. Are you seeing significant adoption yet? Or is it more or less something that's still too early to say? And beyond that, are you finding that people are discovering the product via the AWS marketplace, or is it strictly just a means of purchasing it? So when it comes to discovering, I think we don't have any data about it yet,

which is supported by the fact that we also have zero subscriptions from the marketplace yet. But it's also our fault because we haven't actually actively promoted the fact apart from me sending just a tweet on a tweeter, which is in the value. Which did not include a link to it as well, which means that Google was our friend for this because let's face it, AWS marketplace search is bad. Maybe. I don't know. I was just, you know, super relieved to see. You don't need to agree with that statement. I'm stating it as a fact.

I am not a fan of the marketplace search. It irks me because for whatever reason, whenever I'm in there looking for something, it does not show me the thing that I'm looking for. It shows me the biggest partners first that AWS has, and it seems like the incentives are misaligned. I'm sure someone is going to come on the show to yell about me. I'm waiting for your call.

Do you find that if someone is going to come on this show to yell about me. I'm waiting for your call. Do you find that if someone is going to purchase it, do you have a preference that they go directly, that they go through the marketplace? Is there any direction for you that makes more sense than another? So ideally, we would like to continue all the customers to purchase the software using the classical way, using the subscriptions for our website, because it's just one flow, one system.

It's simpler, it's cleaner. But we wanted to give the adoption and to have more adoption. We'll see if that's going to work. I was going to say there were two issues I had with the pricing. That was one of them. The other is at the high end, the enterprise pricing being $250 a month for unlimited licenses. That doesn't feel like it is the right direction. And the reason I say that is a 50-person company would wind up being able to spend $250 a month to get this for

their entire team. And that's great. They're happy. So could AWS or Coca-Cola. And at that very high level, it becomes something that you are signing up for significant amount of support work in theory or a bunch of other directions. I've always found that from where I stand, especially dealing with those very large companies with very specific SLA requirements and the rest the pricing for enterprise that I always look for as the right answer from my mind is click here to contact us because procurement departments for example like we want this this this this and this around data guarantees and indemnities and all the rest and well yeah that's going to be expensive and well yeah we're a procurement company at a Fortune 50. We don't sign contracts that don't have two commas in them.

So it feels like there's a dialing it in with some custom optionality that feels like it is signaling to the quote unquote sophisticated buyer, as Patio 11 likes to say on Twitter from time to time, that might be the right direction. That's really good feedback. I haven't thought about it this way, but you really opened my eyes on this issue. really well understood, even by larger companies with significant staff and full marketing teams. I still see that pricing often feels like an afterthought. But personally, when I'm trying to figure out, is this tool for me? The first thing I do is I don't even read the marketing copy on the landing page. I look for the pricing tab and click. Because if the only price is call for details, I know A, it's going to be expensive. B, it's going to be a pain in the neck to get to use it because it's two in the morning.

I'm trying to get something done. I want to use it right now. If I had to have a conversation with your sales team first, that's not going to be cheap and it's not going to be something I'm going to be able to solve my problem this week. And that is the other end of it. I yell at people on both sides on that one.

Okay. Again, none of this stuff is intuitive. All of this stuff is complicated. The way that I tend to see the world is, granted, a little bit different than the way that most folks who are kicking around databases and whatnot tend to view the world. Do you have plans in the future to extend Dynabase

beyond strictly DynamoDB, looking to explore other fine database options like Redis or MongoDB or my personal favorite Route 53 text records? Yeah. So we had plans. Oh, we had really big plans. We felt that we are going to create a second JetBrains company. We started analyzing the market when it comes to MongoDB, when it comes to Cassandra, when it comes to Redis. And our first pick was Cassandra because it seemed like to have a really, really similar structure of the table. I mean, it's also NoSQL, it also has a primary index, secondary global indexes, and things like that. But as always, reality surprises us with the amount of detail that we

cannot see from the very top. And it isn't as simple as just uninstall AWS SDK and install Cassandra Connect or Cassandra SDK and just roll with that. It requires a really big and significant investment. And we decided to focus just on one thing and nail this one thing and do this properly. It's like if you go into the cloud, you can try to build a service that is agnostic. It's not using the best features of the cloud.

And you can move your containers, for instance, across the clouds and say, hey, I'm cloud agnostic. But at the same time, you're missing out all of the best features. And this is the same way we thought about Dynabase. Hey, we can provide an agnostic core, but then the agnostic application isn't going to be as good and as sophisticated as something tailored specifically for the needs of this database and user using this exact database. This episode is sponsored in parts by our friend EnterpriseDB. EnterpriseDB has been powering enterprise applications with PostgreSQL for 15 years,

and now EnterpriseDB has you covered wherever you deploy Postgresquil, on-premises, private cloud, and they just announced a fully managed service on AWS and Azure called Big Animal. All one word. Don't leave managing your database to your cloud vendor because they're too busy launching another half-dozen managed databases to focus on any one of them that they didn't build themselves. Instead, work with the experts over at EnterpriseDB. They can save you time and money. They can even help you migrate legacy applications, including Oracle, to the cloud.

To learn more, try Big Animal for free. Go to biganimal.com slash snark and tell them Corey sent you. Some of the things that you do just make so much sense that I get actively annoyed that there aren't better ways to do it in other places for other things. For example, when I fire up a table in a particular region within Dynabase, first it does a scan, which, okay, that's not terrible. But on some big tables, that can get really expensive. But you cap it automatically at 1,000 items. And okay, great. Then it tells me how long did it take. In this case, because I am using on-demand and the rest,

and it's a little bit of a pokey table, that scan took about a second and a half. Okay, you scanned 1,000 items. Well, there's a lot more than 1,000 items in this table. Ah, you limited it so you didn't wind up taking all that time. And it also says that it took 51 and a half RCUs or read credit units because, you know, why use normal numbers when you're AWS and doing pricing dimensions on this stuff? And to be clear, I forget the exact numbers for reads, but it's something like a million read RCUs cost me a dollar or something like that.

It is trivial. It does not matter. But because it is consumption-based pricing, I always live in a little bit of a concern that, okay, if I screw up and just scan the entire 10 megabyte table every time I want to make an operation here, and I make a lot of operations in the course of a week, that's going to start showing up on the bill in some really unfortunate ways. This sort of tells me on an ongoing basis of what it is that I'm going to wind up encountering. These things are all configurable too.

The initial stream limit that you have configured is 1,000. I can set that to any number I want if I think that's too many or too few. You have a bunch of pagination options around it. You also help people build out intelligent queries and even can export that to code. It's not just about the graphical interface, clickety and done,

because I do love my click ops, but there are limits to it. It helps formulate what kind of queries I want to build and then wind up implementing in code. And that is no small thing. Yeah, exactly. This is the way how we also envision that. The language syntax in DynamoDB is really hard. Awful. The term is awful. Yeah, especially for people. I know. People are going to be mad at me, but they're wrong.

It is not intuitive. It took a fair bit of wrapping my head around. And more than once, what I found myself doing is basically just writing a thin CRUD API and Lambda in front of it just so I can query it in a way that I think about it, as opposed to, not even talking changing the query modeling, I just want better syntax. That's all it is. Yeah, you also touched on the modeling.

That's also a very important thing, especially, or maybe even scan or query. Suppose I'm an engineer with 10 years of experience. I come to the DynamoDB, I jump straight into the action without reading any of the documentation. At least that's my way of working. And I have no idea what's the difference between a scan and query. So in Dynabase, when I'm going to enter all those filtering parameters into the UI, I'm going to hit scan.

Dynabase is automatically going to figure out for you what's the best way to query or to scan if query is not possible, and also give you the code that actually was behind that operation. So you can just like copy and paste that straight to your code or service or API and have exactly the same result. So yeah, we want to abstract away some of the weird things about DynamoDB, like, you know, scan versus query,

expression attribute names, expression attribute values, filtering conditions, all sorts of that stuff. Also the DynamoDB JSON, that's also like a bizarre thing, this JSON type thing, which you get out of the box. We also take care of that.

So yeah, yeah, that's also our mission to make the DynamoDB as approachable as possible because it's a great database, but to truly embrace it and to truly use it, it's hard. I want to be clear just for folks who are not seeing some of the benefits of it the way that I've described it thus far. Yes, on some level, it basically just provides an attractive, usable interface to wind up looking at items in a DynamoDB table.

You can also use it to wind up refining queries, to look at very specific things. You can export either a selection or an entire table either to a local file or to S3, which is convenient. But it goes beyond that because once you have the query dialed in, you're seeing the things you want to see. There's a generate code button that spits it out for Python, for JavaScript, for Golang. And there are a few things like the AWS CLI is coming soon, according to the dropdown itself.

Java, ooh, you do like pain. And Golang, for example, it effectively exports the thing you have done by clicking around as code, which is for some godforsaken reason, anathema to most AWS services. Oh, you clicked around to the console to do a thing. Good job.

Now throw it all away and figure out how to do it in code as opposed to here's how to do it. You just did programmatically. My God, the console could be the best IDE in the world, except that they don't do it for some reason. Yeah, yeah. And I love the fact that Dynabase does. Thank you.

I'm a big fan of this. You can also import data from a variety of formats, export data as well. And one of the more obnoxious, you're talking about weird problems I have with DynamoDB that I wish to fix. I would love to move this table to a table in a different AWS account.

Great. To do that, I effectively have to pause the service that is in front of this because I need to stop all writes. Great. Export the table. Take the table to the new account. Import the table.

Repoint the code to talk to that thing, and then get started again. Now, there are ways to do it without that, and they all suck because you have to either write a shim for it, or you have to wind up doing a stream that winds up feeding from one to the other. And in many cases, well, okay, I want to take the table here, I do a knife edge cutover so that new writes go to the new thing, and then I just want to backfill this old table data into it. How do I do that? The official answer is not what you would expect it to be,

the DynamoDB console of import this data. Instead, it's, oh, use AWS Glue to wind up writing an ETL function to do all of this. And it's, what? How is that the way to do these things? There are import and export buttons in Dynabase that solve this problem beautifully

without having to do all of that. It really is such a different approach to thinking about this. And I am stunned that this had to be done as a third party. It feels like you were using the native tooling and the native console the same way the rest of us do, grousing about it the same way the rest of us do, and then set out to fix it like none of us do. What was it that finally made you say, you know,

I think there's a better way and I'm going to prove it? What pushed you over the edge oh i think i was spending just hours in the console and i didn't have a really sophisticated suite of tests which forced me that time to look at the data a lot and import that a lot and edit it a lot and it was just too much i don't know know. At some point, I realized like, hey, there's gotta be a better way. I browsed for the solutions on the internet. I realized that there is nothing on the market. So I've asked a couple of my friends saying like, hey, do you also have this problem?

Is this also a problem for you? Do you see the same challenges? And basically every engineer I talked to said, yeah, I mean, this really sucks. You should do something about it. And that was the moment I realized that I'm really onto something and this is a pain that I'm not alone in.

So yeah, that gave me a lot of motivation. So that was a lot of frustration, but there was also a lot of motivation. So that was a lot of frustration, but there was also a lot of motivation to push me to create a first product in my life. It's your first product, but it does follow an interesting pattern that seems to be emerging. CloudDash, Tamash and Maciej wound up doing that as well.

They're also working at Steady, and they have their side project, which is an electron-based desktop application that winds up interfacing with AWS services. And it's, what are your job requirements over at Steady exactly? And people could be forgiven for seeing these things and not knowing what the hell EDI is, which, guilty, and figure, ah, it's just a very fancy term for a DevRel company because they're doing serverless DevRel as a company. It increasingly feels an awful lot like that. What's going on over there where that culture just seems to be an emergent property?

So I feel like Steady just attracts a lot of people that like challenges and the people that have a really strong sense of ownership and like to just create things. And this is also how it feels inside. There is a plenty of individuals that basically have tons of energy and motivation to solve so many problems, not only in Steady, but as you can see, also outside of Steady, which is a result. CloudDash is a result. The mapping tool from Zach Charles

is also a result. Michael Barr created a scheduling service. So yeah, I think that the principles that we have at Steady basically attract top-notch builders. It certainly seems so. I'm going to have to do a little more digging and see what some of those projects are because they're new to me. I really want to thank you for taking so much time to speak with me about what you're building. If people want to learn more

or try to kick the tires on Dynabase, which I heartily recommend, where should they go? Go to dynabase.dev and there is a big download button that you cannot miss. You download the software, you start it. No email, no credit card required.

You just run it. It scans your credentials, profiles, SSOs, whatever, and you can play with it. And that's pretty much it. Excellent. And we will put a link to that in the show notes. Thank you so much for your time. I really appreciate it.

Yeah, thanks for having me. Rafal Valinsky, serverless engineer at Steady and creator of DinoBase. 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 or a thumbs up and like and subscribe buttons on the YouTubes if that's where you're watching it. Whereas if you've hated this podcast, same thing, five-star review, hit the buttons and such, but also leave an angry, bitter comment that you're not going to be able to find once you write it because no one knows how to put it into DynamoDB by hand. 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. This has been a HumblePod production. Stay humble.