Screaming in the Cloud - Building Community in Open Source with Floor Drees

Episode Date: February 14, 2023

Episode SummaryFloor Drees, Staff Developer Advocate at Aiven, joins Corey on Screaming in the Cloud to discuss her journey into the world of open source and the opportunities she sees to improve developer relations. Floor and Corey dive into the pitfalls and opportunities of being a frequent speaker at events, and Floor shares some best practices to help be prepared for those opportunities. Floor also shares why she feels events should include hybrid remote attendance options, and the benefits of hosting local events to breathe life into new relationships within the developer community. Floor and Corey also discuss the complexities of maintaining an open-source project and what goes into keeping an open-source community healthy and thriving. About FloorFloor is a Staff Developer Advocate at Aiven, a company that manages your favorite open source data tools for you without exploiting the projects and their maintainers. Previously Floor worked in DevRel at Grafana Labs and Microsoft. She is a Devopsdays Core member, and organizes the Devopsdays Amsterdam and Eindhoven chapters. She is a Microsoft MVP for Developer Technologies, and organizes a bunch of meetups, including-but-not-limited-to contributing.today, DevRel Salon Amsterdam, and the Amsterdam Ruby Meetup. Floor is also an art school graduate, who stumbled into tech face-first.Links Referenced:Aiven: https://aiven.iofloor.dev: https://floor.devMastodon: https://mastodon.lol/@floordTwitter: https://twitter.com/floordreesdev.to: https://dev.to/floord

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. Welcome to Screaming in the Cloud. I'm Corey Quinn.

My guest today is a staff developer advocate at a company called Ivan. No, for those who have been following the adventures of the show for a while, I am not talking about Maddy Stratton. I'm instead talking about Flor Dres. Flor, thank you for joining me today. Thank you for having me. And Maddy is my manager, so he's sort of here, you know, like by proxy anyway. But he's not actually here, which means there is absolutely nothing that should preclude us from talking smack about him as he oh so richly deserves. Hi, Maddie. I had this thing not too long ago where we were going

to the same conference and he was speaking just before me and his talk was accepted when he was still at Pulumi and my talk was accepted when I was already at Ivan. But then we turned out to both be working at Ivan at the time of the conference and I was speaking after my manager. That was scary, yo. Part of the challenge as well when I found that I'm doing speaking on stage in conjunction or associated with someone else is on some level you start wondering, okay, well, what is their talk going to be like? And this becomes more challenging when you start speaking at corporate events where, okay, great, so I'm going to be introduced by a CEO at a keynote,

and then they're going to pass off to me, because you want to definitely make sure that you're sparkling and scintillating. It's the reason you were presumably invited to speak, but also you don't necessarily want to upstage the person that brought you in. You don't want to have the energy mismatch. And that's why kiddies are starving. And now our next talk is by Bozo the Clown. It doesn't work that way. There has to be some level of making it work, as well as if you're both working at the same company,

maybe we don't just give two versions of the same talk hitting on the same themes, which is not usually a problem, but it's the stuff that you're terrified of right before you go on stage and it's too late to change anything in your talk. And all you can do is sit there and fret, at least for me. Yeah, I think we have a really great practice at Ivan Doe where we have a speaker's corner so we can rehearse our talks before. And many of us, we've been public speakers for a while, right? We've done dozens of talks, but then still rehearsing in front of an audience, you get challenged on all of the things that you totally take for granted, or you think that your audience will definitely

know. And it's been so useful. And so I've seen, I had seen Matty's talk already and he had seen mine. So we knew going in that we were not talking about the same thing. But it does happen even if you're not working for the same company. I'm a DevOps Days organizer. And sometimes people don't show up for the entire conference and they end up introducing a product that has already been introduced by someone else, but they didn't bother to show up in the morning. And that's painful, I feel like.

The shortest notice I've ever had to give a conference talk on was 10 minutes before the talk. The speaker hadn't shown up. We later found out that the organizer of the conference in question hadn't bothered to confirm that they received the acceptance email. So yeah, great. Yeah, we'll accept your talk. Just assumed that they would

