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