Deftly Building for the Customer with Eric Dynowski

About Eric
Eric Dynowski, Managing Partner and Chief Solutions Officer at Deft, has been developing software, designing global infrastructures, and managing large technology installations for over 20 years. His background in complex infrastructure design and integration has helped him reduce customer budgets by millions.

Announcer: Hello, and welcome to Screaming in the Cloud with your host, Chief Cloud Economist at The Duckbill Group, Corey Quinn. This weekly show features conversations with people doing interesting work in the world of cloud, thoughtful commentary on the state of the technical world, and ridiculous titles for which Corey refuses to apologize. This is Screaming in the Cloud.

Corey: You could build you go ahead and build your own coding and mapping notification system, but it takes time, and it sucks! Alternately, consider Courier, who is sponsoring this episode. They make it easy. You can call a single send API for all of your notifications and channels. You can control the complexity around routing, retries, and deliverability and simplify your notification sequences with automation rules. Visit courier.com today and get started for free. If you wind up talking to them, tell them I sent you and watch them wince—because everyone does when you bring up my name. Thats the glorious part of being me. Once again, you could build your own notification system but why on god’s flat earth would you do that?


Corey: This episode is sponsored in part by Thinkst. This is going to take a minute to explain, so bear with me. I linked against an early version of their tool, canarytokens.org in the very early days of my newsletter, and what it does is relatively simple and straightforward. It winds up embedding credentials, files, that sort of thing in various parts of your environment, wherever you want to; it gives you fake AWS API credentials, for example. And the only thing that these things do is alert you whenever someone attempts to use those things. It’s an awesome approach. I’ve used something similar for years. Check them out. But wait, there’s more. They also have an enterprise option that you should be very much aware of canary.tools. You can take a look at this, but what it does is it provides an enterprise approach to drive these things throughout your entire environment. You can get a physical device that hangs out on your network and impersonates whatever you want to. When it gets Nmap scanned, or someone attempts to log into it, or access files on it, you get instant alerts. It’s awesome. If you don’t do something like this, you’re likely to find out that you’ve gotten breached, the hard way. Take a look at this. It’s one of those few things that I look at and say, “Wow, that is an amazing idea. I love it.” That’s canarytokens.org and canary.tools. The first one is free. The second one is enterprise-y. Take a look. I’m a big fan of this. More from them in the coming weeks.


Corey: Welcome to Screaming in the Cloud. I’m Corey Quinn. For a while I’ve been talking about how I started The Duckbill Group as a highly niche, highly focused consultancy aimed at one very expensive problem—the AWS bill—and that’s all we do. We don’t do implementation; we simply do the thing that it says on the tin. And it turns out that you can get fairly good at the problem like that in not a tremendous amount of time.

And today’s promoted episode of Screaming in the Cloud. My guest is Eric Dynowski, Chief Solutions Officer and Partner at Deft, which is a consulting company that is almost inverted, in the sense that they do an awful lot of stuff. And we’re going to argue about it now. Eric, thank you for taking the time to speak with me today.

Eric: Great to be here, Corey. Can’t wait to dig in. [laugh].

Corey: So, when I started this place back almost five years ago now, I was coming out of an engineering career that I found deeply unsatisfying. I had a bunch of working with computers skill sets, and I wanted to apply them to something that I could use as an independent consultant—because who would ever build a team or a company out of this?—that I could wind up doing repeatedly, so I could, you know, make money, not have a boss, and ideally work less than 80 hours a week. And fixing the AWS bill was the first one I tried; it turned out that, yeah, there is, in fact, an awful lot of expensive business problem hidden in there. And that’s what I’ve been focusing on ever since. I get the distinct impression that your story doesn’t quite sound like that one.

Eric: Well, it’s a little bit like that one, in the sense that I was once an engineer and a technician doing things, and had the crazy idea to go off and start a company that consulted and helped people with their technology needs. And maybe we’re a little bit alike in the sense that we also have a very singular focused offering—I’m going to tease you a little bit here, Corey—is that we do one thing: we provide technology solutions for our customers. But probably what you are getting at is, “Well, that’s a really broad statement, Eric, what is a technology solution?”