know about this. So can you give a talk about, I think, enterprise DevOps or something like that and 10 minutes notice? It's like, so in other words, you want me to stand there in front of everyone, pretend I know what the hell I'm talking about, completely unprepared with no context into what's going on. That is enterprise DevOps, of course. And it sort of snowballed from there. Love it. Origin story. It was entertaining, at least. There were no slides. But people somehow think that when you're speaking without slides, oh my god, they must be an amazing speaker rather than a horrible procrastinator and woefully underprepared.

I wonder, though, did you give that explanation that this is something you were asked to do on the spot, or did you just wing it? Oh, I'm always a big fan of so. I found out I was giving this talk 10 minutes ago because the actual person mentioned on the program is not here. Because that was the ethical way to do it. The unethical thing to do would have been to go up, pretend I was the person listed on the program, and pick fights with people and destroy their career.

So, you know, it seemed like that was not really the right way to go. I also think I'd given the morning keynote, so it was kind of hard to hide. I mean, so giving talks without a lot of notice is sort of become a more common thing now with, you know, pandemic and all kinds of crises and like stuff, stuff happens and people need backup speakers. And I feel like in my profession, at least in developer relations, we should be able to pick that up pretty quickly and have stuff on the shelf. If we're attending a conference, even if we're not on the lineup, if we didn't make it to the lineup, because always be ready to give that talk. Yeah. But I've never been given a subject and then be like, oh, go. That's a different beast. I think there's also a, because this is the stuff that people talk about. It's certainly

one of the most visible aspects of it, but it feels on some level like DevRel is perceived as, oh, you go on stage and give a whole bunch of conference talks. In fact, during the early days of the pandemic, there was a bit of a bloodletting of DevRel folks because it feels like they didn't correct that assumption even within their companies on some level where it's, well, we just have these expensive developer-looking people who don't write production code and go around and speak at conferences all the time and there are no conferences, so what do we do? That felt like a misunderstanding of how it works. I mean, people know me for the stuff that I say on stage, but I spend way more time writing than I do speaking. But it turns out that a public writer is not the same thing as a public speaker.

It's a good role description, though. Yeah, and you do a lot more listening than you do speaking as well, but that's all not very visible. Yeah, I do think also there are some people in developer relations that just love to travel and being on stage, and they were definitely sort of disgruntled by budgets being cut for travel or travel policies changing. Yeah, definitely it was some of that, too. Yeah, on some level, it becomes unsustainable, not just in a climate sense, but in a lifestyle and company sense. Like, yeah, I make $200,000 a year and spend eight times that in travel costs every year. It's okay. You get that Zoom is a thing, right? You can talk to people remotely. Not that it's great for every conversation, but maybe you don't need to look at the DevOps Days events like they're

Pokemon and try to catch them all globally. No, I agree with you. And I also think, and I love that you say DevOps Days in that context, too, because we have city events, right? And for our city events, also, when we're looking at the talks submissions, you want to have a good mix of people that are, you know, local to the region and people that are not necessarily from the region. But otherwise, there's no sense in organizing something like DevOps Days Amsterdam if everyone is from far outside Amsterdam and far outside of the Netherlands. Like, that doesn't make a lot of sense.

You want to have some of the local talent as well. I also feel like, especially for a company to send a developer relations person to the other end of the world where they give a talk and they meet with a customer and then they leave again for their end of the world that sort of like sense of community or that sort of budding flower there's no oxygen anymore and I don't understand that you probably do have some people that are more local or regional that can be mentored into giving more of those kinds of talks or there must be other talent. And so we don't have to fly people around

the world because you're right, the planet is f***ed. And so we don't want to be doing that. Yeah. I've never really understood that. I'm trying to do a lot of events now that are either online or local to where I'm based. And if they're local, then if I can travel there by train, then I try and do that. It's also fun. I can, I don't know, I can work better on a train than I can do on a plane where you have, I don't know, even less space. And there's so much waiting and walking to that corner and that corner. And I don't know, I'm not a big fan of flights in general. No, I don't miss a lot of the constant traveling that I was more or less forced into doing

back when I, in the before times, when speaking was the way that everything seemed to wind up being done. We learned new ways of doing stuff. I don't go on site for client engagements anymore in almost any circumstance, just because even now it's, well, their team's in a whole bunch of different places. So what's the value of flying them all in and flying me in? And in some cases, half the team doesn't show up. So you're presenting to Zoom anyway. It just always

