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

601–610 of 644 posts

Re: Almost every infrastructure decision I endorse or regret

#601

Post by ifwinterco »

AtlasBarfed wrote: post #577
mdaniel wrote: post #526

Earlier quoted context omitted.

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…

Aws refactored their console to use modern wen spa and it is TERRIBLE. It amazes me a company that makes that much money has such a crappy client.

Yeah this amazes me as well - the AWS web interface does work, but it's pretty low quality.

You'd think a company with 1.5m employees could find half a dozen decent front end developers, but apparently not

Re: Almost every infrastructure decision I endorse or regret

#602

Post by andreif »

morsecodist wrote: post #543
andreif wrote: post #514

Earlier quoted context omitted.

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.

My issue isn't just with the names themselves but they are emblematic of AWS's overall mentality. They want to have the AWS(TM) solution to X business case while other cloud providers feel more like utilities that give you building blocks. This obviously works for them and many of their customers I just personally don't care for it. It is probably to do with the level of complexity I am working at (*which is not very…

> while other cloud providers feel more like utilities that give you building blocks.

Idk why you don't see AWS as a utility providing building blocks.

> I don't think trying to emulate AWS's support and consistent API makes sense as a strategy for other cloud providers.

Those are such essential things. It's very hard to imagine prioritising something else and succeeding in anything.

Re: Almost every infrastructure decision I endorse or regret

#603

Post by marcinzm »

davedx wrote: post #578
marcinzm wrote: post #398

Earlier quoted context omitted.

And that's the problem. "It's easy for me because I've done it a dozen times so it's easy for everyone" is a very common fallacy.

This is an oversimplification, but! Dumping postgres to a file is one command. scp the file to a different server is two commands. (Granted you need to setup ssh keys there too). I have implemented backups this way. With sqlite you only need the scp part. You can even push your backup file to an S3 bucket... with one command! Honestly, this argument mystifies me. Of course you can make it as complicated as you want t…

And that works right until you get to publish an incident report like this:

https://about.gitlab.com/blog/2017/02/01/gitlab-dot-com-data...

Re: Almost every infrastructure decision I endorse or regret

#604

Post by dijit »

dfgdfg34545456 wrote: post #598
osigurdson wrote: post #199

Earlier quoted context omitted.

Cloud was supposed to be a commodity. Instead it is priced like at burger at the ski hill.

If it is such a golden goose, then there will be other competitors come in and compete the price down.

not really, the API lock-in and egregious egress fees will keep competitors at the door.

That: and trust is hard earned over a long tail which is harder if you are trying to compete on price.

Re: Almost every infrastructure decision I endorse or regret

#605

Post by el_isma »

cyounkins wrote: post #122

I've climbed the mountain of learning the basics of kubernetes / EKS, and I'm thinking we're going to switch to ECS. Kubernetes is way too complicated for our needs. It wants to be in control and is hard to direct with eg CloudFormation. Load balancers are provisioned from the add-on, making it hard to reference them outside kubernetes. Logging on EKS Fargate to Cloudwatch appears broken, despite following the docs.…

I started with ECS (because I wanted to avoid the complexity of K8s) and regret it. I feel I wasted a lot of time there.

In ECS, service updates would take 15 min or more (vs basically instant in K8s).

ECS has weird limits on how many containers you can run on one instance [0]. And in the network mode where you can run more containers on a host, then the DNS is a mess (you need to lookup SRV records to find out the port).

Using ECS with CDK/Cloudformation is very painful. They don't support everything (specially regarding Blue/Green deployments), and sometimes they can't apply changes you do to a service. When initially setting up everything, I had to recreate the whole cluster from scratch several times. You can argue that's because I didn't know enough, but if that ever happened to me on prod I'd be screwed.

I haven't used EKS (I switched to Azure), so maybe EKS has their own complex painful points. I'm trying to keep my K8s as vanilla as possible to avoid the cloud lock-in.

[0] https://docs.aws.amazon.com/AmazonECS/latest/bestpracticesgu...

Re: Almost every infrastructure decision I endorse or regret

#606

Post by osigurdson »

dijit wrote: post #604
dfgdfg34545456 wrote: post #598

Earlier quoted context omitted.

If it is such a golden goose, then there will be other competitors come in and compete the price down.

