Screaming in the Cloud - Let Your Backups Help you Sleep with Simon Bennett

Episode Date: May 24, 2022

About SimonFounder and CEO of SnapShooter a backup company Links Referenced:SnapShooter.com: https://SnapShooter.comMrSimonBennett: https://twitter.com/MrSimonBennett

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. Finding skilled DevOps engineers is a pain in the neck. And if you need to deploy a secure and compliant application to AWS without such things, forget about it.

But that's where Duplo Cloud can help. Their comprehensive no-code slash low-code software platform guarantees a secure and compliant infrastructure in as little as two weeks while automating the full DevSecOps lifestyle. Get started with DevOps as a service from Duplo Cloud and your cloud configurations will be done right the first time. Telomai sent you and your first two months are free. To learn more, visit snark.cloud slash duplocloud. That's snark.cloud slash d-u-p-l-o-c-l-o-u-d. What if there were a single place to get an inventory of what you're

running in the cloud that wasn't the monthly bill? Further, what if there were a single place to get an inventory of what you're running in the cloud that wasn't the monthly bill? Further, what if there were a way to compare that inventory to what you were already managing via Terraform, Pulumi, or CloudFormation, but then automatically add the missing, unmanaged, or drifted parts to it? And what if there were a policy engine to immediately flag and remediate a wide variety of misconfigurations? Well, stop dreaming and start doing. Visit snark.cloud slash firefly to learn more. Welcome to Screaming in the Cloud. I'm Corey Quinn. One of the things that I learned early on in my career as a grumpy Unix systems administrator is that there are two kinds of people out there. Those who care about backups an awful lot,

and people who haven't lost data yet. I lost a bunch of data once upon a time, and then I too fell on the side of backups are super important. Here to talk with me about them a bit today is Simon Bennett, founder and CEO of Snapshooter.com. Simon, thanks for joining me. Thanks for having me. Thank you very much. It's fun to be able to talk to people who are doing business in the cloud space, in this sense too, that is not venture-backed, that is not, well, we have 600 people here that are building this thing out. And similar to the way that I handle things in the Duckbill Group, you are effectively one of those legacy things known as a profitable business that self-funds. What made you decide to pursue that model as opposed to, well, whatever the

polite version of bilking venture capitalists out of enormous piles of money for fun is? I think I always liked the idea of being self-sufficient and running a business. So I always wanted to start physical business when I was younger. But when I got into software, I realized that that's a really easy way. No capital needed to get started. And I tried for years and years to build products, all of which failed until finally Snapshooter actually gained a customer. Oh, wait, someone finally is paying money for this. I guess I'm onto something.

And it sort of progressed from there. How long have you been in business? We started in 2017. It was an internal project for a company I was working at who had problems with DigiSolution backups, or they had problems with their servers getting compromised. So I looked at DigiSolution's API and realized I could build something. And it took less than a week to build a product with billing.

And I put that online and people started using it. So that was how it worked. Every other product I'd tried before, I'd spent months and months developing it and never getting a customer. And the one time I spent less than a week's worth of evenings, someone started paying. I mean, admittedly, the first person was only paying a couple of dollars a month, but it was something.

There's a huge turning point where you just validate the ability and willingness of someone to transfer $1 from their bank account to yours. It speaks to validation in a way that social media nonsense generally doesn't. It's the, oh, someone is actually willing to pay because I'm adding value to what they do. That's no small thing. Yeah, there's definitely a big difference between people saying they're going to, and they'd love that, and actually doing it. I first heard about you when Patrick McKenzie, or Patio11, as he goes by on Twitter, wound up doing a mini thread on you about, I've now used Snapshooter.com for real, and it was such a joy, including making a server migration easier than it would otherwise have been. Now I have

automatically monitored backups to my own S3 account for a bunch of things, which already had a fairly remote risk of failure. And he keeps talking about the awesome aspects of it. And okay, when Patrick says this is neat, that usually means it's time for me to at least click the link and see what's going on. And the thing that jumped out at me was a few things about what it is that you offer. You talk about making sure that people can sleep well at night, that it's about why backups are important, about you obviously check the boxes and talk about how you do things and why you do them the way that you do, but it resonates around the idea of helping people sleep well at night because no one wants to think about backups