seemed like such a ridiculous rigmarole on some level. Yeah, I was 100% hoping that we would use a lot of the things that we learned during the pandemic time and make sure that our events are more accessible for remote participants once we can go back to in-person events. And in fact, I've done a little study for DevOps Days in my position as a DevOps Days core organizer to figure out how the different organizing teams in different cities responded to 2020-21 when they couldn't meet in person anymore, if they went for a virtual event or if they went for a hybrid event, if some of the restrictions in their area loosened. And if in 2022, or depending on the region, 2023, we'll go back in person again. And if they would still have that sort of online component.

And it's been super interesting reading the response. For the Netherlands, we teamed up with another chapter that was going on in the Netherlands and then offered a combined online experience. But then going back in person this last year, we didn't really put a lot of thought into also offering a live stream. Well, I mean, we've been doing that. It's almost like a no-brainer, but still, it seems to be really hard to get the whole team on the same page and try and offer that for people that participate remote. I heard a response from one of them because I ran a survey with all the organizers of DevOps Days events.

And one of the organizers said that they were afraid that they would not get as many people to their in-person event if they offered it in a hybrid format. So if they would also offer an online element to their conference, they were afraid that people would just sit on their couch and follow the conference from the comforts of their own home and not join at the conference location. And I think that's the people that would join from their couch or maybe, and I always think it's a weird thing because maybe they're joining from their home office, like they're not necessarily home office. There is a couch in my home office.

I tend to wind up having both of those boxes checked. Perfect. Well, that's A plus for setup. But I think that's probably a very different audience. Like that's maybe people that wouldn't come to your in-person event in the first place, maybe because they can't do the whole travel or in-person events are too much for them or any other reason. But I don't think that offering an online component is what's keeping people from coming to your in-person event. You've been involved in the open source and community worlds.

I don't want to conflate the two, though it seems that they are inextricably linked in a bunch of ways. You're a DevOps Days core organizer, but you also have a sustained and, we'll call it enduring, focus on the idea of open source sustainability. What does that mean? It sounds like a bunch of words that someone picked off of a slide somewhere and threw together because it seems that subtly everyone has their own view of what that means. This feels like a college entrance essay, but what does open source sustainability mean to you? I put them on a slide in the first place. Exactly. That's the true demeaning of devops is you build the slides rather than just reading them i mean the acronym is so good too because it says sos and aren't we in a crisis exactly all right so i got involved in open source in the first place when i figured out that

i was just learning to program because I didn't go and get a CS degree or anything. I studied art, actually, something entirely different, and then fell in love with the internet and then wanting to know how the internet works and built for the internet. Poorly at the best of times. I hear you. It was the original question of how does this stuff work? So I started learning about networking. And once you go down that rabbit hole, you're amazed it works at all. So you just basically use this to, so all that you rise above all those levels. So then you just use this to basically like send text messages back and forth. Like, oh no, no,

we do our banking here. Okay, this is definitely something that takes some adjusting period to get used to. I love that you're saying that. I'm actually writing a talk about how I try to explain to my son, who is eight years old, very poorly about how I even make a living, how the company that I work for makes a living, what open source is.

I didn't know where to start. It was a half an hour of rambling and him rolling his eyes at me and so now for a talk I'm trying to summarize it in five minutes and make it something that actually people would understand so yeah fingers crossed in that one no but I entered in open source just figuring out that I could make changes to instructions on how to install something and making sure that no one else would get stuck on that issue again for the setup that I had, if they had the similar setup. And that was just such a revelation for me. It was wonderful. People that I don't know, I could unblock them. What a wonderful thing this is. And I started

looking at more open source projects to contribute to, to look at, start working for a lot of companies that had open source, at least as part of their product offering. And as such, started talking to a lot of maintainers. Much later, when I was working at Microsoft, I started a meetup with a couple of friends who were similarly interested in open source topics. And we had a regular meetup where we talk about with maintainers about some of the issues that they were facing. So creating a safe space or how to get more contributors or how to get funding or how to deal with mental health issues in open source and community. And from talking to a lot of maintainers, I felt like there were a lot of these topics that maybe maintainers between