not really, the API lock-in and egregious egress fees will keep competitors at the door. That: and trust is hard earned over a long tail which is harder if you are trying to compete on price.

I think trust is the biggest factor. If you willingly lock yourself into a vendor specific product, that is obviously your own choice.

Re: Almost every infrastructure decision I endorse or regret

#607

Post by nivertech »

tester457 wrote: post #344
fshbbdssbbgdd wrote: post #152

Earlier quoted context omitted.

I have had the experience of an AWS account manager helping me by getting something fixed (working at a big client). But more commonly, I think the account manager’s job at AWS or any cloud or SAAS is to create a reality distortion field and distract you from how much they are charging you.

> I think the account manager’s job at AWS or any cloud or SAAS is to create a reality distortion field and distract you from how much they are charging you. How do they do this jedi mind trick?

One way is to charge high prices from the get go, and then proactively contact you, and offer to help to reduce your bill by doing some cloud optimization magic ;)

Re: Almost every infrastructure decision I endorse or regret

#608

Post by eduction »

dalyons wrote: post #508
eduction wrote: post #489

Earlier quoted context omitted.

To me this is semantics. So it’s a data warehouse rather than a database. Ok. Or we share data from a common source via “services” - ok but that’s another word for a database and a client (using http to do the talking doesn’t really change anything). I’m not saying literally every source of data has to be shared and centrally managed. I’m also not saying “rdbms accessed via traditional client and queried via sql” whe…

Ok, but the OP and the article are talking specifically about a directly shared rdbms scenario, not some nebulous concept of shared data. Also, operationally it’s not “semantics” at all. You don’t get into (many) operational problems with analysts sharing a datawarehouse. You absolutely do with online apps sharing a rdbms, they aren’t the same thing.

No, neither the article nor the post I originally replied to specify anything more specific than “database”. Database != RDBMS.

A data warehouse is a type of database and is does need to be managed. Your assertion that it is easier to manage is orthogonal to my assertion that there will always be a central database to manage in an organization of decent size.

Re: Almost every infrastructure decision I endorse or regret

#609

Post by foofie »

cedws wrote: post #495
foofie wrote: post #494

Earlier quoted context omitted.

> If you're using a K8S cluster just to deploy a few web apps (...) It's really not about what I do and do not do with Kubernetes. It's on you to justify your "millions upon millions lines of code" claim because it is so outlandish and detached from reality that it says more about your work than about Kubernetes. I repeat: I only need a few dozen lines of kustomize scripts to release whole web apps. Simple code. Easy…

You are missing the point. I recommend you look into Platform Engineering and what it involves.

Please don't deflect the question. You claimed you need millions and millions of LoC to get something running on Kubernetes. I stated the fact that I have multiple apps running in my personal Kubernetes cluster and they only require a couple of dozen lines of Kustomize. You are the one complaining about complexity where apparently no one else sees it. Either you're able to back up your claims, or you can't. I don't think you can, actually, and I think that's why you are deflecting questions. In fact, I'd go as far as to claim you have zero experience with Kubernetes, and you're just parroting cliches.

Re: Almost every infrastructure decision I endorse or regret

#610

Post by theptip »

latch wrote: post #193
theptip wrote: post #162

Earlier quoted context omitted.

That’s just another way of saying the opportunity cost isn’t worth paying to do the migration. Optionality and flexibility are extremely valuable, and that is why cloud compute continues to be popular, especially for rapidly/burstily growing businesses like startups.

I don't mean to pick on your specific comments, but I find these analysis almost always lack a crucial perspective: level of knowledge. This is the single biggest factor, and it's the hardest one to be honest about. No one wants to say "RDS is a good choice . . . because I don't know how nor have I ever self managed a database." If you want a different opportunity cost, get people with different experience. If RDS is…

Lack of expertise in some particular technology is simply another opportunity cost. I can learn how to operate a production DB at scale (I have racked servers and run other production workloads) but as cofounder/CTO in a startup is that the best use of my time?

If the cost of a hosted DB is going to sink the company, then of course, I will figure it out and run it myself. But it’s not, for most startups. And therefore that knowledge isn’t providing much leverage.

Starting an AI company with deep expertise in training models - that is an example of knowledge providing huge leverage. DB tech is not in this bucket for most businesses.

Post reply on HN