Screaming in the Cloud - Episode 11: Hickory Dickory Docker

Episode Date: May 23, 2018

Docker went from being a small startup to an enterprise company that changed the way people think about their infrastructure to now, where its relevance is somewhat minimal. The conversation is no longer around the container level. Docker has become commonplace. Today, we’re talking to Jérôme Petazzoni, formerly of Docker. While he was with the company for about 8 years, Docker definitely experienced a roller coaster ride.   Some of the highlights of the show include: Amount of work conducted on the enterprise vs. community editions Docker was so widely adopted because its core technology was open source Challenge is to build a viable business and revenue model for the long run Similarities between Docker and Red Hat open source platforms Docker went from six people working in a garage to having a few hundred employees and $1.3 billion valuation Changes happened, but they were gradual; the changes were necessary to be a profitable and sustainable company Contingent of internal and external people believed that Docker was the answer for whatever problem surfaced; Docker would save you, but not always Balancing Act: Pushing forward with a correct message and regulating enthusiasm Networking and Docker for dummies; confusion and problems of things not working as expected have been resolved Things will continue to shift; Kubernetes and the orchestration battle What was unthinkable, could happen by companies pushing the envelope and making progress Will who you have as your Cloud provider stop mattering? It depends. All major Cloud providers plan to offer managed Kubernetes services and what Jérôme thinks of them Jérôme’s opinion on whether Kubernetes will follow this same path as Docker What does the road ahead look like for infrastructure automation? There is potential and lots of best practices in Cloud environments. Links: Jérôme Petazzoni on Twitter https://jpetazzo.github.io/ Docker Crunch Base Digital Ocean Red Hat Corey's Heresy in the church of docker talk Kubernetes ZooKeeper Azure .

Hello, and welcome to Screaming in the Cloud, with your host, cloud economist 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 week's episode of Screaming in the Cloud is generously sponsored by DigitalOcean. I would argue that every cloud platform out there biases for different things. Some bias for having every feature you could possibly want offered as a managed service at

varying degrees of maturity. Others bias for, hey, we heard there's some money to be made in the cloud space. Can you give us some of it? DigitalOcean biases for neither. To me, they optimize for simplicity. I polled some friends of mine who are avid DigitalOcean supporters about why they're using it for various things, and they all said more or less the same thing. Other offerings have a bunch of shenanigans, root access and IP addresses. DigitalOcean makes it all simple. In 60 seconds, you have root access to a Linux box with an IP. That's a direct quote, albeit with profanity about other providers taken out. DigitalOcean also offers fixed price offerings. You always know what you're going to wind up paying this month,

so you don't wind up having a minor heart issue when the bill comes in. Their services are also understandable without spending three months going to cloud school. You don't have to worry about going very deep to understand what you're doing. It's click button or make an API call and you receive a cloud resource. They also include very understandable monitoring and alerting. And lastly, they're not exactly what I would call small time. Over 150,000 businesses are using them today. So go ahead and give them a try. Visit do.co slash screaming, and they'll give you a free $100 credit to try it out.

That's do.co slash screaming. Thanks again to DigitalOcean for their support of Screaming in the Cloud. Hello and welcome to Screaming in the Cloud. I'm your host, Corey Quinn. I'm joined today by Jerome Petazzoni, formerly of Docker. Welcome to the show, Jerome. Hi. So you were at Docker for eight years and just recently wound up leaving. I mean, that's long enough to be declared legally dead.

That's effectively an entire career and a half if you go into a non-tech company. What's it like having left a company and having been there that long? Well, that was a first for me. All my previous work experiences had been stretches of one year, two years, some time, and then I would switch to something else. I feel like I cheated a little bit with Docker

because I made it last longer just by switching hats often enough from the very early days where it was like almost literally six guys in a garage. It was not a garage. It was like some co-working space in Soma, but that's as close as it gets to a garage around here. And then going through this evolution of becoming this wannabe competitor to Heroku, managing a team of amazing SRE folks, and eventually the pivot to Docker and then accidentally becoming Docker's evangelist and developer advocate.

And eventually, after a few more years, reducing the number of talks I was doing at conferences to focus on workshops and tutorials and that kind of thing. And at some point, being like, okay, I need to take a break from all this. And yeah, that took almost eight years. And during that time, Docker itself went through a fantastic rollercoaster ride. It went from this tiny startup,