themselves were discussing, but wasn't really apparent to the larger community. And so there was a little bit of a disconnect of why maybe choices were made for different projects or why maintainers try to go down a certain route. And it was difficult for them to then navigate that new reality with contributors because they hadn't taken them on the same journey. And so I always felt that there's a lot of things in the tech world that we all take for granted. We always think that everybody understands why we're doing a certain thing,

but we're not doing a lot of explaining. And if we're doing explaining, we're not doing it in a really accessible way. So that's always been sort of my pet peeve. And the reason why I do a lot of meetups and facilitate a lot of panels just to get people talking to each other and exchange expectations. This episode is sponsored in part by Honeycomb.

I'm not going to dance around the problem. Your engineers are burned out. They're tired from pagers waking them up at 2am for something that could have waited until after their morning coffee. Ring ring. Who's there? It's Nagios, the original Call of Duty. They're fed up with relying on two or three different monitoring tools that still require them to manually trudge through logs to decipher what might be wrong. Simply put, there is a better way. Observability tools like Honeycomb, and very little else because they do admittedly set

the bar, show you the patterns and outliers of how users experience your code in complex and unpredictable environments so you can spend less time firefighting and more time innovating. It's great for your business, great for your engineers, and most importantly, great for your customers. Try free today at honeycomb.io slash screaming in the cloud. That's honeycomb.io slash screaming in the cloud. What I have found across the board with, I guess, community as events with open source, and this is going to get me letters, I can already tell in advance. It feels almost like a PTA meeting or

something similar, like local town council-style politics, where everyone is extraordinarily passionate about what's going on, but the stakes are relatively small in the grand scheme of things in many cases. So you wind up with folks just screaming at each other, and it really becomes a thankless job to some extent. In my time as an open source maintainer and being deeply active in a bunch of different open source communities, one of the things that I have found has been that very often the worst customers in the world are the ones who are not actually customers, they're users. They aren't paying you anything. And I talk to companies across the board, and they see the same thing. The free trial users tend to be far more work than the paying customers. I mean, I

see that on an annual basis as well. We do an annual charity t-shirt drive, and I have more customer service challenges during that week that we do that than I do with the delivery of very highly priced consulting engagements. Because, yeah, you're spending a large amount of money on a consulting project, and there's a challenge. you're going to pick up the phone and talk to someone like a human being. As opposed to, this $35 t-shirt for charity is having slow shipping? I'm going to give that person a piece of my mind via email. Outrageous. It doesn't go well. Yeah.

Yeah. I used to work at a large web hosting company before GoDaddy bought them and proceeded to ruin them like everything GoDaddy ever touches. Media Temple. And it was never the people spending thousands a month that were the problem. It was the folks at the lowest tier offering we had, 10 or 20 bucks a month, calling in and expecting 80 hours a month of engineering work and support and the rest. And on some level, you really have to let the customers who you clearly cannot satisfy go. Everyone's better off for it. The problem is when we're talking about open source communities, it's much harder to do because booting someone from a community leads to drama. Everyone picks sides.

It ends horribly. But if you don't do that, you watch everything devolve into the worst display of humanity. Oh, 100%. Yeah. The project is only as healthy as its community. So if you have very problematic people in there, then you need to get rid of them. 100% agree. But I also think like some of that is a maintainer starting or a group of maintainers starting with a project where they pour their heart and soul in it and they will respond to

everything. But then as a project starts to grow and evolve, they can't actually put as much time into every single contribution or every single issue or PR filed. But they have set that sort of expectation that they could, but it's not a sustainable situation, right? Especially when they start, when the project matures and maintenance just costs more in terms of resources, money, whatever, and they need to maybe start thinking of a way to monetize that thing that they're working on either by adding some enterprise

plan for it or a cloud plan where they offer some support or some differentiating features for it. And then suddenly they're spending time on another, almost like an other product and are not entirely focused on the open source product anymore. And that's sometimes a very difficult pill for less frequent contributors or community members to swallow because they have seen something else and now they have to get used to their maintainer sold out. They need to pay a mortgage. Well, that's the problem too, is I think that there is a malaise, and I've talked about it in a few episodes of this show over the years, where companies want the benefits of open source. They want the easy adoption approach. They want to be able to externalize the cost of development in some cases, where everyone who winds up having a challenge with the product, like, oh, great, pull request, welcome, which is the polite way of saying, no, you fix it. And on some level, it's okay, great. So we've had a bunch of people participate in this and now we've built something super awesome and valuable. How do we cash out? How do we make money out of this? And we're seeing that with license changes. And I have little

