6 ms·
Tailscale employee here. Our database needs are tiny, as explained in the earlier post. So we optimize for things like: "can we run all our tests quickly and e
by bradfitz 5y ago
Tailscale employee here.
Our database needs are tiny, as explained in the earlier post. So we optimize for things like: "can we run all our tests quickly and easily in many environments without containers and VMs?" All three of our storage schemes have had that property.
We have MySQL and PostgreSQL veterans on the team. We know those options well.
- cogman10 5y ago> without containers Why? The official docker postgres package weighs in at 100MB. Assuming you standardized on that, then every environment would end up having a fresh postgres image just waiting to be startup. Meaning, the actual cost is the memory for the server and startup time, not the image itself. Mount the data on tmpfs and you can startup and setup a db in very little time (I know, because that's what we do). You might be able to eek out a bit more performance by hand tuning test files... but.. to what end?
- tptacek 5y agoI can't speak for Tailscale, but our whole raison d'etre is running containers for people, and almost none of our development environments are containerized either. Containers (and remote dev environments) create friction. They're useful tools when that friction is unavoidable anyways, but when it isn't --- and you can design systems with that being a goal --- it makes sense to take full advantage of that.
- dgb23 5y agoHave a look at this headline: > Zero config VPN. Installs on any device in minutes, manages firewall rules for you, and works from anywhere. I don't know how their product works, but my intuition is that your suggestions aren't feasible.
- cogman10 5y agoI suggest reading the article. The reason they haven't chosen "boring" tech has nothing to do with the clients running their software and everything to do with their internal development experiences. > MySQL (or PostgreSQL) would come next. I’m not particularly familiar with anything MySQL post 1998, but I’m sure it would work. The HA story for open source databases is somewhat surprising, though: you can either have traditional lagging replicas, or commit to no-primary-replica clusters that have very surprising transaction semantics. I wasn’t excited about trying to design a stable API or good network graph calculations on top of those semantics. CockroachDB looked very promising, and indeed still does! But it’s relatively new for a database and I was a little concerned about getting attached to features in a fresh DBMS that would be hard to migrate away from if we needed to. The reason they are ruling out products isn't "this won't work where it runs" its "I don't like this". They talk about worrying about network graphs and proceed to use SQLite and copy garbage around.
- tptacek 5y agoIf you're dinging them for not using Cockroach, they explained why they're not using Cockroach in the exact paragraph you quoted: if they use Cockroach, they're committing to the scaling and distribution system that Cockroach provides, which might or might not be a good fit for them 2 years from now. If it isn't a good fit, they're stuck with a huge engineering bill to get themselves out of Cockroach. We're moving towards sqlite for things for the same reason. sqlite is simple to reason about. The distributed state problem not simple, but our distributed state problem is not Tailscale's and theirs isn't yours; every distributed state problem is unhappy in its own way. As they work out the contours of their specific distributed state problem, sqlite isn't the component that's going to break down.
- cogman10 5y ago> If it isn't a good fit, they're stuck with a huge engineering bill to get themselves out of Cockroach. Similar to the current engineering bills they are paying because they switched from a json file -> etcd -> sqlite? Seems like the cost of switching isn't really an issue for them since they've pulled that lever multiple times now.
- tptacek 5y agoIt does seem that way. Keep thinking along those lines. You're almost there!
- jrockway 5y agoI write applications that use Postgres, and don't use Docker for testing. I just create a database based on the name of the test case, delete it, create it, explode the schema in there, and run the tests. The reason is because I don't want to pay Postgres' startup costs every time I run the tests. Tests are run thousands of times a day, while you're in the mindset to rapidly iterate. Any delay is unacceptable. At some point, migrations were taking too long, so I just started caching the database schema. I have a go generate thingie that creates a fresh database, applies all the migrations, and dumps the schema to a file that gets checked in with the code. (CI checks that the migrations actually result in the database state that's checked in. Yes, there is something that regexes out the hostname from the sql file, since Postgres dumps that in there by default and that results in spurious diffs.) I have learned that people often put up with really sub-optimal developer workflows. My test is that you should be able to add "print hello world" to the top of your main function, and see that printed on your screen in less than 5 seconds. (Yes, even if your application is complicated. I have a hacked up copy of K8s that starts that quickly, so that you can write an app that deeply integrates with K8s and not have to reuse a cluster between tests, or pay a long cluster creation cost. All obstacles must be removed!) If it takes longer than that, you are just throwing your developer's salaries into the toilet. (If it takes 6 seconds, you open up HN, and there's an hour gone!)
- deleted 5y ago[deleted]
- epolanski 5y ago> we run all our tests quickly and easily in many environments without containers and VM How's that an important metric to optimize for? Did you ever benchmark the tests with other solutions?