because no one cares about backups. They just care an awful lot about restores, usually right after they should have cared about the backups. Yeah, this is actually a big problem with getting customers because I don't think it's on a lot of people's minds getting backups set up until, as you said in the intro, something's gone wrong. And then they're happy to be a customer for life.

I started clicking around and looking at your testimonials, for example, on your website. And the first one I saw was from the CEO of Transistor.fm. For those who aren't familiar with what they do, they are the company that hosts this podcast. I pay them as a vendor for all the back issues and whatnot. It all, whenever you download the show, it's routing through their stuff. So yeah, I kind of want them to have backups of these things because I really don't want to have all of these conversations again with everyone.

It's the, that's an important thing. But Transistor's business is not making sure that the data is safe and secure. It's making podcasts available, making it easy to publish them. And in your case, you're handling the backup portion of it so they can pay their money. They set it up effectively once, set it and forget it. And then they can go back to doing the thing that they do and not having to fuss with it constantly. I think a lot of companies get it wrong where they seem to think that people are going to make

sustained, engaged efforts in whatever platform or tool or service they've built. People have bigger fish to fry. They just want the thing to work and not take up brain sweat. Yeah, customers hardly ever log in. I think it's probably a good sign when they don't have to log in. So they get their report emails and that's that. And they obviously come back when they've got new stuff to set up. But from a support point of view, it's pretty easy really. People don't constantly on the...

From where I sit, the large cloud providers and some of the small ones too, they all have backup functionality built in to the offering that they've got. And some are great, some are terrible. I assume, perhaps naively, that all of them do what it says on the tin and actually back up the data. If that were sufficient, you wouldn't have any customers. You clearly have customers. What is it that makes those things not work super well?

Some of them are inflexible. So some of the providers have built-in server backups that only happen weekly. And six days of no backups can be a big problem when you've made a mistake. So we offer a lot of flexibility around how often you backup your data. And another key part is that we let you store your data where you want.

A lot of the providers have either vendor lock-in or they only store it themselves. So we let you take your data from one side of the globe to the other if you want. As anyone who's listened to the show is aware, I'm not a huge advocate for multi-cloud for a variety of excellent reasons. And I mean that on a per workload basis, not, oh, we're going to go with one company, call it Amazon, and use everything that they do, including their work mail product. Yeah, even Amazon doesn't use work mail.

They use Exchange, like a real company would. And great, pick the thing that works best for you. But backups have always been one of those areas. I know that AWS has great region separation most of the time. I know that it is unheard of for there to be a catastrophic data loss story that transcends multiple regions. So the story from their side is very often, oh, just back it up to a different region. Problem solved. Ignoring the data transfer aspect of that from a pricing perspective, okay. But there's also a risk element here where everyone talks about the single point of failure with the AWS account that there people don't talk about as much.

It's your payment instrument. If they suspend your account, you're not getting into any region. There's also the story of if someone gets access to your account, how do you back that up? If you're going to be doing backups from my perspective, that is the perfect use case to put it on a different provider. Because if I'm backing up from, I don't know, Amazon to Google Cloud or vice versa, I have a hard time envisioning a scenario in which both of those companies simultaneously have lost my data and I still care about computers. It is very hard for me to imagine that kind of failure mode. It's way out of scope for any disaster recovery or business continuity plan that I'm coming up with.

Yeah, that's right. I don't have that in my disaster recovery plan, to be honest, about going to a different cloud. As in, we'll solve that problem when it happens. But the data is, as you say, in two different places or more. But yeah, the security one is a key one because there's quite a lot of surface area on your AWS account for compromising. But if you're using even a separate AWS account

or a different provider purely for storage, that can be very tightly controlled. I also appreciate the idea that when you're backing stuff up between different providers, the idea of owning both sides of it. I know you offer a solution where you wind up hosting the data as well.

And that has its value, don't get me wrong. But there are also times, particularly for regulated industries, where, yeah, I kind of don't want my backup data just hanging out in someone else's account with whatever they choose to do with it. There's also the verification question, which again, I'm not accusing you of in any way, shape, or form of being nefarious. But it's also one of those when I have to report to a board of directors of like, are you sure that they're doing what they say they're doing? It's a, well, he seemed trustworthy

