DOP 68: Is Docker Back?

Posted on Wednesday, Aug 12, 2020

Show Notes

#68: Docker recently announced integrations with Azure Container Instances (ACI) and Amazon EC2 Container Service (ECS) that makes it simple for developers to use native Docker commands to interact with these services. Darin and Viktor discuss why this is a very big deal not only for Docker, but for the ecosystem as a whole.

Rate, Review, & Subscribe on Apple Podcasts

If you like our podcast, please consider rating and reviewing our show! Click here, scroll to the bottom, tap to rate with five stars, and select “Write a Review.” Then be sure to let us know what you liked most about the episode!

Also, if you haven’t done so already, subscribe to the podcast. We're adding a bunch of bonus episodes to the feed and, if you’re not subscribed, there’s a good chance you’ll miss out. Subscribe now!

Books and Courses

Catalog, Patterns, and Blueprints

Buy Now on Leanpub Buy Now on Udemy

Kubernetes Chaos Engineering with Chaos Toolkit and Istio

Buy Now on Leanpub Buy Now on Udemy Buy Now on Amazon

Canary Deployments to Kubernetes using Istio and Friends

Buy Now on Udemy

Hosts

Darin Pope

Darin Pope

Darin Pope is a services consultant for CloudBees.

His passions are DevOps, IoT, and Alexa development.

Viktor Farcic

Viktor Farcic

Viktor Farcic is a Principal DevOps Architect at Codefresh, a member of the Google Developer Experts and Docker Captains groups, and published author.

His big passions are DevOps, Containers, Kubernetes, Microservices, Continuous Integration, Delivery and Deployment (CI/CD) and Test-Driven Development (TDD).

He often speaks at community gatherings and conferences (latest can be found here).

He has published The DevOps Toolkit Series, DevOps Paradox and Test-Driven Java Development.

His random thoughts and tutorials can be found in his blog TechnologyConversations.com.

Signup to receive an email when new content is released

Transcript

Viktor Farcic: [00:00:00]
If I would need to state one thing that makes developers more productive than less, I would say that that is independence.

Darin Pope:
This is DevOps Paradox episode number 68. Is Docker back?

Darin Pope:
Welcome to DevOps Paradox. This is a podcast about random stuff in which we, Darin and Viktor, pretend we know what we're talking about. Most of the time, we mask our ignorance by putting the word DevOps everywhere we can, and mix it with random buzzwords like Kubernetes, serverless, CI/CD, team productivity, islands of happiness, and other fancy expressions that make it sound like we know what we're doing. Occasionally, we invite guests who do know something, but we do not do that often, since they might make us look incompetent. The truth is out there, and there is no way we are going to find it. PS: it's Darin reading this text and feeling embarrassed that Viktor made me do it. Here are your hosts, Darin Pope and Viktor Farcic.

Darin Pope: [00:01:13]
So what's this thing about Docker right now?

Viktor Farcic: [00:01:18]
They're trying to reinvent themselves. Or rather, maybe go back to their roots. I believe out of desire or necessity. That's hard to say at this moment, but they're going back towards targeting developers and their needs rather than companies, enterprises. I think that they're moving away from the idea of even attempting to help you run your applications in production and focus on let's say developer productivity would probably be the right word.

Darin Pope: [00:02:05]
If you haven't kept up with it, Viktor, why don't you let people know what this productivity change from Docker is all about? Because it may not apply to everyone.

Viktor Farcic: [00:02:20]
Yes. So the way how I would interpret their recent changes is that they're trying to enable people us, to do with Docker, and in this context, Docker binary, the same operations as we would be normally doing in local, in laptops or in servers that we set up manually and to be more specific, they're targeting now interoperability between Docker binary and Azure and AWS. so they are trying to provide means for people to use Azure container instances and, AWS ECS, with Docker in a way that is, I was about to say transparent, but that is not really true because the way how those two work is quite different, but we'll get there, I guess. But for now I think it's developer productivity by moving developers fully or partially to cloud from their laptops.

Darin Pope: [00:03:38]
Now we're stating it as developer productivity, but how are you defining developer productivity?

Viktor Farcic: [00:03:49]
You caught me now. You caught me saying a word without really going through it well. You know, it really depends on the type of developer. Docker in general was always, I believe, focused on developers. So we can in a way, distinguish Docker, let's say, and even Docker Swarm on one hand and Kubernetes on the other by who is the target audience. Now, what I'm about to say does not mean that it's only for those people or only for those, but predominantly Docker was oriented towards individual developers. So this is how you can package your application. This is how you can run your applications and the dependencies of your application on your laptop. This is how you can create a virtual machine easily, provisioned with Docker and what so not and so on and so forth. Very, very simple to use. Amazing user experience without too many, what is the word? Nuts and bolts or something

