💾 Archived View for dioskouroi.xyz › thread › 29429047 captured on 2021-12-04 at 18:04:22. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2021-12-03)
-=-=-=-=-=-=-
________________________________________________________________________________
I was hoping this would've been a more surprising list, but it was titled 'common'.
Don't migrate an application from the datacenter to the cloud
Good advice that follows the pattern of don't do a rewrite with a plan to cut-over. Instead make two and gradually transition to the newer one.
Don't write your own secrets system
Follow-on to 'don't do your own crypto'
Don't run your own Kubernetes cluster
Are you a Fortune 100 company? If no, then don't do it.
Don't Design for Multiple Cloud Providers
This seems like an extension of YAGNI. If you're not using it, don't build it. If you really will need it, use it as you're building it. A good example is if you're doing multi-datacentre redundancy using standard tech, it _might_ be worthwhile to do multi-cloud. But have an actual threat model in mind that this mitigates, e.g. cloud provider 'A' may become a conflict-of-interest competitor in the foreseeable future.
Don't let alerts grow unbounded
Don't write internal cli tools in python
Nobody knows how to correctly install and package Python apps. If you write an internal tool in Python, it either needs to be totally portable or just write it in Go or Rust. Save yourself a lot of heartache as people struggle to install the right thing.
+1 This one rarely gets mentioned.
One that I would add, that I haven't experienced but can certainly foresee is "don't switch major datastores". Switching between MySQL and PostgreSQL might be rough but doable. Switching between MySQL and CockroachDB for a large, heavily-used app could stall developing new features for a long time or make everything take 5x longer. The reason isn't the query syntax, it's the query characteristics. Using a std rdbms gives you the ability to do many relatively quick round-trip queries (though you should avoid N+1's) some can be tolerated. A distributed DB can have high throughput but will have high latency for simple queries.
From yesterday
https://news.ycombinator.com/item?id=29434740
- 130 comments