Corey: It is. And the reason I did this is because my marketing budget was 50 bucks. So, I wanted something that the Rolodex effect is what I was after, where when someone says at a party to someone else, “Well, I have a problem: my AWS bill.” I want the answer to be, “Hey, I have someone for you to talk to.” You don’t generally tend to see that with more broad statements around positioning most of the time.

Eric: Sure. Sure.

Corey: I also felt like if I was going to be, all right, I’m the best cloud architect advisor ever. Great, now I’m competing against folks like you and the giant consultancies that are in every country. And honestly, those folks have better airport ads than I’m going to be able to put up, at least at the time. Now, I have a platypus for a mascot. So, one wonders whether that would still hold true. You took a very different approach and have done fantastically—

Eric: Yeah.

Corey: —well with it.

Eric: Yeah, I mean, maybe a little bit of history here is helpful. When I started my company, which was Turing Group back in 2013, we did actually focus pretty tightly just on AWS, and that’s all we did. We wanted to help customers get in AWS, fix their problems in AWS, scale in AWS, manage their costs, all these sorts of things. And along the way, we had customers coming back to us saying, “We love you guys. You’re doing great in [laugh] AWS, but I have other needs too.”

And I started saying, “Well, I know a guy over there that does that.” And, “I’ve got a good friend over here at this company that does it.” And, you know, we’re referring back and forth. And kind of parallel to that, one of my business partners who is running a company called Server Central was having the exact inverse problem. And, you know, they were providing managed services within the data center, managed networking capability, things of that nature, you know, helping customers build out an infrastructure to operate at scale, where it’s like, “Oh, we need 1000 servers, and we need them really inexpensive, and we have to be able to manage them at scale.”

And they were crushing it, doing a great job except his customer start getting back to him saying, “Love what you guys are doing. We’re also using AWS, and we want some help with that.” And so, he would pick up the phone and call me and say, “Eric, can you guys help here?” And in some sense, we were competitors. I wanted to move everybody out of the data center into the cloud.

And he wanted to move everyone out of the cloud back into the data center or keep them in the data center. And it was like, “Okay, this is weird, but we both have the same problem.” And so we went out to lunch and started this conversation of like, “Well, what if we weren’t competitors?” [laugh].

Corey: “Maybe there’s alignment here.” Yeah. I think Ben Franklin once said that three moves is as good as a fire when it comes to cleaning out old cruft. And migrations are like that. I do want to call out that since I make a frequent practice of saying that multi-cloud as a best practice is foolish, I want to be clear that is in the absence of other constraints.

If you’re building something new, you probably should pick a provider and go all-in. I don’t care which one you do—you might; I don’t—but beyond that, at a significant point of scale, when a company says, “All right, we’re in one provider—or a data center—and we’re going to move to a cloud or other clouds.” Generally, they’re correct. They have context that I don’t when I’m speaking in the general case. I am not anti-multi-cloud; I am anti-multi-cloud when it is foolish and when it’s badly done. Just to set my bias out there and, ideally, avoid getting some letters.

Eric: You know, I tend not to disagree with that in the right context as well. When we were doing just AWS only, I think I would have argued that multi-cloud, yeah, there’s no place for it. If you’re going multi-cloud, you’re giving up on all of the greatness that a single public cloud has to offer. You know, and by the greatness, I mean, the proprietary services they offer, and the APIs, and things like SNS and SQS and Route 53, all of those things that you could build into your application and just start using them without having to build all the infrastructure to run it. And so I would agree with you, I think, in that sense.

But I wish the world were that simple and I wish the companies that we worked with operated in a nice, clean, unambiguous context. But the more you dig in, I think you realize that when you start dealing with a company, maybe, that has 20,000 employees and offices all across the country, and 25 years of legacy applications—or maybe a vision for the future that just is so massive that it requires a different point of view—and this is really where we engage. And it’s interesting that you mentioned about the context, and usually, if a customer approaches us and says, “We want to go multi-cloud,” the first thing we do is put the brakes on and get away from the discussion around multi-cloud and move straight into, “What are you trying to accomplish here?” And navigate that conversation before it turns into—you know, let’s not start with the solution type of discussion.