is not the greatest answer. And the boards ask questions like that all the time. Netflix has talked about this, where they back up a rehydrate the business level of data to Google Cloud from AWS, not because they think Amazon is going to disappear off the face of the earth, but because it's easier to do that and explain it than having to say, well, it's extremely unlikely and here's why, and not get torn to pieces by auditors, shareholders,

et cetera. It's the path of least resistance and there is some validity to it. Yeah. When you see those big companies who've been with ransomware attacks, and they've had either pay the ransom, or they've literally got to build the business from scratch, like the cost associated with that is almost business ending. So just one backup of their data offsite, they could have saved themselves millions and millions of pounds. It's one of those things where an ounce of prevention is worth a pound of cure. And we're still seeing that stuff continue to evolve and continue to exist out in the ecosystem. There's a whole host of things that I think about like,

ooh, if I lost that, it would be annoying, but not disastrous. When I was going through some contractual stuff, when we were first setting up the Duckbill Group and talking to clients about this, they would periodically ask questions about, well, what's your DR policy for these things? Well, we have a number of employees, no more than two are located in the same city anywhere. And we all work from laptops because it is the 21st century. So if someone's internet goes out, they'll go to a coffee shop. If everyone's internet goes out, do you really care about the AWS bill that month? It's a very different use case and aligning with these things. Now, let's be clear.

We are a consultancy that fixes AWS bills. We're not a hospital. There's a big difference in use case and what is acceptable in different ways. But what I like is that you have really built something out that lets people choose their own adventure and how managed they want it to be, what the source is, what the target should be. And it gives people enough control, but without having to worry about the finicky parts of aligning a bunch of scripts that wind up firing off in cron jobs. Yeah, I'd say a fair few people run into issues running scripts or, you know, they silently fail

and then you realize you haven't actually been running backups for the last six months until you're trying to pull. Bold of you to think that I would notice it that quickly. Yeah, very true. Yeah, that's presuming you have a disaster recovery plan that you actually test. Lots of small businesses have never even heard of that as a thing so having us us kind of manage backups sort of enables us to very easily tell people that backups of like we couldn't take the backup like you need to address this also to your previous point about the control you can decide completely where data flows between so when people ask us about what's gdpr policies around data and stuff we can say well we don't

actually handle your data in that sense. It goes directly from your source through almost a proxy that you control to your storage. The best answer to GDPR is out of scope. Please come again and just pass that off to someone else. In a way, you've already approved those two. You've approved the person that you're managing servers with

and you've already approved the people that you're doing storage with. You do need already approved the people that you're doing storage with. You do need to approve us, but we're not handling the data. So we're handling your data, like your actual customer. We're not handling your customer's data. Oh, yeah, no, it's a valuable thing. One of my famous personal backup issues was, oh, okay, I'm going to back this up onto the share drive.

And I sort of might have screwed up the backup script in the better way, given the two possible directions this can go. But it was backing up all of its data and all the existing backup data. So, you know, exponential growth of your backups. Now, my storage vendor was about to buy a boat and name it after me before when I caught that. Oh Oh yeah, let's go ahead and fix that. But this stuff is finicky. It's annoying. And in most cases, it fails in silent ways that only show up as a giant bill in one form or another. And not having to think about that is valuable.

I'm willing to spend a few hours setting up a backup strategy in the rest. I'm not willing to tend it on an ongoing basis just because I have other things I care about and things I need to get done. Yeah, it's such a kind of a simple and trivial thing that can quickly become a nightmare when you've made a mistake. So not doing it yourself is a good solution. So it wouldn't have been a patio 11 recommendation to look at what you do without having some insight into the rest of the nuts and bolts of the business and the rest. Your plans are interesting.

You have a free tier, of course, which is a single daily backup job and half a gig of storage or bring your own and then it's unlimited storage. Yeah. Unlimited. The only limits are your budget. Yeah. ZomboGot.com got it slightly wrong. It's not your mind. limits are your budget. Yeah, ZomboGut.com got it slightly wrong. It's not your mind, it's your budget. And then it goes from light to startup to business to agency at the high end. A question I have for you is, at the high end, what I've found has been sort of the

SaaS approach, the top end has always been a contact us form, where it's the enterprise scope of folks, where they tend to have procurement departments looking at this. And they're going to have a whole bunch of custom contract stuff, but they're also not used to signing checks with fewer than two commas in them. So it's the signaling and the messaging of reach out and talk to us. Have you experimented with that at all yet? Is it something you haven't gotten to yet?

