Take, for instance, Azure deployments. You can certainly use the Azure portal to do just about everything. Microsoft publishes loads of documentation on how to deploy, manage, and monitor your systems with the portal. They also provide similar docs for the Azure CLI and Azure PowerShell, giving folks the basics of what they need to do to script out the work.
Similarly, one of the main technologies that DevOps practitioners swear by is Kubernetes (k8s). I cannot envision a standard IT shop going down the k8s path without having some DevOps Engineer preaching it to them, as it's not a simple system at all. Everything configured with text files. Everything managed via command line with "kubectl". Requirements for all types of open source apps to monitor it. It is just hard.
Where I struggle, though, is that management of your k8s system is STILL being taught to just be run by some tech from his/her laptop. There are all kinds of features that allow you to do blue/green or canary deployments. You can gently scale up or down your pods to accommodate heavy traffic times. You can configure all kinds of traffic shaping to route to different versions of the same application running under different pods. Very slick stuff!
But ALL of that stuff is taught to engineers using kubectl! That, my friends, is no different than using any other management utility on your local machine to take care of your systems. Sure, you can script out the commands and run them via some pipeline, but that removes so much of the flexibility of using kubectl locally that I do not believe it's really viable.
In other words, don't believe all of the automation hype around k8s. If you want k8s, have at it, but for the love of God, don't tie your engineers' hands by making them use some pipeline to manage everything. Accept that they need to use kubectl locally so they can actually do their jobs effectively.
No comments:
Post a Comment