Comment by siliconc0w
2 days ago
You're always trading off speed with fidelity. Usually, trying to maintain a local integration environment is going to become too slow and expensive. The problem isn't even necessarily Kubernetes, but as dependencies increase it just gets slower and slower to try and run a copy of the world locally.
I like a fast svelte dev environment with something like docker-compose which might require some mocked out dependencies to keep things fast and then using Kubernetes for other environments once I have local tests passing.
You can always swap out some of those services for always-running prod or dev-in-the-cloud services.
I have a big mix of setups for my projects. I like Vite+Bun (client+server) for smallish projects because the dev servers start instantly. But then I have to remind myself how to actually productionize it when it comes time for that, but it's not too hard.
Then sometimes I need to bring in a database. I don't like running those locally, undockerized because now you're locked into one specific version and it just gets messy. So sometimes if I'm lazy I just connect to my prod database server and just create a separate dev DB on it if needed. Then I don't need to start and stop anything, I just connect. Easy.
For a big complex app you can mix-and-match any of the above. Run the services that you need to iterate heavily on locally, and just farm out the rarely changing stuff to the cloud.
I think that's a fair point -- you're making a tradeoff. And the best part is that you don't need to choose one or the other.
In my case, I find that I prefer having higher fidelity and simpler service code by using Tilt to avoid mocks. It's also nice for frontend development because, using a Kubernetes ingress, you can avoid the need for things like frontend proxies, CORS and other development-only setup.