Corey: Part of the problem, it seems, that when you start talking to folks about these things, especially in some vendor corners, an awful lot of self-interest that winds up informing the answers that immediately come from it, where it’s, “Oh, yeah, you want to go multi-cloud.” And you scratch underneath the surface and the reason is that if you go all-in on one provider, they have nothing left to sell you, in some cases. Other times, it’s by a cloud provider themselves pushing multi-cloud strongly because they know that if you go all-in on one provider, it will absolutely not be them. So, the hard part is finding someone who can serve as a trusted advisor. And I mean that in the actual sense of a person, not the crappy AWS service that tells you everything’s fine when it isn’t. That’s ‘Plausible Advisor’ at best. Let’s be clear here.

Eric: Well, come on. If it wasn’t for Trusted Advisor, we wouldn’t have a market for all the third-party analysis tools [laugh] and people like you to help us manage our costs.

Corey: Believe me, if I thought a tool could solve the problem, I would have built it years ago. Tried, turned out it didn’t, and well, here we are. You position what you do at Deft as starting from an advisory perspective. You’re not pushing a particular product, you’re not pushing any particular vendors that I’m aware of, you have a partner list that is not a single vendor, what a concept. So, it’s clear that you’re doing something that goes one of two ways.

Either it is, yeah, we’ll take money from anyone who will pay us, or alternately you’re approaching it from a thoughtful perspective of trying to figure out what’s going on with the customer. Based upon our conversations, I’m going to go ahead and guess it’s that one.

Eric: It definitely is the latter, Corey. We’ve certainly had many customers approach us over the years and ask for things that are a bad fit. And a bad fit might be, they’re asking for technology experience we don’t have. If someone came to us and said, “We want you guys to be Oracle DBAs because you do technology,” our answer is very likely going to be no. Could we learn to be Oracle DBAs? Yeah, we probably could. Do we want to probably not? Maybe?

Corey: There are some very qualified Oracle DBAs out in the world, and it’s—

Eric: There’s—

Corey: —great.

Eric: —there’s places for people to specialize. And I think one of our virtues is to know and recognize where we belong and where we don’t belong. And the good thing is, not only have we sort of built up our own partner list in terms of technology partners, strategic partners, but we also have our own internal list of referral partners where we know that something’s out of our wheelhouse, and I got another company and another team here that I know can crush it and help them out. There’s other areas of work that we just don’t get into. If you want to outsource your IT and have a company that’s going to help you figure out why your printer is not working, definitely not us.

You’re going to be wasting your money with a firm like us. Or maybe you want to partner in a way that isn’t going to take the best advantage of the capabilities that we have, meaning you just want to take advantage of us in a halfway manner, and you want to keep an internal team and the two teams are up against one another and fighting about stuff constantly. We need to have good strong trust between our two companies and our partnerships. And so if we feel like there isn’t an opportunity for that, we might walk away from it as well.

So, it’s not a case of everything that walks in front of us, here’s a proposal. [laugh]. We definitely do some opportunity vetting and analysis. We ask a lot of questions upfront about how our customers work, what their internal teams are like, what their expectations of us are, what they want in that relationship. Is it transactional or is it strategic? We’re interested in the strategic partnerships with our customers.

Corey: I think this is something that is not well understood by a lot of the fly-by-night folks, for lack of a better term. I don’t mean to sound disparaging, but the folks who don’t seem to understand that long-term reputation is important. I mean, both of our consulting companies, although radically different in focus, have pages on our site where we list reference customers. In fact, there’s some overlap between our customers. And as we look at this, you aren’t allowed to put a customer logo up if they’re going to take umbrage to you doing it, first off. And secondly, you don’t want to put a customer logo up if people are going to ask them about their experience with you, and the response is, “Oh, they were crap.” At some point, no, let’s not do that.