more or less in a garage that had this great software idea that they wound up bringing a lot of attention to, changed the way that people tended to think about their infrastructure, got very large, and then effectively wound up not having a stated revenue model that could carry them and continue to sustain that growth. So it went from tiny startup to enterprise company to now it feels like the relevance of Docker as a company in the marketplace just eight years later is somewhat minimal.

The focus has moved on either to orchestration or to serverless technologies, things that are powered by Docker technology. But the conversation isn't around the container level anymore. Is that an accurate assessment? It's one side of the things. I think that Docker Inc., the people at Docker Inc. are at least were acutely aware that it's not just around the container runtime.

Maybe it was in 2014, 2015, but very quickly, the conversation, as you said, moved towards higher levels of the stack. How do I orchestrate my containers? How do I manage the lifecycle of my container images, which means how do I build them? Where do I put these images? Then how can I be sure that this image doesn't contain

some three years old vulnerability that was let through because we are building stuff from some antique package repository, et cetera, et cetera. How do I find out if my hosts are running that kind of image? So I think Docker moved into that space pretty quickly, maybe faster than we credit them with the vulnerability scanning things, with Docker Enterprise Edition, etc. Perhaps one thing that confuses or annoys people is that there is a gap between the Enterprise Edition offering,

which is pretty solid. I haven't used it a lot because I tend to have skin reactions when I use Enterprise software. But the few times I did demos with it, I was positively impressed. And then the open source side. And it looks like, okay, we nailed down the container engine.

That's great. It's open source and everybody can use it and it's everywhere. And then all the evolutions happened more on the enterprise software side, which also maps to the evolution of the company from this kind of open source hero or champion to being more on the enterprise side and seemingly less friendly to open source. And I emphasize seemingly because, yeah, of course,

there used to be a time where 90% of the engineering people at Docker were working on open source because there was only open source in Docker products. Now it's a very different split. Maybe it's 50-50. Maybe it's even more tilted to the enterprise side. I don't know exactly. So

that's a big difference. But there are still people working on open source software at Docker, and I think there will be for a long time. And perhaps some people are disappointed, thinking, oh, Docker was so big that by now they should be worth like $11 trillion or whatever.

But I think Docker is kind of comfortably making a spot in the enterprise software ecosystem now. And that's the best that can do now. It feels a bit challenging to look back to 2010 when this all started as.cloud once upon a time and see, even with perfect foreknowledge, how the world would evolve to have, I guess, changed Docker's growth trajectory even with perfect foreknowledge, how the world would evolve to have, I guess, changed

Docker's growth trajectory in the context of the reason that Docker was as adopted as widely as it was is because the core technology was open source. It was given away to people at no charge to them. The challenge has always been for companies, and this predates Docker for a very long time, how do you build a viable and sustainable business full of very expensive, very talented people, and have a revenue model that can drive that over the long term? Eventually, venture capitalists want to see some form of return on their investment? Sure. First and foremost, I don't consider myself as a good business person in the sense that I don't know how to make money out of things. If I did, my presence would be very different because in 2005, when I started my own company in France, we were the first folks to have a virtual machine hosting

offering. We were selling VMs for hosting, and that was really how we wanted to differentiate ourselves. So that was a few years before EC2, and yet that didn't turn into a successful business. The company still exists, and it still pays for a handful of very talented folks to do amazing things. But interestingly, neither of them is Jeff Bezos or Ingres Close. So yeah, disclaimer, I'm not really a business person. So what I'm going to say is probably a bit simplistic, but I feel like this challenge that you pointed out, like how do we make money out of open source, especially when there are VCs being like, hey, where is the money now?

I think that this has been addressed by folks like Red Hat. And I feel like, even if that might be making cringe a few of my former co-workers, I feel like Red Hat and Docker's business model are actually pretty close in the sense that, like, hey, there is this thing, it's free,

you can get Fedora, you can get Cepthos without giving a dollar to Red Hat. And yet, Red Hat gets a lot of money from RHEL and from services and from a lot of things to make open source awesome in the eye of the enterprise buyer. And I'm aware that it is a very simple view of things, but that's how I understand it. And from what I could tell from my last quarters at Docker, my co-workers were

