Data Centers Developer

Why the biggest container lock-in threat may not be hardware or software-related

Containers are meant to make developers' lives easier, but the expertise necessary to run them at scale can create serious lock-in issues, Diamanti's CEO argues.

Image: iStockphoto/Nastco

With the emergence of modern, containerized applications, developers are moving faster than ever. But moving from development on laptops to production in the data center is a huge challenge for IT. Not surprisingly, then, everyone is chasing a container strategy. Most enterprises are forced down the DIY path because there are no other solutions, piecing together a bespoke computing quilt of people, software, and hardware. The challenge is that the business side of the house, pushing innovation and speed, wants to see results now, not in a year.

The other challenge, less discussed, is how to do this effectively without getting locked into a particular vendor.

Diamanti CEO Jeff Chou argues that it may not make sense for a company to get trapped in a loop of hiring teams of experts (who can be easily recruited away) to build a custom solution that requires a never-ending cycle of tuning and maintenance. In fact, Chou told me, the real lock-in with containers isn't about hardware or software, but rather the expertise your own team needs to acquire.

People are the problem

In so saying, Chou is essentially deflecting lock-in blame from Diamati's container-focused appliance. After all, many enterprises struggle with a container strategy at first and rely on their internal teams of experts to get into production at scale, but what's wrong with that? Every month it gets easier and easier as the ecosystem recognizes the requirement to accommodate and simplify the use of containers.

SEE: Why Kubernetes' platform prowess is a bigger threat to Amazon than its containers (TechRepublic)

In response, Chou asked me: "Have you ever looked at Docker's web site to see what they recommend just for consideration around the challenges you will encounter in networking and storage? It's terrifying." When I asked him to elaborate, he shared this:

Here is the URL to their page on Docker Engine plugins. You have to learn all of these things, every single one of them, to figure out how to solve networking and persistent storage. And your future architecture is dependent on scores of third-party plug-ins? Really? This is just the beginning. It's 10% of what you have to study and master.

In contrast, this is our user manual, which accomplishes the same thing:

$ dctl cluster create my-cluster [args]

$ dctl network create my-network [args]

$ dctl volume create my-volume [args]

$ kubectl create -f my-deployment.yaml

That's it. It fits on the back of a business card.

While self-serving, he has a point. Too often, enterprises underestimate how arduous the journey can be for deploying containers into production at scale. Even so, what about the risk of hardware lock-in? Chou was unperturbed: "Look, for buyers who are obsessed with avoiding hardware lock-in, I'd argue that our platform can at least get them up and running and then grow while they build their team of experts and create their own DIY implementation for the future."

The prisoners' dilemma

That team of experts, however, is a problem, according to Chou. Most enterprises he encounters don't have a viable container strategy. Not yet, anyway. Each has to balance not merely developer needs, but also IT requirements. There are at least three ways to juggle this, Chou explained to me.

SEE: Learn Docker from Scratch (TechRepublic Academy)

The first group knows that they need a strategy but don't know where to start. This group is overwhelmed by solution choices and the universe of containers in general. The next group is customers who know enough to be dangerous. They went down the container path and hit their heads against the wall time and again. Their container strategy is fraught with pain. The third type is customers who are well versed in new technologies, who have adopted containers, and have a solution. But it's not great.

These first two groups buy from Diamanti, Chou told me. The third group, however, does not, and ironically that's the exact group that experiences human capital lock-in, he says. "Their amazingly talented team has built a container strategy, and they publish amazing LinkedIn profiles. Well, they get hired away quickly by competitors."

This, Chou said, is "human capital lock-in." It's a matter of IT talent that becomes celebrities who are bigger than their jobs. As such, Chou posited, "When they walk out of the door, so does your container strategy. Few employers see this risk coming."

It's ironic that containers, which promise to make applications less dependent on any particular infrastructure provider, yield an array of lock-in possibilities. But in a world increasingly fashioned by developers, avoiding Chou's human capital lock-in seems not only impossible, but inadvisable. A Diamanti-style appliance may require less developer horsepower to build a successful container strategy, but that just means an enterprise's developers are going to have to do heavy-lifting elsewhere.

Also see

Visit TechRepublic