Live data from Hacker News

Almost every infrastructure decision I endorse or regret

cep.dev

611–620 of 644 posts

Re: Almost every infrastructure decision I endorse or regret

#611

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

That would totally be my preference if business users didn't want access.

Getting them to use Github/Gitlab is an argument I've never won. Typically it goes the other way and I end up needing to maintain a Monday or Airtable instance in addition to my ticketing system.

Re: Almost every infrastructure decision I endorse or regret

#612

Earlier quoted context omitted.

https://github.com/Azure/karpenter-provider-azure there is this in the works for karpenter on aks

It’s actually released in preview, they called it Node Auto Provisioning. Doesn’t work with Azure Linux unfortunately.

Azure Linux support has been added recently [1], and so is available for self-hosted Karpenter (you can specify "imageFamily: AzureLinux" in AKSNodeClass), will be rolled out for the managed experience (Node Auto Provisioning) soon.

[1] https://github.com/Azure/karpenter-provider-azure/pull/72

(source: On the team that is developing the provider)

Re: Almost every infrastructure decision I endorse or regret

#614
Terraform is great but it's so frustrating sometimes. You just pray that the provider has a specific configuration of whatever resources you're working with, because else when them resources are up on multiple env then you'll have to edit those configs somehow.

Re: Almost every infrastructure decision I endorse or regret

#615

I don't get why all startups don't just start with a PaaS like Render, Fly.io or Heroku. Why spend time setting up your own infra and potentially have to hire dedicated staff to manage it when you can do away with all that and get on with trying to move your business forward? If and when you start experiencing scaling problems (great!), that's the time to think about migrating to setting up infra.

Because like every service-oriented offering, each platform differentiates as hard as it can to lock you in to their way of doing things. Things largely look the same on the surface; this takes the most effect at the implementation-detail level, where adjusting and countercorrecting down the track is fiddly and uses an adrenally-draining level of attention span - right when you're at the point where you're scaling an…

When you're starting out, you just need a server to run your application and a database.

It literally doesn't matter what service you're using at that point.

I don't see how you need to be "doing things their way" when that's all you have.

Re: Almost every infrastructure decision I endorse or regret

#616
post #612

Earlier quoted context omitted.

It’s actually released in preview, they called it Node Auto Provisioning. Doesn’t work with Azure Linux unfortunately.

Azure Linux support has been added recently [1], and so is available for self-hosted Karpenter (you can specify "imageFamily: AzureLinux" in AKSNodeClass), will be rolled out for the managed experience (Node Auto Provisioning) soon. [1] https://github.com/Azure/karpenter-provider-azure/pull/72 (source: On the team that is developing the provider)

Awesome, thank you.

Re: Almost every infrastructure decision I endorse or regret

#617
post #253

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

We are a reasonably large AWS customer and our account manager sends out regular emails with NDA information on what's coming up, we have regular meetings with them about things as wide ranging as database tuning and code development/deployment governance. They often provide that consulting for free, and we know their biases. There's nothing hidden about the fact that they will push us to use AWS services. On the oth…

Fwiw as a medium spend (250k to eventually grow into 1M+ year) GCP customer we had the same deal with product roadmaps shared up-front under NDA etc.

And never did I miss something in GCP that I could find in AWS. Not sure the breadth is adding much compared to a simpler product suite in GCP.

Re: Almost every infrastructure decision I endorse or regret

#618

Earlier quoted context omitted.

That's how nearly every aspect of every business works; would you you start a bakery by learning construction and building it yourself?

Construction is a one time cost. It infrastructure is in constant use. It's like accounting and finance. Yeah a lot of companies use tax firms, but they all have finance and accounting in-house.

I don't think that's the important distinction, lots of ongoing costs are outsourced.

Amazon may have their own shipping fleet, most retailers of smaller scale pay someone else to do it for profit.

Re: Almost every infrastructure decision I endorse or regret

#619

Earlier quoted context omitted.

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.

awesome. I remember reading about this a while ago, but never tried. Since it has the same API i can imagine its not daunting as a multi-cloud infrastructure. I guess permissions might be more complex, as in EC2 instance profiles wouldnt grant access, etc.

Just to make sure nobody is confused by this - R2 has the same API as S3, not GCS. We had to build a simple abstraction around GCS/S3 to perform the migration. But if you're migrating from S3, it's pretty much drop-in. We even use the AWS-provided S3 Java library (especially convenient for making signed URLs).

Re: Almost every infrastructure decision I endorse or regret

#620

Earlier quoted context omitted.

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.

Because you don't need any specific support for ECS? It's just Docker.

Yes but lose a ton of functionality docker isn't a replacement for helm.
Post reply on HN