Eric: [laugh]. That’s right.

Corey: The only way to get there is to deliver on an engagement in such a way that the response is, “That was great. Would you do it again?” “Can I?” And the idea of excitement of delivering an outcome where people who you’ve worked with become some of your biggest advocates, that’s how I always viewed the proper way of building a business.

Eric: Yeah. Now, I’d ask you, in terms of when you guys are providing advice to your customers about AWS spend, or someone approaches you, obviously, you’re probably first thinking, “Okay, well, how much AWS spend do you have in a month and is this worth my time?” But there’s probably another element of evaluation that you must do in terms of is this a good customer for us, and can we do the right thing for them? What are pieces that you guys think about?

Corey: Oh, absolutely. As a general rule, we do a lot of AWS contract negotiation. And that is, if you have an AWS offer in front of you for committing to something, come talk to us; it’s fun. That’s half of our engagements today. The other half are cost optimization projects, and generally speaking, we aren’t going to be able to effectively deliver return on investment for much less than about a million bucks a month in spend.

So, I do at some point want to explore how to help people who are not already paying a king’s ransom to AWS every month, but that is down the road. The next step is a conversation. It’s a, “So great, you want to optimize your AWS bill.” And then my favorite is the—I get the quote-unquote, “Dumb question.” “Why? Why do you care? Why is this an actual problem other than it looks like a phone number and your CFO has some questions, what is the actual concern?”

Very often, we’ll find that it’s not that you’re spending too much on cloud, in many cases, it’s that it’s not understood what it’s doing. “Okay, the bill is 20% higher this month. Is that new normal? Is that something that’s going to inform our planning and we do adjust our expectations for what this is going to cost to run this? Is it just a mistake that someone left up?” The same questions would have arisen if the bill were 20% lower, except somehow it never is.

Eric: Right, right. You know what’s interesting about that, Corey is, too, also I think that you tend to tease AWS from time to time. And also I think the work you do would not be in Amazon’s interest, right? They want customers to spend more money on their infrastructure and their services and their capabilities, and you’re helping customers spend less. But what’s interesting about that is that we’re one of the few managed service partners in the country.

And I don’t know how much you know about that program, and what it takes to get into that program and to maintain the certification in that program. It’s like a three-day audit; there’s 500 control items that we have to go through. In fact, it was that program that took our business to the next level. It was that program and its rigor that took what we were doing and actually matured it and turned it into what I would consider a respectable world-class operation. But one of the interesting aspects of that audit is that there’s several control items in there that ask us to show Amazon that we are taking steps to manage our customers’ costs on AWS and reduce spend. And it’s interesting that Amazon is the one pushing that on us and instilling that requirement as we support our customers in Amazon.

Corey: It’s counterintuitive, but this is one of those areas where there’s no one on the other side of this issue. Of course, Amazon wants customers to spend more money with Amazon—I swear the company spends half its time lying awake at night worrying someone who isn’t them is making money somewhere, at least that’s how it feels some days. But they want that spend to be intelligent. They don’t want the narrative to be that the cloud is just as expensive a bunch of nonsense. If there’s a bunch of instances that are sitting there idle, they will advise you—if they’re on top of the game—to turn them off because that is the goal. They want it to be—

Eric: That’s how they deliver on their promise. Right.

Corey: Well, yeah. Pandemic aside, with most of our customers, what we notice a year after an engagement is that they’re in fact spending more than they were when we started. But it’s more efficient; it’s growth that’s tying into this. It becomes a component of cost of goods sold where, “Yeah, we’re doing more business, so it costs us more to fulfill that business; we’re perfectly happy,” is generally the response to that. And I think that everyone with a vision that extends beyond this quarter’s numbers is likely to start to get into that, on some level.

Eric: Right.

