Ever since its release in 2013, Docker has quickly catapulted into the enviable position of being the darling of every (operations manager's) eye. If you've been vacationing on Mars since then or simply haven't been staying on top of the news releases such as the one that has heralded Microsoft's intention to support Docker on Windows (a cause célèbre for sure since Docker is originally a Linux specific platform), here is what you've missed.
Docker is a partitioning capability within the address space of an operating environment. By allowing the partition to use the host OS directly even though that OS resides outside of the partition (known as a container), the start up time is substantially reduced as is the resource requirements for the management of the container. (I hope my z/OS readers find this concept to be somewhat familiar.)
Financial people love this because the cost of acquiring licenses for the operating environment can be substantially reduced since, theoretically, every component that is not part of the application itself can reside outside of the container. This means only one Windows license needs to be procured versus one per VM, which is traditionally the modus operandi.
The concept is simple, but how does it work?
Essentially, a special file (called a dockerfile) contains one or more instructions on how a container is to be created. The dockerfile is used as part of a (presumably) automated process to generate the container on the file system, which can contain as little as a single application and its associated binaries. This container (a subdirectory in the file system) is transferred to the target environment as any set of files would be and is started there using the docker run time, which can be invoked via command line interface or an API (typically REST based but there are other implementations).
System Administrators love this because containers are easy to deploy (XCOPY anyone?) and maintain (REST interfaces can be easily integrated into any modern Infrastructure Management platform).
So that's it, isn't it? End of story? We can now throw away all of our Application Release Management platforms like IBM's UrbanCode Deploy, BMC's Varalogix, or CA Technologies' Release Automation, right?
"Not so fast, pardner." This concept falls down when people eye it as a substitute for true application release management. More specifically, we can describe the latter using five of the six question words that everyone learned in high school English:
Who. It should not be allowable for anyone in an organization to deploy an application to an environment. In fact, even for those who should be allowed to do so, there are frequently others who have to approve the deployment decision.
What. For organizations that truly embrace the concept of business agility, deploying a complete application every time is unacceptable. Artifacts deemed as low risk (e.g. content updates) may be deployed immediately while higher risk artifacts will be queued up to be released after much testing and other validation. Docker falls into this category but has limitations, which will be touched on below.
Where. The target environment of a deployment is frequently different from every other possible target environment that an application will touch during its journey from development to production. These differences are typically addressed by making changes to the configuration of the application after it has been deployed.
When. Release windows are not a new concept. Even in non-production environments, a case for establishing a release window could be made since environments are often shared among multiple teams within the same function or even across functions (i.e. testing and development may use the same environment).
How. Probably the most problematic to fully integrate into an organization's operational capabilities, the process of deploying an application is far more than simply understanding how to install and configure it. Integration with ITSM applications to ensure that change requests have been entered and are in the correct state, approval gates have been successfully completed, etc. have to be incorporated into the process of deployment so that the state of the operating environment is always well understood.
Of the five question words above, Docker only addresses one of them and not in the most effective manner possible. Consider the scenario of a well known bank based in Europe. They currently have in excess of a thousand production releases every month. This was accomplished by recognizing that not all production releases are high risk. In the example under What it was noted that certain types of artifacts had minimal impact. As a result, the release of those artifact types could be expedited, which helped ensure that this bank's customer facing assets were always meeting the needs of their clientele.
If they were using Docker, however, the entire application would need to be rebuilt regardless of the types of artifacts that were actually approved for production release. The risk that unapproved binaries could be released into production is simply unacceptable for most companies. And this is only for one of the five items, above - Docker does nothing to address the other four.
To summarize, Docker is an exciting and (relatively) new technology that should be viewed as simply another mechanism that exists within the greater whole of application release. But it should not be viewed as a replacement for a well defined methodology that not only includes the "what," but also includes "who," "where," "when," and "how".
Docker is a partitioning capability within the address space of an operating environment. By allowing the partition to use the host OS directly even though that OS resides outside of the partition (known as a container), the start up time is substantially reduced as is the resource requirements for the management of the container. (I hope my z/OS readers find this concept to be somewhat familiar.)
 |
| Typical Virtual Machine layout (from www.docker.com) |
The concept is simple, but how does it work?
Essentially, a special file (called a dockerfile) contains one or more instructions on how a container is to be created. The dockerfile is used as part of a (presumably) automated process to generate the container on the file system, which can contain as little as a single application and its associated binaries. This container (a subdirectory in the file system) is transferred to the target environment as any set of files would be and is started there using the docker run time, which can be invoked via command line interface or an API (typically REST based but there are other implementations).
System Administrators love this because containers are easy to deploy (XCOPY anyone?) and maintain (REST interfaces can be easily integrated into any modern Infrastructure Management platform).
So that's it, isn't it? End of story? We can now throw away all of our Application Release Management platforms like IBM's UrbanCode Deploy, BMC's Varalogix, or CA Technologies' Release Automation, right?
 |
| Typical Docker layout (from www.docker.com) |
Who. It should not be allowable for anyone in an organization to deploy an application to an environment. In fact, even for those who should be allowed to do so, there are frequently others who have to approve the deployment decision.
What. For organizations that truly embrace the concept of business agility, deploying a complete application every time is unacceptable. Artifacts deemed as low risk (e.g. content updates) may be deployed immediately while higher risk artifacts will be queued up to be released after much testing and other validation. Docker falls into this category but has limitations, which will be touched on below.
Where. The target environment of a deployment is frequently different from every other possible target environment that an application will touch during its journey from development to production. These differences are typically addressed by making changes to the configuration of the application after it has been deployed.
When. Release windows are not a new concept. Even in non-production environments, a case for establishing a release window could be made since environments are often shared among multiple teams within the same function or even across functions (i.e. testing and development may use the same environment).
How. Probably the most problematic to fully integrate into an organization's operational capabilities, the process of deploying an application is far more than simply understanding how to install and configure it. Integration with ITSM applications to ensure that change requests have been entered and are in the correct state, approval gates have been successfully completed, etc. have to be incorporated into the process of deployment so that the state of the operating environment is always well understood.
Of the five question words above, Docker only addresses one of them and not in the most effective manner possible. Consider the scenario of a well known bank based in Europe. They currently have in excess of a thousand production releases every month. This was accomplished by recognizing that not all production releases are high risk. In the example under What it was noted that certain types of artifacts had minimal impact. As a result, the release of those artifact types could be expedited, which helped ensure that this bank's customer facing assets were always meeting the needs of their clientele.
If they were using Docker, however, the entire application would need to be rebuilt regardless of the types of artifacts that were actually approved for production release. The risk that unapproved binaries could be released into production is simply unacceptable for most companies. And this is only for one of the five items, above - Docker does nothing to address the other four.
To summarize, Docker is an exciting and (relatively) new technology that should be viewed as simply another mechanism that exists within the greater whole of application release. But it should not be viewed as a replacement for a well defined methodology that not only includes the "what," but also includes "who," "where," "when," and "how".