Or do you not have interest in serving that particular market segment i'd say we've we've been gearing the business from starting off very small with one solution to you know last two years ago we added the uh the ability to store data from one one provider to a different provider so we are sort of stair-stepping our way up to enterprise. For example, at the end of last year, we went and got certificates for ISO 27001 and one other one. I can't remember the name of them. And we're probably going to get SOC 2 at some point this year. And then, yes, we will be pushing more towards enterprise as we add APIs as well,

so people can set up backups on the fly or as in they can put it as part of their provisioning. That's hopefully where I'm seeing the business go, as in we'll become under-the-hood backup provider for a managed posting solution or something, where their customers won't even realize it's us, but we're taking the backups away from responsibility, away from businesses. For those listeners who are fortunate enough to not have to have spent as long as I have in the woods of corporate governance, the correct answer to, well, how do we know that that vendor is doing what they say that they're doing because the, well, he seemed like a nice guy is not going to carry water? Well, here are the certifications that they've attested to. Here's copies under NDA of their audit reports that call out what controls they claim to have,

and it validates that they are in fact doing what they say that they're doing. That is corporate speak that attests that you're doing the right things. Now, you're going to, in most cases, find yourself spending all your time doing work for no real money if you start making those things available to every customer spending 50 cents a year with you. So generally the, oh, we're going to go through the compliance, get you the reports is one of the higher, more expensive tiers where you must spend at least this much for us to start engaging down this rabbit hole of various nonsenses. And I don't blame you in the least for not going down that path. One of these years, I'm going to wind up going through at least one of those certification approaches myself. But historically, we don't

handle anything except your billing data, and here's how we do it, has so far been sufficient for our contractual needs. But the world's evolving. Sophistication of enterprise buyers is at varying places. And at some point, it'll just be easier to go down that path. Yeah. To be honest, we haven't had many of those customers. Sometimes we have people who come in well over the plan limits, and that's where we do a custom plan for them. But we've not had too many requests for certification.

But obviously we have the certification now, so if anyone ever did want to see it under NDA, we could add some commas to any price. This episode is sponsored in parts by our friend EnterpriseDB. EnterpriseDB has been powering enterprise applications with Postgresquille for 15 years. And now EnterpriseDB has you covered wherever you deploy Postgresquille, 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. What I like as well is that you offer backups for a bunch of different things. You can do snapshots from effectively every provider. I'm sorry, I'm just going to call out because I love this. AWS and Amazon LightSail are called out as

two distinct things. And Amazonians will say, oh, well, under the hood, they're really the same thing, et cetera. Yeah, the user experience is wildly different. So yeah, calling those things out as separate things makes sense. But it goes beyond that because it's not just, well, took a disk image. There we go. Come again. You also offer backup recipes for specific things where you can, for example, back things up to a local file on external storage where someone is. Great. You also back up WordPress and MongoDB and MySQL and a whole bunch of other things. A Unify cloud controller, which is something I have in my house and I keep thinking I should find a way to back that up.

Yeah, this is great. It's not just about the big server thing. It's about having data living in managed services. It's about making sure that the application data is backed up in a reasonable, responsible way. I really like that approach. Was that an evolution or was that something you wound up focusing on almost from the beginning? It was an evolution. So we started with the snapshots, which got the business quite far,

to be honest. And it was very simple. It was just digital ocean to start with, actually, for the first two years. Pretty easy to market in a way, because it's just focused on one thing. Then the other solutions came in like the other providers and you know once you add one it was easy to add many and then came database backups and file backups and i just had those two solutions because that was what people were asking for like they wanted to make sure their their whole server snapshot if you're if you have a whole server snapshot the point in time datatime data for MySQL could be corrupt. There could be stuff in RAM that a MySQL dump would have pulled out, for example.

There's a possibility that the database could be corrupt from a snapshot. So people are asking for a bit more peace of mind with doing proper backups of MySQL. So that's what we added. And it soon became apparent when more customers were asking for more solutions that we really needed to step back and think about what we were actually offering. So we rebuilt this whole database engine that allowed us to consume data from anywhere.