Corey: One thing I do want to ask you is—relevant to what you just said—one thing that we do at The Duckbill Group explicitly is we have no partners, full stop. And the reason behind that is because with what we’re doing around billing, and money, and contract negotiation, and the rest, as soon as we have a partner, it suddenly gives rise to a bunch of real or perceived conflicts of interest. And in this particular niche, it makes an awful lot of sense not to do that. Now, if you’re in any other arena, where you’re in—“Oh, you’re in security, for example. Oh, we have no partners with any vendors,” the answer question becomes, “Well, what’s wrong with you? What, there’s no one willing to trust you? Do you think somehow you’re better than all these other people?” It’s the wrong answer. So, my question for you is, how do you evaluate whether you should partner with a particular company or not?

Eric: Sure. Great question. Deft’s reason for existence—when we think about ourselves, we reframe it as our purpose—is to deliver on the promise of technology. And if you unpack that statement a little bit is like, “Well, what the heck is the promise of technology? What does that even mean?”

And what we get down to is that technology itself doesn’t make any kind of promises. That router you just bought, it doesn’t promise really anything; that EC2 instance you just booted in AWS doesn’t really ultimately, at the end of the day, promise anything. It’s incapable of making promises, but people are. And what we promise is that we can wrangle that technology, we can configure it, we can set it up in a particular kind of way, we can bring in the right components into the solution, and deliver on a promise of, “Yes, you can scale to 100 million users,” or, “Yes, you can reduce latency and improve the customer experience for your customers.” It’s all about the people, and that’s what we have the most of.

And that’s the best thing that we have in our house.s we have an inventory of highly qualified, talented, empathetic, compassionate, excited people. So, when we start thinking about our partners and who we want to partner with, what we take into consideration is what technology, tools, and capabilities do our people need to have in their toolbox, such that when we start working with our customers crafting that promise and that solution, we’ve got the right things at hand and at the right time. And then the second piece of it is, does the partner align well with us in terms of our vision? And in some sense, keeping us relatively technology-neutral, in the same sense that you’re trying to stay neutral from that billing perspective and making sure that you’re looking out and advocating for your customers first.

So, when we’re thinking about our partners as well, it’s not that, oh, well, we want to build our whole business on top of AWS, or Azure, or in our data center. And those are the on—you know, we try to remove dogma from the picture in that sense, and try to probably be dogmatic mostly about the customer and what it is that they’re trying to achieve, and being honest with them. So, it’s more of a, “Hey, let’s scan the horizon. Let’s listen to our customers, let’s understand what problems they’re trying to solve, what challenges they have today. Let’s evaluate the technology options on the table across the world.” Our partner might be [unintelligible 00:18:36], it might be VM, or it might be Amazon, it might be a small little company somewhere that does a niche service. But our job is to come together with all of those things and present a cohesive solution.

Corey: And it’s clearly working. You were the Turing Group and you wound up partnering with—you said your business partner—who was over at Server Central, which I’m just guessing from the name and assuming I hadn’t paid attention to the industry for a while, sounds like it might not be fully cloud-focused, on some level, given the name. What did they do? And why was merging the right answer?

Eric: Yeah. I mean, it’s funny that you bring that up. Server Central. Wow, a server; who’s talking about servers anymore, right? It’s containers and virtualization and—

Corey: But they’ve got to run somewhere.

Eric: That’s right. Serverless applications. Like, hmm, is this the right name? And I think it speaks to the 20-year heritage that Server Central has had and how they built their business. And they do and did, and we do have a cloud focus that’s not related to the public cloud.

We have a significant number of customers that operate on private clouds that we’ve built for them and manage for them, for various reasons. Some are legit and some maybe not so legit and mostly about how they feel about something. And some of them are technically driven. And after we brought the companies together, we realized that hey, you know what, we have a lot of brand equity and history and Server Central and we have to respect that. Turing Group had its own set of brand equity in the market that we had established and promoted a certain kind of ideology and thinking.

And so for a short period of time, we were a little bit unsure of how are we going to bring this together in any kind of cohesive fashion? And it actually went out into the world for about a year as Server Central Turing Group. And I think my tongue twisted as I said it, [laugh]. It’s a lot of words and it mostly just confuses people and makes them scratch their head. And so we went off on a journey to figure out what our reimagined new company is going to look like with all the combined services and capabilities that we have.

