pchico83

Also, how hard would it be to run mutagen on web assembly?

The Okteto CLI lets you develop inside a container, no matter if it is running locally or in a remote cluster. The main advantages of developing inside containers are:

- replicability: development containers eliminate the need to install your dependencies locally, everything is pre-configured in your development image.

- fast inner loop development: native builds inside your development container are faster than the docker build/redeploy cycle.

- less integration issues: your development container reuses the same variables, secrets, sidecars, volumes, etc... than your original deployment.

We would love to talk more about the issues you have. If you want to schedule a call just drop us an email.

Those are really good questions, we have similar requests from our users. We don't have general answers yet, but let me explain a few solutions we have in place. Data: data is hard. There are teams that workout the problem with fixtures and a database per developer. We also have a PoC for cloning namespaces and its data using Velero (this way, you can clone staging on your own developer namespace). We also have teams that have a dev database for all the frontend developers... Service dependencies: we push to define your dependencies using one or more Helm charts. This way, developers have a one-click experience to deploy the full stack on their namespaces. Once the app is running, developers use the Okteto CLI to put on dev mode any service and start synching their local code changes. Some parts of the stack might be shared by all the developers in a common namespace. Third-party APIs: this is also a wide spectrum, but our experience says it is easier to integrate them at the cluster level that in every developer workstation.

Don't take me wrong, I am a big fun of serverless. We use it in production too. But I also think it does not cover a large percentage of the deployment spectrum, at least for a few years. And serverless can also benefit from tools like Okteto

Right, that works. I think that setup does not scale well for large teams or if you are not able to run all your services locally due to resource constraints

You can achieve good isolation with a combination of RBAC, network policies, OPA rules and runtimes like gvisor. We also monitor suspicious activity with Falco. For deeper security, we offer Okteto Teams, which runs on a dedicated cluster, and Okteto Enterprise, which runs on your own cluster.

One of the advantages of using Kubernetes vs a remote VM, which is an approach followed by companies like Stripe, Slack, Eriksson and much more... is that Kubernetes is very efficient allocating resources. Idle dev environments don't consume resources, they can be scaled to zero and restarted in a few seconds, and the same infra is shared by your entire team

Yes, the possibilities with this are very exciting. We have already integrated Gitlab runners in our Application Catalog, and we are working on a UX to deploy a branch and put it on dev mode on a single command.

Thanks for your feedback. We changed our free tier a few weeks ago to avoid abuse, but we will probably improve over it in the following months. Our focus is on development, not on hosting production apps, so I hope we can do more drastically things than heroku.

That really depends on the size of your app. You also lose the ability to run debuggers. Not to mention how hard is to run serverless java applications, which is the dominant enterprise programming language.