Screaming in the Cloud - Into the Great Wide Open Source with Julia Ferraioli

Episode Date: December 23, 2021

About JuliaJulia Ferraioli calls herself an Open Source Archaeologist, focusing on sustainability, tooling, and research. Her background includes research in machine learning, robotics, HCI, and accessibility. Julia finds energy in developing creative demos, creating beautiful documents, and rainbow sprinkles. She’s also a fierce supporter of LaTeX, the Oxford comma, and small pull requests.Links:Open Source Stories: https://www.opensourcestories.org

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. It seems like there's a new security breach every day. Are you confident that an old SSH key or a shared admin account isn't going to come back and bite you?

If not, check out Teleport. Teleport is the easiest, most secure way to access all of your infrastructure. The open source Teleport access plane consolidates everything you need for secure access to your Linux and Windows servers. And I assure you, there is no third option there. Kubernetes clusters, databases, and internal applications like AWS Management Console, Yankins, GitLab, Grafana, Jupyter Notebooks, and more. Teleport's unique approach is not only more secure, it also improves developer productivity.

To learn more, visit GoTeleport.com. And no, that's not me telling you to go away. It is GoTeleport.com. This episode is sponsored in part by our friends at Redis, the company behind the incredibly popular open-source database that is not the BindDNS server. If you're tired of managing open-source Redis on your own, or you're using one of the vanilla cloud caching services, these folks have you covered with the go-to managed Redis service for global caching and primary database capabilities, Redis Enterprise. To learn more and deploy not only a cache, but a single operational data platform for one Redis experience, visit redis.com slash hero.

That's R-E-D-I-S dot com slash hero. And my thanks to my friends at Redis for sponsoring my ridiculous nonsense. Welcome to Screaming in the Cloud. I'm Corey Quinn. My guest today is someone I have been very politely badgering to come on the show for a while, ever since I saw her speak a couple years ago in the before times at Monktoberfest. As I've said before, anytime the Red Monk folks are involved in something, it is something you probably want to be involved in. That is my new guiding star philosophy when it comes to conferences, Twitter threads, opinions, breakfast cereals, you name it.

Please welcome Julia Ferrioli, the co-founder of Open Source Stories. Julia, thank you for joining me today. Thank you for having me. And I definitely agree on the Red Monk side of things. They are fantastic folk. They're a small company, which is sort of interesting to me from a perspective of just how outsized their impact on this entire industry is. But I've had as many of them as they will let me have on the show. They are welcome to come back whenever they want, just because every single one of them, though they're very different from one another, make everyone around them better with their presence. And that's just a hard thing to see.

I didn't mean to turn this into a love letter to Redmog, but here we are. I don't mind it. They have the ability to amplify the goodness that they see. Anything from their survey designs to just how they interact online. It's wonderful to see. Speaking of amplifications, you are the co-founder of Open Source Stories, the idea of telling, to my understanding,

the stories behind open source. This is sort of like, what is it, behind the music? In this case, it's behind the code? I mean, how do you envision this? Ooh, I like that framing. So open source stories is a project that myself and Amanda Kassari founded not that terribly long ago

because when we were doing research about how to model open source and open source ecosystems, we realized that a lot of the research papers that have been published about open source are pulled mostly from GitHub Archive, which is this repository of GitHub data. It could be the actual Git commit history, as well as the activity streams from GitHub as well. But that doesn't capture a lot of the nuances behind open source, things like the narratives, how communities interact, where communication is happening, etc. All of these things can happen outside of the hosting platform. So we launched this project to help tell these stories of the people and

events and scenarios behind the open source projects that really power our industry. I'm going to get letters for this one. I'm sure of it. But I've been involved in the open source ecosystem for a while, and I've noticed that there's been a recurring theme among various projects, particularly the more passionate folks working on them, where they talk an awful lot, but they aren't very good at telling stories at the same time. And nowhere is this more evident than when we look at what passes for a lot of these

projects, documentation. One of the transformative talks that I went to was Jordan Sissels years and years ago at the Southern California Linux Expo. And it was a talk about Logstash, which doesn't actually matter because the part that he said that really resonated with me, that his whole theme of his talk was around, was if a new user has a bad time, it's a bug. And the idea,

