Kubernetes complexity is forcing end-users to decide if they want to manage their container deployments themselves or rely on established platforms from vendors like VMware and Red Hat, which come with a form of lock in that they are trying to avoid.
During an end-user panel discussion at this week’s virtual KubeCon + CloudNativeCon North America 2020 event, that dilemma was presented as one that continues to drag on the Kubernetes ecosystem. This despite the community’s ongoing push to make Kubernetes boring.
“Obviously everything can be improved, and I think it's a never-ending journey to make developers more efficient,” noted Nicolas Chaillan, the chief software officer for the U.S. Air Force. “That being said, you also have to pay attention to vendor lock in … so we don't end up completely depending on some of these tools, particularly if they're not open.”
Chaillan, who has been a strong proponent of the Cloud Native Computing Foundation’s (CNCF) open source model, said that it’s now a mandate that for all of the DevSecOps teams at the Department of Defense (DoD) to base their work on open source and projects like Kubernetes and the Istio service mesh.
However, Chaillan’s group also works with 100,000 people, most of them contractors, and that makes for a training challenge that is exacerbated by vendor lock in.
“We see a lot of different training hubs coming out from given companies, but often they'll be aligned to their products and so that's not something we were interested in because we don't want to be locked into a single product, whether it's VMware, or Red Hat, or anybody else, I don't care,” Chaillan said. “The danger often is some of these companies refuse to work on products that are not directly aligned to their … company's products, and so like a Red Hat consulting service person would not be comfortable working on Rancher where Rancher would be just fine working on OpenShift … so we have that kind of issue.”
Michael Lieberman, a senior innovative engineer and VP at financial firm Mitsubishi UFG, echoed Chaillan’s vendor lock-in concerns, adding that his group is also looking for easier ways to alter established Kubernetes-based platforms.
“A lot of them have their opinion set already and how they want your application to look … and we want to be able to take our opinions and sort of layer them on top of these tools instead of sort of some of these tools trying to enforce their opinions on us,” Lieberman said.
Ongoing Kubernetes Complexity ChallengeThis complexity challenge is continuing to play out in enterprise environments. A recent survey from D2iQ found that more than half of IT decision makers and more than three-fourths of developers “claim that Kubernetes add-ons cause a great deal of pain and introduce complexity” within an organization.
That pain is also making it harder for enterprises to attract and keep qualified developers. The survey found that 38% of developers and architects said “their work makes them feel extremely burnt out, with 51% stating that building cloud native applications makes them want to find a new job.”
Comments