Screaming in the Cloud - Heresy in the Church of Docker Desktop with Scott Johnston

Episode Date: October 26, 2021

About ScottScott first typed ‘docker run’ in 2013 and hasn't looked back. He’s been with Docker since 2014 in a variety of leadership roles and currently serves as CEO. His experience previous to Docker includes Sun Microsystems, Puppet, Netscape, Cisco, and Loudcloud (parent of Opsware). When not fussing with computers he spends time with his three kids fussing with computers.Links:Docker: https://www.docker.comTwitter: https://twitter.com/scottcjohnston

Hello, and welcome to Screaming in the Cloud, with your host, Chief Cloud Economist at the Duckbill Group, Corey Quinn. This weekly show features conversations with people doing interesting work in the world of cloud, thoughtful commentary on the state of the technical world, and ridiculous titles for which Corey refuses to apologize. This is Screaming in the Cloud. This episode is sponsored in part by Liquibase. If you're anything like me, you've screwed up the database part of a deployment so severely that you've been banned from ever touching anything that remotely sounds like SQL at at least three different companies.

We've mostly got code deployment solved for, but when it comes to databases, we basically rely on desperate hope with a rollback plan of keeping our resumes up to date. It doesn't have to be that way. Meet Liquibase. It's both an open source project and a commercial offering. Liquibase lets you track, modify, and automate database schema changes across almost any database, with guardrails that ensure you'll still have a company left after you deploy the change. No matter where your database lives, Liquibase can help you solve your database deployment issues. Check them out today at Liquibase.com. Offer does not apply to Route 53. This episode is sponsored in part by something new. Cloud Academy is a training platform built on two primary goals, having the highest quality content in tech and cloud skills

and building a good community that is rich and full of IT and engineering professionals. You wouldn't think those things go together, but sometimes they do. It's both useful for individuals and large enterprises, but here's what makes this something new. I don't use that term lightly. Cloud Academy invites you to showcase just how good your AWS skills are. For the next four weeks, you'll have a chance to prove yourself. Compete in four unique lab challenges where they'll be awarding more than $2,000 in cash and prizes. I'm not kidding.

First place is $1,000. Pre-register for the first challenge now. One that I picked out myself on Amazon SNS image resizing by visiting cloudacademy.com slash Corey. C-O-R-E-Y. That's cloudacademy.com slash Corey, C-O-R-E-Y. That's cloudacademy.com slash Corey. We're going to have some fun with this one. Welcome to Screaming in the Cloud.

I'm Corey Quinn. Once upon a time, I started my public speaking career as a traveling contract trainer for Puppet. I've talked about this before. And during that time, I encountered someone who worked there as an exec, Scott Johnston, who sat down, talked to me about how I viewed things, and then almost immediately went to go work at Docker instead. Today's promoted episode brings Scott onto the show. Scott, you fled to get away from me, became the CEO of Docker over the past, what is it, seven years now. You're still standing there, and I'm not making fun of

Docker quite the way that I used to. First, thanks for joining me. Great to be here, Corey. Thanks for the invitation. I'm not sure I was fleeing you, but we can recover that one at another time. Oh, absolutely. In that era, one of my first talks that I started giving that anyone really paid any attention to was called Heresy in the Church of Docker, where I listed about 10 to 13 different things that Docker didn't seem to have answers for, like network separation, security, audit logging, et cetera, et cetera. And it was a fun talk that I used to basically learn how to speak publicly without crying before and after the talk. And in time, it wound up aging out as these problems got addressed. But what surprised me at the time was how receptive the Docker community was to the idea of a talk that wound up effectively criticizing something that for, well, a number of them, it felt a lot of the time like it wasn't that far from a religion. It was very hype-driven. Docker, Docker, Docker was a recurring joke. Docker has changed a lot. The burning question that I think I want to start this off with is that it's 2021. What is Docker?