tolerance for companies that change their license to prevent Amazon from building an equivalent thing. It's like, first, Amazon does nothing wrong when they wind up taking something that's open source and operating within the confines of that license. Just because you don't like it does not mean they're being a bad actor, first off. I mean, let's be clear, Amazon does many things that are wrong. That just doesn't happen to be one. The next thing to think about from that perspective is Amazon does things at hyperscale. I promise you, they are not grabbing the open source version of whatever, slapping it onto some EC2 instances, and here you go.

This is a running managed service in most cases. They are having to tweak it for their own storage substrate. They're having to work around the constraints within their environment. The fact that a lot of these things are designed to run on 15 different operating systems is probably largely irrelevant to them. They needed to work really well on one. They can strip out a lot of the optional functionality, dial in on the features that they're offering, and in some cases it feels

like they're doing a complete rewrite and just offering API compatibility at most. So this idea that they're just going to take your code, do a make-build, and then start selling it to people is a little misguided as well. Yeah, it's an oversimplification for sure. It just seems that companies get lost and wrapped around their own axle on these things. And I do

have some sympathy for folks. Take Docker as a great canonical example of this. The technology was transformative and great, and there was no real clear path for Docker the company to wind up building an offering around this stuff in a way that was easily and reasonably able to be monetized. And they wound up changing their licensing and their pricing for large companies because their stated goal was they didn't want to wind up monetizing onesies and twosies here of individuals playing around with stuff. But then suddenly these large companies get told, so you know those 5,000 developers you have doing all kinds of stuff throughout the company. Here's a bill. Looks like a telephone number, but it's not. Pay it now.

And it turns out that that is not a super compelling sales pitch. I know, having tried it myself once or twice. Yeah. And I mean, we see different ways of open source projects also trying to make sure that they can afford continuing spending time on the projects. And sometimes that's in the form of donations or applying for any of those FUZ funds that are out there. But then also some of the, that takes a lot of time, right? Like it's almost like fundraising and fundraising is an entire job. And you'll see maintainers being able to spend less time on the project just because they need to make sure that there is a constant stream of money coming in. Because also if you have money coming in the one month and then nothing the next month, that's a problem. And I've spoken to a lot of maintainers who feel like they need to still

continue to write code while they're also trying to make sure that the project is being able to continue in the long run and continues to attract contributors and continues to attract adoption. And it's like all the basic things that a company needs to do as well. And we think it's completely normal that these are roles that people and companies need to fulfill. But then when we see this as an open source project, no, no, no, no, the maintainers need to continue writing code because otherwise they're not maintaining the projects. And it's hurtful. That's not a way for projects to grow. And so, yeah, they try other things. They maybe try supporting end of life versions for a fee or offer bug fixes or extra

features for a fee. Or we've seen a lot of companies try and try all these different methods, right? And there is no silver bullet, but it's important to have the discussion. Yeah, because it's not sustainable to ask people to work for free. I mean, there's also been an evolution that I'm not sure many individual hobbyists really understand that back in the 90s and 2000s, when a lot of us got started with these things, open source was very much something that was done by hobbyists. Now there are very large companies who employ developers to have, as their full-time job, working on open source software. Red Hat is the easiest example to pick

out of the list, but Microsoft, Google, even Amazon has a number of folks whose that is their sole job. That is a very different thing, because on some level, when a company gets into a space of, cool, we're basically going to be doing this giant open source project, like take when Amazon open sourced all of its documentation. It really felt on some level like you're trying to make your users responsible for keeping documentation updated. I'm sorry, I'm not here to volunteer for what was at the time a trillion-dollar company. Now their stock's not doing so well, so oops-a-doozy. But they're still not small enough for me to view them as a scrawny underdog and want to do volunteer work on their behalf. Yeah, I think the response to Microsoft open sourcing.net was very similar.

