You can still have lots of great upstream open source technologies,
and you will have a 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 and, and, and, and, and.
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.
Thanks for joining me.
Great to be here, Corey.
Thanks for the invitation.
I'm not sure I was fleeing you, but, uh,
we can recover that one at another time.
Oh, absolutely.
This episode is sponsored in part by my day job, the Duck Bill Group.
Do you have a horrifying AWS bill?
That can mean a lot of things.
Predicting what it's going to be.
Determining what it should be.
Negotiating your next long-term contract with AWS, or
just figuring out why it increasingly resembles a phone
number, but nobody seems to quite know why that is.
To learn more, visit duck bill group.com.
Remember, you can't duck the duck Bill.
Bill and my CEO O informs me.
That is absolutely not our slogan.
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, etc, etc.
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've got to 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 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 didn't meant that the silo became increasingly
irrelevant because works on my machine was no longer a problem.
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, etc.
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%.
That's very intentional as well.
We certainly had good products and great customers and we're
solving problems for customers on the opposite side, 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, 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 the needs of developers without any other
distractions from a revenue, customer, channel, so on and so forth.
So, we knew this was going to come up in the conversation, but as of a couple
of weeks ago, as of the time of this recording, you announced a somewhat
Well, let's say controversial change in how the pricing and licensing worked.
Now, as of we're taking effect at the end of this year,
the end of January, rather, of next year, Docker Desktop is
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?
Great surface area for a 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, and The CLI, Compose.
We can make it super easy just to get that up
and running and configured with smart defaults.
Secured, hardened, and importantly updated.
So any vulnerabilities patched and so on and so forth.
The point is like, 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 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 Set up
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, 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 ten
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.
Like, 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?
And so the thresholds that you just mentioned, the 250 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 it.
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 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.
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, 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 to 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 both been around long enough to know like 12 working days
to have a assigned agreement with an enterprise agreement is unheard of.
Yeah, let's be very clear here on the duckbill group
side of things, where I do consulting projects.
I'm 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 and Q3, you have to clarify what year they're talking about.
So 12 days is unheard of.
So we've been very encouraged by that.
And I'll, I'll just give you a 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 the
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 road map in the last year.
And again, with, uh, 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 and businesses are supporting
us, we're happy to double down and create more value.
My big fear when the change was announced was the uncertainty inherent to it.
Because if there's one thing that big companies 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, 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 percent of organizations, 80
percent of businesses want to be in compliance.
They have 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 percent represent opportunity?
Yeah, you know, it does, but it's a big ecosystem.
The 80 percent 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.
Here at the Duck Bill Group, one of the things we do with,
you know, my day job is we help negotiate AWS contracts.
We just recently crossed 5 billion of contract value negotiated.
It solves for fun problems such as.
How do you know that your contract that you
have with AWS is the best deal you can get?
How do you know you're not leaving money on the table?
How do you know that you're not doing what I do on this podcast
and on Twitter constantly and sticking your foot in your mouth?
To learn more, come chat at duckbillgroup.
com.
Optionally, I will also do podcast voice.
When we talk about it, again, that's duck bill group.com.
I also have a hard time imagining that you and your leadership
team would be shortsighted 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 percent 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 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 a hundred percent.
So we got most and we're off to a good start by all accounts.
And look, a lot of folks too, sometimes we'll 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 are, and have a license or compliance or not.
And sometimes just a little tap on the shoulder said, Hey, did you know that?
You might, 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 percent to have a great,
successful business and continuing successful community.
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, alright, they have it installed in 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, I am, I guess, mature enough to admit that my take that, oh, Docker is
terrible, which was never actually my take, I 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.
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, 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 Duck Bill 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, albeit 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.
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 know, you and I were talking before about
it goes back to LPAR on IBMs and, you know,
BSD Jails and Cheroots on Linux.
You know, Cheroot, right?
I mean, Bill Joy putting Cheroot 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 ops side, but in the 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 these 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, they're happy.
Just 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.
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 A
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, 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 a 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 and, and, and, and,
and so what we're offering is a engineered product
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, they're 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.
For the vast majority of users, they're free.
If you're consuming a lot of that, then there's a,
there's a subscription that kicks in there as well.
We're giving you value in exchange for you having to spend your
time, your engineers, managing all that 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, I've encountered this my entire career, where I
started off doing large scale email systems administration,
and hey, 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 if you're 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, 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.
Okay.
So, okay, great, people are going to have opinions on this stuff.
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 um, 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 yes, 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 like 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 could 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 5
star review on your podcast platform of choice.
Whereas if you hated this podcast, please leave a 5 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 Cracker.