So we can easily add more backup types. So the reason you can see all the ones you've listed there is because that's kind of what people have been asking for. And every time someone comes up with a new open source project or database or whatever, we'll add support. Even ones that I've never heard of before when people ask for some weird file. All it takes is just waiting for someone to reach out and say, hey, can you back this thing up, please? Yeah, exactly.

Some weird file-based database system that I've never, ever heard of. Yeah, sure. Just give us a test server to mess around with, and we'll build. Essentially, we use Bash in the background for doing the backups. If you can stream the data from a command, we can then deal with the whole management process. So that's the reason why.

And then I was seeing in the Laravel space, for example, people were doing MySQL backups and they'd have a script. And then for whatever reason, someone rotated the passwords on the database and the backup script was forgotten about. So there it is, not working for months. So we thought we could build a backup where you could just point it at where the Laravel project is. We can get all the config we need at the runtime

because it's all there with the project anyway. And then thus, you never need to tell us the password for your database. And that problem goes away. And it's the same with WordPress. I'm looking at this now, just as you go through this, I'm a big believer in disclaiming my biases, conflicts of interest, et cetera. And until this point, neither of us have traded a penny in either direction between us that I'm ever aware of. Maybe you bought a t-shirt or something once upon a time, but great. I'm about to become a customer of this because I already have

backup solutions for a lot of the things that you currently support. But again, when you're a grumpy admin who's lost data in the past, it's, huh, you know what I would really like? That's right, another backup. And if that costs me a few hundred bucks a year for the peace of mind, it's money well spent because the failure mode is I get to rewrite a whole lot of blog posts and rerecord a whole bunch of podcasts and pay for a whole bunch of custom development again. And it's just not something that I particularly want to have to deal with. There's something to be said for a holistic backup solution. I wish that more people thought about these things. Can you imagine having

to pull all the blog posts off WebR? Oh my God. That is called the crappiest summer internship someone has ever had. And that is the, that is just painful. I can't quite fathom having to do that as a strategy. Every once in a while, some big site will have a data loss incident or go out of business or something. And there's a frantic archiving endeavor that happens where people are trying to copy the content out of the Google search engines cache before it expires at whatever timeline that is. And that looks like the worst possible situation for any sort of giant backup. At least that's one you can fix.

I mean, if you were to lose all the payment information, then you've got to restitch that all back together or anything else. That's a fixable solution. But a lot of these other ones, if you lose the data, there's no two ways around it, you're screwed. Yeah, it's a fixable solution, but a lot of these other ones, if you lose the data, there's no two ways around it, you're screwed. Yeah, it's a challenging thing. And it's also, the question also becomes one of, well, hang on, I know about backups on this because I have this data,

but it's used to working in an AWS environment. What possible good would it do me sitting somewhere else? Yeah, the point is it's sitting somewhere else, at least in my experience. You can copy it back to that sort of environment. I'm not suggesting this is a way that you can run your AWS serverless environment on DigitalOcean, but it's a matter of if everything turns against you, you can rebuild from those backups. That's the approach that I've usually taken. Do you find that your customers understand that going in, or is there an education process? I'd say people come for all sorts of reasons for why they want backups. So having your data in two places for that is one of the reasons. But I think there's a lot of

reasons why people want peace of mind for either developer mistakes or migration mistakes or hacking all these things so i guess a big one we come up with a lot is people talking about databases and they don't need backups because they've got replication and trying to explain that replication between two databases isn't the same as a backup like you make a a mistake. You run your delete query wrong on the first database. It's gone. Replicated or not. Right. The odds of me fat-fingering an S3 bucket command are incredibly

likelier than the odds of AWS losing an entire region's S3 data irretrievably. I make mistakes a lot more than they tend to architecturally. But let's also be clear, they're one of the best. My impression has always been that the big three mostly do a decent job of this. The jury is still out, in my opinion, on other third-party clouds that are not, I guess,

tier one. What's your take on that? I have to be careful. We've got quite good relationships with some of these. Oh, of course, of course, of course. But yes, I would say most customers do end up using S3 as their storage option. And I think that is because it is, I think, the best. Like as in terms of reliability and performance, some storage can be a little slow at times for putting data in, which could or could not be a problem depending on what your use case is. But there are some trade-offs. Obviously S3, if you're trying to get your data back out, is expensive.