Is it a technology? Is it a company? Is it a religion? Is it a community? What is Docker? Yes. I mean that sincerely. Often the first awareness or the first introduction that newcomers have is in fact the community. Before they get their hands on the product, before they learn that there's a company behind the product, is they have a colleague who is either through a Zoom or sitting next to them in some places or in a coffee shop and says, "'Hey, you gotta try this thing called Docker.'" And they lean over either virtually or physically

and look at the laptop of their friend who's promoting Docker and they see a magical experience. And that is the introduction of so many of our community members having spoken with them and heard their own kind of journeys. And so that leads to like, okay, so why the excitement? Why did the friend lean over to the other friend and introduce? It's because the tools that Docker provides just helps devs get their app built and shipping faster, more securely with choice, without being tied into any particular runtime,

any particular infrastructure. And that combination has proven to be a breakthrough dopamine hit to developers since the very beginning, since 2013, when Docker was open sourced. It feels like originally the breakthrough of Docker, that people will say, oh, containers aren't new. We've had that going back to LPARs on mainframes. Yes, I'm aware. But suddenly, it became easy to work with and didn't take tremendous effort to

get unified environments. It was cynically observed at the time by lots of folks smarter than I am that the big breakthrough Docker had was how to make my MacBook look a lot more like a Linux server in production. And we talk about breaking down silos between ops and dev, but in many ways, this just meant that the silo became increasingly irrelevant because works on my machine was no longer a problem of, well, you better back up your email because your laptop's about to go to production in that case. Containers made it easier. And that was a big deal. It seems on some level, like there was a foray where Docker, the company was moving into the world of, okay, now we're going to run a lot of these containers in production for you, et cetera. It really feels like recently the company

as a whole and the strategy has turned towards getting back to its roots of solving developer problems and positioning itself as a developer tool. Is that a fair characterization? 100%. And that's very intentional as well. We certainly had good products and great customers and we're solving problems for customers on the upside, I'll call it. But when we stood back, this is around 2019, and said, where's the real joy, for lack of a better word? Where's the real joy from a community standpoint, from a product experience standpoint, from a what do we do different and better and more capable than anyone else in the ecosystem? It was that developer experience. And so the reset that you're referring to in November 2019 was to give us the freedom to go back and just focus the entire company's efforts on of the time of this recording, you announced a somewhat, well, let's say controversial change in how the pricing and licensing worked. free for folks to use for individual use, and that's fine. And for corporate use, Docker Desktop also remains free until you are a large company, defined by $10 million in revenue a year,

and or 250 employees or more. And that was interesting. I don't think I'd seen that type of requirement placed before on what was largely an open-source project. It is now a developer tool. I believe there are closed source aspects of it as well for the desktop experience, but please don't quote me on that. I'm not here to play internet lawyer engineer. But at that point, the internet was predictably upset about this because it is easy to yell about any change that is coming regardless. I was less interested in that than I am in what the reception

has been from your corporate customers. Because let's be clear, users are important. Community is important, but goodwill will not put food on the table past a certain point. There has to be a way to make a company sustainable. There has to be a recurring revenue model. I realize that you know this, but I'm sure there are people listening to this who are working in development somewhere who are, wait, you mean I need to add more value than I cost? It was a hard revelation for me back when I had been in the industry a few years.

Sure. And I'm still struggling with that some days. Sure, you and me both. Yeah. So what has the reaction been from folks who have better channels of communicating with you folks than angry Twitter threads? Yeah, great surface area for discussion, Corey. Let's back up and talk on a couple points that you hit along the way there. One is, what is Docker Desktop? Docker Desktop is not just

Docker Engine, right? Docker Desktop is a way in which we take Docker Engine, Compose, Kubernetes, all important tools for developers building modern apps, Docker Build, so on and so forth. And we provide an integrated engineered product that is engineered for the native environments of Mac and Windows and soon Linux. And so we make it super easy to get the container runtime, Kubernetes stack, the networking, the CLI, Compose. We make it super easy just to get that up and running and configured with smart defaults,

secured, hardened, and importantly, updated. So any vulnerabilities, patch, and so on and so forth. The point is, it's a product that is based on, to your comments, upstream open source technologies, but it is an engineered commercial product. Docker Desktop is. Docker Desktop is a fantastic tool. I use it myself. I could make

