| This is a garbage quality post but the underlying premise I think is fair. I’ve heard much more reputable people like Kelsey Hightower make similar claims recently. Just as a matter of personal interest I spent the last year looking into the question of how close could a small and possibly even competent one person team get to doing “cloud native” “best practices” from day one if they made the right choices. My assessment is that, we as an industry are right now, entering an interesting stage where this is starting to look vaguely possible thanks to some recent offerings. Running Kubernetes for example has in just the past couple of months potentially become a genuinely hands off exercise thanks to GKE Autopilot where you can just throw containers at it and it will just work and do the right thing by default. Granted this is only one part of the problem however. The other super powerful component of K8s however is it’s idea of a reconciliation loop. People are starting to see this as not JUST a tool for managing application lifecycles and scaling but now as one of the key new primitives in automation. If you can specify: 1. The current state of a system. 2. What code needs to be run in order to transition from one state of a system to another Then you can create a custom resource definition in order to manage that for you. This is where you’re starting to see a lot of interesting new things emerge. For example while tools like Terraform are great to setup infrastructure they don’t have a solution for say when someone starts manually adding, removing or otherwise configuring your infrastructure outside of it. That’s a great example of a problem that can now just go away and this is where you’re seeing a new generation of tools emerge in that space like Crossplane. Now I can not only specify my infrastructure as code, have everything go through a gitops style workflow but I can also rest assured that I won’t ever have a configuration drift problem again. Other cool areas I’ve noticed emerging at the application development level include projects like Dapr which is one of the best things to come out of Microsoft in years I think. But for those who are unfamiliar with it their promise is again built on top of Kubernetes custom resource definitions and says here is a single standard API which you can use and we will do pretty much any task relevant to distributed applications for you using best practices and you never have to think about it or touch it. So this means I as a developer or an operator am no longer thinking about things like service discovery or having to set up read replica databases anymore etc. Finally, one more piece of the puzzle I’m excited about is a project called “open application model” which once again is built on top of custom resource definitions and let’s me as a developer to just specify my various applications as common components and traits I.e this is a service and it should be available to the outside world. With that information it has everything it needs to once again just go and do the right thing and I never need to think about it again. Basically, I agree with what is said here even if it’s poorly written. I don’t think right now is necessarily a great time to go and become a Kubernetes expert because the need for them is likely to become much smaller in the future as organisations instead move to various standards that CAN be automated in predictable and reliable ways. P.S Open policy agent is another powerful abstraction that plays a key part here that I haven’t mentioned. But this is a great place to put all of the logic that defines “what is the right thing to do (especially if it is specific to my business)” and the rest of the tools I’ve mentioned here can use that. But normally coding this stuff manually at scale across distributed systems would have become a nightmare. |
I never heard of Autopilot before but it sounds like what AWS has had for a while with Fargate where you don't need to manage your worker nodes, instead you define what compute resources you want and what tier of instances they should run on (CPU optimized, general, etc.).
Things like this are definitely a very welcome change but running a production workload on Kubernetes is still no where near a hands off exercise, even with the cluster creation and scaling aspect abstracted away. There's still learning, using and applying Kubernetes.
Sure once you have the knowledge and experience you might only need something like 200-250 lines of YAML to run a production grade stateless web app service on your cluster including a few bells and whistles like external-dns but getting there isn't hands off and things are changing, then there's also figuring out how to automate all of this into a CI / CD pipeline and ensuring any services being built are architected to run in a load balanced container friendly way (using object storage, generally stateless, env variables, etc.). Not all of these things are a given.
I just mostly went through this path in the last few months while working part time for a client. I'm basically at the point of wrapping things up with external-dns and it's taken around 80 hours to get there. That's not including automating all of this in CI yet too. In end there's no way I would classify myself as an expert either, there's still a lot left to learn, but that timeframe includes learning Kubernetes from scratch after already having worked with Docker / Ansible for 6+ years and being comfortable with sysadmin / ops tasks in general. It wasn't the hardest thing in the world but it wasn't anywhere near hands off. It was like learning any other complex piece of software. A crazy amount of trial and error while reading the docs and scouring the internet for as many resources as you can find.
The same process happened with Serverless too. It took a different amount of time to get a function running in a production ready way but there were a ton of things to learn along the way.
In both cases this required spending a lot of time learning things that a lot of developers either don't care about or don't have time to learn because they are busy developing business features. IMO the demand for ops style roles will never go away, even going with the highest level of abstraction with Heroku requires spending time setting it all up and keeping things in check.