on track to achieve similar things. That's that. Yeah. The last time I checked, Docker had a few hundred employees and had a $1.3 billion valuation. As you mentioned, starting it off as six people sitting in a garage. What was it like as the company transformed and effectively hit hyper growth? Well, first of all, the early days were pretty much exactly like the, as you can imagine. So it was like six of us sitting around a big table in a co-working space, six white dudes and not a single one of diversity on site. It took us some time to realize that maybe this might be a problem and we should address it.

But eventually we did. And but eventually we uh we did and uh and i i'm glad that that we did um the transformation happened kind of you know in a very subtle way of course because you don't go from six to 500 or 600 like overnight um it's i don't really know if i could put specific points in the timeline because this is all a kind of a continuous thing. Even switching CEOs, sometimes you could think, oh my God, they're switching CEOs. It's going to be a huge, deep changes. No, because the CEOs that we had over time,

I think were smart enough to not try to suddenly be like, all right, now we're going to change the culture overnight because I'm the new CEO. No, I remember when Ben Golub came on board, he did a lot of kind of roundtable meetings with us to assess what was the culture like? What do we want to reinforce? What do we want to reinforce, what do we want to change. And when Steve Singh came around, I hear that similar things happened. I was not part of that because I was not physically in the office at that time. And my role in the company also evolved. So it's really hard to put the finger on the specific point in time when things change.

But of course, yeah, at some point we went from garage startup to enterprise software. And of course, a lot of people feel either unhappy or frustrated about that because it's a different atmosphere. It's like, oh, my God, we have all these people in suits. What are they doing? I think they're sales, right? Yeah. And they're bringing that thing that we call revenue. Huh, interesting. That's new. So a lot of change happened, but they were pretty gradual. And yeah, I don't deny that some people probably woke up overnight and were like, oh, crap, that's not the company I used to work for and love and whatever. But I think that these changes were necessary. Just like I was joking about bringing in revenue, having sales, etc.

But yeah, that's what you need to do if you want to turn into a profitable and sustainable company. One of my historical criticisms of Docker was always that there was a contingent of people, and you were never in this group, incidentally. You were always very even-handed. But there were folks both internal and external in the community who thought that regardless of what your problem was, the answer was going to be Docker as a containers. It turned into jokes where someone tried to give a lightning talk once which was just five minutes of saying Docker, Docker, Docker the entire time.

That may or may not have been me. And the challenge there was that it felt like it was this panacea that could be poured onto any problem that you had. Whatever it was, Docker was going to save you from yourself, your architecture, your poor decisions. And while Docker did unwrap and unleash a number of different opportunities and infrastructure, it doesn't solve for everything.

How did you feel going through that process as you see some of the hype start to run away with itself? I think at first I didn't notice it and I feel bad about it because as you pointed out, there are lots of people who are extremely enthusiastic about Docker and be like, yeah, it's going to be the best thing

since sliced bread. Some people inside the company, some people outside. And at first, I think I mistook that for the Californian optimism where everything is awesome and when something is not awesome, that it's horrible. It took me a while to realize that, yeah, there are some people who are overdoing it, either deliberately or just because

they are really convinced that docker is going to save the world and then um at that point it's it's a very delicate things to do to say okay well docker is great for many things but not all of them and i know that you're super excited about it but um let's see how we can tone down things a little bit because it's not helping the cause in the long run um if we try to have people um run replicated uh mongodb shots as the first thing they do on docker it's probably not going to end well and and nobody wants that we that i think um at some point the answer i i built for that is all right i'm not going to debate if you can do everything with docker or not because you can you can probably do everything i mean if you're my giver you can probably build a um a car or whatever with just a screwdriver and a little bit of duct tape um so sure uh but my my

point was more to say okay let's start with the easy things and so stateless applications something like a new that low impact um use use docker as a kind of glorified package manager because that's going to be easy and it's going to help you because building packages is hard and boring. And then little by little, let Docker work its way towards CI, maybe have some CD, but for staging or QA or something like that. And little by little, you can assess what's going on, see what the problems are, but don't try to go too fast. And I think internally, it has been a very difficult balancing act between pushing forward a moderate message, because we don't want people to get burned. And also, you have to have some enthusiasm and to be convincing and say,