a bunch of snide comments that on Mac, it's basically there to make sure the fans are still working on the laptop. But again, computers are hard. I get that. It's incredibly handy to have a graphical control panel. It turns out that I don't pretend to understand those people, but some folks apparently believe that there are better user interfaces than text in an 80-character-wide terminal window. I don't pretend to get those people, but not everyone has the joy of being a Linux admin for far too long. So I get it. Making it more accessible, making it easier, is absolutely worth using. That's right. It's not a hard requirement to run it on a laptop-style environment or a developer workstation, but it makes it really convenient. Before Docker Desktop, one had to install a hypervisor,

install a Linux VM, install a Docker engine on that Linux VM, bridge between the VM and the local CLI on the native desktop. Like, lots of setup and maintenance and tricky stuff that can go wrong. Trust me, how many times I stubbed my own toes on putting that together. And so Docker Desktop is designed to take all of that setup nonsense overhead away and just let the developer focus on the app. That's what the product is and just talking about where it came from and how it uses these other upstream technologies. Yes, and so we made a move on August 31st, as you noted, and the motivation was the following. One is we started seeing large organizations

using Docker Desktop at scale. When I say at scale, not one or two or 10 developers, like hundreds and thousands of developers. And they were clamoring for capabilities to help them manage those developer environments at scale. Second is we saw them getting a lot of benefit in terms of productivity and choice and security from using Docker Desktop. And so we stood back and said, look, for us to scale

our business, we're at 10 plus million monthly active developers today. We know there's 45 million developers coming in this decade. How do we keep scaling while giving a free experience, but still making sure we can fund our engineers and deliver features and additional value, we looked at other projects. Corey, the first thing we did is we looked outside our four walls and said, how have other projects with free and open source components navigated these waters? 50 employees and the 10 million revenue were actually thresholds that we saw others put in place to draw lines between what is available completely for free and what is available for those users that now need to purchase a subscription if they're using it to create value for their organizations. And we're very explicit about that. You could be using Docker for training. You could be using Docker for eval in those large organizations, we're not going to chase you or be looking

to you to step up to a subscription. However, if you're using Docker Desktop in those environments to build applications that run your business or that are creating value for your customers, then purchasing a subscription is a way for us to continue to invest in a product that the ecosystem clearly loves and is getting a lot of value out of. And so that was, again, the premise of this change. So now to the root of your question is like, so what's the reaction? We're very, very pleased. First off, yes, there were some angry voices out there. Yeah. And I want to be clear, I'm not trivializing people who feel upset. Not at all.

When you're suddenly using a thing that is free and discovering that, well, now you have to pay money for it. People are not generally going to be happy about that. When people view themselves as part of the community of contributing to what they saw as a technical revolution or a scrappy underdog, and suddenly they find themselves not being included in some way, shape, or form, it's natural to be upset. I don't want to trivialize people's warm feelings toward Docker.

It was a big part of a lot of folks' personality, for better or worse, for a few years in there. But the company needs to be sustainable. So what I'm really interested in is, what has that reaction been from folks who are, for better or worse, yes, yes, we love Docker, but I don't get to sign $100,000 deals because I just really like the company I'm paying the money to. There has to be business value attached to that. That's right. That's right. And to your point, we're not trivializing either the reaction by the community. It was encouraging to see many community members got right away what we're doing. They saw that still a majority of them can continue using Docker for free under the Docker personal subscription. And that was also intentional.

And you saw on the internet, on Twitter and other social media, you saw them come and support the company's moves. And despite some angry voices in there, there was overwhelmingly positive. So to your question, though, since August 31st, we've been overwhelmed, actually, by the positive response from businesses that use Docker Desktop to build applications and run their businesses. And when I say overwhelmed, we were tracking because Docker Desktop has a phone home capability. We had a rough idea of what the baseline usage of Docker Desktops were out there. Well, it turns out, in some cases, there are 10 times as many Docker Desktops inside organizations,

