pchico83

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

Hi Jacob. I am one of the founders of Okteto (https://okteto.com/), a remote development platform for Compose and Kubernetes applications. We use Syncthing to sync code between the developer laptop and pods running in Kubernetes. I would love to know your thoughts on the strengths and weak points of Mutagen vs Syncthing for this use case. Thanks!

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

Would something like Okteto Enterprise fit your needs? https://okteto.com/docs/enterprise

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.

Sorry if you find it patronizing, I tried to describe the problem in a general way to make it interesting for the general reader, independently of how we solve the problem.

Okteto, in particular, does not impose any IDE. It works with online IDEs, vscode, vscode remote, IntelliJ, IntelliJ remote... it is one of our core values. What we move to the remote cluster is the development environment runtime.

How do you develop your functions? Using Kubernetes as a development platform also applies to serverless, we have articles with Cloud Run and OpenFaaS: https://www.openfaas.com/blog/painless-serverless-developmen...

The idea is to have replicable and production-like dev environments, no matter your deployment tool

why? we offer vanilla kubernetes namespaces. There are no hidden dependencies

I haven't tried rust, but I usually work with Go. The performance really depends on the resources assigned to your container. Okteto Cloud gives you 4 CPUs and 8Gi RAM. Also, it is important to persist dependencies and cache information using volumes to take advantage of incremental builds.

Github codespaces is a step forward to eliminate local setup and have replicable dev environments running in containers. But for true cloud-native applications, you would need a kubernetes namespace to run other services, databases or access the kubernetes API. This blog post explains our vision of cloud-native development at www.okteto.com

You can also use "okteto up", which syncs your local code to kubernetes pods. "okteto up" is more oriented to speed up the inner loop cycle.

I share the vision of this article. We are working on the same problem at Okteto Inc.

As an ex-docker employee, I love to work with docker-compose and I agree it is usually a good enough abstraction for development.

But it is not only about the tool, I think the future of development is on the cloud and Kubernetes is a perfect fit for ephemeral dev environments:

- You have unlimited hardware and network resources but efficiently shared by all your team.

- You can share endpoints for fast validation and easier integration with external systems and webhooks.

- You reduce k8s integration issues.

- You have access to infra services like service mesh, logs aggregators and metrics from development.

We just need to improve our dev tools to reach a great dev experience on remote Kubernetes clusters. I have been working like this for 2 years now and I can say my dev experience is much better than before. I have replicable dev environments, I can spin a new dev environment on a new namespace for each git branch, switch dev environments with a single command, and deploy my changes instantly.

And 5G is just around the corner and it will make the experience even better.