Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Almost every infrastructure decision I endorse or regret

cep.dev

Post reply on HN
Print view View original

331–340 of 644 posts

Re: Almost every infrastructure decision I endorse or regret

#331

Post by ratherbefuddled »

morsecodist wrote: post #131

> 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're relatively small GCP users (low six figures) and have monthly cadence meetings with our Google account manager. They're very accommodating, and will help with contacts, events and marketing.

Re: Almost every infrastructure decision I endorse or regret

#333

Post by krab »

mr_moose wrote: post #218
hintymad wrote: post #73

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

To me, it sounds like your company went through a complex re-architecturing exercise at the same time you moved to Kubernetes, and your problems have more to do with your (probably flawed) migration strategy than the tool. Lifting and shifting an "EC2 + ASG" set-up to Kubernetes is a straightforward process unless your app is doing something very non-standard. It maps to a Deployment in most cases. The fact that you…

Not familiar with the OP but this may have been the pitch for migration: "K8S will allow us better automation".

Re: Almost every infrastructure decision I endorse or regret

#334

Post by smokel »

hhsectech wrote: post #317
jumploops wrote: post #280

Earlier quoted context omitted.

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…

There are two possible scenarios here. Firstly, they can't find the talent to support what you implemented...or more likely, your docs suck! I've made a career out of inheriting other peoples whacky setups and supporting them (as well as fixing them) and almost always its documentation that has prevented the client getting anywhere. I personally dont care if the docs are crap because usually the first thing I do is u…

I agree that bad documentation is a serious problem in many cases. So much so that your suggestion to write the documentation after the fact can become quite impossible.

If there is only one thing that juniors should learn about writing documentation (be it comments or design documents), it is this: document why something is there. If resources are limited, you can safely skip comments that describe how something works, because that information is also available in code.

(It might help to describe what is available, especially if code is spread out over multiple repositories, libraries, teams, etc.)

(Also, I suppose the comment I'm responding to could've been slightly more forgiving to GP, but that's another story.)

Re: Almost every infrastructure decision I endorse or regret

#335

Post by politelemon »

rswail wrote: post #253
morsecodist wrote: post #131

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

> There's nothing hidden about the fact that they will push us to use AWS services.

Our account team don't even do that. We use a lot of AWS anyway and they know it, so they're happy to help with competitor offerings and integrating with our existing stack. Their main push on us has been to not waste money.

Re: Almost every infrastructure decision I endorse or regret

#336

Post by izacus »

LispSporks22 wrote: post #89
ndjshe3838 wrote: post #78

I’m imagining a developer in the 90s/00s reading this list and being baffled by the complexity/terminology

I agree. I’m afraid I’m one of those 00s developers and can relate. Back then many startups were being launched on super simple stacks. With all of that complexity/word salad from TFA, where’s the value delivered? Presumably there’s a product somewhere under all that infrastructure, but damn, what’s left to spend on it after all the infrastructure variable costs? I get it’s a list of preferences, but still once you’v…

Look, the thing is - most of infra decisions are made by devops/devs that have a vested interest in this.

Either because they only know how to manage AWS instances (it was the hotness and thats what all the blogs and YT videos were about) and are now terrified from losing their jobs if the companies switch stacks. Or because they needed to put the new thing on their CV so they remain employable. Also maybe because they had to get that promotion and bonus for doing hard things and migrating things. Or because they were pressured into by bean counters which were pressured by the geniuses of Wall Street to move capex to opex.

In any case, this isn't by necessity these days. This is because, for a massive amount of engineers, that's the only way they know how to do things and after the gold rush of high pay, there's not many engineers around that are in it to learn or do things better. It's for the paycheck.

It is what it is. The actual reality of engineering the products well doesn't come close to the work being done by the people carrying that fancy superstar engineer title.

Re: Almost every infrastructure decision I endorse or regret

#337

Post by movpasd »

charred_patina wrote: post #125
LispSporks22 wrote: post #74

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…

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."?

Re: Almost every infrastructure decision I endorse or regret

#338

Post by andreif »

alentred wrote: post #308
andreif wrote: post #291

Earlier quoted context omitted.

That's completely opposite to my experience. Do you have any examples of AWS naming that you think is "teenage boy trying to be cool"? I am genuinely curious.

BigQuery - Athena Pub/Sub - Kinesis Cloud CDN - CloudFront Cloud Domains - Route 53 ...

Pub/sub is more like SNS or EventBridge Bus to me

Re: Almost every infrastructure decision I endorse or regret

#339

Post by andreif »

alentred wrote: post #308
andreif wrote: post #291

Earlier quoted context omitted.

That's completely opposite to my experience. Do you have any examples of AWS naming that you think is "teenage boy trying to be cool"? I am genuinely curious.

BigQuery - Athena Pub/Sub - Kinesis Cloud CDN - CloudFront Cloud Domains - Route 53 ...

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

Re: Almost every infrastructure decision I endorse or regret

#340

Post by interroboink »

hhsectech wrote: post #319
smitty1e wrote: post #307

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…

Eh? I've never had a problem moving data out of AWS. Have people lost the ability to write export and backup scripts?

My (peripheral) experience is that it is much cheaper to get data in than to get data out. When you have the amount of data being discussed — "Enterprise data. Going back years." — that can get very costly.

It's the amount of data where it makes more sense to put hard drives on a truck and drive across the country rather than send it over a network, where this becomes an issue (actually, probably a bit before then).

Post reply on HN