I hear a lot of chatter about the technical benefits of Docker. Typically these are coming from the Development and DevOps communities. However, what I am not hearing a lot about is the business justification for Docker. Especially from within the middle and upper ranks of IT management
Sure, Docker is the new cool hotness that has taken the infrastructure world by storm. But at the end of the day, at least in capitalistic organizations, there needs to be a compelling business reason to move to a new trendy technology.
So what is the compelling business justification for Docker?
I think there may be a few. Lets explore some of them.
Run your application anywhere. I think this may be one of the harder business justifications. Let me explain. If you look at this from the angle of that I can run my app, in any cloud, or in my datacenter or on my private cloud, that sounds great. I believe you would get some economies because of the low requirement for specific server configurations for a particular workload.
But in reality the management that you might need to move your workloads / containers and the system that you would need to arbitrate, and understand the cost savings of one cloud vs the next vs capitalization is significant. So in theory, this one sounds good, but is probably one of the more difficult to do well, provided that your app is a candidate to either run anywhere, or burst into the public cloud when capacity is needed. In other words, there are no overwhelming compliance, privacy or security requirements that it cannot be run anywhere.
Server optimization and density – or running more stuff on one server. The business justification here seems pretty simple. I can run more containers on a single server than I could individual workloads. This is most likely because containers are lighter weight and there is less probability that there will be contention between the workloads / services running in the containers, versus running services in the server OS.
We see this with many users in QA test. Here, the need to spin up a number of different environments for testing is one of the biggest challenges. So yes, to build out your test grid, on fewer QA resources seems like a reasonable thing and thus, if you use less server resource, then you spend less money.
I actually think the bigger business benefit comes from the fact that the QA team can spin more test environments faster, thus decreasing the time involved to do the testing, rather than server consolidation. But in any event, there is business justification here.
Cost – eliminating expensive licensing, a la VMware. Ok, I get it. Run containers on the servers that you already own, eliminate VMware licensing and save money. Actually, this may be one of the simpler business justifications for Docker, in that VMware’s share of the IT budget in some shops has grown to be significant over the years. This move does not mitigate the need for container management and automation, especially one that is enterprise grade (scale, security, etc), but in fact having a similar set of management tools on top of Docker is a prerequisite for migrating from VMware to Docker and achieving massive CapEx benefits.
Increase the speed and reliability of product delivery – I believe this may be one of the strongest business justifications for Docker. What if I could optimize my dev, QA and production teams? Dev can focus on software innovation and push that easily down a continuous deployment pipeline.
Then, I am increasing my competitiveness in the market for results in improvements in market share and revenue.
So this is not really a cost saver, but a top line improvement! If I can innovate faster than my competitor, and get some of the benefits mentioned prior, like QA test density and running the workload where it makes the most sense, then I can maximize the financial benefit of Docker.
In this model, you would want to track certain business metrics, like:
- rate of innovation changes
- deploy time tracking or getting new code deployed from dev to QA and Production
- success rate of deployments.
These are classic DevOps business metrics that would be needed in helping bring this huge business justification for Docker to fruition and exactly the type of management system that StackEngine is building.
In summary, we here at StackEngine believe that Docker and containers are not only a major technological innovation but provide significant business cost and revenue improvements, if approached in the right ways. Like providing the needed enterprise worthiness (scale and security) and providing a collaborative approach to increasing the speed of product delivery and being able to measure it.
I would love to hear feedback, especially from middle and upper management on the thoughts presented above. Where do you see significant business justification?
The post Business Justification for Docker appeared first on StackEngine.