Darin Pope: [00:04:57]
Yeah, that's fine. Yeah. Knobs and switches. It's really, it does it and you go on.

Viktor Farcic: [00:05:02]
Exactly. So, Kubernetes came more from Google experience where, we need to do complex operations. So for complex operations, we need a lot of things. It's not going to be easy. At least not initially we are moving in that direction, but it's definitely not. So it's predominantly focused on sysadmins, operators, people who manage your production. Let's say your cluster, often for large scale. So in this context, when I say developer productivity, I mean, simplify many of the things that an average developer does, like, how you're going to build your application. Well, it's not going to be Maven this and that. It's going to be Docker build. How are you going to deploy dependent database on your laptop? Well, it's going to be docker run, right? How are you going to combine that database with your application? It can be docker compose. l could even argue operations that are not so complex today or before Docker, but they are made even easier than that.

Darin Pope: [00:06:12]
I think that's the thing to lift out what Docker is doing right now is they are leveraging docker compose to do specifically the ACI integrations. I haven't looked at the ECS ones because at the time we're recording this, the official announcement for ECS just came out yesterday or the prerelease for ECS, whatever you want to call it. Specifically it's ECS Fargate. So if you want to do stateful set, sorry . Cause it is only supporting Fargate if I

Viktor Farcic: [00:06:43]
yes. Fargate with ECS, as far as I know. So not EKS, not Kubernetes with Fargate on ECS.

Darin Pope: [00:06:54]
Well, yes, that's a very strong distinction because I've forgot about Fargate being available for EKS. They're leveraging Docker compose, which if I remember right, we both sort of had buried a long time ago. Just because what was the use of Docker compose if I'm living in a Kubernetes world, there was zero value, but now there's huge value.

Viktor Farcic: [00:07:25]
I'm not yet sure whether it's huge, but there is value. I still cannot wrap around my head whether there is value or no, but that is not to a fault of Docker but the other powers or to be more precise the platforms that they're targeting, but yes, compose suddenly becomes more interesting if you are going to use Azure container instances or ECS. So the whole idea is that, you have Docker compose file or you keep running Docker run commands. And then the same thing, more or less that you would do with your containers on your laptop, you can do in Azure container instances or ECS. So basically those two become extensions of your laptop and allow you to do over there more or less, the same things as what you can do on your laptop. Now, the important thing is that this is unlikely ever going to become a way for you to run production for quite different reasons. Azure container instances, at least from my perspective is not, and will never be a service where you should run production load. Never. And Because Azure container instances is a way for us to run containers in isolation, meaning you cannot assemble a system with many different containers, communicating with each other, unless you want to go through external load balancer and what so not and you cannot replicate your applications. So you cannot have more than one replica. So it is literally equivalent of docker run, not even docker compose that has multiple containers, literally docker run. That's what it does. Docker run, no matter how tempting that might have seemed in the past is not really how you run production. If you cannot scale, if you cannot load balance requests, if you cannot really treat storage, networking, and all that stuff, it's not going to be your production. But that does not necessarily mean that Azure container instances is a bad service or a bad idea, but rather recognizing for what it is. It allows you to run containers easily. isolated containers and I'm repeating isolated containers. I can imagine some uses for that. Imagine local development where actually your laptop is not enough from capacity perspective, or let's say development when you want to collaborate with others. Let's say that you and me now work on something and I want to show you what I just made. I can, I can either give you access to my laptop by exposing it to internet and what so not or I can just deploy it to Azure container instances. It can be a quick preview for you, right? Now , I still in my head don't have it clear how wide that usefulness can be, but it is what it is let's say. While ECS is a completely opposite. thing, ECS is a production ready service. That's where you can run anything from a simple single replica application to very, very complex systems. But then, while ECS becomes much closer to what you would consider a platform to run production, it is equally further away from principles of Docker. And then I would be questioning like, Hey, would you really want to use Docker to run production on ECS knowing that running production load in ECS means that you need to press 57,000 buttons and define a thousand different things. It's a complex beast, right? If I just let docker compose create everything, and load balancer and the cluster and, you know, everything that ECS needs, then maybe that would be too much of a simplification because no matter how much complex ECS is, it still requires us to control that complexity in a way. So that's where I see Docker as being potentially less useful, unless you're going to treat ECS in a similar way, like Azure container instances, which is a valid option, because if your company is paying AWS then, yeah, why not spin up something quick that is not necessarily production ready, but it's useful for you as a developer then maybe. Those are two very different use cases, different destinations and even if you look at the commands, you will see that they behave and feel very differently. The commands to deploy to container instances from Azure and ECS. One more thing just before I forget, you mentioned Docker compose. One curious thing is the change that I don't know if you noticed. It took me awhile to notice. It's not docker-compose, it's not docker-compose binary anymore, but it is docker compose. They're putting compose functionalities back into Docker.

