Almost every infrastructure decision I endorse or regret • Hacker News Board

Re: Almost every infrastructure decision I endorse or regret

#231

Post by wodenokoto » Sat, Feb 10, 2024, 6:49 AM UTC

morsecodist wrote: post #131

> Picking AWS over Google Cloud I know this is an unpopular opinion but I think google cloud is amazing compared to AWS. I use google cloud run and it works like a dream. I have never found an easier way to get a docker container running in the cloud. The services all have sensible names, there are fewer more important services compared to the mess of AWS services, and the UI is more intuitive. The only downside I ha…

If you are big enough to have regular meetings with AWS you are big enough to have meetings with GCP.

I’ve had technicians at both GCP and Azure debug code and spend hours on developing services.

Re: Almost every infrastructure decision I endorse or regret

#232

Post by MarkMarine » Sat, Feb 10, 2024, 6:50 AM UTC

itpragmatik wrote: post #194

Not sure the fascination about Go - one can write fully scalable functional readable maintainable upgradable rest api service with Java 17 and above.

I struggle with the type system in both, but today I was going through obscure go code and wishing interfaces were explicitly implemented. Lack of sum types is making me sad

Re: Almost every infrastructure decision I endorse or regret

#233

Post by hitekker » Sat, Feb 10, 2024, 6:50 AM UTC

Props to the author for writing up the results from his exercise. But I think he should focused on a few controversial ones, and not the rotes ones.

Many of the decisions presented are not disagreeable (choosing slack) and some lack framing that clarifies the associated loss (Not adopting an identity platform early on). I think they're all good choices worth mentioned; I would have preferred a deeper look into the few that seemed easy and turned out to be hard, or the ones that were hard and got even harder.

Re: Almost every infrastructure decision I endorse or regret

#234

Post by bilalq » Sat, Feb 10, 2024, 6:51 AM UTC

CSMastermind wrote: post #10

So by and large I agree with the things in this article. It's interesting that the points I disagree with the author on are all SaaS products: > Moving off JIRA onto linear I don't get the hype. Linear is fine and all but I constantly find things I either can't or don't know how to do. How do I make different ticket types with different sets of fields? No clue. > Not using Terraform Cloud No Regrets I generally recom…

Linear has a lot going for it. It doesn't support custom fields, so if that's a critical feature for you, I can see it falling short. In my experience though, custom fields just end up being a mess anytime a manager changes and decides to do things differently, things get moved around teams, etc.

- It's fast. It's wild that this is a selling point, but it's actually a huge deal. JIRA and so many other tools like it are as slow as molasses. Speed is honestly the biggest feature.

- It looks pretty. If your team is going to spend time there, this will end up affecting productivity.

- It has a decent degree of customization and an API. We've automated tickets moving across columns whenever something gets started, a PR is up for review, when a change is merged, when it's deployed to beta, and when it's deployed to prod. We've even built our own CLI tools for being able to action on Linear without leaving your shell.

- It has a lot of keyboard shortcuts for power users.

- It's well featured. You get teams, triaging, sprints (cycles), backlog, project management, custom views that are shareable, roadmaps, etc...

Re: Almost every infrastructure decision I endorse or regret

#235

Post by dalyons » Sat, Feb 10, 2024, 6:57 AM UTC

sgarland wrote: post #168

dalyons wrote: post #123

Earlier quoted context omitted.

Or, you just avoid doing multi tenet from the start and none of those become your problem to unblock. What’s the downside?

Done that as well; it still becomes my problem because teams without RDBMS knowledge eventually break it, and… then I get paged. Full Stack is a lie, and the sooner companies accept that and allow people to specialize again, and to pay for the extra headcount, the better off everyone will be.

I disagree I guess. Multiple companies I’ve worked at have broken up their shared db into many dbs that individual teams own the operations of, and it works just fine. At significant scale in traffic and # of eng. No central dbas needed - smaller databases require much less skills to manage. The teams that own them learn enough.

Re: Almost every infrastructure decision I endorse or regret

#236

Post by dalyons » Sat, Feb 10, 2024, 7:00 AM UTC

eduction wrote: post #149

dalyons wrote: post #121

Earlier quoted context omitted.

