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

The many lies about reducing complexity part 2: Cloud

ea.rna.nl

Post reply on HN
Print view View original

41–50 of 131 posts

Re: The many lies about reducing complexity part 2: Cloud

#41

Post by threentaway »

harikb wrote: post #22
bane wrote: post #17

Earlier quoted context omitted.

I've worked with a number of teams over the last few years who use AWS and I'd say from top to bottom they all build their strategy more or less the same way: 0. Whatever is the minimum needed to get a VPC stood up. 1. EC2 as 90%+ of whatever they're doing 2. S3 for storing lots of stuff and/or crossing VPC boundaries for data ingress/egress (like seriously, S3 seems to be used more as an alternative to SFTP than for…

+1 I bet cloud providers are incentivized not to provide detailed billing/usage stats. I remember having to use a 3rd party service to analyze our S3 usage. Infinite scalability is also a curse - we had a case where pruning history from an S3 bucket was failing for months and we didn’t know until the storage bill became significant enough to notice. I guess in some ways it is better than being woken up in the middle…

This seems like you didn't have proper monitoring and alerting set up for your job, not sure how that is a downside of AWS.

Re: The many lies about reducing complexity part 2: Cloud

#42

Post by skohan »

ratww wrote: post #39
skohan wrote: post #30

I have to say, at my current company we are using Serverless, and it really does feel like it reduces complexity. No runtime/framework to set up, no uptime monitoring or management required on the application layer, and scaling is essentially solved for us. I mean you do pay for what you get, but it does feel like one of those technologies which really lowers the barrier to entry in terms of being able to release a p…

I used to be very excited about serverless, and I still have high hopes for it. But for me it ended up replacing the complexity of runtime and frameworks with the complexity of configuring auxiliary srevices like Gateway API, Amazon VPC, etc. We needed to move the complexity to some tool that configured the services around Lambda, like Terraform or Cloud Formation, or at best to a framework like Claudia or Serverless…

Yeah I certainly agree that the complexity doesn't really go away completely, and sometimes it's much more frustrating to have to configure poorly documented services rather than just having access to the host OS.

I guess my overall point would be that two of the hardest things to do in terms of making a production-ready application are scaling and security, and Serverless pretty much obviates them. So it's not a magic wand, but it does take away some of the significant barriers to entry.

Re: The many lies about reducing complexity part 2: Cloud

#43

Post by ithrow »

candiddevmike wrote: post #29

I see a lot of mentions in the comments about just using the basic storage/networking/compute from AWS/AZ/GCP--if that's all you're using, you should really consider other providers. Linode, Digital Ocean, and Vultr will be far more competitive and offer faster machines, cheaper, and with better bandwidth pricing. The point of using AWS/AZ/GCP is to leverage their managed service portfolio and be locked in. If you ar…

IME, the network of AWS is much better than that of DO, Linode.

Re: The many lies about reducing complexity part 2: Cloud

#44

Post by dilyevsky »

ithrow wrote: post #43
candiddevmike wrote: post #29

I see a lot of mentions in the comments about just using the basic storage/networking/compute from AWS/AZ/GCP--if that's all you're using, you should really consider other providers. Linode, Digital Ocean, and Vultr will be far more competitive and offer faster machines, cheaper, and with better bandwidth pricing. The point of using AWS/AZ/GCP is to leverage their managed service portfolio and be locked in. If you ar…

IME, the network of AWS is much better than that of DO, Linode.

How so?

Re: The many lies about reducing complexity part 2: Cloud

#45

Post by dilyevsky »

candiddevmike wrote: post #29

I see a lot of mentions in the comments about just using the basic storage/networking/compute from AWS/AZ/GCP--if that's all you're using, you should really consider other providers. Linode, Digital Ocean, and Vultr will be far more competitive and offer faster machines, cheaper, and with better bandwidth pricing. The point of using AWS/AZ/GCP is to leverage their managed service portfolio and be locked in. If you ar…