Like, oh, well, it's the community's problem now. Good luck. Send a postcard if you ever get there. Yeah. So, Ivan, we actually also employ a couple of people that work on the upstream projects that are in our portfolio, like Postgres or OpenSearch. And they work entirely for these projects. They don't have to relay anything to our product team whatsoever.

But it's still an interesting, I say interesting where I should really say challenging, position to be in as a developer working on these upstream projects. Because your timelines are so different from a business timeline, right? Like we work with fiscal years and OKRs and that kind of stuff. How do you set an OKR for submitting to a big project like Postgres? You have absolutely no way of knowing when someone will actually look at your pull request or merge your pull request. So you can't say, oh, so many merged pull requests in this quarter. The maintainers don't work on open source full-time, how to make sure that they continue to pay these people to work on open source, even if it's,

yeah, it's on a different timeline. And it's difficult to explain that to stakeholders. One of the dawning realizations that I think that a number of enterprises have had over the last 10 years has been, well, do we want to use open source software or don't we? Has been met with, that's adorable that you think you're already not in a thousand different places in a thousand different ways. Welcome to reality. know that our developers would never go online and just copy and paste things out of Stack Overflow or grab something off of GitHub. It's really, you found that the only developers in the world who don't know those things exist because as soon as they do, I promise they're doing that. We all do that. That's how this industry works. That was just met by, oh my God, and the company's trying desperately to do the draconian crackdown

thing where any line of code must be originally sourced, et cetera, et cetera. And good luck reinventing those wheels because you're absolutely going to need it. And I think most companies have evolved past that, but it becomes a very uneasy balance. I always find corporate attorneys break out in sweats when you start talking to them about it in any real depth. Yeah, or when you start talking about ASPOM and why you should have a software bill of materials or supply open source supply chain security stuff, I had a really interesting conversation. And that's again, talking to the almost being me being in a, definitely being in a filter bubble where I'm just like, oh, well, everybody understands this, but there was, um,

there was an event and there were some, some open spaces, and I suggested a discussion around DevSecOps being a band-aid on a bullet wound. Because while we should certainly check our code bases for vulnerabilities, we should also figure out where those vulnerabilities come from in the first place. And I was talking about license changes and maintainer drain and dependency management and all that kind of stuff. And then suddenly one of the people in the room says, changes and maintainer drain and dependency management and all that kind of stuff. And then suddenly one of the people in the room says, well, but then we could just have a mirror of all the components that we're using in our code base. And I was like, but no, now you're a maintainer of all of these code bases. And also it's not like pinning those components at a certain release, make sure that there's no vulnerabilities creeping in.

Sometimes we discover vulnerabilities after they've been in components for years. Sometimes we discover vulnerabilities when reading that morning's edition of the New York Times. I mean, oh, oopsie-doozie, did I do that? That was fun. Yeah. Log4J, I'd never seen an invoice for that. We must not be using it anywhere. Exactly. So for me, it's like baffling whenever I get a response like that. It's almost like

they're not aware of everything, of all the components that they're using, all the libraries that they're using, and that that's a thing that they should monitor and track. And you can't automate that. Developers love automation. Why aren't I like, I don't understand. Why did they leave this to sort of the wild, wild west and we'll figure it out if something comes along and breaks our stuff. It's just something that I can't wrap my head around.

I really want to thank you for taking so much time out of your day to talk to me about what you're up to. If people want to learn more, where's the best place for them to find you? They should probably go to my website, which is floor.dev. Floor is spelled F-L-O-O-R, like the floor, because in the Netherlands, we don't think about names that are international. And you'll find links to my Mastodon Twitter, dev.to, where I write stuff. I try and write a lot of event write-ups,

which is a lost art, I feel like, the last couple of years, because I enjoy explaining to other people what I've just learned. And we will, of course, put links to that in the show notes. Thank you so much for your time. I appreciate it. Thank you. Floor Dries. I appreciate it. Thank you. Floor Dries, Staff Developer Advocate at Ivan. I'm cloud economist Corey Quinn,

and this is Screaming in the Cloud. If you 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 in your podcast platform of choice, along with an angry comment that you will no doubt turn into an odious, badly positioned conference talk. 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.