Why would you make it a shared resource if you don’t have to? Decades of experience have shown us the massive costs of doing so - the crippled velocity and soul crushing agony of dba change control teams, the overhead salary of database priests, the arcane performance nightmares, the nuclear blast radius, the fundamental organizational counter-incentives of a shared resource . Why on earth would we choose to pay thos…

You wouldn’t but in any decent sized organization you will have to. If it is an organization that needs to exist there will be some common set of critical data.

That’s just not true though, I’ve worked at decent sized companies without shared RDBMs, so you don’t have to.

You DO have to share data in other ways, usually datawarehouse or services, but that is not the same thing.

Re: Almost every infrastructure decision I endorse or regret

#237

Post by Glyptodon » Sat, Feb 10, 2024, 7:01 AM UTC

sgarland wrote: post #37

vrosas wrote: post #34

Earlier quoted context omitted.

Bad schema decisions are made regardless of whether you’re one database or 50. At least with many databases the problems are localized.

But then the DB Team – if you have one – is responsible for 50 databases, each full of their own unique problems. This will undoubtedly go over poorly, but honestly I think every data decision should be gated through the DB Team (again, if you have them). Your proposed schema isn’t normalized? Straight to jail. You don’t want to learn SQL? Also straight to jail. You want to use a UUIDv4 as a primary key? Believe it o…

What's the best non serial option for PKs in your view? Or do you prefer dual PK approach?

Re: Almost every infrastructure decision I endorse or regret

#238

Post by extr » Sat, Feb 10, 2024, 7:06 AM UTC

charred_patina wrote: post #125

LispSporks22 wrote: post #74

I feel like this is overkill for a startup. Why not dump your application server and dependencies into rented data center (or EC2 if you must) and setup a coarse DR? Maybe start with a monolith in PHP or Rails. None of that word salad sounds like startup to me, but then again everyone loves to refer to themselves as a startup (must be a recruiting tool?), so perhaps muh dude is spot on.

I don't want to be negative, but this post reads like a list of things that I want to avoid in my career. I did a brief stint in cloud stuff at a FAANG and I don't care to go back to it. Right now I'm engineer No. 1 at a current startup just doing DDD with a Django monolith. I'm still pretty Jr. and I'm wondering if there's a way to scale without needing to get into all of the things the author of this article mentio…

You can scale to any valuation with any architecture. Whether or not you need sophisticated scaling solutions depends on the characteristics of your product, mostly how pure of a software play it is. Pure software means you will run into scaling challenges quicker, since likely part of your value add is in fact managing the complexity of scaling.

If you are running a marketplace app and collect fees you're going to be able go much further on simpler architectures than if you're trying to generate 10,000 AI images per second.

Re: Almost every infrastructure decision I endorse or regret

#239

Post by pcl » Sat, Feb 10, 2024, 7:12 AM UTC

latch wrote: post #193

theptip wrote: post #162

Earlier quoted context omitted.

That’s just another way of saying the opportunity cost isn’t worth paying to do the migration. Optionality and flexibility are extremely valuable, and that is why cloud compute continues to be popular, especially for rapidly/burstily growing businesses like startups.

I don't mean to pick on your specific comments, but I find these analysis almost always lack a crucial perspective: level of knowledge. This is the single biggest factor, and it's the hardest one to be honest about. No one wants to say "RDS is a good choice . . . because I don't know how nor have I ever self managed a database." If you want a different opportunity cost, get people with different experience. If RDS is…

> No one wants to say "RDS is a good choice . . . because I don't know how nor have I ever self managed a database."

I don't think that's accurate. I've self-managed databases, and I still think that RDS is compelling for small engineering teams.

There's a lot to get right when managing a database, and it's easy to screw something up. Perhaps none of the individual parts are super-complicated, but the cost of failure is high. Outsourcing that cost to AWS is pretty compelling.

At a certain team size, you'll end up with a section of the team that's dedicated to these sorts of careful processes. But the first place these issues come up is with the database, and if you can put off that bit of organizational scaling until later, then that's a great path to choose.

Re: Almost every infrastructure decision I endorse or regret

#240

Post by isoprophlex » Sat, Feb 10, 2024, 7:14 AM UTC

> There are no great FaaS options for running GPU workloads

This hits hard. Someone please take my (client's) money and provide sane GPU FaaS. Banana.dev is cool but not really enterprise ready. I wish there was a AWS/GCP/Azure analogue that the penny pinchers and MBAs in charge of procurement can get behind.