Darin Pope: [00:13:21]
Why do you think that is?

Viktor Farcic: [00:13:24]
I think that Docker is probably realizing that compose might be their most valuable asset and maybe want to put it all in one place because when you. I mean, so what I'm going to say does not necessarily mean that that's really their strategy, but if I would be in their shoes, I would recognize, you know, what? Docker machine? Dead. Swarm? Finished and so on and so forth. So basically they're left with only out of a big portfolio of tools, they are left with two: docker and docker compose. So while separation into those two together without 17 others made sense when you have 20 tools, you want to separate them. But when you have two tiny tools, then maybe having one makes more sense from user perspective on the long run. But that's my guess. So, I don't know the strategy for real.

Darin Pope: [00:14:24]
Now you have worked with the ACI implementation. Have you worked with the ECS implementation yet since it just announced?

Viktor Farcic: [00:14:34]
Not sufficiently to judge it.

Darin Pope: [00:14:39]
So the answer's no, that's okay to say no,

Viktor Farcic: [00:14:42]
Let's say no, let's say the answer is, I used it, it failed to work in my case. After two attempts I gave up, in a positive sense because it is very, very early alpha, beta whatever it is. So I cannot judge them for me not being able to succeed using it. so I give up for now I will revisit the subject let's say one month or two from now.

Darin Pope: [00:15:08]
Yes, because, and this is the other thing too. As of we're recording this on Thursday, the 30th good grief. 30th of July. the notification came out yesterday and it's still in the experimental channel. So if you're still running the stable channel, you won't see these features. So do you want to break your local Docker to play with some stuff you may not use? That's your choice.

Viktor Farcic: [00:15:36]
I mean, to be honest, I cannot guarantee of course, but I cannot recall the last time Docker or ever Docker breaking something. Having a feature that doesn't work as expected yeah, but they're very good at isolating stuff. Actually, and this is curious, you do get Docker as a single binary that you today need to download from the edge channel, which is experimental features channel. But, Azure container instances is a separate project. Completely separate from Docker and ECS is a separate project with separate GitHub repository. It's just that's when they build the binary, they combined multiple repositories and then build the binary and you get things combined. What I'm trying to say with that is that if something is broken in, let's say ECS, that is pretty separate from the rest. It wouldn't really break your Docker or anything like that, or not very likely.

Darin Pope: [00:16:37]
That's an interesting, cause I have not dug into it that deep. They're producing a monolith from a bunch of different repositories.

Viktor Farcic: [00:16:50]
Yes, they're assembling different repositories into one, like call it monolith. Yes. Which is in a way...

Darin Pope: [00:16:59]
so here's where I'm going with that. And this is not the topic of this episode, but it seems like logically the Docker binary would have been every or everything that's related to the Docker binary would have been in a single mono repo and not separate repositories, if you follow standard convention.

Viktor Farcic: [00:17:25]
Yes,but I'm not sure even actually whether mono repos are used, where the primary objective of mono repos is to assemble one big binary. At least that's not what I'm seeing usually. It's rather that, they are used so that each application and mono repo can be built separately, but there are interdependencies between all those. So it's more convenient to keep them in the same repo.

Darin Pope: [00:17:56]
Yeah, again, that's not the purpose of this episode, but the way that you stated it with a number of my clients that are still mono repo, they say, well, there's no way I could ever decompose my application into separate repositories. That would be too hard because everybody wants to have everything sitting inside of their favorite IDE without having to switch between different repositories.

Viktor Farcic: [00:18:24]
You're touching the nerve now and I'm doing my best, not to explode because that would result in another 20 minutes or so.

Darin Pope: [00:18:32]
Well, this takes us back to the very beginning of developer productivity, and we'll save this for later,but what is true developer productivity. True developer productivity isn't having everything open up in a single window in your IDE. It's part of it, but it's not true developer productivity.

Viktor Farcic: [00:18:55]
yeah. I'm thinking now aloud. If I would need to state one thing that makes developers more productive than less, I would say that that is independence. The ability to work, within a team, preferably small team unconstrained from the rest of the work of the company. That's probably the most important in my head, the most important factor that determines somebody's productivity.

