Interested to know what's changed (if anything) in the two years since this was written.
Infrastructure decisions I endorse or regret after 4 years at a startup (2024)
91–100 of 247 posts
Re: Infrastructure decisions I endorse or regret after 4 years at a startup (2024)
#92Previous discussion (626 comments): https://news.ycombinator.com/item?id=39313623
Re: Infrastructure decisions I endorse or regret after 4 years at a startup (2024)
#93Earlier quoted context omitted.
If you work in a team, email is limited to the people you cc: while a convo in a slack channel can have people you didn't think of jump in* with information. See the other point in the article about discouraging one on one private messages and encouraging public discussion. That is the main reason. * half a day later or days later if you do true async, but that's fine.
I am neutral in this particular topic, so don’t think I’m defending or attacking or anything. But aren’t mailling lists and distribution groups pretty ubiquitous?
But - from the people you actually want to get to contribute - emails come with an expectation of a well thought out text. IMs ... less so.
I've been working across time zones via IM and email since ... ICQ.
I'm probably biased by that but I consider email the place for questions lists and long statuses with request for comments, and for info that I want retained somewhere. While IM is a transient medium where you throw a quickie question or statement or whine every couple hours - and check what everyone else is whining about.
Re: Infrastructure decisions I endorse or regret after 4 years at a startup (2024)
#94Interested to know what's changed (if anything) in the two years since this was written.
for one thing the ingress nginx is retiring[1], so they're probably revsiting alternatives, maybe even the service meshes for the new gateway api.
1: https://kubernetes.io/blog/2026/01/29/ingress-nginx-statemen...
Re: Infrastructure decisions I endorse or regret after 4 years at a startup (2024)
#95Earlier quoted context omitted.
I am neutral in this particular topic, so don’t think I’m defending or attacking or anything. But aren’t mailling lists and distribution groups pretty ubiquitous?
But - from the people you actually want to get to contribute - emails come with an expectation of a well thought out text. IMs ... less so. I've been working across time zones via IM and email since ... ICQ. I'm probably biased by that but I consider email the place for questions lists and long statuses with request for comments, and for info that I want retained somewhere. While IM is a transient medium where you th…
I have now been roped into talking more about a topic I have no interest in and am completely ambivalent to… :/
But clearly, thats cultural.
If you keep your eyes on the linux kernel mailing you’ll see a lot of (on topic) short and informal messages flying in all directions.
If you keep your eyes on the emails from big tech CEOs that sometimes appear in court documents; you’ll see that the way they use email is the same way that I’d use slack or an instant messenger.
Thats likely because its the tool they have available- we have IM tools that connect us to people we need (inside the company)- making email the only place for long form content, which means its only perceived as being for long form content.
But when people have to use something federated more often, it does seem like email is actually used this way.
Re: Infrastructure decisions I endorse or regret after 4 years at a startup (2024)
#96This is the best post to HN in quite some time. Kudos to the detailed and structured break-down. If the author had a Ko-Fi they would've just earned $50 USD from me. I've been thinking of making the leap away from JIRA and I concur on RDS, Terraform for IAC, and FaaS whenever possible. Google support is non-existent and I only recommend GC for pure compute. I hear good things about Big Table, but I've never used in i…
Curious from you or others when FaaS isn’t possible? What criteria do you look for to decide or migrate off?
Re: Infrastructure decisions I endorse or regret after 4 years at a startup (2024)
#97> Picking Terraform over Cloudformation: Endorse I, too, prefer McDonald's cheeseburgers to ground glass mixed with rusty nails. It's not so much that I love Terraform (spelled OpenTofu) as that it's far and away the least bad tool I've used in the space.
Terraform/openTofu is more than OK. The fact that you can use to to configure your Cisco products as well as AWS is honestly great for us. It's also a bit like ansible: if you don't manage it carefully and try to separate as much as possible early, it starts bloating, so you have to curate early. Terragrunt is the only sane way to deploy terraform/openTofu in a professional environment though.
I never understood this. Why not use Ansible instead, especially if you already use it? Doubly so when you have Cisco config to manage. The experience is generally so much better it's not comparable, and it is much easier to infer running state.
Re: Infrastructure decisions I endorse or regret after 4 years at a startup (2024)
#98Earlier quoted context omitted.
Not an opinion on Pulumi specifically, but an opinion on using imperative programming languages for infrastructure configuration: don't do it. (This includes using things like CDKTF) Infrastructure needs to be consistent, intuitive and reproducible. Imperative languages are too unconstrained. Particularly, they allow you to write code whose output is unpredictable (for example, it'd be easy to write code that creates…
> Particularly, they allow you to write code whose output is unpredictable Is that an easy mistake to make and a hard one to recover from, in your experience? The way you have to bend over backwards in Terraform just to instantiate a thing multiple times based on some data really annoys me..
> Is that an easy mistake to make and a hard one to recover from, in your experience?
If you're alone in a codebase? Probably not.
In a company with many contributors of varying degrees of competence (from your new grad to your incompetent senior staff), yes.
In large repositories, without extremely diligent reviewers, it's impossible to prevent developers from creating the most convoluted anti-patterny spaghetti code, that will get copy/pasted ad nauseam across your codebase.
Terraform as a tool and HCL as a programming language leave a lot to be desire (in hindsight only, because, let's be honest, it's been a boon for automation), but their constrained nature makes it easier to reign in the zealous junior developer who just discovered OOP and insists on trying it everywhere...
Re: Infrastructure decisions I endorse or regret after 4 years at a startup (2024)
#99(2024) past discussion: https://news.ycombinator.com/item?id=39313623
Thanks! Macroexpanded...
Almost every infrastructure decision I endorse or regret - https://news.ycombinator.com/item?id=39313623 - Feb 2024 (626 comments)
Re: Infrastructure decisions I endorse or regret after 4 years at a startup (2024)
#100This is the best post to HN in quite some time. Kudos to the detailed and structured break-down. If the author had a Ko-Fi they would've just earned $50 USD from me. I've been thinking of making the leap away from JIRA and I concur on RDS, Terraform for IAC, and FaaS whenever possible. Google support is non-existent and I only recommend GC for pure compute. I hear good things about Big Table, but I've never used in i…
What do you use if not slack? OPs advice is standard best practice. Respect peoples time by not expecting immediate response, and use team or function based channels as much as possible. Other options are email of course, and what, teams for instant messages?
We use self-hosted Mattermost (team version, i.e. without limits but no enterprise features like LDAP). Fine for a small team (around 40 active users here) where you can script account actions via the API, probably not fine when users become a lot more, or you might need access to the compliance functions for audit purposes, etc.
For us the free version of Slack was insufficient, the commercial one too expensive, and anyway, given that it's a cloud-based system, it's not compliant with our internal rules for confidential information (unless we can get some specific agreement with them). On the side, there is a bit too much analytics/telemetry in the Slack client.