There’s also packet (now equinix metal) that gives control over l2 and have nice things such as ibgp. I think vultr may do too but their docs are poor and support was uncooperative

Re: The many lies about reducing complexity part 2: Cloud

#46

Post by ratww »

the-smug-one wrote: post #9
sanp wrote: post #4

Earlier quoted context omitted.

There is an element of _how_ as well. You could create simple monoliths or overengineered microservices. Or, complex monoliths with heavy coupling vs cleanly designed microservices with clear separations of concern.

Are microservices meant to separate data too? As in, each service has its own database. Wouldn't that lead to non-normalisation of the data or a lot of expensive network lookups to get what I want/need? What is the point of micro services anyway :-)?

> Are microservices meant to separate data too? As in, each service has its own database.

Ideally yes, to scale.

Sometimes you have a service with obvious and easy-to-split boundaries, and microservices are a breeze.

Some things that are easy to turn into microservices: "API Wrapper" to a complex and messy third-party API. Logging and data collection. Sending emails/messages. User authentication. Search. Anything in your app that could become another app.

However, when your data model is tightly coupled and you need to choose between tradeoffs (data duplication), having bigger services, or even keeping it as a monolith.

Btw, if you don't care about scalability, sharing a database is still still not the best idea. But you can have a microservice that wraps the database in a service, for example. Tools like Hasura can be used for that.

Re: The many lies about reducing complexity part 2: Cloud

#47

Post by ratww »

skohan wrote: post #42
ratww wrote: post #39

Earlier quoted context omitted.

I used to be very excited about serverless, and I still have high hopes for it. But for me it ended up replacing the complexity of runtime and frameworks with the complexity of configuring auxiliary srevices like Gateway API, Amazon VPC, etc. We needed to move the complexity to some tool that configured the services around Lambda, like Terraform or Cloud Formation, or at best to a framework like Claudia or Serverless…

Yeah I certainly agree that the complexity doesn't really go away completely, and sometimes it's much more frustrating to have to configure poorly documented services rather than just having access to the host OS. I guess my overall point would be that two of the hardest things to do in terms of making a production-ready application are scaling and security, and Serverless pretty much obviates them. So it's not a mag…

Yes, I agree with that point. I think my point was more that Serverless is a good idea, but the current implementations are still not good at removing complexity. But I can see this easily changing, with open standards and the such.

Re: The many lies about reducing complexity part 2: Cloud

#48

Post by ithrow »

dilyevsky wrote: post #44
ithrow wrote: post #43

Earlier quoted context omitted.

IME, the network of AWS is much better than that of DO, Linode.

How so?

Less hiccups and downtime. It's faster and with better latency to other third party services. Superior internal control. Ex: In, linode a private IP address gives EVERYONE on the same data center access to your Linode server. Also, last time I used them they didn't have a Firewall.

Re: The many lies about reducing complexity part 2: Cloud

#49

Post by didericis »

ratww wrote: post #35
didericis wrote: post #33

Earlier quoted context omitted.

The simplicity of having one cloud based product rather than several native products built for different systems is an argument I’ve heard a lot.

This is an advantage of the web platform, not exactly related to cloud. You can get this advantage with an on-premises web product, or with old school hosting.

Very true, just trying to explain the source of the “cloud reduces complexity” argument. There are a number of small operations that don’t want to manage all their own hardware, so cloud and web are conflated, and you get the web platform simplicity argument being used to justify a cloud platform.

Re: The many lies about reducing complexity part 2: Cloud

#50

Post by ratww »

ehnto wrote: post #36

I don't understand what people are building in order to need half of this decoupled and managed elsewhere anyway. It wasn't all that challenging to self manage it five years ago, what's changed? My guess is that the average small to medium project has drank the enterprise coolaid, and they are suffering the configuration and complexity nightmares that surround managing cloud infrastructure before they really needed t…

There are products (Terraform, CloudFormation) that help managing without an UI, but they also add complexity, so our point definitely stills stands.
Post reply on HN