‫Now you might still be wondering even ‫after learning some of the key features
‫of Docker, why does Docker need to exist?
‫Obviously, we've been packaging software ‫for decades with tons of other package
‫managers deploying software to servers.
‫So let's talk about it.
‫This video is going to focus on.
‫Three things around.
‫Why Docker and why now?
‫And at the time it was ‫created, there was friction.
‫There was things in the way of us going ‫to the next level of speed and ease of use
‫of the software lifecycle, particularly ‫around packaging, distributing and
‫running all the software we're making.
‫And I like lists of three, I guess.
‫So this main list of isolation, ‫environments and speed, those
‫three areas are what I want to talk ‫about as the three overall reasons.
‫I feel like the containers themselves had ‫to exist and why they're so popular today.
‫first up the problem of isolation.
‫And if we go back to the beginning ‫of my career, back in the nineties,
‫We can start talking about what servers ‫used to be before we had containers.
‫If we go back even farther than just ‫2013, before Docker was created.
‫And we talk about the early two thousands ‫in the nineties, when we moved from
‫mainframe to PC , this might be what ‫a typical admin would look like.
‫I had a couple of servers per company.
‫You know, we, we wouldn't really be able ‫to manage a hundred servers per person.
‫Again, this was like, you know, 2000.
‫And so we would have these ‫very expensive, large servers.
‫That it was rare to consume all ‫their resources with a single app.
‫So then you'd end up with all ‫these apps, just all cobbled
‫together on the same server.
‫And the server became brittle.
‫It became hard to manage because you might ‫need to change one thing for one app and
‫then another app needed a different thing.
‫And then you'd have to manage their ‫different Python versions or your
‫different Apache versions on different ‫servers, just to balance it all out.
‫At the same time, you wanted to ‫put more and more stuff on each
‫server, but nothing was isolated.
‫So all these apps were ‫sharing the same file system.
‫They usually couldn't be multiple ‫versions of that app without
‫lots of complicated hacking.
‫And that was a big problem.
‫Then came VMs.
‫So once VMs became really popular, even ‫before the cloud, we were able to abstract
‫out all of our applications and start ‫putting fewer applications on smaller
‫VMs, all riding on the same large host.
‫So it might look like this and we ‫might start with Chef or Puppet
‫as some way to manage all these ‫growing numbers of servers.
‫In fact, we would have so many servers ‫then by the early 2010s, before Dockers
‫creation, that it was becoming very hard ‫to manage all of them at once you were
‫one single admin, maybe trying to manage ‫dozens, if not, hundreds of servers.
‫Even with the cloud, helping us spin up ‫machines faster, tearing them down faster.
‫It was a lot, it was so much to manage, ‫that it just became too much for a lot
‫of us and the cloud, I think made it ‫better, but also worse because it made it
‫so much easier to spin up so many more.
‫So how can Docker help with that?
‫How can it help us reduce the ‫amount of infrastructure to manage
‫while also ensuring isolation of ‫our workload so that things don't
‫become brittle or hard to manage?
‫Well, if this was our setup 20 years ‫ago, instead of spreading out all
‫these VMs with unnecessary numbers ‫of OSs, what containers do is they
‫give us the isolation, like a VM.
‫It's not quite the same, but we'll just ‫argue for now that it's an isolation
‫layer, where they get their own IP ‫address, they get their own file system,
‫they get their own process space.
‫And so it seems like almost a full ‫VM, but you don't need all the
‫different operating systems so we can ‫reduce our operating system count.
‫Our physical host count.
‫You no longer have to use VMs ‫as the layer of isolation.
‫And it might look like this instead ‫of using SSH, you would use the
‫Docker CLI . Or if you move on to ‫Kubernetes, you could use the Kubernetes
‫CLI and your applications are all ‫isolated in their own containers.
‫This allows you many benefits, including ‫running multiple versions of the same app
‫on the same system, without any conflict.
‫Next up the problem of environments.
‫And obviously we were spinning up ‫tons of OSS, like I talked about,
‫but the number of different types ‫of environments was also increasing.
‫Did you ever hear of works on my machine?
‫It was sort of made famous ‫as a joke by Jeff Atwood.
‫One of the founders of stack overflow in a ‫famous blog post from way back in the day.
‫But this works on my machine idea ‫was a little snarky, but the joke
‫was it is often the developer's job ‫to ensure the application works right.
‫But they don't have all the environments ‫that are necessary for this app to run in.
‫So they just run it on their machine, ‫they test on their machine and then
‫when it doesn't work somewhere else, ‫they say that works on my machine.
‫It's really challenging when we have ‫all these different OSs, and Docker
‫coined this, the matrix from hell, ‫which essentially means for every
‫part of your app, which is above me.
‫And then for every type of ‫environment over here on this.
‫You have a different configuration.
‫Maybe you have to install the ‫dependencies a different way.
‫Maybe the dependencies are slightly ‫different because one has a
‫different version in the other.
‫You have all these different types of ‫environments, and you've probably had
‫to either read or write documentation ‫on how the app that the developer
‫uses on Mac needs to be installed ‫differently on windows, which needs
‫to be installed differently on a ‫Linux server and on and on and on.
‫Now the container image and the ‫container itself became a fundamental
‫abstract or a contract between where ‫it's run and what's running inside it.
‫Much like physical containers in ‫the real world that allow us to
‫ship goods all around the world from ‫almost a hundred year ago design.
‫The goal there was, the people that ‫deliver the physical containers didn't
‫have to know what was inside it.
‫And the people that put their stuff ‫inside the container didn't have
‫to know or care how the container ‫physically got to its destination.
‫Those were an abstraction of now epic ‫proportions of millions of containers all
‫around the world being shipped, and pretty ‫much everything in your house has probably
‫been in a container in its lifetime.
‫The same thing is true of images ‫and Docker containers now.
‫They are a consistent standard format ‫known now as the OCI standards.
‫Those ensure that wherever you run ‫the container, it will be run the
‫same consistent way with the same ‫exact dependencies it was built with.
‫Next up the problem of speed.
‫Now I don't necessarily mean here.
‫The speed of CPU's or the speed of.
‫Those things just naturally get ‫faster over time, but I'm really
‫talking about the speed of business.
‫And when we talk about IT, and software, ‫and the software lifecycle, we're really
‫talking about the ability for businesses ‫and organizations to execute on their
‫ideas, to deliver their software ideas ‫to the customer as fast as possible, and
‫that's part of the software life cycle.
‫Well, it turns out that the industry ‫has been shifting infrastructure
‫and architecture since the Dawn of ‫computing for this exact reason.
‫I made this nice little graphic ‫because you can start at the top way
‫back in the nineties where I got my ‫start and we had mainframes moving
‫to PCs in a distributed architecture.
‫That was largely about the speed ‫of being able to deploy change.
‫You were now able to install DOS on ‫a single machine, without having to
‫wait for the mainframe to be updated ‫to whatever the next Unix version was.
‫We no longer could move all at once.
‫We needed different parts of our ‫organization to move in different
‫directions at different speeds.
‫Hence the Dawn of distributed computing.
‫Then we went from bare metal, the virtual, ‫because we were tired of waiting on the
‫ordering of hardware and waiting for ‫it to be implemented in a data center.
‫We wanted to speed things up and get ‫better utilization of our resources.
‫Virtualization and virtual machines became ‫extremely popular for those reasons.
‫Then data center to cloud was the next ‫step because we were now needing to
‫deploy ideas even faster than our own ‫hardware and data centers could allow.
‫We wanted to run servers that ‫we didn't currently have in
‫minutes, not days or weeks.
‫And the cloud gave us access ‫to near instant resources.
‫Which, Obviously, it's the reason ‫why the cloud is so huge today.
‫And then finally, we're on ‫the next leg of that journey.
‫Moving from the massive host expansion ‫that we had, where we had too many
‫hosts and kernels and operating systems.
‫And now we're going to be able to ‫reduce the number of those, because
‫we're now able to isolate the ‫workloads inside them and safely run
‫them together on the same kernel.
‫I'm including serverless here, by the ‫way, because if you really dig into most
‫serverless platforms, they're really just ‫running containers in the background.
‫It may be a container that you shipped as ‫an image, or it just may be a container
‫that they're running your function in, ‫but they're still running in a container.
‫And this is why I like to talk about ‫faster, faster, faster, essentially what
‫containers and Docker give you is an ‫ability to develop faster, to build your
‫apps faster, to test them faster and ‫to deploy them to your servers faster.
‫Now are you still with me?
‫Do I still have your attention?
‫Let's recap that real quick.
‫So the reason that containers ‫exist is three major reasons.
‫In my opinion, the better isolation ‫inside a single OS, saving us time
‫and OS and dependency management, ‫but also giving us the isolation we
‫need to protect our applications.
‫Then we have reduced ‫environmental variances.
‫So the difference between each ‫environment that it runs is very minimal.
‫Again, usually just your connection ‫settings for databases, maybe some
‫URL paths, stuff like that, ports.
‫And then the rest is all exactly ‫the same as you built and tested it.
‫And finally increasing our speed of ‫change, not just for the software
‫itself, but for the business that ‫wants to implement that software.
‫We're now able to develop faster, ‫build it faster, deploy it, the
‫servers faster and test it faster.
‫All because these container images ‫and the containers themselves
‫are so easy to build, deploy, and ‫redeploy and rerun and all that.
‫So I hope this makes sense.
‫I'll see you in the next video.