When containers are not the answer

Containers seem to be the default approach for most systems migrating to the cloud or being built there, and for good reasons. They provide portability and scalability (using orchestration) that is more difficult to achieve with other enabling technology. Moreover, there is a healthy ecosystem around containers, and a solution is easier to define.

However, much like other hyped technologies these days, such as AI, serverless, etc., we’re seeing many instances where containers are misapplied. Companies are choosing containers when other enabling technologies would be better, more cost-efficient solutions.

Indeed, I think we’re leaving millions of dollars on the table by choosing a technology that’s not the right fit. We’re going after points for hype and another trending technology on the CV.

The core downside of containers today is the overapplication of container development and the migration of existing applications to containers in “application modernization” projects. It’s not that containers don’t work—of course they do. But many things “work” that are hugely inefficient compared to other technologies.

Most companies are chasing the benefit of portability for a workload that is unlikely to ever move from its target host platform. Also, and most importantly, they do not understand that to truly take advantage of what containers offer requires a complete re-architecture of the application in most instances, which they typically didn’t do.

Net-new development has this problem as well. Enterprises are spending as much as four times the money to build the same application using container-based development and deployment versus more traditional methods. Also at issue, the container-based application could cost more to operate by using more cloud-based resources, such as storage and compute. It also costs more to secure and more to govern.

When evaluating containers, here are a few core points to consider:

  • Focus on returning value back to the business. It’s the old story of developers and engineers who don’t look out for the business as much as they should. Don’t follow the hype.
  • Don’t overstate benefits, such as portability, that may never be used. If it costs twice or even four times the money to get there, what are the chances you’ll ever move an application?
  • Understand operational costs. Containers may cost more to operate in the long term. I’m not saying don’t ever use containers, but understand the true cost of maintaining them over the years.
  • Use architectural best practices. Applications often need to be redesigned for containers to be effective. “Wrapping” something doesn’t give you efficiency by default. 

This is a cautionary tale to point out the need for a healthy skepticism about any technology. I’m using containers as an example, but it could really be any technology. Keep an eye on the value returned to the business, and you’ll likely make the right calls.

Copyright © 2022 IDG Communications, Inc.

Source