Darin Pope: [00:19:35]
If you're using ACI, if you're using ECS and going back to the example that you gave of, Hey, I need people to be able to review what I've done, but I don't want to poke a hole on my laptop. I don't want to use something like ngrok or some other reverse coming in to my machine. And I can deploy to ACI or ECS? Done deal. It's and let's say you are going ECS, which is more productionized. I'm using the word, not your word. I see plenty of applications, production level applications, running on ECS.

Viktor Farcic: [00:20:23]
Yes.

Darin Pope: [00:20:25]
So let's say I'm not an Azure shop. I am an AWS shop and we use ECS a lot. As a developer, depending on again, how large the application is, how much interdependencies there are. The thing that I write as a developer could be re-leveraged by the operations team to actually manage it longterm. It's too early to say, but it seems like it's leaning in that direction.

Viktor Farcic: [00:21:00]
Maybe. I suspect really that, Docker is going as a company now is going out of its way to separate itself from anything production related. That's what my gut tells me. Bad experience. I think that they realized that they failed, You know, because production is really what you sell to companies. That is what we package as enterprise solution and all that stuff. Right. They're going away from that. I think that they're really targeting developers, ECS. Let's face it. I mean, both of our personal experiences with different companies, hey, ECS production is never going to be docker compose up from developer terminal. It's not going to be.

Darin Pope: [00:21:52]
But it could be from docker compose up from a Terraform or Ansible playbook.

Viktor Farcic: [00:22:00]
Yes. I'm not sure because what is happening in that's why support for Azure container instances is to me potentially more interesting. ECS simply what it does is it spins up or runs a few CloudFormation templates of which you have absolutely no control. No control whatsoever. No knobs, no switches, nothing. Just default ones. That is the part that is from my perspective, very unlikely to be acceptable for most companies for production, just to clarify. Now, as far as I know, there is no attempt, at least not now to do compose up inside of the existing ECS cluster. That might change. If it does then, yes, why not? What might be successful if it, replaces container definition for ECS, which is typically that JSON file that is not CloudFormation just JSON very reminiscent of docker compose. But yeah, then maybe.

Darin Pope: [00:23:14]
If you're interested in either ACI or ECS or both, right? I mean, what if, if you're, if you're not trying to do something totally fancy and you just need to run a container and let's say you wanted to have an experiment and you wanted to experiment. Okay. I want to spin up a container and let's make this just a normal three tier application for a moment. It's an API call. I would spin up an ACI based container. I'd spin up an ECS based container. I would use some third party database service. Mongo as a service. Redis. I don't care. Just as a service and then put CloudFlare in front of it and see what happens.

Viktor Farcic: [00:24:02]
Yeah, we should do that. We should do that experiment to see. Some kind of tutorial. That would be fun.

Darin Pope: [00:24:08]
That's lightweight. Not only do you get multi-region. You get multi-vendor.

Viktor Farcic: [00:24:13]
Yeah.

Darin Pope: [00:24:14]
Now your application has to be architected in a very specific way. It's got to be simple.

Viktor Farcic: [00:24:22]
Needs to be written written in 21st century.

Darin Pope: [00:24:25]
Yes preferably actually in 2020. Cause it's all in the edge. I misspoke experimental. I knew it was an E word. I forgot it was edge. But man, this is good news for all developers and this is actually great news for Docker I believe.

Viktor Farcic: [00:24:48]
Yes. If you're ACI user, if you're an Azure user, I have absolutely no reservation. Just use it. It makes no sense not to use that feature. Absolutely no sense not to use if you're already ACI user. ECS. I think that it will take at least half a year minimum until that is anything close to be really GA the feature from Docker. So let's say that we need to wait a bit more, but ACI, if you're an Azure user, just go for it right now immediately. Use memory on your laptop to play some games while you're running your containers in ACI.

Darin Pope: [00:25:30]
If you made it this far, next week, we're going to go a little bit deeper, not specifically about the Docker compose things we've been talking about today, but much like the other episode where you were talking about functions as a service, next week, we're going to talk about containers as a service across the big three. There will be weeping and gnashing of teeth. So if you liked our functions as a service episode, where we compared the big three, get your seatbelts ready because next week we're comparing containers as a service.

Darin Pope:
We hope this episode was helpful to you. If you want to discuss it or ask a question, please reach out to us. Our contact information and the link to the Slack workspace are at https://www.devopsparadox.com/ contact. If you subscribe through Apple Podcasts, be sure to leave us a review there. That helps other people discover this podcast. Go sign up right now at https://www.devopsparadox.com/ to receive an email whenever we drop the latest episode. Thank you for listening to DevOps Paradox.