Hacker News new | ask | show | jobs
by nhoughto 2234 days ago
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?

1 comments

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

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.

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