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

481–490 of 644 posts

Re: Almost every infrastructure decision I endorse or regret

#481

Post by deskamess »

neonsunset wrote: post #304
mordae wrote: post #290

Earlier quoted context omitted.

Nope. None of my below 30 colleagues know SQL. They use ORM in REPL or visual tools.

LINQPad is awesome and EF Core is just this good so I can see why some would just choose not to deal with SQL. With that said, this still sounds like a strange situation - most colleagues, acquaintances and people I consulted know they way around SQL and dropping down to 'dbset.FromSql($"SELECT {...' is very commonplace out of the need to use sprocs, views or have tighter control over the query.

I had not updated LINQPad in a while and just saw the price this year. Eeesh. I now live in a .NET Interactive (Jupyter like) environment.

Re: Almost every infrastructure decision I endorse or regret

#483

Post by Hasu »

simonbarker87 wrote: post #469
alentred wrote: post #308

Earlier quoted context omitted.

BigQuery - Athena Pub/Sub - Kinesis Cloud CDN - CloudFront Cloud Domains - Route 53 ...

Perfect list, also: Google Cloud Run - Lambda Sure I get the reference to the underlying algebraic representation of coding but come on, Lambda tells us nothing of what it does. Products (not brands, products) should be named in a way that means something to the customer afaic.

> Perfect list, also:

> Google Cloud Run - Lambda

ECS is the AWS equivalent of Cloud Run. GCP Cloud Functions are the equivalent of AWS Lambda.

ECS / Cloud Run = managed container service that autoscales

Lambda / Cloud Functions = serverless functions as a service

Re: Almost every infrastructure decision I endorse or regret

#484

Post by foxhop »

I think kubernetes is a mistake and should have went with AWS ECS (using fargate or backed by autoscaling ec2), if single change he wouldn't need to even thing about a bunch of other topics on his list. Something to think about, AWS Lambda first then fallback to AWS ECS for everything else that needs to really be on 100% of the time.

Re: Almost every infrastructure decision I endorse or regret

#485

Post by Solvency »

mschuster91 wrote: post #362
Spivak wrote: post #208

Earlier quoted context omitted.

I think they're more getting a k8s requiring a whole mess of 3rd party code to actually be useful when bringing it to prod. For EKS you end up having coredns, fluentbit, secrets store, external dns, aws ebs csi controller, aws k8s cni, etc. And in the end it's hard to say if you've actually gained anything except now this different code manages your AWS resources like you were doing with CF or terraform.

We have all of that neatly extracted into a Terraform module. Write it once and now EKS clusters are essentially disposable.

You just added yet another Thing in that huge pile of things representing millions of lines of code. That's the point.

Re: Almost every infrastructure decision I endorse or regret

#486

Post by afpx »

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…

That's the cost of two people.

Re: Almost every infrastructure decision I endorse or regret

#487

Post by dieortin »

roughly wrote: post #205

The Bazel one made me chuckle - I worked at a company with an scm & build setup clearly inspired by Google’s setup. As a non-ex-Googler, I found it obviously insane, but there was just no way to get traction on that argument. I love that the rest of this list is pretty cut and dry, but Bazel is the one thing that the author can’t bring themself to say “don’t regret” even though they clearly don’t regret not using it.

I’m curious, what do you find insane about Bazel? In my experience it makes plenty of sense. And after using it for some months, I find more insane how build systems like CMake depend on you having some stuff preinstalled in your system and produce a different result depending on which environment they’re run on.

Re: Almost every infrastructure decision I endorse or regret

#488

Post by Solvency »

iaresee wrote: post #450
viraptor wrote: post #229

Earlier quoted context omitted.

Another annoying thing is that the billing dashboards do not map clearly to what's on the pricing pages / in the contract. Good luck figuring out the extras for RUM when you have multiple orgs. Then they have things that I wanted to try for a long time, but... support doesn't care? Repeated "would you like to use this? / very likely, can we try it out? / (silence)". I love their product, but they are so annoying to d…

> Another annoying thing is that the billing dashboards do not map clearly to what's on the pricing pages / in the contract. Good luck figuring out the extras for RUM when you have multiple orgs. I, quite literally, was griping to my Datadog CSM about this exact thing last week. They'll email me and be, "Oh, you know you're logging volume this month put you into on-demand indexing rates, right?" and my answer is alwa…

And why do you continue to deal with scum like this? You're ultimately going to pay it and business will carry on as usual for them.

Re: Almost every infrastructure decision I endorse or regret

#489

Post by eduction »

dalyons wrote: post #236
eduction wrote: post #149

Earlier quoted context omitted.

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.

To me this is semantics. So it’s a data warehouse rather than a database. Ok. Or we share data from a common source via “services” - ok but that’s another word for a database and a client (using http to do the talking doesn’t really change anything).

I’m not saying literally every source of data has to be shared and centrally managed. I’m also not saying “rdbms accessed via traditional client and queried via sql” when I say database. I’m just saying a shared database of some shape is inevitable.

Re: Almost every infrastructure decision I endorse or regret

#490

Post by macNchz »

rnts08 wrote: post #441
matwood wrote: post #342

Earlier quoted context omitted.

I am good at databases (have been a DBA in the past), and 100% agree with this. RDS is easy to standup and get all the things you mentioned, and not have to think about again. If we grow to the point where the overhead is more than a FT DBA, awesome. It means we are successful, and are fortunate to have options.

Unfortunately there are so many people and teams who thinks that simply running their databases on RDS means that they're backed up, highly-available and can be easily load balanced, upgraded, partitioned, migrated and so on which is simply not the case with the basic configuration. RDS is a great choice, for prototyping and only for production if you know what you're doing when setting it up. FWIW, this is common in…

Well…just using the defaults when creating an RDS Postgres in the console give you an HA cluster with two read replicas, 7 days of backups restorable to any point in time, automatic minor version upgrades, and very easy major upgrades. So unless you start actively unchecking stuff those are not entirely invalid assumptions.
Post reply on HN