and the average seems to be settling in around three times or four times as many. And we are already closing business, Corey. In 12 business days, we have companies come through, say, yes, our developers use this product. Yes, it's a valuable product. We're happy to talk to a salesperson and give you over to procurement. And here we go. So you and I have both been around long enough to know like 12 working days to have a signed agreement with an enterprise agreement is unheard of. Let's be very clear here on the Duckbill Group side of things, where I do consulting projects. I sell projects to companies that are great. This project will take, I don't know, four to six weeks, whatever it happens to be. And yeah, you're going to turn a profit on this project in about the first four hours of the engagement. It is basically push button and you will receive

more money in your budget than you had when you started. And that is probably the easiest possible enterprise sale. And it still takes 60 to 90 days most of the time to close deals. That's right. Trying to get a procurement deal for software through enterprise procurement processes is one of those things when people say, okay, we're going to have a signature in Q3, you have to clarify what year they're talking about. So 12 days is unheard of. Yep. So we've been very encouraged by that. And I'll just give you rough numbers. Like the overall response is 10 times our baseline expectations, which is why maybe unanticipated question, or you're going to ask it soon, we came back within two weeks because we could see this curve hit right away on the 31st of August. We came back and said, great, now that we have the confidence that the community and businesses are willing to support us and invest in our sustainability, invest in the sustainable, scalable Docker, we came and we accelerated, pulled forward items in our roadmap for developers

using Docker Desktop, both for Docker Personal for free in the community, as well as the subscribers. So things like Docker Desktop for Linux, right? Docker Desktop for Mac, Docker Desktop for Windows, been out there about five years. As I said, we have heard Docker Desktop for Linux rise in demand over those years because if you're managing a large number of developers, you want a consistent environment across all those developers, whether they're using Linux, Mac, or Windows desktops.

So Docker Desktop for Linux will give them that consistency across their entire development environment. That was the number two most requested feature on our public roadmap in the last year. And again, with the positive response, we're now able to confidently invest in that. We're hiring more engineers than planned. We're pulling that forward in the roadmap to show that, yes, we are about growing and growing sustainably. And now that the environment don't like, it's uncertainty because uncertainty equates to risk in their mind. And a lot of other software out there,

and yes, Oracle databases, I am looking at you, have a historical track record of, okay, great, we have audit rights to inspect your environment. And then when we wind up coming in, we always find that there have been licensing shortfalls because people don't know how far things spread internally, as well as, honestly, accounting for this stuff in large, complex organizations is a difficult thing. And then there are massive fines at stake, and then there's this whole debate back and forth.

Companies view contracts as if every company behaved like that when it comes down to per seat licensing and the rest. My fear was that that risk avoidance in large companies would have potentially made installing Docker Desktop in their environment suddenly a non-starter across the board, almost to the point of being something that you would discipline employees for, which is not great. And it seems from your response that that has not been a widespread reaction. Yes, of course, there's always going to be some weird company somewhere that does draconian things that we don't see. But the fact that you're not sitting here telling me that you've been taking a beating from this from your enterprise buyers tells me

you're onto something. I think that's right, Corey. And as you might expect, the folks that don't reach out are silent. And so we don't see folks who don't reach out to us, but because so many have reached out to us so positively and basically quickly gone right to a conversation with procurement versus any sort of back and forth or questions and such tells us we are on the right track. The other thing, just to be really clear, is we did work on this before the August 31st announcement as well. This being, how do we approach licensing and compliance and such. And we found that 80% of organizations, 80% of businesses want to be in compliance. They not just want to be in compliance, but they have a history of being in compliance, regardless of the enforcement mechanism and whatnot.

And so that gave us confidence to say, hey, we're going to trust our users. We're going to say grace period ends on January 31st, but we're not shutting down functionality. We're not sending in legal activity. We're not putting any sort of strictures on the product functionality because we have found most people love the product, love what it does for them, and want to see the company continue to innovate and deliver great features. And so, okay, you might say like, well, isn't that 20% represent opportunity? Like, yeah, you know, it does, but it's a big ecosystem. The 80% is giving us a great boost. And we're already starting to plow that into new investment. And let's just start there, right? Let's start there

