[nhoughto]

“developers shouldn’t install Kubernetes locally as this requires hardware resources and deeper knowledge about this technology”

Totally disagree with that, developers should be sympathetic to the environment there code runs in, definitely spend the 5 mins to install kube through docker desktop and be done.. shorter feedback loop then too having it run properly local.

[Ramiro]

Ramiro here (co-founder of Okteto)

I agree that "developers should be sympathetic to the environment there code runs in". But that's about where the code runs in production, not where the developer runs it while coding. That's why we are pushing towards using remote clusters, so that you are developing on an environment that's as close to prod as possible.

In my opinion, Minikube, Docker for Desktop, Kind and others present two big challenges: First, it's not trivial to run them locally. They require extra memory, cpu and battery, they have issues starting/stopping (I don't use my local cluster that often, and I've spent way more than 5 minutes just starting/stopping/troubleshooting it). And, at the end, they have different components (load balancers, disk, network) and configuration from a remote kubernetes clusters, creating more dev-prod skew.

Second, the feedback loop is not that fast. You still need to either mount volumes (which is slow if you handle multiple files, like node's node_modules folder) or end up building containers to validate your changes. Sure, you don't have to push and pull them, but what if you didn't have to even build them?

[nhoughto]

Yeah I guess that might work for some workflows, we try and keep local as close to prod as possible, and how we build local artifacts that we test as close to how we build prod artifacts. Giving us a fighting chance of being able to repro prod bugs for example, if a team was making a different set of trade offs that would work.

Thinking about it more, we have had the problem of docker desktop using a bunch of memory and slowing productivity, so shipping that giant vm elsewhere would solve for that, can I spin up 16gb+ namespace/env in okteto?

[Ramiro]

If your kubernetes cluster can support a 16GB pod, it will work with okteto.

That said, the pattern we recommend to follow is to split it into smaller dev envs. That makes it easier to manage, and allows you to have dedicated dev envs for different parts of your app (e.g. your API dev env and your frontend dev env).

[nhoughto]

Ah I see, I assumed it was a okteto managed cluster. I should rtfm more =)

Splitting parts of an env is against our principles tho, put everything together and test against real endpoints where possible, there is no api dev env or web or app, there is just a dev env.

[Ramiro]

There's two parts to Okteto. The open source project (https://github.com/okteto/okteto), which launches development environments and works with any kubernetes distribution.

And Okteto Cloud (https://okteto.com) our development platform for Kubernetes Applications, that integrates everything you need to build cloud native apps (development environments, a build service, a private registry, SSL endpoints, etc...)