oh, you didn't read the documentation properly. When I started working with Linux in some IRC chat rooms, the standard response that someone asked for help was to assume that they're an idiot, begin immediately accosting them with RTFM for read the freaking manual, and then look for ways that you could turn this back around on them and make it their fault. And I looked at this, and at the time, it's like, wow, these people are mean to other people. And I was a small,

angry teenager. It's like, this is my jam. Here I am. And yeah, many decades later, I'm looking at this and I feel a sense of shame because that's not the energy I want to put into the world. A lot of those communities have evolved and grown. And what used to be the area, an arena for hobbyists is now powering trillion dollar companies. Absolutely. I like the whole, if the user has a bad experience, that's a bug because it absolutely is. And I feel like a lot of these projects haven't invested nearly as much into the user experience as they have into polishing the code. And the attitude that that kind of perpetuates throughout the project about how you treat your users.

It's pervasive and it really sets up the types of features that you develop, the contributors that you encourage to commit to the project. And it just creates a, to put it minorly, less than welcoming environment for users, contributors, maintainers alike. And we don't really need that sort of hostility, especially when we're talking about projects that underpin the foundations, in some cases, of the internet. When we look at what open source is, I mean, I shortcut to thinking in terms of the context through which I've always approached it, which was generally code, or in my sad particular story, back in the olden days on Goodfreenode, when that was where a lot of this discourse happened, I was network staff and helping a bunch of different communities get channels set up through a Byzantine process, because of course there was a Byzantine process. It was an open source community. And there's one thing we love in open source. It is pretending to be lawyers

when we're not. And we're sort of cargo culting what we think process and procedure often look like. So yeah, there was a bunch of nonsensical paperwork happening there, but it was mostly about helping folks collaborate and communicate. But I first and foremost think in terms of code and in terms of community, what is open source to you? Well, I entered open source in the sourceforge days when all you had to do was go and download some code from the internet and hit the right download button, make sure not to hit one of the extraneous ones. And all you need for that is for the code to be under the right license. And to an extent, that's what's true today for open source. At the heart of it, this minimum criteria for what constitutes open source is, okay, does it comply with the open source definition that the open source initiative puts forth?

Now, I understand that not everybody necessarily agrees with the open source definition, but it's useful as a shortcut for how we think about the basic requirements. But what I find when people are talking about open source online is that they have these very different models. You'll hear from people that, OK, well, if it doesn't have a standard governance model, it's not really open source. The no true Scotsman argument. Yeah. So I find that we've got these different expectations for what open source is. And that leads to us talking past each other or discounting different types of open source. When what we really need to do is come up with better language, a better vocabulary for how to talk about these things. So for example, I used to work in developer relations. And in developer relations, one of the big things that you do is release sample code. Now, oftentimes, I'm not looking for that sample

code to be picked up by a bunch of different developers and incorporated as a library into their project. Well, that's your error in that case, because congratulations, that's running in production at a bank somewhere now. Oh, I know. And that has definitely happened with my code. And I'm ashamed to say that. But generally speaking, you're not looking to build a huge community around sample code, right? You say that, but then again, Stack Overflow, it was originally done rather well. So there's that. Yes, that is true. But when you release code on Stack Overflow or GitHub or in a GIST or just on your blog, the thing that allows the bank to come in and incorporate that into their own application

or to even just learn from it is the fact that it is open source. Now, it doesn't have a lot of the things that a community like Python or Kubernetes has, but it is still open source. It just has a different purpose than those communities and those ecosystems. now to talk about open source as if it were the same type of thing that it was back in the 90s and the noughts and even the teens, where it's a bunch of more or less either hobbyists or people who are perceived to be hobbyists. Sure, an awful lot of them are making commits from their redhat.com email address, but okay. And some of these people are increasingly being paid to workplaces, but then you see almost, I don't necessarily agree with the framing of the New York Times article by Dai Wakabayashi,

who's a previous guest on the show, of Amazon strip mining open source. But they definitely are in there, and other companies as well, are sort of appropriating it or subverting it or turning it into something that it was not previously, for lack of a better term. What's your take on that? Oh, that's a hard one. From a fundamentals perspective, that is absolutely within their rights under the definition of open source, and in some cases, the spirit of open source as well. Oh, and I would argue with someone who said that they should be constrained from doing this as far as a matter of legalities or rights or ridiculous Looney Tunes license changes.

