Live data from Hacker News

Almost every infrastructure decision I endorse or regret

cep.dev

511–520 of 644 posts

Re: Almost every infrastructure decision I endorse or regret

#511
I've seen a lot of comments about how bad DataDog is because of cost but surprisingly I haven't seen open-source alternatives like OpenTelemetry/Prometheus/Grafana/Tempa mentioned.

Is it because most people are willing to pay someone else to manage monitoring infrastructure or other reasons?

Re: Almost every infrastructure decision I endorse or regret

#512

Earlier quoted context omitted.

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

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 got on the Leetcode grind and got into a FAANG. Realized I hated it, so I quit after about 9 months with no job lined up.

While unemployed I convinced myself I was going to get a job in robotics (I actually got pretty close, I had 3 final level interviews with robotics companies), but the job market went to shit pretty much the exact day I quit my job lol. I spent about 6 months just learning ROS, Inverse Kinematics, math for robotics, gradient descent and optimization, localization, path planning, mapping etc. I taught at a game development summer camp for a month and a half, that was awesome. Working with kids is always a blast. Also learned Rust and built a prototype for a multiplayer browser-based coding game I had been thinking about for a while. It was an excuse to make a full stack application with some fun infrastructure stuff.

https://ai-arena.com/#/multiplayer

The backend is no longer running, but originally users could see their territory on the galaxy grow as their code won battles for them.

For the current role, I really just got lucky. The previous engineer was on his way out for non-job related reasons. He had read a lot of the books I had (Code Complete, Domain Driven Design) and I think we just connected over shared interests and intellectual curiosity.

I think that in the modern day, so many people are really just in this space for the paycheck-- and that's okay! Everyone needs to make a living. But I think that if you have that intellectual curiosity and like making stuff, people will see that and get excited. It ends up being a blessing and a curse.

I have failed interviews because of honesty "I would Google the names of books and read up on that subject" or "I think if I was doing CSS then I would be in the wrong role" (I realize how douchey that sounds but I just was not meant to design things, I have tried). But I have also gone further in interviews than I should have because I was really engrossed in a particular problem like path planning or inverse kinematics and I was able to talk about things in plain terms.

I think it's easier to learn things quickly if they are something you're actually interested in, it becomes effortless. Basically I just try to do that so I can learn optimally, then I try to get lucky.

EDIT: Oh I just thought of more good advice. Find senior devs to learn from. They can be kind of grumpy in their online presence, but they help you avoid so many tar pits. I am in a Discord channel with a handful of senior engineers. The best way to get feedback is to naively say "I'm going to do X", they will immediately let you know why X is a bad idea. A lot of their advice boils down to KISS and use languages with strong typing.

Re: Almost every infrastructure decision I endorse or regret

#513

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…

I am yet to meet an IRL person who believes Azure has "sane management interface". In my experience it was horribly inconvenient, filled with weird anti-UX solutions that were completely unnecessary. It maybe shows you all at once, or at least tries to, but it's such a horrible idea for a complex system. Non-surprisingly it never worked properly with various widgets hanging or erroring-out. It was impossible to see wtf is going on, what state it is in, or how to do anything about it. Azure will always be an example of a web UI done horribly wrong. This does actually not surprise me at all since Microsoft products are known for this. Every time I need to extend my kids Xbox subscriptions I have to pull my hair out to figure out how to do it in their web mess.

How can you even compare it to AWS is a mystery to me. There are pages showing all your resources, not sure why you think it's a problem. Could be a problem from long time ago?

Re: Almost every infrastructure decision I endorse or regret

#514

Earlier quoted context omitted.

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

why is that?

Why it's weird to blame them for product names? Because their purpose slightly different. I can see where negativity comes from and understand, but product name is a lot less important as consistent API experience. AWS is the best among big players by far, hats off and well-done to their teams and leadership. I hope the others will finally learn and follow.

Re: Almost every infrastructure decision I endorse or regret

#515

Earlier quoted context omitted.

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

It's nice when things do what they say on the tin. That being said, it's hard to build a "brand" when you start out with a generic name.

How many popular products have you named and launched? Naming products is hard to meet both usability and marketing objectives. This has never been as big of a problem for me, as GCPs APIs for example. Those are the true evil. Product names I care little for.

Re: Almost every infrastructure decision I endorse or regret

#516
post #351

Earlier quoted context omitted.

No, but again, that sounds like a lot of complexity your average startup does not need. Multi-az? Why?

Because their Enterprise client requires it on their due diligence paperwork.

Which makes little sense anyway as in practice the real problems you have are from region/connectivity issues, not AZ failures.

Re: Almost every infrastructure decision I endorse or regret

#517

Earlier quoted context omitted.

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

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?

Re: Almost every infrastructure decision I endorse or regret

#518

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

aws is even worse yet somehow people love them, maybe because they get to talk to a support "human" to hand-hold them through all the badness

Re: Almost every infrastructure decision I endorse or regret

#519

Earlier quoted context omitted.

We have all of that neatly extracted into a Terraform module. Write it once and now EKS clusters are essentially disposable.

You just added yet another Thing in that huge pile of things representing millions of lines of code. That's the point.

Everything we run our workloads on is based on millions of LoCs, whether it's in the OS, in K8S, in is built-in or external kinds. If you decide to run K8S in AWS, you'll be better of using Karpenter, external-secrets and all these things as they will make your life easier in various ways.

Re: Almost every infrastructure decision I endorse or regret

#520

Earlier quoted context omitted.

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.

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