Live data from Hacker News

Almost every infrastructure decision I endorse or regret

cep.dev

181–190 of 644 posts

Re: Almost every infrastructure decision I endorse or regret

#181
post #83

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.

Agreed. It’s just ridiculous. Some just love to spend money and make things more complex.

Re: Almost every infrastructure decision I endorse or regret

#182

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

> My contrarian view is that EC2 + ASG is so pleasant to use.

Sometimes I think that managed kubernetes services like EKS are the epitome of "give the customers what they want", even when it makes absolutely no sense at all.

Kubernetes is about stitching together COTS hardware to turn it into a cluster where you can deploy applications. If you do not need to stitch together COTS hardware, you have already far better tools available to get your app running. You don't need to know or care in which node your app is suppose to run and not run, what's your ingress control, if you need to evict nodes, etc. You have container images, you want to run containers out of them, you want them to scale a certain way, etc.

Re: Almost every infrastructure decision I endorse or regret

#184
post #91

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

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.

Re: Almost every infrastructure decision I endorse or regret

#185

Earlier quoted context omitted.

Newer (aka next gen aka Team-managed) Jira projects are pretty solid.

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…

trigger warning please on the Jira stuff

Re: Almost every infrastructure decision I endorse or regret

#186

Earlier quoted context omitted.

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?

If my scale exceeds the cost benefit tradeoff, then I will thank God/Allah/Buddah/Spaghetti Monster. These questions always sound flawed to me. It's like asking won't I regret moving to California and paying high taxes once I start making millions of dollars? Maybe? But that's an amazing problem to have and one that I may be much better equipped to solve. If you are small, RDS is much cheaper, and many company killin…

I assume that you do that math on all your new features too, right? The calculation of how much extra money they will bring in?

On some level, AWS/GCP/California relies on you doing this calculation for the things that you can do it on easily (the savings of moving away), while not doing this calculation on things where it's hard to do (new development). That way, you can pretend that your new features are a lot more valuable than the $Xk/year you will save by moving your infra.

Re: Almost every infrastructure decision I endorse or regret

#187

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

In another section , they mentioned they don't have DBA, no app team own the database and the infra team is overwhelmed.

RDS make perfect sense for them

Re: Almost every infrastructure decision I endorse or regret

#188

Earlier quoted context omitted.

Heii On-Call is $32 per month total for your team — not per user. https://heiioncall.com/ (Full disclosure: part of the team building it)

Looks super interesting, and that $3/month for hobbyists is just low enough to meet my budget for hobby services, but please, for on-call stuff, you gotta have alerts that make phone calls. Nothing else is going to wake me in the middle of the night. This is the #1 feature I expect from an on-call service - you're on-call because you will be called .

Thanks for the feedback!

We use iOS “Critical Alerts” and similar on Android that breaks through any Do-Not-Disturb settings. https://heiioncall.com/blog/better-alerting-for-heii-on-call... Would you be willing to give that a shot? It wakes me every time :)

(It’s configurable too; we have vibrate-only or silenced modes. Think old-school beeper.)

In the rare case that it doesn’t wake you, we have configurable escalation strategies to alert someone else on your team after a configurable number of minutes.

Re: Almost every infrastructure decision I endorse or regret

#189

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

AWS enterprise support (basically first line support that you paid for) is actually really really good. they will look at your metrics/logs and share with you solid insights. anything more you can talk to a TAM who can then reach out to relevant engineering teams

Re: Almost every infrastructure decision I endorse or regret

#190

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

> I have never found an easier way to get a docker container running in the cloud

We started using Azure Container Apps (ACA) and it seems simple enough.

Create ACA, point to GitHub repo, it runs.

Push an update to GitHub and it redeploys.

Post reply on HN