Well, there are definitely folks who are trying to make that the case. Yeah. Oh, yeah. I'm on the position of they're within their rights to do it, but it's time for a good old-fashioned public shunning as a result. I'm not sure I agree. I think that it is a natural consequence of how open source has gained in popularity. And in some cases, it's a testament to open sources success. Now, does it pose some serious challenges for the open source community and open source ecosystem? Absolutely. Because this is a new way of using open source that was unanticipated and, in fact, could be characterized as a black swan event in open source.

The fundamental attribution error that I see back at the very beginning was that, well, we wrote the software, therefore we are the best in the world at running it. Therefore, if there's going to be a managed service, clearly ours will be the best. Amazon's core strength has apparently been operational excellence, as they like to call it. My position on that is a little bit less of tying into the mystery, a little bit more of they're really fast at getting paged and fixing things in a hurry before customers notice.

So, okay, great. It's column A, column B, whatever. The bigger concern I have with Amazon is its product strategy is yes. If it were just a way to run EC2 instances or virtual machines, then sure, that's great. And every open source project should on some level see some validation of its market through a lens of, oh, we're getting some competition. That's great. The challenge I see is that in the line of competitors, Amazon is at or near the front all the time on basically everything.

And if they would pick a lane to stay in, great. Google's a good example of this. There are things that Google very strongly considers in its wheelhouse. But for other things, they partner with the open source-based company in question to create a managed service partner offering, and that's great. Amazon pulls a, nope, we're just going to build this out as first party, the end. And they compete with everyone, including themselves on almost every

axis. And that's where it just gets into a, like leave some oxygen for the rest of us. I mean, it feels like they lie awake at night worrying that someone who isn't them is somehow making money somewhere. That is, I think, on some level more of the black swan event than someone else deciding that they can host a particular open source project more effectively. But that's where I stand. And again, this is just me as an enthusiastic and obnoxious observer. You're operating in this space. What do you think?

That's the important part of the story. Well, I mean, you definitely have a point. Amazon or AWS, maybe not necessarily Amazon, takes on different technologies far and wide. So they're not limiting themselves to a space. But that said, I think it comes down less to what is possible with open source and what is okay under the guise of open source and what is good for the open source ecosystem. And when you fork a project, you do have to understand that you are bifurcating the open source ecosystem. And that can lead to sustainability problems down the road.

So I think the jury is still out on whether forking a project, running it as a managed service, as Amazon is doing with some of the open source projects, if that's going to come back to bite them, just from a developer community standpoint, because you're going to have people committing to one or the other, but possibly not both. I think this is why Amazon, I know they're very annoyed by their perception in the open source ecosystem, but you take a look at other large tech companies and almost all of them have a few notable open source projects that started life there. For example, we have, I think Cassandra came out of Facebook, but don't quote me on that. Kubernetes came out of Google, a fact for which they steadfastly refused

to apologize so far, and so on and so forth. But Amazon's open source initiatives have been, we've open sourced this thing that is basically only used at Amazon. Or my personal favorite, we've put all of our documentation up on GitHub so that you can write corrections to it yourself from the community, which I'm hearing is,

please volunteer for a $1.6 trillion company so that they don't have to improve their documentation by hiring expensive people internally. You can sort of guess my position on that. It seems like they have not launched anything that has a deep heart within Amazon that is broadly adopted outside of their walls. My question for you is, do you believe that having that level of adoption externally is required for a healthy open source project? Again, I think it goes back to the goals of why you're open sourcing something. I don't believe that it's necessarily required for the open source project to be quality and be usable. But if your goal is adoption, or if your goal is to get ideas and best practices out there,

then yeah, you do need that engagement by the broader community. You do need the contributors. But there are a lot of cases where open sourcing a technology is more for the validation rather than the adoption of the tech. So it really depends. I'd say the most cynical reason I've seen to open source things comes from Netflix, where they have a recurring pattern of open sourcing something. There are two or three commits, and then it basically sits there unattended. What I firmly believe is happening is that a senior engineer at Netflix is working on the thing, and they're about to change jobs. So they open source the project so that they can change jobs