and grow from there. 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 also have a hard time imagining that you and your leadership team would be short-sighted enough to say, okay, that even 20% of companies that are willing to act dishonestly around stuff like that seems awfully high to me. But assuming it's accurate, would tracking down that missing 20% be worth setting fire to the tremendous amount of goodwill that Docker still very much enjoys? I have a hard time picturing any analysis where that's even a question other than something you set up to make fun of. No, that's exactly right, Corey. It wouldn't be worth it, which it which is why again we came out of the gate with like we're going to trust our users they love the community they love the product they want to support us most of them want to support us and you know when you have most you're never going to get

100 so we got most and we're off to a good start by all accounts and look a lot of folks too sometimes will be right in that gray middle where you let them know that they're getting away with something. They're like, all right, you caught me. We've seen that behavior before. And so we can see all these activity out there and we can see if folks have a license or compliance or not. And sometimes just a little tap on the shoulder said, hey, did you know that? You might be paying for that. We've seen most folks at the time say, ah, okay, you caught me. Happy to talk to procurement. So this does not have to be heavy-handed. As you said, it does not have to put at risk the goodwill, the 80%. And we don't have to get 100% to have a great, successful business and continuing successful community. Yeah. I'll also point out that by my reading of your terms and conditions

and how you've specified this, I mean, this is not something I've asked you about. So this could turn into a really awkward conversation, but I'm going to roll with it anyway. It explicitly states that it is and will remain free for personal development. That is correct. When you're looking at employees who work at giant companies and have sloppy, bring your own device controls around these things. All right. They have it installed on their work machine because in their spare time, they're building an app somewhere. They're not going to get a nasty gram and they're not exposing their company to liability by doing that.

That is exactly correct. And moreover, just keep looking at those use cases, right? If the company is using it for internal training, right? Or if the company is using it to evaluate someone else's technology, someone else's software, all of those cases are outside the pay for subscription. And so we believe it's quite generous and allowing of trials and tests and use cases that make it accessible and easy to try, easy to use. And it's just in the case where if you're a large organization and your developers are using it to build applications for your business and for your customers, thus you're getting a lot of value using the product. We're asking you to share that value with us so we can continue to invest in the product. And I think that's a reasonable expectation. The challenge that Docker seems to have had for a while has been that the interesting breakthrough revelatory stuff that you folks did

was all open source. It was a technology that was incredibly inspired in a bunch of different ways. I am, I guess, mature enough to admit that my take that, oh, Docker is terrible, which was never actually my take, was a little short-sighted and very good at getting things wrong across the board. And that is no exception. I also said virtualization was a flash in the pan, and look how that worked out. I was very anti-cloud, et cetera, et cetera. Times change, people change, and doubling down on being wrong gains you nothing. But the question that was always afterwards, what is the monetization strategy? Because it's not something you can give away for free and make it up in volume. Even VC money doesn't quite work like that forever.

So there's a, the question is what is the monetization strategy that doesn't leave people either resenting you because remember that thing that used to be free isn't anymore. Doesn't it suck to be you and is still accessible as broadly as you are given the sheer breadth and diversity of your community. Like I can make bones about the fact that 10 million in revenue and 250 employees are either worlds apart or the wrong numbers or whatever it is, but it's not going to be some student somewhere sitting someplace where their ramen budget is at risk because they have to spend $5 a month or whatever it is to have this thing. It doesn't apply to them. And this feels like unorthodox, though it certainly is, it's not something to be upset about in any meaningful sense. The people that I think would actually be upset and have

standing to be upset about this are the enterprise buyers. And you're hearing from them in what is certainly, because I will hear it if not, that this is something they're happy about. They are thrilled to work with you going forward. And I think it makes sense. Even when I was doing stuff as an independent consultant before I formalized the creation of the Duckbill Group and started hiring people, my policy was always to not use the free tier of things, even if I fit into them, because I would much rather personally be

