Live data from Hacker News

Almost every infrastructure decision I endorse or regret

cep.dev

531–540 of 644 posts

Re: Almost every infrastructure decision I endorse or regret

#531
post #520

Earlier quoted context omitted.

I thought you meant API and parameters. Blaming them for product names is weird to me.

aws api and param names are stupidly long CamelCased and not even consistent half the time like a leaky abstraction over their underlying implementation

You remember any example? I don't call API directly and usually use CLI/SDK/CDK that work a lot better than gcloud. I did see some inconsistencies between services (e.g. updating params for SQS and SNS) and that could definitely be improved. But honestly, comparing to GCP mess, AWS is ten times better.

Re: Almost every infrastructure decision I endorse or regret

#532

Earlier quoted context omitted.

I am confused. Doesn't Modal Labs solve this?

Definitely. But the sad reality is that in some corporate environments (incumbent finance, government) if it's not a button click in portal.azure.com away, you can spend 6-12 months in meetings with low energy gloomboys to get your access approved.

Ah, I see. Yeah, been victim of that bureaucracy as well.

Re: Almost every infrastructure decision I endorse or regret

#533

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…

This may be a noob question - but why not use Github Projects instead of Linear or Jita?

You're staying within an ecosystem you know and it seems to offer almost all of the necessary functionality

Re: Almost every infrastructure decision I endorse or regret

#535

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…

Don't need any of it. Start simple. Some may be useful though. The list makes good points. Keep it around and if you find yourself suffering from the lack of something, look through the list and see if anything there would be good ROI. But don't adopt something just because this list says you should.

One thing though, I'd start with go. It's no more complex than python, more efficient, and most importantly IMO since it compiles down to binary it's easier to build, deploy, share, etc. And there's less divergence in the ecosystem; generally one simple way to do things like building and packaging, etc. I've not had to deal with versions or tooling or environmental stuff nearly as much since switching.

Re: Almost every infrastructure decision I endorse or regret

#536
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.

While I love ECS you're not giving k8s enough credit. Nearly every COTS (common off the self) app has a helm chart, hardly any provide direct ECS support. If I want a simple kafka cluster or zookeeper cluster there's a supported helm chart for that, nothing is provided for ECS, you have to make that yourself.

Re: Almost every infrastructure decision I endorse or regret

#537

Earlier quoted context omitted.

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.

Have you named any successful product?

Yes, named a product and sold over 100,000 units of them. Naming products is hard but not that hard.

Re: Almost every infrastructure decision I endorse or regret

#538
post #483

Earlier quoted context omitted.

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

Thanks for the clarification hadn’t appreciated the difference. Also somewhat reiterates my point which is nice as well

Re: Almost every infrastructure decision I endorse or regret

#539

Earlier quoted context omitted.

I'm currently early in my career and "the software guy" in a non-software team and role, but I'm looking to move into a more engineering direction. You've pretty much got my dream next job at the moment — if you don't mind me asking, how did you manage to find your role, especially being "still pretty Jr."?

What a coincidence! I've got my dream job too! The things I did to get here are honestly kind of stupid. I started out at a defense contractor after graduating and left in the first six months because all the software devs were jumping ship. Went to a small business defense contractor (yep that's a thing) and learned to build web apps with React and Django. Then the pace of business slowed so after about 18 months I…

I did this myself for a good 15 years or so, but eventually with a family, money became a bit more of a priority, and it's hard to get a good job if all you've worked at is small shops. Any next role in a larger tech company will likely be a downgrade until you can prove yourself out, which of course you may not be able to because things are so different, and motivation will run low because you're being tasked with all the stuff that caused you to leave big tech in the first place. It can be quite miserable to be grouped with a bunch of kids with 3-5 YOE that have no idea how to build something from scratch, and they're outperforming you because they know the system.

In my case it took a good five years and a couple job hops to rebalance. But eventually you get back to a reasonable tech leadership role and back to making some of the bigger decisions to help make the junior devs' lives less miserable.

No regrets, but the five years it takes to rebalance can be pretty hard.

Re: Almost every infrastructure decision I endorse or regret

#540

Earlier quoted context omitted.

Oh I disagree - we migrated from azure to AWS, and running a container on Fargate is significantly more work than Azure Container Apps [0]. Container Apps was basically "here's a container, now go". [0] https://azure.microsoft.com/en-gb/products/container-apps

Heh, your comment almost echos the positive thing I was going to say, as well as highlighting half of why I loathe Azure with every fiber of my being https://learn.microsoft.com/en-us/azure/container-instances/... is the one I was going to plug, because coming from a kubernetes background it seems to damn near be the PodSpec and thus both expresses a lot of my needs and also is very familiar https://learn.microsoft.c…

Oh yeah. This and resource groups are the only two things that azure did well. Everything else is a disaster.
Post reply on HN