and then pick up where they left off with an internal fork. I view it as a game. Basically, they're passing themselves a football as they run across the street. And people laugh when I say that, but I've also had people over drinks say, you are closer than you might think sometimes, which on some level is terrifying. It feels like life is imitating art, but here we go. That definitely happens, and I have seen it as well. People want to essentially use open source to exfiltrate IP. Yeah, only doing it the legitimate way as opposed to the, please don't hope that I don't find that USB stick I've hidden in my sock on my last day. Yes, and this is why open source offices have a challenging job in helping facilitate the release of open source software.

So it is hard to ascertain when that is happening. Yeah, no company is ever going to have a big statement that is going to be anything other than, honestly, marketing speak when it comes time to explain why they're doing a certain thing. It's, oh yeah, we're open sourcing this so we don't get sued in three years by this other company that might prove to be a competitive threat, or we're open sourcing this as a hiring and recruiting technique. I mean, I would argue it wasn't open sourced. One of the best approaches that I've seen from that perspective came out of Google. I'm firmly convinced to this day that App Engine was run not by their SRE team, but by their recruiting arm. Because if you can build a great app on App Engine, well, this is kind of like how we think about things inside of Google

come and work here, either via acqui-hiring or a just outright interview funnel. Maybe that's too cynical too. But again, that leads to the question of, is it really open source when it has these deep ties to specific platforms? Here's an open source tool that presumes you're running on top of AWS. Well, great. Sure, it's built by the community

and anyone can access these things, but without paying per second to a cloud provider, probably the reference cloud provider developing this against, it's not going to get very far. So it's a nuanced argument, and there are shades of that nuance to every aspect of it.

And if there's one thing that Twitter is terrible at, it is capturing nuance in 280 characters. And even in the, all right, this is my nuanced take on open source. In this thread, I will tweet one of 5,712. Great. That's not really the forum for that either. And people lose sight of nuance.

It's a sticky, delicate thing. And it feels like a lot of the open source community has been enthusiastically agreeing with each other, sometimes violently so, but they're not sharing a common language in which to do it. Yeah. And in terms of the purposes of open source projects, it is okay for them to have different ones as long as they're telegraphing those purposes to their users and the people who are looking at the projects for their own use. But whether it's open source, I think it's okay for that to be the baseline and then build out the vocabulary of the types of projects that you want from there based on those expectations.

Yes, this particular technology only works with this cloud provider. That's open source that facilitates and accelerates development with that cloud provider. This episode is sponsored by our friends at Oracle Cloud. Counting the pennies, but still dreaming of deploying apps instead of hello world demos? allow me to introduce you to Oracle's always free tier. It provides over 20 free services and infrastructure, networking, databases, observability, management, and security. And let me be clear here, it's actually free. There's no surprise billing until you intentionally and proactively upgrade your account. This means you can provision a virtual machine instance or spin up an autonomous database that manages itself, all while gaining the

networking, load balancing, and storage resources that somehow never quite make it into most free tiers needed to support the application that you want to build. With Always Free, you can do things like run small-scale applications or do proof-of-concept testing without spending a dime. You know that I always like to put asterisk next to the word free. This is actually free, no asterisk. Start now. Visit snark.cloud slash oci-free. That's snark.cloud slash oci-free. I always try and stay away from explicit value judgments on a lot of these things because it's nuanced.

And no one who doesn't work at Facebook wakes up expecting to do terrible things today. We're all trying to do the best we can with the constraints we're operating within. The challenge is that when you're at a company like an AWS or a Google or a Microsoft or one of these giant companies, the same pressures that the rest of the, quote-unquote, mere mortals in the ecosystem have to contend with are very different. Talking to people who work at these big companies, they have meetings and review processes that here at my 12-person company, I don't even have to consider.

Easy example of that. Never once have I put something out into the world and had a single discussion about, is this going to get us in trouble with respect to antitrust? That has never been on my radar as far as things I have to care about. Even at my previous job at a highly regulated financial company, where you could argue that they are approaching monopoly status in some areas of the market organically with passive investing being what it is. Great. Their open source discussions were always much more aligned with what licenses are we willing to accept legal risk for using internally? Because there are things that are like IP is why we have a business

