51–60 of 67 posts
The pitch is kinda funny to me: > Modern apps are made of too many services. They're everywhere and in constant communication. So we made tooling to make it easier for you to make more of them!
Great talk about this... https://www.youtube.com/watch?v=j2AQ9eTZ3-0
Earlier quoted context omitted.
I think if you ever have highly dynamic infrastructure requirements -- think along the lines of a control plane that's spinning up additional workers -- it's really helpful to be able to run your infra provisioning logic locally. There's nothing worse than having to wait on cloud builds to test your iterations.
What would be the difference between eg Tilt and Pulumi for this?
Why do not use well organized Makefile instead of invent new junk. Is it a product placement?
Earlier quoted context omitted.
Not to mention the developer experience is usually sub-par. I firmly believe that the primary way of interacting with my tests should be the ability to run them one by one from the IDE, and running the code should be run / attach with breakpoints.
It takes some work, but it's entirely possible to both use Docker and run individual tests with breakpoints (in a Docker container) in your IDE. For example, you can attach VS Code to a running container.
i don't get the value of a tool like this. Do we really struggle bringing up services as containers and applying kube configs? For my development of services that run in kube, I don't dev with kube, you shouldn't have to. I also use docker-compose for most dev env services. Perhaps i'm not developing the right kind of software. Whoever finds this type of tool useful, when would you use it?
I still think "dev environments" really ought to be running tests directly with your languages native tool. e.g. `cargo test`, `bundle exec rspec`, etc. If you make me run a VM that runs Kubernetes that runs a docker container that runs the tests, I will be very, very upset. Doing this properly and reliably can still be a lot of work, possibly more work if not relying on Docker is a design goal (which must be if you…
Not to mention the developer experience is usually sub-par. I firmly believe that the primary way of interacting with my tests should be the ability to run them one by one from the IDE, and running the code should be run / attach with breakpoints.
I simple have a container for each project using my own container-shell
I run my bundles / whatever. Have all the tooling and can use VSCode to attach via ssh (I use orbstack, so I get project hostnames for free)
It’s the best workflow for me. I really wanted to like containers but again, it’s too heavy, buggy, bulky.
Interesting to see this pop up here! I’ve been using Tilt for multiple years now but the pace of development seems to have slowed down after the Docker acquisition. I love how Tilt enables creating a local development environment that lets my services run the same in production , test and development. Greatly simplifies my service code and improved my quality. In particular, I’d love to see Tilt be better around hand…
As far as I understand, this might be is the best tool for the guy who acquires a SaaS and have no clue how to develop/tweak stuff. Again still have no clue how you enable this or do you still have tilt in production. Marketing is not a big deal for tilt as far as I understand.
To your other point, Tilt is to development as ArgoCD is to deployment. Tilt enables on-demand, reproducible development environments that are sufficiently high-fidelity that you can often replace your shared and/or long-lived testing clusters.
With Tilt, I test my application using the same Kubernetes specs / Kustomizations / Helm Charts that you use to deploy into production. When it comes time to deploy my application, I supply these same specs / kustomizations / charts to ArgoCD.
Because I can reuse the specs for both testing and production, I enjoy far greater testability of my application, improving quality and time to market.
I still think "dev environments" really ought to be running tests directly with your languages native tool. e.g. `cargo test`, `bundle exec rspec`, etc. If you make me run a VM that runs Kubernetes that runs a docker container that runs the tests, I will be very, very upset. Doing this properly and reliably can still be a lot of work, possibly more work if not relying on Docker is a design goal (which must be if you…
You give up a bit of snappiness, sure, but you can also keep the very small non container based tooling like linting outside of the container.
Earlier quoted context omitted.
What would be the difference between eg Tilt and Pulumi for this?
Tilt is for your laptop, where you're editing code. Pulumi is for your cloud environments.