yeah, this is awesome, let's do it, et cetera. So just because that's the way it works, like that's the way it works. Well, first for me as a European looking at the Californian startup culture, as I was joking about, like everything is awesome. And if something is not awesome, it's probably like, because it's really horrible. So you have to kind of be super enthusiastic with your customer, with your users, with your investors, with everyone. And so if you're not, then people

are going to think, oh, it's weird. That person didn't say awesome five times in the last two minutes. So something must be wrong. So that was the difficult balancing act. It was having a positive message and also being able to tone down when things were kind of over-inflating the abilities of Docker, etc. for me where I got up and gave a talk about things that I really didn't understand how Docker could address. And what I expected was that people who heard this talk would excoriate me. They would tear me to pieces and say, haha, idiot, you don't understand how this works. Here's the answer. And instead, that talk got picked up at roughly a dozen conferences and people really started to care about it and i was blown away by that i just assumed that i was the dumb one that i didn't understand oh networking and docker isn't an issue you just do this this and this and in time that talk did have a shelf life, where now almost everything I pointed out

is no longer an active concern. There has been enough development in the space that, surprise, things that were problems three years ago aren't anymore. But at the time, that was eye-opening for me. It was transformative to think that, wait, if I don't know how this works and other people don't know how this works and other people don't know how this works, are we just all kidding ourselves? Yeah. And so that talk for the viewers is, I think you're referring to Heresy in the Church of Docker. And it's an amazing talk. I've seen it at least two times and I've enthusiastically, how can I say that?

There was a committee in the conference wondering if that talk would just be like rambling and ranting and trash talk or inappropriate or whatever. And I say, no, no, no, I've seen that talk. It's great. You wanted that conference. So I think there are, first, about that talk, as you pointed out, there are many things that you noticed, oh, this didn talk, as you pointed out, there are many things that you noticed,

oh, this didn't work as expected, and Docker seems weird in that regard, and how do we do this? And you are not the only one, obviously. And I think it reminds me a little bit of that amazing talk about the security of systems called something like, well, like big bags of water or something like that, like unsafe at any speed, explaining that

the computer security is just starting to get somewhere. It makes a parallel with car security, where in the the past car security was just horrible and you would die in car accidents all the time because the car was unsafe at any speed and then we added airbags and car frames that kind of deform better under shock etc etc we started catering to the weak yeah it happened yeah except for the fact that the weak is like 100% of the population. And I think for computer security, we're kind of getting there as well. So the discourse is shifting between, oh yeah, of course, what do you mean? You didn't have a 16 characters password using uppercase, lowercase symbols, emojis, and numbers,

and you haven't changed it every month, as we ask, no wonder you got hacked. So the discourse is evolving towards something that is actually possible for normal human beings. And I think for Docker, it was the same thing. I'm glad that the evolution went faster because at first, Docker was super exciting and useful but required a lot of extra little knowledge, like how do I get my networking to work properly? What if I need wire speed performance on the network, etc.,

because I'm doing video streaming or gaming or VIP or whatever. And little by little, we addressed these things. And in, I would say, kind of multiple tiers. The first tier is like, hey, this is a little recipe that I'm going to share with you. It's a hack. It's going to be weird, and maybe you're not going to like it, but it will do the trick and it will let you kind of ram down that roadblock and continue on your fantastic Docker journey, etc. And then little by little, we made these hacks less hackish. We cleaned these things and made them part of the product. And eventually, the user experience and documentation, etc., follows along.

And at some point, you reach the point where if you want to do that network thing, then it's documented and it's there and there are blog posts and explanations and all you need so that it works well. So your talk pointed out a lot of these early hacks and early, I want to say misconceptions, but maybe misexplanations would be better. And that was great because personally, when I watched that talk, it made me realize the areas where we needed to improve because it's really hard

when you're using Docker since like half a decade and you're trying to have an objective look on it to figure out, okay, what are the pain points? It's hard. So having smart people

do that thing and then point out that the issues they had was extremely helpful, at least for me. It's always a challenge, too, when you have an emerging technology come out and companies that can iterate rapidly or are just starting out and able to dive directly in to whatever that technology is. That's exciting and it's fun and you fail fast and you learn things and technology progresses quickly. The other side of it is the large enterprise companies that some would call stodgy, others would say they have actual revenue

