💾 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

View Raw

More Information

⬅️ Previous capture (2021-12-03)

➡️ Next capture (2021-12-05)

🚧 View Differences

-=-=-=-=-=-=-

Don't Make My Mistakes: Common Infrastructure Errors I've Made

Author: todsacerdoti

Score: 12

Comments: 2

Date: 2021-12-03 12:03:54

Web Link

________________________________________________________________________________

karmakaze wrote at 2021-12-03 22:59:06:

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.

slyall wrote at 2021-12-04 22:13:37:

From yesterday

https://news.ycombinator.com/item?id=29434740

- 130 comments