New era for app Dev, DevOps, and IT operations

Using containers and orchestrators changes the way we look at building software and defining a software delivery pipeline. Container-based development fundamentally supports what the DevOps folks call a shift left, where developers of distributed systems become more accountable for the quality of the overall solution, meaning the binaries and how they are connected. Hence, wiring up my services in no longer the networking, integration, or operations teams' problem; it belongs to the developers. In fact, the YAML specification for connecting and deploying their application is now an artifact that gets checked into source code control! 

Faster deployment of fixes and enhancements is a prime motivation for containerizing monolithic web applications built with job and .NET. Containerization allows each team to operate independently and deploy its application as soon as it is ready to go, no longer having to wait for all of the other application teams or the next quarterly release cycle.

Containerizing applications can be really helpful for breaking up the organization log jams associated with pre-container monolithic deployments, as each application gets its own runtime container. This container includes all of their specific runtime dependencies, such as Java and Tomcat, for the application to run. Because we are using containers, we become less concerned about the overhead associated with starting and operating similar containers in production by remembering how Docker isolates application execution, while sharing common layers from the filesystem for fast start times and efficient resource utilization. So, rather then having to coordinate across all of the teams involved in a deployment, each team has its own isolated stack of dependencies, which allows them to deploy and test on their own schedule. Not surprisingly, after applications are containerized, it is much easier to independently refactor them.