a paying customer, which elevates the, I guess, how well my complaints are received. Because if I'm a free user, I'm just another voice on Twitter. I'll be at a loud one and incredibly sarcastic one at times. But if I'm a paying customer, suddenly the entire tenor of that conversation changes. And I think there's value to that. I've always had the philosophy of you pay for the things you use to make money. And that, again, that is something that's easy for me to say now. Back when I was in crippling debt in my 20s, I assure you it was not, but I still made the effort for things that I use to make a living. Yeah.

And I think that philosophy is directionally correct. No, I appreciate that, Corey. There's a lot of good threads in there. Maybe just going way back, Docker stands on the shoulders of giants, right? There was a lot of work with container tech in the Linux kernel. You and I were talking before about it goes back to LPAR on IBMs and, you know, BSD Jails and Chirrut's on Linux. You know, Chirrut, right? I mean, Bill Joy putting Chirrut in. And Tupperware parties, I'm sure. Yeah. Right. And all credit to Solomon Hayek, Docker's founder, who took a lot of good up-and-coming tech, largely on the op side, but in Linux kernel, took the primitives from Git and combined that with a mutable

copy-on-write file system and put those three together into a really magical combination that simplified all this complexity of dependency management and portability of images across different systems. And so in some sense, that was the magic of standing on the giant shoulders, but seeing how these three different waves of innovation or three different flows of innovation could come together into a great user experience. So also then moving forward, I wouldn't say they're happy, just to make sure you don't get inbound angry emails, the enterprise buyers, but they do recognize the value of the product. They think the economics are fair and straight ahead.

And to your point about having a commercial relationship versus a free or non-existing relationship, they're seeing that, oh, okay, now I have insight into the roadmap. Now I can prioritize my requirements that my devs have been asking for. Now I can double down on the secure supply chain issues, which I've been trying to get in front of for years, right? So it gives them an avenue that now, much different than a free user, as you observed, it's a commercial relationship where it's two-way street versus, okay, we're just going to use this free stuff and we don't have much of a say because it's free and so on and so forth. So I think it's been an eye-opener for both the company, but also for the businesses. There is a lot of value in a commercial relationship beyond just, okay, we're going to invest in new features and new value for your developers. The challenge has always been, how do you turn something that is widely beloved,

that is effectively an open source company, into money? There have been a whole bunch of questions about this. And it seems that the consensus that has emerged is that a number of people for a long time mistook open source for a business model instead of a strategy. And it's very much not. And a lot of companies are attempting to rectify that with weird license changes where, oh, you're not allowed to take our code and build a service out of it if you're a cloud provider. Amazon's product strategy is, of course, yes. So, of course, there's always going to be something coming out of AWS that is poorly documented, has a ridiculous name, and purports to do the same thing for way less money, except magically you pay them by the hour. I digress. No, it's a great surface area. You're

right. I completely didn't answer that question. No, it's fair. It's a hard problem. It's easy to sit here and say, well, what I think they should do, but all of those solutions fall apart under 10 seconds of scrutiny. Super, super hard problem, which, to be fair, we as a team and a community wrestled with for years. But here's where we landed, Corey, the short version is that you can still have lots of great upstream open source technologies, and you will have an early adopter community that loves those, use those, gets a lot of progress running fast and far with those. But we found the vast majority of the market doesn't want to spend its time

cobbling together bits and bytes of open-source tech and maintaining it and patching it. So what we're offering is an engineered product that takes the upstream, but then adds a lot of value, we would say, to make it an engineered, easy to use, easy to configure, upgrade, secure, so on and so forth. And the convenience of that versus having to

cobble together your own environment from upstream has proved to be what folks are willing to pay for. So it's the classic kind of paying for time and convenience versus not. And so that is one dimension. And the other dimension, which you already referenced a little bit with AWS, is that we have SaaS, right? We have a SaaS product in Docker Hub, which is providing a hosted registry with quality content that users know is updated not less than every 30 days, that is patched and maintained by us. And so those are examples of, in some sense, consumption examples. So we're using open source to build this SaaS service, but the service that users receive, they're willing to