and agreements to contend with. They have compliance concerns. They have legacy software that does not support being deployed in completely new ways without some serious rework. And I feel like with any exciting technology, there's always going to be some form of long tail as companies start progressing to a point where, for example, containerization becomes viable. But in less than a decade, what fascinates me is that Docker has more or less gone from this thing that hobbyists and experiment types tend to use to something that is relatively mainstream to now it's progressed almost to the point of

being part of the plumbing. It's not something that needs to be actively thought about in quite the same way. Today, it feels like that decision point has been moved up the stack to your selection of orchestration tooling. And down the road, potentially, even that's going to wind up being eaten as things slowly move up the stack and things that used to be complex now become commonplace and just work. How do you see the orchestration battle playing out? Relatively recently, I believe, Docker, as a company, wound up supporting Kubernetes as a first-class citizen for a lot of their orchestration needs. Sure. I think, just as you pointed out, that things are going to move up the stack. So first of all, the engine

is not really relevant anymore. Yeah, okay, you're running containers. You're probably running them on Docker. You can also use other container runtimes, but for now, most folks run that on Docker just because it works and it's kind of

not relevant anymore. I think that in the future, things will continue to shift the same way that things shifted, for instance, for hypervisors. Even in the open source side on Linux, it used to be like, oh, are you running Xen or are you running KVM?

Both had their pros and cons. And nowadays, I don't even know which one EC2 is running. I used to know, but I think they changed maybe multiple times. So I have no idea. And honestly, I don't care. I used to care because it was useful to know the intricacies and details and be like, oh, this is using Xen.

Therefore, I know that the spin lock implementation is going to behave in really interesting ways, and I need to know that. But eventually, that becomes irrelevant and part of the plumbing. And I think that each time that we make a significant improvement in a given space, we just push the envelope one step further. I'm going to give

an example that probably was the one that opened my eyes on this. If we think about these highly available distributed key value stores that were and still are very popular when you need to store important stuff. So I'm talking about ZooKeeper, etcd, console, these kind of things. It used to be the case that you had mostly ZooKeeper and it worked, but it was kind of difficult to deploy and operate and maintain. And when you had ZooKeeper in the equation,

it's like, oh, great, now we have the JVM, and we have this extra thing to maintain. But we need that because we need that highly available key value store. And then I remember when EatsCD came along, that was suddenly kind of, I mean, to me, like the SRE person speaking, it was kind of a revolution because setting up pcd was super easy and of course we knew it was it was new so there would be some rough edges etc etc right but in the long run we could see that this would be amazing because operations that used to be um frightening like decommissioning a node to put another one instead, etc.

All these things would be completely normal, routine operations on HCD. And then some people started thinking, hey, what if I just put an HCD server on every single of my EC2 instances? That way I can just connect to local hosts everywhere. And that's easier. I don't have a separate cluster to maintain. And at first, it seems like a good idea, and then very quickly you're like,

oh no, that doesn't work because there is this rough protocol that I need to learn about, and if I have thousands of writers there, it doesn't exactly work, etc., etc. But what is really interesting is that this idea of let's put one etcd server on every machine, we would never have thought about that with Zookeeper because it would just have been completely unfathomable.

Well, I know probably a few people tried or maybe even did it, but for most of us, it was just unthinkable. So etcd kind of pushed the envelope by moving us to the next stage, which is, okay, now we're going to run

that stuff everywhere. It's going to be pervasive and we're already thinking about new use cases for that thing. And I think that this is

progress in our space. We have something that used to be kind of experimental and special, and then at some point it becomes mainstream. And when it becomes mainstream, then a lot of people who did not want to touch the technology with a 10-foot pole suddenly can embrace the technology, and these people have new ideas that the older people didn't have.

And that's how we make progress. So I think that we're going to see similar things on the orchestration space. Now that we have Kubernetes that is a really solid and complete and awesome offering, we still have stuff like Mesos and Swarm on the side when you have some specific needs.

So I think that at some point, there are applications, use cases that are going to appear just because something like Kube becomes pervasive. Just because you can rely on the fact that you're going to have Kube becomes pervasive. Just because you can rely on the fact that you're going to have Kube everywhere. So instead of being like, maybe we could do this, but we need the customers to have Kubernetes

and that's too small of a market to really think about it. Instead, you can be like, okay, to use our stuff, people need Kubernetes, but almost everyone does. so let's do it. Docker did that in some ways. Kube is going to do that. I don't know what's going to be next because I don't really define myself as a visionary person,

