Live data from Hacker News

Almost every infrastructure decision I endorse or regret

cep.dev

521–530 of 644 posts

Re: Almost every infrastructure decision I endorse or regret

#521
post #392

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

> "regular cadence meetings with our AWS account manager" and I am not sure what could be discusse. As being on a number of those calls, its just a bunch of crap where they talk like a scripted bot reading from corporate buzzword bingo card over a slideshow. Their real intention is two fold. To sell you even more AWS complexity/services, and to provide "value" to their person of contact (which is person working in yo…

> We're paying north of 500K per year in AWS support (which is a highway robbery), and in return you get a "team" of people supposedly dedicated to you, which sounds good in theory but you get a labirinth of irresponsiblity, stalling and frustration in reality.

I’ve found a lot of the time the issues we run into are self-inflicted. When we call support for these, they have to reverse-engineer everything which takes time.

However when we can pinpoint the issue to AWS services, it has been really helpful to have them on the horn to confirm & help us come up with a fix/workaround. These issues come up more rarely, but are extremely frustrating. Support is almost mandated in these cases.

It’s worth mentioning that we operate at a scale where the support cost is a non-issue compared to overall engineering costs. There’s a balance, and we have an internal structure that catches most of the first type of issue nowadays.

Re: Almost every infrastructure decision I endorse or regret

#522

Earlier quoted context omitted.

Heartily seconded. Also don't forget the docs: Google Cloud docs are generally fairly sane and often even useful, whereas my stomach churns whenever I have to dive into AWS's labyrinth of semi-outdated, nigh-unreadable crap.

To be fair there are lots of GCP docs, but I cannot say they are as good as AWS. Everything is CLI-based, some things are broken or hello-world-useless. Takes time to go through multiple duplicate articles to find anything decent. I have never had this issue with AWS. GCP SDK docs must be mentioned separately as it's a bizarre auto-generated nonsense. Have you seen them? How can you even say that GCP docs are good af…

very few things are cli only, most have multiple ways to do things. and they have separate guide reference sections that can easily be found. compared to aws where your best bet is to hope google indexed the right page for them.

Re: Almost every infrastructure decision I endorse or regret

#523

Earlier quoted context omitted.

Azure is a complete disaster, deserves its own garbage-category, and gives people PTSD. I don't think AWS/CGP should ever be compared to it at all.

Funnily enough, I have the opposite opinion. AWS has "fun" features like the ability to just lose track of some resource and still be billed for it. It's in here... somewhere. Not sure which region or account. I'll find it one day. GCP is made by Google, also known as children that forgot to take their ADHD medication. Any minute now they'll just casually announce that they're cancelling the cloud because they're bor…

you're lucky if azure works without errors half the time...

Re: Almost every infrastructure decision I endorse or regret

#524

Earlier quoted context omitted.

> I have never found an easier way to get a docker container running in the cloud I don't have a ton of Azure or cloud experience but I run an Unraid server locally which has a decent Docker gui. Getting a docker container running in Azure is so complicated. I gave up after an hour of poking around.

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.com/en-us/azure/templates/microsoft....

Your link does seem to be a lot more "container, plus all the surrounding stuff" in line with the "apps" part, whereas mine more closely matches my actual experience of what you said: container, go

The "what the fucking hell is wrong with you people?" part is that their naming is just all over the place, and changes constantly, and is almost designed to be misleading in any sane conversation. I quite literally couldn't have guessed whether Container Apps was a prior name of Container Instances, a super set of it, subset, other? And one will observe that while I said Container Instances, and the URL says Container Instances, the ARM is Container Groups. Are they the same? different? old? who fucking knows. It's horrific

Re: Almost every infrastructure decision I endorse or regret

#525
post #471

Earlier quoted context omitted.

Millions upon millions of lines of code?! What? Can you specify what you were trying to do with it?

Argo CD, Argo Rollouts, Vault, External Secrets, Cert Manager, Envoy, Velero, plus countless operators, plus a service mesh if you need it, the list goes on. If you're providing Kubernetes as a platform at any sort of scale you're going to need most of this stuff or some alternatives. This sums up to at least multiple million LOC. Then you have Kubernetes itself, containerd, etcd...

that's not much different from using the cloud PaaS offerings besides who runs that million lines and who gets the freedom/control for customization.

Re: Almost every infrastructure decision I endorse or regret

#526

> 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 don’t have as much experience with aws but I do hate gcp. The ui is slow and buggy. The way they want things to authenticate is half baked and only implemented in some libraries and it isn’t always clear what library supports it. The gcloud command line tool regularly just doesn’t work; it just hangs and never times out forcing you to kill it manually wondering if it did anything and you’ll mess something up runnin…

Oh, friend, you have not known UI pain until you've used portal.azure.com. That piece of junk requires actual page reloads to make any changes show up. That Refresh button is just like the close-door elevator button: it's there for you to blow off steam, but it for damn sure does not DO anything. I have boundless screenshots showing when their own UI actually pops up a dialog saying "ok, I did what you asked but it's not going to show up in the console for 10 minutes so check back later". If you forget to always reload the page, and accidentally click on something that it says exists but doesn't, you get the world's ugliest error message and only by squinting at it do you realize it's just the 404 page rendered as if the world has fallen over

I suspect the team that manages it was OKR-ed into using AJAX but come from a classic ASP background, so don't understand what all this "single page app" fad is all about and hope it blows over one day

Re: Almost every infrastructure decision I endorse or regret

#527

Earlier quoted context omitted.

Serial integers always work better than any uuid as PKs, but the thing with uuid4 is that it disrupts any kind of index or physical ordering you decide to put on your data. Uuids are really for external communication, not in-system organization.

Serial index forces a synchronisation point on every entity that can create records. If this is only ever a single database that’s fine but plenty of apps can’t scale this way.

If you have a sharded DB, each instance can get its own range of ints, which are periodically refreshed.

PlanetScale uses int PKs [0], and they seem to have scaled just fine.

[0]: https://github.com/planetscale/discussion/discussions/366

Re: Almost every infrastructure decision I endorse or regret

#528
post #466
post #438

Earlier quoted context omitted.

It smells like ZIRP is not over yet. VCs are still burning money in the AWS fire pit.

ZIRP was never the root problem. The problem was: too much money, too few consequences for burning it . The existence of the uber-wealthy means that markets can no longer function efficiently. Every market remains irrational longer than anyone who's not uber-wealthy can remain solvent. Welcome to the new normal.

Now it's "fix it with AI". (And pay lip service to green tech.)

Re: Almost every infrastructure decision I endorse or regret

#529
post #88

Earlier quoted context omitted.

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?

Anything non-k-sortable in a B[+,-]tree will cause a ton of page splits. This is a more noticeable performance impact in RDBMS with a clustered index (MySQL's InnoDB, MS SQL Server) [0], but it also impacts Postgres [1] in multiple [2] ways.

[0]: https://www.percona.com/blog/uuids-are-popular-but-bad-for-p...

[1]: https://www.cybertec-postgresql.com/en/unexpected-downsides-...

[2]: https://www.2ndquadrant.com/en/blog/on-the-impact-of-full-pa...

Re: Almost every infrastructure decision I endorse or regret

#530
post #522

Earlier quoted context omitted.

To be fair there are lots of GCP docs, but I cannot say they are as good as AWS. Everything is CLI-based, some things are broken or hello-world-useless. Takes time to go through multiple duplicate articles to find anything decent. I have never had this issue with AWS. GCP SDK docs must be mentioned separately as it's a bizarre auto-generated nonsense. Have you seen them? How can you even say that GCP docs are good af…

very few things are cli only, most have multiple ways to do things. and they have separate guide reference sections that can easily be found. compared to aws where your best bet is to hope google indexed the right page for them.

> few things are cli only

wdym? As far as I see, it's either CLI or Terraform. GCP SDK is complete garbage, at least for Python compared to AWS boto3. I have personally made web UI for AWS CLI man pages as a fun project and can index everything myself if needed. Googling works fine. If you are not happy with it then ChatGPT is to the rescue. I honestly do not see any problem at all.

Post reply on HN