pay for because they're not having to patch the Mongo upstream. They're not having to roll the image themselves. They're not having to watch the CVEs and scramble when everything comes out. When there's a CVE out in our upstream, our official images are patched no less than 24 hours later and typically within hours. That's an example of a service, but all based on upstream open-source tech that for the vast majority of users are free. If you're consuming a lot of that,

then there's a subscription that kicks in there as well. But we're giving you value in exchange for you having to spend your time, your engineers managing all that I just walked through. So those are the two avenues that we found that are working well, that seem to be a fair trade and fair balance with the community and the rest of the ecosystem. I think the hardest part for a lot of folks is embracing change. And I've encountered this my entire career, where I started off doing large-scale email systems administration. And hey, it turns out that's not really a thing anymore.

And I used to be deep in the bowels of Postfix, for example. I'm referenced in the SVN history of Postfix once upon a time, just for helping with documentation and finding weird corner cases, because I'm really good at breaking things by accident. And Vue is just part of my identity. And times have changed and moved on. I don't run Postfix myself or anything anymore. I haven't touched it in years. Docker's still there. And it's still something that people are actively using basically everywhere. And there's a sense of ownership and identity from especially early adopters who glom onto it because it is such a better way of doing some things that it is almost incomprehensible that we used to do it any other way. That's

transformation. That's something awesome. But people want to pretend that we're still living in that era where technology has not advanced. The miraculous breakthrough in 2013 is today's de rigueur type of environment where this is just, oh yeah, of course you're using Docker. If you're not, people look at you somewhat strangely. It's like, oh, I'm using serverless. Okay, but you can still build that in Docker containers. Why aren't you doing that? It's like, oh, I don't believe in running anything that doesn't make me pay AWS by the second. So, okay, great. People are going to have opinions on this stuff. But time marches on.

And whatever we wish the industry would do, it's going to make its own decisions and march forward. There's very little any of us can do to change that. That's right. Look, it was a single container back in 2013, 2014, right? And now what we're seeing, and you kind of went there, is we're separating the implementation of the service from the service, right? So the service could be implemented with a container, could be a serverless function, could be a hosted XYZ as a service on some cloud. But what developers

want to do is, where they're moving towards is assemble your application based on services, regardless of the how. You know, is that how a local container, to your point, you can roll a local serverless function now in an OCI image and push it to Amazon. Oh, that's one of the now 34 ways I found to run containers on AWS. You can also, in Compose, abstract all that complexity away. Compose could have three services in it. One of those services is a local container. One of those services might be a local serverless function that you're running to test.

And one of those services could be a mock to a database as a service on a cloud. Right? And so that's where we are. We've gone beyond the single container Docker run, which is still incredibly powerful. But now we're starting to up-level to applications that consist of multiple services. And where do those services run? Increasingly, developers do not need to care. And we see that as our mission is continue to give that type of power to developers to abstract out the how, extract out the infrastructure so they can just focus on building their app. Scott, I want to thank you so much for taking the time to speak with me.

If people want to learn more, and that can mean finding out your opinions on things, potentially yelling at you about pricing changes, more interestingly, buying licenses for their large companies to run this stuff. And even theoretically, since you alluded to it a few minutes ago, look into working at Docker. Where can they find you? No, thanks, Corey. Then thank you for the time to discuss and look back over both years, but also zoom in on the present day. So www.docker.com, you can find any and all what we just walked through. They're more than happy to yell at me on Twitter at Scott C. Johnston. And we have a public roadmap that is in GitHub. I'm not going

to put the URL here, but you can find it very easily. So we love hearing from our community. We love engaging with them. We love going back and forth, and it's a big community. Jump in. The water's warm. Very welcoming. Love to have you. And we'll, of course, put links to that in the show notes. Thank you so much for your time. I really do appreciate it. Thank you, Corey. Right back at you. Scott Johnston, CEO of Docker. 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 Docker isn't interested in it at all, because here's how to do exactly what Docker does in LPARs on your mainframe until the AWS 400 comes to crush it.

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.