in many respects. So anything that touches that, that theoretically means that we don't have to disclose how the entire system, how the rest of it works is not allowed to be used here. And there are reviews and processes and compliance requirements for that. I get that concern. And at a certain point of scale, you're negligent. If you don't have a function that looks at it through that lens. But I look back to the early days of just puttering around with, I want to do a thing. And I found this project somewhere that people are excited about in the pre-GitHub days. I can download it off of SourceForge or whatnot, and I can make it work.

But it doesn't do this one thing I want to do. Hey, the code's available. Can I fix it myself? Absolutely not. I'm crap at writing code, but I can talk to people and piece it together from wisdom that they offer. And it turns something into something awful until finally it gets an attraction that someone who knows what they're doing looks at it and refactors it and makes it good. And that's the open source community I recognize and that I see from my early developmental period. I don't recognize what we see in the ecosystem today through that same lens of, okay, go online, be nice to people. Well, that's new. See how this thing works. And oh, if I'm having a problem, I'm probably not the only person who's having a problem like this. You have to get really good at using Google more than you do at writing code in some respects.

But at that point, it's almost entirely a copy and paste, except that's not technical enough for the open source world. So instead, we have to learn the 500 arcane subcommands to get in order to get it's not necessarily where you might tend to look. But those projects are still there. They're still running. They might be a little less high profile than a lot of the ones that are getting a lot of attention right now, but they are still there. On some level, it feels like the blame for this lies at least partially at the feet of Slack and its success, because it used to be that you had IRC. That was how folks communicated. I remember the early days of that and things like Jabber or internal servers, internal IRC servers at companies. Great. You'd have engineering all talking on that.

And oh, you want to have someone in finance or marketing join that thing. Yeah, the short answer is, is that won't be happening. But you can try and delude yourself and set it up with a special client and the rest. Slack removed all of that friction, but it's balkanized to the point where every once in a while I have to go through

and remove a bunch of Slack channels slash workspaces slash whatever we're calling them this week from my desktop client because it's basically eating all the RAM like it's trying to be Google Chrome. And then it's great, but there's no universal federated thing the way that there was with IRC where I just pop in a different channel for a different project. And IRC is still there, and it comes back to life whenever Slack takes an outage and then Slack gets fixed and it sort of bleeds off again. But I don't want to be in 500 different Slack workspaces, one for every open source project that I'm using. And there's no coherent sense of identity and community anymore the way there once was. And I feel like I'm old man yelling at the passing of time at this, but you're right. Open source to me was always much more about community than it was about code. Yeah. And I think that we do not talk about the impact of tools for open source that we use because you're right with IRC, it was unified. You could pretty much guarantee that projects of a certain size were present there.

And with Slack, you have to sign up for yet another account. I'm not quite yet sure why I can't find the right channels that I need to join in Slack. So there's a lot of navigation and a lot of prerequisite knowledge that you need to have in order to be productive. And then you've got other tools being used for communication by other communities. Like, I believe Gitter is a major one as well. Then you have to make sure that you're up to date with all of these different interfaces, Discord, everything. And the sociological implication of that shouldn't be underestimated. What are you going to do if you find a project that uses a communication tool that you just really don't want to use

or don't want to sign up for yet another account. Maybe you pass on by and you find one that works within your existing set of tools. There aren't a lack of open source projects to join right now. You can be choosy. And we don't yet know what the impact is of that.

It's challenging. There's no good answer that I've found that solves all of these things. It's become so balkanized on some level that every project out there that I see, and there are some small ones that are incredibly foundational to basically civilization as we know it, but it's not working right because you have to figure out where they are and what the community norms are because they change from project to project. And there are so many different things. And even go into NPM and install some relatively trivial thing that does command line string processing or whatnot, and it installs 40 different dependencies and there's a problem and you want to figure out exactly how that works and et cetera, et cetera, et cetera.

Absolutely. With NPM specifically or Node specifically, it is interesting that the development model kind of encourages this obscurity and obfuscation of functionality. So it is hard to go in, debug an issue, go to the specific community, understand how they work, contribute a patch, just to fix something that is five levels up. It gets confusing for developers.