believe it or not, but I think that this is what's going to happen. As things like Docker, Kubernetes, etc. have become pervasive, it feels like we are on the cusp of being able to have an application and a configuration written in YAML or some other language. Please don't email me talking about how JSON is better. I promise I don't care. You were approaching a point very rapidly where that's all it takes to deploy an application or a workload to any cloud provider so in near real time you'll be able to arbitrage between different providers

for cost reasons or for different service offerings in different locations do you think that we're heading to a point where who our cloud provider is stops mattering um i i think that it will stop mattering for some applications but but still matter for others uh what i mean by that is that um if if we if we look to the past uh in theory if you put everything like your whole application in puppet or terraform or use Ansible or config management all the way, in theory, your choice of infrastructure shouldn't matter too much because it's abstracted by the wonderfulness of config management, right?

The reality is a little bit different because each infrastructure has its own little different things. And even if Docker helps to kind of play in that field, there are still a few differences. Like, for instance, oh, you're using maybe Dynamo or SQS or something like that. What's the equivalent if you move away from AWS. And conversely, Google Cloud Platform came around with GKE, which at least until the end of 2017 was by far the best managed host offering of Kubernetes. That may change, of course, now that both AWS and Azure have their own offering and obviously try as hard as they can to catch up.

So I think that for some applications, it will be really easy to migrate, easier than ever. Not just because of Docker. It's more like Docker moved the slider a little bit. So now there are more applications that are easier to migrate. But obviously, if you have a big, complex application relying on APIs and services specific to a given provider, or just because the sheer size of your data means that moving around

is let's say complicated then docker or not docker cube or not cube that that's not going to change anything so yeah tldr that it will help a little bit of course but it won't be like suddenly the magic wand that makes hybrid deployments and cloud portability a thing overnight. To that end, all of the major cloud providers have at least announced, if not rolled out, a managed Kubernetes service. Have you had the chance to explore those in any significant depth? Do you have any early opinions as far as which ones are wonderful which ones are terrible or are you holding out to see more than has already been delivered so i have a stale second-hand opinions uh in the summer of 2017 i spent a lot of time with folks who had decided to go to production on Kubernetes. And back then,

the big takeaway was that GKE was really fantastic and everything else sucked. That was before AWS and Azure were out there offering. So I would expect that things are going to evolve. So here, honestly, I don't have any provision or anything like that because it's really hard to get an idea of not only the resources, but the roadmaps and also the priorities internally of these different people. So I think in that case, choice is good.

That means that a lot of people who wanted to have managed Kubernetes clusters don't necessarily have to move to GKE. They can also explore, I think it's EKS and AKS on AWS in Azure. Yeah, so then I don't have a particular preference myself, especially given the fact that now I'm not on call anymore since a few years now, but I don't even have a vested interest either way.

The only things that, the only uptime that i care about now is the uptime of my blog which is basically static pages so i don't really need a cube cluster for that um yeah so sorry i don't have a a nice quotable answer on that no no trouble at all it's it's one of those areas that's still very actively undergoing development, and we're still seeing companies coming out with these in new and interesting ways. follow in the path of Docker in that people care for a while tremendously about what orchestration system they're using, but then get to a point where that's abstracted away to the point where once again, it's part of the plumbing and no one explicitly cares. It's possible. I've witnessed already a few conversations about, hey, should we use Ksonnet or Helm or something else to define our applications?

So for some folks, it looks like Kube is a done deal, but then suddenly there are lots of new things to figure out. And I think that that doesn't make Kube irrelevant, far from it, because even if we look back, okay, now Docker is not really the question anymore, but when we work on our applications locally, generally there will be either Docker for Mac or Docker for Windows or something like that.

So we still use Docker really closely on a day-to-day basis. So with Kube, I feel it's kind of the same thing. We're like, okay, we can agree and accept that we're going to have a Kube cluster. Now, how are we going to define our applications and how are we going to move images around

and, as I said earlier, find vulnerabilities, etc. Now we can work even harder on these problems, on these challenges. So last question that I'll beat you up with. Play futurologist for a minute. What do you think the road ahead is going to look like as far as infrastructure automation,

