Why Not Using Containers Is Costing You Money and Negatively Impacting Your Customers
An often overlooked area of significant drain on software engineers' time is the effort to generate, oversee and integrate software changes into the production environment. Organizations not using containers are incurring unnecessary labor costs and failing to reap significant efficiencies associated with software development and delivery.
If you keep hearing about containers or docker at work and the first thought in your head is similar to the above image, this is for you. The goal with this blog is to draw a non technical mental picture that explains why your software engineers will benefit from adopting container technology for software development and delivery. No matter how you look at it, how you spend your time has an opportunity cost. For software engineers, a way to leverage their time more efficiently is accomplished with containers.
Similarities Between Physical Containers and Software Containers
Both physical containers and software containers are packed up with assets to be moved around and this can be verified through a manifest. In both cases, a manifest will give information about the contents as well as loading sequence.
The containers we see everyday in docks, on boats, and attached to trucks have some contents included that is moved from destination to destination. Software containers include source code, assets, dependencies, and the operating system required for your software to run. Once the software container is built, it too can be moved from destination to destination. In the software containers case, it can be moved to different hosts such as an engineers computer, a data center's server, and or a cloud providers server.
Software containers are digital objects with the source code, assets, dependencies, and operating system required for the software to run. The assets are things like images that may need to be loaded up and used when your software is running. The dependencies are other pieces of software that your software is dependent on to run as expected. The operating system is the software that orchestrates the hardware, software, and resources required for your software to run.
This is pretty much where the similarities between the containers in our physical world differ from the software containers in our digital world end. For example, if a Ferrari inside a physical container on a boat from Italy fell off the side of the ship, the car would be considered a total loss even if it was recovered from the ocean floor. For software containers, you can have identical copy's running along side one another on a single host. Also, if the software container crashes, there are ways to have a copy of the container stood up again.
Non Container Software Is Like Just Shipping The Contents of One Container On a Boat
A manifest will include the containers, their contents and loaded order. There may be multiple physical containers with similar contents, but they are still stored in separate containers.
You can think of the host as the boat that ships either container or non container software. Further, using non container software is like dumping the contents of only one container onto the boat. As you can imagine, shipping contents of only one container on a boat at a time is not the most effective way to deliver goods.
Why Containers Improve Feature Delivery
Most companies today use some sort of source code management to work as the central location to store code. Some examples are github, gitlab, and bitbucket. If your team is not using containers it can be problematic just getting your team on the same working piece of software. Not the best use of time and resources for your IT department.
When you don't control the source code, assets, dependencies, or operating system you can run into a seemingly unending number of issues. Depending on how much interaction you have on your team, you may have overheard one of the most frustrating things an engineer can hear.
"Well, it works on my machine"
Without going too deep, you can think of it like trying to watch the latest John Wick on two different TV's. Assume you can fish an old Sony TV out of your grandparents attic and hook it up to some tattered RCA cables from your junk drawer. I think we all could agree the viewing experience is going to be subpar relative to something like the TV's today. Attempting to spend the time to figure out how to improve the old TV's picture would be a waste of time and resources.
You can take the above analogy and extend it to your cloud production environment. If you don't lock in the source code, assets, dependencies, and operating system for your engineers locally, there is no way a cloud environment is going to be the same either. Leveraging containers to create features reduces the configuration variation between your engineers computers and the environments where your code runs. Further, it improves confidence and time to market for your whole pipeline of software delivery.
Conclusion
A host can be thought of like a container ship. You can decide to dump the contents of a single container onto the ship or take advantage of stacking up many containers prior to releasing it from port on its voyage. Further, you can control how everything is packed up inside of your containers to ensure that new features are delivered at a faster pace with consistency through all environments. It is well worth taking the time to migrate your current development practices with the goal of improving customer feature request delivery.