So if containers are this big, new, complicated paradigm to learn, why bother with it? Slightly faster run times than VMs are nice, although these days, powerful computers are so cheap that it might be cheaper to buy faster servers than to train a development team on how to use containers.

The thing with containers is that their benefits do not stop at being faster than VMs; they start there. A development team might indeed even work faster and more efficiently once they're comfortable with using containers. This is because containers can streamline and even make possible various development and operations tasks, such as testing, DevOps, and continuous deployment. I've seen it argued very well that the biggest benefit to containers is not the security or speed of your app, but rather, the speed with which you can build, test and deploy new features when using them.

So we'll talk about how containers can help you, both from a technological standpoint, but also from a management perspective.

The first thing that containers enable is fast testing. Containers can be built and spun up very quickly, and code inside a container will run the same pretty much no matter what computer it's running on. As such, if you build an app with containers, every time you check in code, you can quickly build a new container with that code and play around with it. If you run your app in containers in production, then the containerized app that a developer has on their computer is exactly the same as the app that will run on the cloud.

Gone are the days of each developer managing the dependencies on their computer to ensure that the app that they're working on can run locally. This quick feedback loop for your developers can lead to better code being written, and for less need for troubleshooting when strange bugs pop up that are caused by the developer having a slightly different version of the software on their computer than that you're running in production. In addition, this makes it easier for others to get up and running with your code as well.

For instance, an open-source project might include a Docker file as part of their GitHub repo. This way, anyone who downloads the code to their machine in order to edit it can get a version up and running to test their changes with just a few Docker commands, whereas before, the developer would have to set up a new VM on their machine which followed a number of instructions on how to get exactly the software that the open-source project needs to run. Now they only need to run one or two commands and the rest is done automatically by Docker.

For instance, this small open source project makes it easy to test the project by spinning up containers for the databases, so you don't have to install a network the database software on your host OS. This can be useful within a company as well. You can quickly get non-technical people testing new software once they learn the basic Docker commands. Imagine a design or marketing team that feels empowered to test and give feedback on your alpha builds without needing help from the developers. Simply send them a new Docker file and ask them to build and run it. Containers are also really useful when it comes to the DevOps process.

DevOps is a way of doing development work where the developer and IT teams work closely together, and as much of the process is automated as possible. For instance, with continuous deployment, any accepted change to the main code base is deployed to the users, and this process is made much easier with containers. Container systems are immutable, which makes upgrading them easy. Without containers, you may have to deploy the new code by taking machines offline, updating the app on that machine, and then spinning it up again, doing this for each machine until they're all running the same software. With containers, you simply build a new image with the new code and push that out to your cluster. You never update a container itself because they are unchangeable or immutable.

Your orchestration software will direct new traffic to the new containers, and as the old containers are no longer needed, because they're no longer seeing new traffic, they'll be shut down. This way, your users experience a seamless transition to the new software, and you don't have to worry about periods of having fewer servers online during the transition. Docker, in particular, is very easily automated, having been designed with that automation in mind. It's easy to plug Docker into your CICD process so that containers are built from new code, tested and then pushed into production all automatically. Finally, once an app is up and running, this same orchestration software makes scaling the app to the amount of traffic it's seeing very easy. It's kind of like a load balancer in a typical cloud setup.

The orchestration software will look at what containers are getting sluggish from too much traffic and will spin up more of that kind of container. If you've built your app using microservices, as is suggested when containerizing an app, then the orchestration software has a lot of fine detailed control over what gets spun up or down.

Maybe only your database server needs more help. The front end is fine. It takes some time for teams to containerize an app and update their workflow to work best with containers, but once they do, they should be writing better code, getting more feedback from different parts of the organization, and deploying and managing the apps more easily. In the next lesson, we'll explore what it actually takes to containerize an app.