as far as deploying software from a developer laptop into a cloud environment that winds up being globally spanning. Do you think that we're still going to see incremental improvements, or do you think there's another Docker-like paradigm shift waiting in the wings? That's an excellent question. First, as a disclaimer, usually my provisions and forecasts turn out to fail miserably. So I don't know if there will be a big shift. There are many things kind of waiting in the wings, as you said, like serverless and IoT and blockchain, etc. So it's kind of interesting to see,

all right, what kind of potential do we have here? And a few things that... Well, first of all, the thing to me that is really exciting in the road ahead with containers, generally speaking, and here I'm putting everybody into that big umbrella, Docker, Kube, everything. But the really exciting thing is that there are lots of best practices in cloud environments.

Like you should have golden images and you should do canary deployments and blue-green and this and that and feature switches and whatever. And I feel like containers give us an easier way to do that. For instance, immutable infrastructure used to be something that maybe Netflix was doing and maybe AWS themselves and a few other folks. But when you really kind of dive in the trenches

and ask people, that stuff is hard. And often it steps on the brakes of innovation because now each time you want to roll out a single line of code, it has to be baked into an AMI and then the servers have to be replaced, et cetera, et cetera. And that takes a while. an EMI, and then that servers have to be replaced, etc., etc. And that takes a while, and the tooling for that is huge and complex.

So with containers, that tooling becomes easier, faster to use, etc., etc. So we can have immutable stuff with 10 seconds between I put my line of code and then I get images built and pushed on my servers. So that's exciting. There are certainly other things that are going to make these workflows easier. There are certainly new workflows that are going to appear,

new stuff that will seem even better than the feature switch canary blue-green deploys that we do today. But I don't know for sure what they are. Otherwise, I would probably be gathering a team to create a startup around that. So no, I don't really have a good forecast on that, unfortunately. Thank you very much for sharing your thoughts on infrastructure. One last thing before we call it an episode.

You've been very active lately, and maybe for a while, and I just started noticing it more recently, on Twitter, talking about a variety of different topics that aren't directly tied to technology. English as a not primary language, you've talked about mental health, you've talked about diversity. You're basically using a short form communications method to have very in-depth, almost essays in a way that flows naturally. I'll throw a link to your Twitter feed in the show notes, but what's sparked your use of Twitter as a platform to have that type of conversation? That's an excellent question. I think the main reason is audience, because thanks to my

involvement in the container story, I attracted a following on Twitter. And so that's a platform. And one of the things that I decided to do starting, I think, in 2015 was to use that platform for... That sounds really cheesy, but for social good in a way. Because if there are thousands and thousands of people

willing to listen to me talk about container stuff, I might as well try to move the needle even just a tiny little bit by telling about these other things that are not container-related at all, but that matter to me and

I feel like we don't talk about them enough, in particular for diversity and mental health. Speaking about French and English is more a kind of byproduct, where a few times I had thoughts and conversations with others, kind of marveling at the differences between French and English and how concepts map between the languages. And so I decided to kind of throw that in the mix as well.

Now, another thing I noticed about Twitter a while ago is that it feels at least to me like a good way to consume that kind of short kind of information, something that is longer than a tweet, maybe not long enough for a full blog post. And I'm pretty sure that I'm not the only person to sometimes kind of scroll aimlessly through my Twitter timeline like a zombie. And I think other people do that as well and i i i noticed that if there is a link to a blog post um perhaps i will read it but most likely i will uh start it um and and then perhaps later i will read it perhaps if it's a thread it's short enough so that i can

invest a little bit of time into that and and if i'm bored i can just scroll past it and it's a thread, it's short enough so that I can invest a little bit of time into that. And if I'm bored, I can just scroll past it and it's quick. I don't need to leave my timeline. I don't need to open a web browser, which on the phone is not really a good experience because 90% of the screen surface is ads and other stuff. So I felt like Twitter was a good outlet for that. Twitter has many flaws and I don't even want to start talking about them,

but I feel like it was a good outlet for these short, yeah, microblogs kind of, yeah. Perfect. Thank you so much for appearing on an episode of Screaming in the Cloud, Jerome. My name is Corey Quinn. This has been Screaming in the Cloud. This has been this week's episode of Screaming in the Cloud.

You can also find more Corey at screaminginthecloud.com or wherever fine snark is sold.