Why container frameworks risk taking the focus off development [Q&A]

Enterprises often adopt containers as a way to save money. But they can end up spending time, resources and cash building their own container management framework and in the process getting away from their core business objectives.

We spoke to Kieron Sambrook-Smith, chief commercial officer at cloud application specialist Platform.sh, to discuss why enterprises tend to lose sight of business goals in order to manage containers, and the strategies they can implement to stop distracting their developers from doing what they do best, writing code.

BN: Why are containers gaining such widespread attention right now?

KSS: Containers make application management activities faster, cheaper and more consistent. Compared to the Virtual Machine (VM) approach, containers are lightweight and therefore make much more efficient use of expensive server resources. They also offer numerous other benefits compared to VMs, especially for developers. The contents of a container include everything needed to run an application, which means you can easily move the whole application from test to staging, switch operating systems, or migrate it from the data-center to the cloud. This agility provides significant competitive advantages while considerably lowering costs.

BN: Can enterprises build containers and container frameworks internally?

KSS: Yes of course they can, and managers will be getting plenty of encouragement from their technical teams who want to run head first into this exciting new world of containers. You can build your own Docker-based application management platform, or you can use one of the cloud management platforms (CMPs) -- with Docker Swarm, Kubernetes and Mesos being the most common -- which aim to reduce the complexity of managing containerized applications. However, any enterprise with the will to build needs to have large budgets and be able to find all the right new skill sets to do it properly. CMPs are still complex, and combined with the complexity of the chosen container technology itself, overall build costs can reach epic proportions. Once the build is complete, continuous maintenance costs are also quite hefty. And then to put the icing on the cake; running all this in the cloud doubles up the complexity. Pretty soon, you’re investing as much or more in your workflow and infrastructure than your product or application. The question they should be asking first is, "should we be building out a CMP framework ourselves, or buying a cloud-based PaaS (Platform-as-a-Service)?"

BN: What are the common hang-ups enterprises typically face when trying to build their own container frameworks?

KSS: Developers and engineers will have to learn and maintain 15-20 different toolsets. This underlying services fabric means many single points of failure. For faster time to market, building a repeatable build process for deterministic results is difficult. This covers the main development and deployment process block. To significantly reduce security problems, creating an immutable read-only production environment is difficult. Achieving higher levels of application resilience, i.e. seamless scaling and failover, means building rock solid orchestration -- which is difficult. Your cost economies for cloud compute storage will be 2-3x higher than a PaaS vendor with just a few thousand customers. You will always need highly experienced and expensive DevOps/Support teams to maintain and manage your CMP.

BN: How can an enterprise determine if its apps and services really do require custom-built containers?

KSS: Building a CMP gives you the flexibility to manage containers, and the better you build it the more you can do with them, including all the edge cases you may have… but do you really need all this flexibility? It's very likely you're doing the same things many other organizations around the world are doing, so why not buy something that already caters to the 99 percent of common things you do? Nobody builds their own accounting systems anymore; they buy something that meets the majority of their requirements, and they then bend the edge cases back into a shape that fits the new system. We're talking about solving problems on a wider scale within a large organization of course, not about a handful of business application and processes. But the same issues of perspective exist, in so much as "if we build out our own CMP we will be able to handle every future possibility", as opposed to "it would make more sense to standardize on a set of technologies and build our applications in a more repeatable way and to a more manageable standard".

There are a lot of advantages to standardizing on fewer technologies, and making your build architecture less project specific. You just don't need to approach every new project with a completely blank sheet of paper, and design everything around it to a deeply bespoke level of detail, which containers of course give you the ultimate freedom to do. The majority of your projects can be standardized as much as possible, with a handful of exceptions you treat as unique cases. So ask yourself, is what we’re doing really exceptional? Because more likely than not, it's what most other companies are doing. And therefore, do you really need such extreme levels of flexibility in your container management approach?

BN: What's a better approach for most enterprises to take in order to leverage the potential of containers?

KSS: There are many technologies and application types that will be better off on a PaaS, and that will bring far greater agility and cost-benefit to the business -- literally overnight. There are container based PaaS solutions out there today that are serverless, provide absolute and total abstraction of the underlying cloud, and provide developer workflow from code to live, with no infrastructure management -- just development.

BN: What's the best use of in-house developers' time, resources and talents?

KSS: The best use of in-house developer time is to concentrate them on turning ideas from the business into code. You don't really want them doing anything else, do you? Let them do what they do best, so you can do what you need to do best; launching high-value applications and running beautiful websites, and let a quality PaaS do everything in between.

Image credit: maninblack/depositphotos.com