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

251–260 of 644 posts

Re: Almost every infrastructure decision I endorse or regret

#251

Post by rswail »

sgarland wrote: post #29
vasco wrote: post #7

Earlier quoted context omitted.

That's a huge instance with an enterprise license on top. Most large SaaS companies can run off of $5k / m or cheaper RDS deployments which isn't enough to pay someone. The amount of people running half a million a year RDS bills might not be that large. For most people RDS is worth it as soon as you have backup requirements and would have to implement them yourself.

> Most large SaaS companies can run off of $5k / m or cheaper RDS Hard disagree. An r6i.12xl Multi-AZ with 7500 IOPS / 500 GiB io1 books at $10K/month on its own. Add a read replica, even Single-AZ at a smaller size, and you’re half that again. And this is without the infra required to run a load balancer / connection pooler. I don’t know what your definition of “large” is, but the described would be adequate at best…

If you're not using GP3 storage that provides 12K minimum IOPS without requiring provisioned IOPS for >400GB storage, as well as 4 volume striping, then you're overpaying.

If you don't have a reserved instance, then you're giving up potentially a 50% discount on on-demand pricing.

An r6i.12xl is a huge instance.

There are other equivalents in the range of instances available (and you can change them as required, with downtime).

Re: Almost every infrastructure decision I endorse or regret

#252

Post by rswail »

Scubabear68 wrote: post #106
electroly wrote: post #6

> The markup cost of using RDS (or any managed database) is worth it. Every so often I price out RDS to replace our colocated SQL Server cluster and it's so unrealistically expensive that I just have to laugh. It's absurdly far beyond what I'd be willing to pay. The markup is enough to pay for the colocation rack, the AWS Direct Connects, the servers, the SAN, the SQL Server licenses, the maintenance contracts, and a…

Elsewhere today I recommended RDS, but was thinking of small startup cases that may lack infrastructure chops. But you are totally right it can be expensive. I worked with a startup that had some inefficient queries, normally it would matter, but with RDS it cost $3,000 a month for a tiny user base and not that much data (millions of rows at most).

That sounds like the app needs some serious surgery.

Re: Almost every infrastructure decision I endorse or regret

#253

Post by rswail »

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 other hand, they will also help us optimize those services and save money that is directly measurable.

GCP might have a better API and better "naming" of their services, but the breadth of AWS services, the incorporation of IAM across their services, governance and automation all makes it worth while.

Cloud has come a long way from "it's so easy to spin up a VM/container/lambda".

Re: Almost every infrastructure decision I endorse or regret

#254

Post by pinkgolem »

nyc_data_geek wrote: post #86
electroly wrote: post #6

> The markup cost of using RDS (or any managed database) is worth it. Every so often I price out RDS to replace our colocated SQL Server cluster and it's so unrealistically expensive that I just have to laugh. It's absurdly far beyond what I'd be willing to pay. The markup is enough to pay for the colocation rack, the AWS Direct Connects, the servers, the SAN, the SQL Server licenses, the maintenance contracts, and a…

Some orgs are looking at moving back to on prem because they're figuring this out. For a while it was vogue to go from capex to opex costs, and C suite people were incentivized to do that via comp structures, hence "digital transformation" ie: migration to public cloud infrastructure. Now, those same orgs are realizing that renting computers actually costs more than owning them, when you're utilizing them to a signif…

Keep in mind, there is an in between..

I would have a hard time doing servers as cheap as hetzner for example including the routing and everything

Re: Almost every infrastructure decision I endorse or regret

#255

Post by 8organicbits »

hitekker wrote: post #233

Props to the author for writing up the results from his exercise. But I think he should focused on a few controversial ones, and not the rotes ones. Many of the decisions presented are not disagreeable (choosing slack) and some lack framing that clarifies the associated loss (Not adopting an identity platform early on). I think they're all good choices worth mentioned; I would have preferred a deeper look into the fe…

> not the rotes ones

It helps to hear the validation, although I think almost every decision has a dissenting voice in the HN comments.

Re: Almost every infrastructure decision I endorse or regret

#256

Post by rswail »

Cacti wrote: post #191
bigstrat2003 wrote: post #164

Earlier quoted context omitted.

I'm right there with you on Jira. The haters are wrong - it's a decent enough ticket system, no worse than anything else I've used. You can definitely torture Jira into something horrible, but that's not Jira's fault. Bad managers will ruin any ticket system if they have the customization tools to do so.

Using Jira feels like using IBM enterprise web software from 2005, and I am simply not going to make my teams put up with that amount of inanity.

We switched to JIRA around 2005 away from IBM enterprise web software, because it was a breath of fresh air.

So on the standard tech hype cycle, that sounds about right.

Re: Almost every infrastructure decision I endorse or regret

#257

Post by rswail »

Jedd wrote: post #92
tootie wrote: post #22

Earlier quoted context omitted.

Interesting. Atlassian also just launched an integration with OpsGenie. I have the same opinion of JIRA. I've tried many competitors (not Linear so far) and regretted it every time.

> Atlassian also just launched an integration with OpsGenie. Given Atlassian bought OpsGenie in 2018, this either somewhere between quite late and unsurprising .

Two different measurements (time and Atlassian development processes) that are orthogonal.

Anything Atlassian does is mostly quite late and its integration story is so pathetic that it's unsurprising.

Try to have a bitbucket pipeline that pushes to confluence. Seems like a basic integration to have, after all, Confluence has an API (well, actually it has 3 different ones) so surely Atlassian would make a basic thing like "publish a wiki page" a thing you get out of the box.

Nope.

Re: Almost every infrastructure decision I endorse or regret

#258

Post by Rainymood »

As a machine learning platform engineer these sound like technology choices as opposed to infrastructure decisions. I would love to read this post but really with the infrastructure trade-offs that were made. But thanks for the post.

Side node: There is a small typo repeated twice "Kuberentes"

Re: Almost every infrastructure decision I endorse or regret

#259

Post by rswail »

AznHisoka wrote: post #169
magicalhippo wrote: post #72

Earlier quoted context omitted.

Good question. We don't have a DBA either. I've learned SQL as needed and while I'm not terrible, it's still daunting when making the schema for a new module that might require 10-20 tables or more. One thing that has worked well for us is to alway include the top-most parent key in all child tables down yhe hierarchy. This way we can load all the data for say an order without joins/exists. Oh and never use natural k…

Not to pick on you, but is SQL not basic knowledge for every software engineer these days? Or have times changed?

Times have changed. If you have C# programmers and they can't do it in Entity Framework/LINQ, then they can't do it.

Re: Almost every infrastructure decision I endorse or regret

#260

Post by WildGreenLeave »

foofie wrote: post #184
cedws wrote: post #91

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. Securing Kubernetes is a nightmare. And lock-in never really went away because it's all coupled with cloud specific stuff anyway. Many of the core concepts of Kubernetes should be taken to build a new alternative without all the footguns. Security should be baked in, not an afterthought when you need…

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

I run my own cluster too, it is managed by one terraform file which is maintained on GitHub [0]. Along with that I deploy everything on here with 1 shell script and a bunch of yaml manifests for my services. It's perfect for projects that are managed by one person (me). Everything is in git and reproducable. The only thing I am doing unconventional is that I didn't want to use github actions, so I use Kaniko to build my Docker containers inside my cluster.

0 https://github.com/kube-hetzner/terraform-hcloud-kube-hetzne...

Post reply on HN