And that’s how we arrived at Deft and the idea that’s how we want to engage with our customers; that’s what we want our solutions to be like; that’s what we want the experience in working with us to be. And we want to remove the friction and anxiety that technology can bring. It reminds me of when I was starting my first company. I spent a lot of time sort of navel-gazing, saying, “What do I like about this, and why am I doing this?” And went back to my early days as an engineer, and at the core of it was a really simple idea and it was the idea that when I helped somebody with a technology problem, they were elated. They thought it was magic. They thought it was black magic.

They didn’t understand how I took this goofy, strange, cryptic thing and made it do what they wanted, and I did it quickly and I did it deftly. And there was joy and they were happy and I loved that; I loved that response. I loved knowing that I helped fix this mysterious problem for somebody that just didn’t even know where to begin. And I did it time and time again and it helped me grow my career. And when we started the first company, it was sort of like, I want to continue that feeling.

I want to create that feeling for our customers where they feel like maybe they’re stuck with some crazy complex technology problem, and because I happen to have the innate skill for understanding these things and figuring these things out and I have a team that can do it, we can create that same feeling for our customers. And we want to continue doing that today.

Corey: This episode is sponsored by our friends at Oracle HeatWave is a new high-performance accelerator for the Oracle MySQL Database Service. Although I insist on calling it “my squirrel.” While MySQL has long been the worlds most popular open source database, shifting from transacting to analytics required way too much overhead and, ya know, work. With HeatWave you can run your OLTP and OLAP, don’t ask me to ever say those acronyms again, workloads directly from your MySQL database and eliminate the time consuming data movement and integration work, while also performing 1100X faster than Amazon Aurora, and 2.5X faster than Amazon Redshift, at a third of the cost. My thanks again to Oracle Cloud for sponsoring this ridiculous nonsense. 

Corey: I do want to point out that, at least in my mind, there’s always a little bit of, I guess, we call it technical elitism, on some level, where, “Oh, someone is working through a partner. They must be a company that’s stuck in the past.” But a glance at companies that you’re working with, make it very clear that’s not the case. I mean, Ars Technica, New Relic, Wildbit. You’ve got some companies that are very forward-looking, and by no definition are these companies that don’t understand cloud or understand how the internet works. It’s something that I think is not fully understood among a subset of the industry that, in many cases, having a third-party partner, in many cases winds up helping you go faster, further.

Eric: Yeah. It might be cliche to say—oftentimes, in cliches, there’s a little bit of truth—which is, focus on what you’re good at, and focus on what you’re best at, and focus on your core products. And with a lot of these technology companies where you might read on the surface that, “Oh, yeah, they’re a smart bunch over there. Why do they need a partner?” Technology is complicated. The stack is deep.

Whether you’re talking about deployment pipelines, or should I use a fiber connection on this or should I use copper? Or should we have jumbo frames enabled? Or should we be using API Gateway and Lambda functions for this? I just listed a broad range of technologies and things that solve different problems. And these customers have their own products that they have to put out into the world; those products need to be meaningful and thoughtful and aligned with their customers.

And because that technology stack is complex and deep, it creates an opportunity for companies like ours—for partners—to step in, and grab a piece of that complexity, and manage it, and handle it, and help a customer with it to create the space for them to create the most excellent product. And so even though they are technology companies because you’re managing this big wrangling layered technologies, abstractions, and—well, even when we talk about containerization, right, and running a small application, there’s seven layers before you get to the CPU. [laugh]. And within that seven layers, there’s I don’t know how many lines of code, and there’s how many hidden assumptions and configuration files, and you name it. And there’s areas of that entire stack that we’re really good at and customers derive value from that.

