Live data from Hacker News

Almost every infrastructure decision I endorse or regret

cep.dev

491–500 of 644 posts

Re: Almost every infrastructure decision I endorse or regret

#491

Earlier quoted context omitted.

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 signif…

Funny story time. I was once part of an acquisition from a much larger corporate entity. The new parent company was in the middle of a huge cloud migration, and as part of our integration into their org, we were required to migrate our services to the cloud. Our calculations said it would cost 3x as much to run our infra on the cloud. We pushed back, and were greenlit on creating a hybrid architecture that allowed us…

Yes, I do believe autoscaling is actually a good use case for public cloud. If you have bursty load that requires a lot of resources at peak which would sit idle most of the time, probably doesn't make sense to own what you need for those peaks.

Re: Almost every infrastructure decision I endorse or regret

#493

Earlier quoted context omitted.

Do jira pages still take 30 seconds to load, and have all the interaction speed of cold molasses? Does it have nice keyboard shortcuts yet? Do I still need to perform an arcane ritual of setup to get the ticket statuses to be what I want? Linear has been such a breath of fresh air, with such a solid desktop app (on Mac OS) that I don’t ever want to go back. Stuff happens instantly , the layout and semantics are an ex…

No, Jira loading is relatively OK and on par with other SPAs. It's got a CTRL+SHIFT+P style actions menu for tickets which helps cut down on point and click pain (especially for linking issues etc). Setting up statues and workflows and how they map to a board is relatively straightforward. There are lots of things where Jira falls short, but the pain points on an under-resourced self hosted instance of ten years ago…

Does Jira still have multiple flavours of markdown for different fields and editors? Last I used it, it used a different flavour for creating and editing a ticket. Also another flavour for bitbucket. None of these were compatible and it would convert between them in the backend but I was left confused every time when I would have to switch formatting styles

Re: Almost every infrastructure decision I endorse or regret

#494
post #480
post #184

Earlier quoted context omitted.

> K8S is a disastrous complexity bomb. You need millions upon millions of lines of code just to build a usable platform. I don't know what you have been doing with Kubernetes, but I run a few web apps out of my own Kubernetes cluster and the full extent of my lines of code are the two dozen or so LoC kustomize scripts I use to run each app.

If you're using a K8S cluster just to deploy a few web apps then it's not really a platform that you could provide to an engineering team within a medium-large company. You could probably run your stuff on ECS.

> If you're using a K8S cluster just to deploy a few web apps (...)

It's really not about what I do and do not do with Kubernetes. It's on you to justify your "millions upon millions lines of code" claim because it is so outlandish and detached from reality that it says more about your work than about Kubernetes.

I repeat: I only need a few dozen lines of kustomize scripts to release whole web apps. Simple code. Easy peasy. What mess are you doing to require "millions upon millions" lines of code?

Re: Almost every infrastructure decision I endorse or regret

#495
post #494
post #480

Earlier quoted context omitted.

If you're using a K8S cluster just to deploy a few web apps then it's not really a platform that you could provide to an engineering team within a medium-large company. You could probably run your stuff on ECS.

> If you're using a K8S cluster just to deploy a few web apps (...) It's really not about what I do and do not do with Kubernetes. It's on you to justify your "millions upon millions lines of code" claim because it is so outlandish and detached from reality that it says more about your work than about Kubernetes. I repeat: I only need a few dozen lines of kustomize scripts to release whole web apps. Simple code. Easy…

You are missing the point. I recommend you look into Platform Engineering and what it involves.

Re: Almost every infrastructure decision I endorse or regret

#496
post #349

Earlier quoted context omitted.

I’ve implemented such a process for companies multiple times, bro. I know what I’m talking about.

And that's the problem. "It's easy for me because I've done it a dozen times so it's easy for everyone" is a very common fallacy.

What happened to having people trained by external trainers for what you need? That’s much cheaper than having everything externally “managed” and still having to integrate all of it. The number of services listed in TFA is just ridiculous.

Re: Almost every infrastructure decision I endorse or regret

#497

Earlier quoted context omitted.

My funny story is built on the idea that AWS is Hotel California for your data. A customer had an interest in merging the data from an older account into a new one, just to simplify matters. Enterprise data. Going back years. Not even leaving the region. The AWS rep in the meeting kinda pauses, says: "We'll get back to you on the cost to do that." The sticker shock was enough that the customer simply inherited the ol…

Is R2 a sensible option for hosting data? I understand egress is chesp.

R2 is great. Our GCS bill (almost all egress) jumped from a few hundred dollars a month to a couple thousand dollars a month last year due to a usage spike. We rush-migrated to R2 and now that part of the bill is $0.

I've heard some people here on HN say that it's slow, but I haven't noticed a difference. We're mainly dealing with multi-megabyte image files, so YMMV if you have a different workload.

Re: Almost every infrastructure decision I endorse or regret

#498
post #67

> There are no great FaaS options for running GPU workloads, which is why we could never go fully FaaS. I keep wondering when this is going to show up. We have a lot of service providers, but even more frameworks, and every vendor seems to have their own bespoke API.

I don’t think anybody should go “fully FaaS”, it’s like saying screwdrivers are useless, all you need is a hammer. That being said, Cloudflare is on the path to offering a great GPU FaaS system for inference. I believe it’s still in beta, but it’s the most promising option at the moment.

Right, I still find it faster to manually provision a specific instance type, install PyTorch on it, and deploy a little flask app for an inference server.

Re: Almost every infrastructure decision I endorse or regret

#499

Earlier quoted context omitted.

RDS pricing is deranged at the scales I've seen too. $60k/year for something I could run on just a slice of one of my on-prem $20k servers. This is something we would have run 10s of. $600k/year operational against sub-$100k capital cost pays DBAs, backups, etc with money to spare. Sure, maybe if you are some sort of SaaS with a need for a small single DB, that also needs to be resilient, backed up, rock solid bullet…

> $600k/year operational against sub-$100k capital cost pays DBAs, backups, etc with money to spare. One of these is not like the others (DBAs are not capex.) Have you ever considered that if a company can get the same result for the same price ($100K opex for RDS vs same for human DBA), it actually makes much more sense to go the route that takes the human out of the loop? The human shows up hungover, goes crazy, gr…

And when you have performance issues you still need a DBA. Because RDS only runs your database. It is up to you to make it fast.

Re: Almost every infrastructure decision I endorse or regret

#500
post #184
post #91

Earlier quoted context omitted.

K8S is a disastrous complexity bomb. You need millions upon millions of lines of code just to build a usable platform. Securing Kubernetes is a nightmare. And lock-in never really went away because it's all coupled with cloud specific stuff anyway. Many of the core concepts of Kubernetes should be taken to build a new alternative without all the footguns. Security should be baked in, not an afterthought when you need…

> K8S is a disastrous complexity bomb. You need millions upon millions of lines of code just to build a usable platform. I don't know what you have been doing with Kubernetes, but I run a few web apps out of my own Kubernetes cluster and the full extent of my lines of code are the two dozen or so LoC kustomize scripts I use to run each app.

You're both using hyperboles that don't match the reality of the average-sized company using Kubernetes. It's neither "millions upon millions of lines of code" nor "just a few dozen lines of kustomize scripts".
Post reply on HN