It can contribute to longer-term bugs that we see propagate throughout the system. It is not an easy problem to solve, and I have a lot of sympathy for newcomers to the open source ecosystem because it is so hard to navigate. And I think that that's an as-yet-unsolved problem that we need to address. So what was it that inspired you to create open source stories? I love the direction you're taking this in. I love the way you're thinking about it. Where did it come from? What started this? Well, when Amanda and I were going back and doing research around,

you know, aside from the code for an open source project, where are the different entry points? Where are the different interaction points between projects, ecosystems, and the industry? And we did a couple of interviews, just very organic interviews with some subject matter experts in Node, in Python, in Go. And there was a point where we stopped, or at least I stopped taking notes because I was just so fascinated by the narrative that our interviewee was putting forth and was talking about. And what we wanted was for it to not just be this meeting between a few people. We wanted to be able to share that with anyone. And so one of the things that really inspired us was StoryCorps, which allows you to record much like we're doing today,

40 minutes worth of interactions between one to three people. Oh, we're going to cut it down to five minutes at most. Like one question, one answer, boom, we're done. I kid, I kid. But it's really about facilitating the sharing of knowledge and sharing of these oral histories. Because as you're doing research into interactions in specific open source communities, you'll get articles, you'll get change logs, all of that good stuff, but you won't get the nuance that we've been talking about over the course of this podcast. You lose the story. Behind the story.

Right. How are decisions made. How are people thinking about. The interactions with their users. What are the. Turning points. For a project. What are those conversations.

Between the maintainers. That changed the entire game? Those are the sorts of stories that we're hoping to capture because they're important for history, for knowledge sharing, for learning from our past and making decisions for the future. And so that's really what we wanted to capture. And we wanted to capture the narratives behind the people that don't necessarily show up in the code base too. Talking about the designers, the product managers, the marketers behind open source that make it successful.

Because there's so much more than code. Oh my God, yes. It's, how do I put this politely without getting letters? Well, I guess I'll take a stab at it and see how it plays out. I look at so much of the brilliant code that has been written and the documentation is abhorrent and the design of the site and the has been written and the documentation is abhorrent and the design of the site and the icon and the interface, it looks like a joke that I put on Twitter trying to be

funny. The code is important, don't get me wrong, but there's so much more to it than that. And we see this in the industry too, where companies have gone out of business trying to get their code base just right. It's, yeah, you can launch code that is really, really bad, but if you have product market fit, it is survivable. I've heard stories in the early days of Twitter that we saw the fail whale all the time because it was an abhorrent monstrosity to the point it became a running joke. But it turns out when you hit product market fit, you can afford really good engineers to come in and fix

a lot of that stuff. That stuff is more important than the quality of the code. And that is something that I think that we have a collective industry-wide delusion about. And it's a blind spot for us. Yeah, I think we get wrapped up in the cleverness of the tech. And I've fallen prey to this too. I get so involved in how I'm solving a problem and forget about the actual problem that I'm trying to solve, right? It's not necessarily about the how, but about the what. And without your fantastic tech writers, designers, usability experts, your open source project is going to be your open source project. It's not going to necessarily get that wide adoption if that is indeed your goal for the technology that you're releasing. So it really is about making sure that as we're launching and working on these open source projects and ecosystems, that we are inviting people to the

table that have these other unique skills that goes beyond the code and speaks to what makes the project different and unique. I really want to say just how much I appreciate your taking the time to talk to me about this. If people want to get involved themselves, how do they do that? Because I have a hard time accepting that you're doing something called open source stories that eschews community involvement. Yeah, so we absolutely would love more folks to get involved. I have been primarily the person working on the site, so we can always use contributors to the site itself. But we also want more storytellers and facilitators. And so if you go to opensourcestories.org,

we've got a page specifically designed to facilitate contributions. So check that out. And we look forward to hearing from anyone who wants to participate. And we will, of course, include links to that in the show notes. Thank you so much for taking the time to speak with me today. I really appreciate it. Thanks for having me. Julia Ferrioli,

co-founder of Open Source Stories. I'm cloud economist Corey Quinn, and this is Screaming in the Cloud. If you've enjoyed this podcast, please leave a five-star review on your podcast platform of choice. Whereas if you've hated this podcast, please leave a five-star review on your podcast platform of choice. Whereas if you've hated this podcast, please leave a five-star review on your podcast platform of choice, along with an angry comment calling me a fool because I did not bother to RTFM first. 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.