Very cool! This is a great example of how ephemeral environments can help for a lot more than just fast inner loops or manual verification.
49 karma · joined February 25, 2011
I've heard great things about Matrix. Peeble's founder, Eric, was building Beeper, a chat app with a similar purpose to what you describe (it recently got acquired by Wordpress). I believe that the core was built on top of Matrix, so you might be up to something there.
Building auth stacks is not trivial and is not what will make your SaaS successful. The more you can leverage experts to focus on what makes your SaaS special, the better.
The main library (the one by the Civic Center) closes way later than the rest. Good spot if you're working alone.
I've played with shell autocompletion before, but this way easier to use. Good luck!
1. Register each dev env with the provider. Dev Envs can have predictable URLs (e.g in okteto cloud it's the name + namespace + domain), so you can directly register it. This works well with self-service webhooks like Github.
2. Have a proxy that routes to the right dev env. This works if there's a key you can use for the routing, like a user ID or the subscription.
3. Have a proxy that duplicates traffic and send it to all the dev envs.
I'm curious wow do you solve this on the DTAP env. Are you registering a single endpoint with the webhook? Then how does it reach the separate dev envs? (or do you have a single, shared dev env?)
> We need to maintain separate profiles for running apps in debug mode, to expose the java debug port to the host and supply the right JVM options
Yes, you should. This is something you can do in the 'okteto.yml' file. You can specify different environment variables, different commands and even a different image (e.g. an image with your dev tools and debugger, which you don't need in prod).
> Latency
This can be a challenge, for sure, specially if you have a bad network connection. In our experience, debuggers and incremental file sync don't require too much bandwidth.
> Don't leave your debugger paused for too long
This has happened a lot to me. In the latest version we introduced a switch to disable healthchecks during dev time so avoid this.
> And forget about trying to debug something that happens on application boot
This is the trickiest definitely. I've had luck by pausing the debugger on attach (on go and node you can do this), but it's not the most optimal.
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...)
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).
This is an area where I'm particularly interested in. We are constantly experimenting in ways to better integrated it into our idea of remote development environments.
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?
That's where caching, container layers and build stages can help a lot. Specially for development, where you might be rebuilding the same container over and over.
We have a fork of buildkit where we are implementing multitenant protections, authentication, etc ...
When you are using Okteto Cloud to run your apps, you get all this:
- Build is run in big servers in the Okteto Cloud infra. It's based on buildkit, and it's heavily cached and optimized towards development scenarios. The build context is sent from your local machine to the service and everything else happens there. - The registry in the same infrastructure as the build services. The image is pushed from the build service to the registry, instead of from your machine. - The deployment runs in the same cluster as well, to speed up the time it takes to pull the image.
You can also use "okteto push" with your own infra, by providing your own buildkit service, registry and k8s cluster. Depending on where they are located with respect to each other this might be slower or faster (e.g using dockerhub for registry will be slower than using a dedicated one in your own cluster, mainly due to network speed and proximity).
The biggest benefits of this approach are being able to move all this to the k8s cluster, where you can leverage more compute power and faster network transmission. That way you are not pulling and pushing images across the internet.
We recently wrote a post on how to integrate Okteto with NodeJS apps, in case anybody wants to try it out: https://okteto.com/blog/how-to-develop-node-apps-in-kubernet...