Corey: One area that you’ve been relatively active within is the hybrid universe. My talking point on that has generally looked a lot like the snarky take of, “Well, you have a company in a data center today, and they’re going to go all-in on the cloud. And it turns out halfway through that it’s hard to move some workloads. There is no AWS/400 and they have a mainframe.” So, what are they going to do? They give up halfway, plant a flag, declare victory, and now we’re hybrid as a best practice. That is not entirely accurate, but there’s an element of accuracy in some cases to it.

Eric: Yeah.

Corey: But I don’t get the sense that’s how you see it. I’m left with a strong impression that it’s a very intentional choice for some of your customers, that in some cases, workloads that are live in data centers, were at one point living in a cloud provider. Talk to me about that.

Eric: Yeah, I like to think of it not as, like, a binary situation. And something that exists on degrees, and often times has a lot to do with the lifecycle of a product or company and the scale of a company. And we touched on this earlier in our conversation, which is that if someone approached us—maybe a startup or a smaller company—trying to migrate off of half-dozen servers and move into the public cloud, and they approached us and said, “Yeah, we need to be hybrid for this thing,” I would probably question that and I would question it really hard, and say, “Really, what are you going after here? You’re going to give up a lot if you choose to go hybrid, and you won’t really take advantage of some of the amazing opportunities that a full-on single cloud solution has to offer.” On the flip side, we’ve seen companies that started like that, were a hundred percent in public cloud on a single provider, everything’s working fine.

There was no issues whatsoever, except the bill, or maybe a fear of what the bill could be. And this is something that happens at scale. There’s just a point where the public cloud just doesn’t make sense anymore, even despite those benefits. And for the bottom line and in terms of the margins and your cost of revenue, giving up some of those additional benefits that allow you to grow and scale is worth it. And if you look at the technology landscape, there’s a reason Facebook’s not in AWS. [laugh].

There’s a reason a lot of these larger technology companies where we have hundreds of millions of users or bazillions of petabytes of data, that move out and get out of there. I mean, look at Dropbox right? [laugh]. Is Dropbox storing all their data in the public cloud? Not really, and they are a public cloud in a sense on their own, right?

Corey: Yeah, they did just launch a 34-petabyte data warehouse for analytics on AWS, and they’ve made a bunch of big—

Eric: Yeah, yeah. I mean—

Corey: —deals out of that, but the core storage workload, yeah, that does not economically make sense, given their access patterns and how they have built that offering. So yeah, that is a very well understood, very specific, very niche workload. Yeah, that does not belong in AWS.

Eric: We’ve even gone as far as launching our own multi-petabyte managed object storage solution, it’s totally S3 compatible. It works identically to the way S3 works, but we have customers that actually can do better on our platform, either because we can provide lower latency, we can provide custom contracts that aren’t just purely pay as you go; there’s all kinds of different options that we can give our customers that are more custom and tailored to their needs that you’re going to get from, “Here’s your API keys have fun.” [laugh]. And so there’s still a market for that stuff and there’s still a need for that stuff.

Corey: There really is.

Eric: So, the answer is it depends, Corey. [laugh].

Corey: It seems to be the answer to any nuanced question. So, if people want to learn more about what you’re doing at Deft, and potentially whether it might help them with some of the challenges they’re facing, where can they find you?

Eric: Easy. deft.com, D-E-F-T dot com. Great, short four-letter domain name that you wouldn’t believe what we had to go through to get. [laugh].

Corey: I can only imagine. Thank you so much for taking the time to speak with me today. I really appreciate it.

Eric: You’re welcome, Corey.

Corey: Eric Dynowski, Chief Solutions Officer and Partner at Deft. 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 hated this podcast, please leave a five-star review on your podcast platform of choice, along with a comment telling me that no, customers should in fact go all-in on your third-rate cloud.

Corey: If your AWS bill keeps rising and your blood pressure is doing the same, then you need The Duckbill Group. We help companies fix their AWS bill by making it smaller and less horrifying. The Duckbill Group works for you, not AWS. We tailor recommendations to your business and we get to the point. Visit duckbillgroup.com to get started.

Announcer: This has been a HumblePod production. Stay humble.