The good, bad, and ugly of containers has been saved
The good, bad, and ugly of containers
Deloitte on Cloud Blog
A rapid rise in the use of containers has been fueled largely by the perception that containers remove us from cloud provider dependency. While this can be the case, there are many other factors to consider before leveraging containers.
November 13, 2018
A blog post by David Linthicum, managing director, chief cloud strategy officer, Deloitte Consulting LLP
Forrester Research suggested two years ago that 31 percent of enterprise IT organizations had deployed containers1 as part of their cloud operations. However, current research suggests that deployment figure could be fast-approaching 50 percent2.
This rapid rise in the use of containers has been fueled largely by the perception that containers remove us from cloud provider dependency. While this can be the case, there are many other factors to consider before you leverage containers. These factors include the amount of work it takes to “containerize” existing applications, the need for security and governance, and finally the cost of operations (CloudOps).
Review those factors against the core benefit of containers. First, containers are built to leverage a distributed architecture that allows workloads to exist in containers, and work together as a single application. While scaling was once a problem with containers, the new trend toward the use of container orchestration tools, such as Kubernetes, can make clustering and scheduling containers quick and easy. Indeed, most container deployments leverage some type of container orchestration layer.
A second core benefit is portability. It’s true that if you write net-new container-based applications, as well as containerize existing applications, they can be moved from cloud platform to cloud platform, generally speaking.
The downside is the cost tradeoff. If you containerize existing applications as they move to the cloud, you’ll likely spend about 50 percent more time and money than you would if you ported the application without the assistance of a container standard. For example, if you port 1000 existing applications at a projected cost of 30 million dollars, you’ll actually likely spend 45 million to leverage container-based development.
Of course, this differs a great deal from project to project, with some costing a bit more, other projects a bit less. This is largely dependent upon the state of the applications, including technology leveraged, databases, etc. However, it’s safe to say that it’s going to be more expensive.
The cost tradeoff is enough to make some enterprises avoid containers all together. However, many enterprises plan to leverage containers to provide the assurance of portability, as well as the ability to leverage a distributed architecture and cluster managers such as Kubernetes. This approach often proves to be too compelling, and can remove risk, but at a greater cost.
Interested in exploring more on cloud?