This week I had the opportunity to attend Microsoft Ignite in Orlando. I will be making my best effort over this week to document and communicate out my learnings each day. Today was day zero and I was able to attend the pre-conference training “Container Fest.” Overall, I was a little disappointed because the session was very lecture heavy and light on demo’s and labs, me and my crew even got kicked out at 6 PM while we were working on the lab :(. Don’t get me wrong, I learned a ton, and this class validated my assumptions of containers, they totally rock!
It is cliche, but containers are designed to “build once, run anywhere.” My entire career, I have been chasing the dream where a line of code it written and it works anywhere I want it to work. Despite all my unit testing, automated deployments, and documentation, production applications break because changes were made to the system, network, software, etc.
Infrastructure as code is a requirement with containers. Your server configuration, network setup, patching level, everything about your container, is defined in code. You have all the benefits associated with that, such as rapid deployments, scalability, and change management. Most importantly, everyone that is working on a product or solution is speaking in the same language and using the same technology stack to solve the problem at hand.
There is still overhead to maintaining and operating these containers, and their hosts. You still have operating systems that need to be patched and rebooted. Even though there is zero down time, if done correctly, you software stack will still be updated and you will still need to keep it up to date. If you set up your build and deploy process, this can be minimal, but it is still a consideration.
I see two situations where containers are a no brainer. First is if you value portability. Containers run on prem, and in any public cloud. If you value, or part of your cloud strategy is portability or diversification, containers enable it. Second is for applications where you do not have sufficient control over the build and release process, i.e. third party software. I still have a lot to learn about how to make this work, but containers can make updates to systems seamless and automatic. More importantly they also can make changes to the underlying software stack equally seamless and automatic. I cannot count the number of times that a operating system update had some negative impact to a production system that I had to deal with the next morning. It is not that the people applying the updates are doing anything wrong, they just don’t know everything about every system. Containers have the possibility to automate and improve the delivery of changes to 1st and 3rd party system, and I intend to explore more and learn how.