If you were to look at Backblaze, for example, as well, that's considerably cheaper than S3, especially when you're talking in the petabyte scale. There can be huge savings there. So they all sort of bring their own thing to the table. Personally, I store the backups in S3 and in Backblaze and in one other provider. Oh, yeah.

I like to have them spread. Every once in a while in the industry, there's something that happens that's sort of a watershed moment where it reminds everyone, oh, right, that's why we do backups. I mean, I think the most recent one, and again, love to them, this stuff is never fun, was when that OVH data center burned down. And OVH is a somewhat more traditional hosting provider in some respects. Their pricing is great, but they wind up giving you what amounts to, here's a server in a rack, you get to build all this stuff yourself. And

the backup story is one of those, oh, okay, well, I just got two of them and I'll copy backups to each other. Yeah, but they're in the same building and that building just burned down. Now what? And a lot of people learned a very painful lesson. And oh, right, that's why we have to do that. Yeah.

The other big lesson from that was that even if the people with data in a different region, like they'd had cross-regional backups because of the demand at the time for accessing backups, if you wanted to get your data quickly, you're in a queue. Because so many other people were in the same boat as you trying to restore backups. So being off-site with a different provider would have made that a little easier. It's a herd of elephants problem. You test your DR strategy on a scheduled basis. Great. You're the only person doing it, give or take, at that time, as opposed to a large provider has just lost a region and everyone is hitting

their backup service simultaneously. It generally isn't built for that type of scale and provisioning. One other question I have for you is when I make mistakes, for better or worse, they're usually relatively small scale. I'll want to restore a certain file or I will want to, oh, that one item I just dropped out of that database really should not have been dropped. Do you currently offer things that go beyond the entire restore everything or nothing? Or right now, are you still approaching this from the perspective of, this is for the catastrophic case where you're in some pain already? Mostly the catastrophic stage. So we have MySQL bin logs as an option. So if you wanted to do like a point-in-time restore,

which may be more applicable to what you're saying, but generally it's a whole website recovery, for example. Like, oh, we have a WordPress backup that'll go through all the WordPress websites on a server and we'll back them up individually so you can restore just one. There are ways that we have helped customers in the past just pull one table, for example, from a backup.

But yeah, we're geared towards the kind of the set and the forget. And people don't often restore backups, to be honest. They don't. But when they do, it's obviously crucial that they work. So I prefer to backup the whole thing and then help people. Like if you need to extract 10 megabytes

out of an entire gig backup, that's a bit wasteful, but at least you've got the data there. Yeah, I'm a big believer in having backups in a variety of different levels because I don't really want to do a whole server restore when I remove a file. And let's be clear, I still have that grumpy old Unix admin. Before I start making changes to a file, yeah, my editor can undo things and remembers that persistently and all.

But I have a disturbing number of files and directories whose names end in dot back with then like a date or something on it, just because it's, yeah, like, oh, I have to fix something in Git. How do I do this? Step one, I'm going to copy the entire directory. So when I make a pig's breakfast out of this, I lose things that I care about rather than having to play Git Surgeon for two more days, I can just copy it back over and try again. Disk space is cheap for those things, but that's also not a holistic backup strategy because I have to remember to do it every time.

And the whole point of what you're building and the value you're adding from my perspective is people don't have to think about it. Yes. Yeah, yeah, yeah. Once it's there, it's there, it's running. As you say, it's not the most efficient thing. If you wanted to restore one file, not to say you couldn't, but at least you didn't have to think about doing the backup first.

I really want to thank you for taking the time out of your day to talk to me about all this. If people want to learn more for themselves, where can they find you? So, Snapshooter.com is a great place, or on Twitter, if you want to follow me, I am Mr. Simon Bennett. And we will, of course, put links to that in the show notes. Thank you once again. I really appreciate it. Thank you. Thank you very much for having me.

Simon Bennett, founder and CEO of Snapshooter.com. I'm cloud economist Corey Quinn, and this is Screaming in the Cloud. If you've enjoyed this episode, please leave a five-star review on your podcast platform of choice. Whereas if you've hated this episode, please leave a five-star review on your podcast platform of choice, along with an angry, insulting comment that, just like your backup strategy, you haven't put enough thought into. 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.