5. The dial between experimental and boring will need regular tuning
Lachhman points out that using Kubernetes no longer qualifies as experimental or “bleeding-edge” in and of itself. The project is about to turn five years old, and it’s a stable, reliable platform.
That said, the ecosystem is constantly evolving: Think about things like operators, the cluster API, GitOps, and the aforementioned service mesh tools. Kubernetes teams will need to decide how they will turn the knobs between innovation and control, Lachhman says, and that’s a management consideration all its own.
On the one hand, most teams – especially in earlier stages of their adoption – are probably better served by erring on the side of “boring.”
“Take a page out of the Site Reliability Engineering profession by keeping approaches simple,” Lachhman says. “Understand that not being on the latest beta or Special Interest Group [SIG] in the CNCF is not detrimental to you and your Kubernetes workloads.”
On the other hand, you don’t want to miss out on new capabilities that might solve real problems. “Core to platform engineering is offering choice,” Lachhman notes. So you’ll have to decide the approach that is right for you.
“From the SRE [perspective], weighing options of more tried-and-true approaches versus new approaches inside Kubernetes is a radio dial always being turned,” Lachhman says.
6. Rigid development doesn't play well with containers and orchestration
Modern IT tools work best with modern IT practices and culture. This can be as much a people management issue as it is a technology management issue.
“Kubernetes is all about rapid development and deployment,” says Yankovskiy from Zettaset. “Some organizations may need to transition to the DevOps model to realize the full benefit of Kubernetes.”
This principle also applies to applications themselves. Not everything’s a fit for containers and orchestration; the “lift-and-shift” is not always the best strategy for migrating legacy applications to containers and running it with Kubernetes. In fact, the better choice might be to not migrate that app at all.
“Not everything has to run on Kubernetes,” Yankovskiy says. “Kubernetes is a tool for a job. It is good for many things, but with many legacy applications migrating to containers, it is important to understand that not everything must run in containers.”
7. Don't try to be a hero
Learning is a good thing, but so is knowing your constraints. Otherwise, managing Kubernetes over the long term may become a bear. Know when to enlist outside help.
“Avoid ‘resume skills chasing’ and know when to delegate complexity away,” Lachhman advises. “Building your own clusters from scratch and running conformance tests every time you deploy might seem the golden standard to do, but handing off that complexity to a PaaS or Kubernetes vendor might not be such a bad idea for most workloads.”
[ Want to learn more? Watch the on-demand webinar: Kubernetes 101: An introduction to containers, Kubernetes, and OpenShift. ]
