Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Almost every infrastructure decision I endorse or regret

cep.dev

Post reply on HN
Print view View original

81–90 of 644 posts

Re: Almost every infrastructure decision I endorse or regret

#81

Post by xtracto »

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…

DatDog is a freaking beast. NY wife works in workday (a huge employee management system) and they have a very large number of tutorials, videos, "working hours" and other tools to ensure their customers are making the best use of it.

Datadog on the other side... their "DD University" is a shame and we as paying customers are overwhelmed and with no real guidance. DD should assign some time for integration for new customers, even if it is proportional to what you pay annually. (I think I pay around 6000 usd annually.

Re: Almost every infrastructure decision I endorse or regret

#82

Post by otterley »

jrockway wrote: post #71
sroussey wrote: post #51

If you are startup that can can’t afford a DBA, then why why why are you using Kubernetes?

Why wouldn't you use Kubernetes? There are basically 3 classes of deployments: 1) We don't have any software, so we don't have a prod environment. 2) We have 1 team that makes 1 thing, so we just launch it out of systemd. 3) We have between 2 and 1000 teams that make things and want to self-manage when stuff gets rolled out. Kubernetes is case 3. Like it or not, teams that don't coordinate with each other is how star…

On AWS, at least, there are alternatives such as ECS and even plain old EC2 auto scaling groups. Teams can have the autonomy to run their infrastructure however they like (subject to whatever corporate policy and compliance regime requirements they might have to adhere to).

Kubernetes is appealing to many, but it is not 100% frictionless. There are upgrades to manage, control plane limits, leaky abstractions, different APIs from your cloud provider, different RBAC, and other things you might prefer to avoid. It's its own little world on top of whatever world you happen to be running your foundational infrastructure on.

Or, as someone has artistically expressed it: https://blog.palark.com/wp-content/uploads/2022/05/kubernete...

Re: Almost every infrastructure decision I endorse or regret

#83

Post by kypro »

ndjshe3838 wrote: post #78

I’m imagining a developer in the 90s/00s reading this list and being baffled by the complexity/terminology

I thought the same reading it – is it really this hard to build an app these days?

Things were more far more manual and much less secure, scalable and reliable in the past, but they were also far far simpler.

Re: Almost every infrastructure decision I endorse or regret

#84

Post by xyzzy_plugh »

hintymad wrote: post #73

> EKS My contrarian view is that EC2 + ASG is so pleasant to use. It’s just conceptually simple: I launch an image into an ASG, and configure my autoscale policies. There are very few things to worry about. On the other hand, using k8s has always been a big deal. We built a whole team to manage k8s. We introduce dozens of concepts of k8s or spend person-years on “platform engineering” to hide k8s concepts. We publish…

I tend to agree that for most things on AWS, EC2 + ASG is superior. It's very polished. EKS is very bare bones. I would probably go so far as to just run Kubernetes on EC2 if I had to go that route.

But in general k8s provides incredibly solid abstractions for building portable, rigorously available services. Nothing quite compares. It's felt very stable over the past few years.

Sure, EC2 is incredibly stable, but I don't always do business on Amazon.

Re: Almost every infrastructure decision I endorse or regret

#85

Post by viraptor »

steveBK123 wrote: post #66
viraptor wrote: post #50

Earlier quoted context omitted.

Lots of cases. It doesn't even have to be a tiny database. Within Also, Aurora gives you the block level cluster that you can't deploy on your own - it's way easier to work with than the usual replication.

Once you commit to more deeply Amazon flavored parts of AWS like Aurora, aren't you now fairly committed to hoping your scale never exceeds the cost-benefit tradeoff?

Or you're realistic about what you're doing. Will you ever need to scale more than 10x? And on the timescales where you do grow over 10x, would it be better to reconsider/re-architect everything anyway?

I mean, I'm looking after a 4 instance Aurora cluster which is great feature wise, is slightly overprovisioned for special events, and is more likely to shrink than grow 2x in the next decade. If we start experiencing any issues, there's lots of optimisations that can be still gained from better caching and that work will be cheaper than the instance size upgrade.

Re: Almost every infrastructure decision I endorse or regret

#86

Post by nyc_data_geek »

electroly wrote: post #6

> The markup cost of using RDS (or any managed database) is worth it. Every so often I price out RDS to replace our colocated SQL Server cluster and it's so unrealistically expensive that I just have to laugh. It's absurdly far beyond what I'd be willing to pay. The markup is enough to pay for the colocation rack, the AWS Direct Connects, the servers, the SAN, the SQL Server licenses, the maintenance contracts, and a…

Some orgs are looking at moving back to on prem because they're figuring this out. For a while it was vogue to go from capex to opex costs, and C suite people were incentivized to do that via comp structures, hence "digital transformation" ie: migration to public cloud infrastructure. Now, those same orgs are realizing that renting computers actually costs more than owning them, when you're utilizing them to a significant degree.

Just like any other asset.

Re: Almost every infrastructure decision I endorse or regret

#87

Post by zmgsabst »

steveBK123 wrote: post #66
viraptor wrote: post #50

Earlier quoted context omitted.

Lots of cases. It doesn't even have to be a tiny database. Within Also, Aurora gives you the block level cluster that you can't deploy on your own - it's way easier to work with than the usual replication.

Once you commit to more deeply Amazon flavored parts of AWS like Aurora, aren't you now fairly committed to hoping your scale never exceeds the cost-benefit tradeoff?

…no?

There’s still a defined cost to swapping your DB code over to a different backend. At the point where it becomes uneconomical, you’re also at a scale you can afford rewriting a module.

That’s why we have things like “hexagonal architecture”, which focus on isolating the storage protocol from the code. There’s an art to designing such that your prototype can scale with only minor rework — but that’s why we have senior engineers.

Re: Almost every infrastructure decision I endorse or regret

#88

Post by inquist »

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 wrong with uuidv4 as PK?

Re: Almost every infrastructure decision I endorse or regret

#89

Post by LispSporks22 »

ndjshe3838 wrote: post #78

I’m imagining a developer in the 90s/00s reading this list and being baffled by the complexity/terminology

I agree. I’m afraid I’m one of those 00s developers and can relate. Back then many startups were being launched on super simple stacks.

With all of that complexity/word salad from TFA, where’s the value delivered? Presumably there’s a product somewhere under all that infrastructure, but damn, what’s left to spend on it after all the infrastructure variable costs?

I get it’s a list of preferences, but still once you’ve got your selection that’s still a ton of crap to pay for and deal with.

Do we ever seek simplicity in software engineering products?

Re: Almost every infrastructure decision I endorse or regret

#90

Post by __turbobrew__ »

It is a shame karpenter is AWS only. I was thinking about how our k8s autoscaler could be better and landed on the same kind of design as karpenter where you work from unschedulable pods backwards. Right now we have an autoscaler which looks at resource utilization of a node pool but that doesn’t take into account things like topology spread constraints and resource fragmentation.
Post reply on HN