[nickjj]

> 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.

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.

[mhoad]

I think maybe I didn’t do a good job explaining the various abstractions and how they work together but in the scenario I outlined above combining those things together you most certainly are not going to be handwriting K8s yaml files and I don’t think that’s going to be a common thing to do in the future let alone having to configure DNS yourself etc.

These are all very much things that can be and are in the process on being abstracted away.

We are actually fairly close to a point now where you as an application developer can just describe your apps and how they work and be basically done.

Knowing how to use kubernetes is not going to be any kind of a requirement in the not too distant future.

[nickjj]

> We are actually fairly close to a point now where you as an application developer can just describe your apps and how they work and be basically done.

I don't know, DO launched their application deployment platform a few months ago and it's an abstraction on top of Kubernetes.

It's still in its early stages and while I use and love DO I didn't find this app platform to be near ready to run a complex web application on. It was really nice for running a hello world example web server and it sure looked great on a few demos videos but as soon as I tried to hook up a real application with a few moving parts I got pretty stuck to the point where I was hard blocked by it.

I'm sure DO's app platform will improve over time but people and organizations have applications to deploy today. Waiting around until the next thing is around, fully baked and battle tested isn't an option for most. It's almost always worth learning something fairly stable and implementing it and then incrementally changing it over time. If you always wait around for the new hotness you'll never ship anything and when you do, you'll always be in the most dangerous situation of being patient zero with limited documentations and bugs.

Heroku for what it is, does a good job but they also have 14+ years of experience and likely hundreds of thousands of dev hours behind it to create its abstractions and iron out the kinks, and despite that it's still not something everyone flocks to without question.

I think we have a very very long time to go before a serious contending solution comes along that perfectly abstracts away app deployment at scale to specifying a few configuration properties.

[nosvince]

>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.

I think that's what this article alludes to. You won't need to manage Kubernetes with an automated container orchestration platform that just needs your container or cluster. If an automated system can take care of the management, then the "cloud management" part of DevOps is greatly reduced.