Live data from Hacker News

The many lies about reducing complexity part 2: Cloud

ea.rna.nl

111–120 of 131 posts

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

#111
post #109

Earlier quoted context omitted.

You seem to have made up your mind, but for the benefit of others: yes, we use many AWS products and are having a fantastic time of it. AWS services are more reliable, less buggy and have more stable APIs than any of the alternatives. Specific services that made a difference to us are Fargate, Spot, Batch, SQS/SNS, Lambda, ECR, EFS, ELB/ACM, CloudWatch Logs, IAM, Aurora RDS, SSM/Secrets Manager, and Step Functions -…

The key glue to a lot of what you mentioned missing in your list to make a lot of this work for outside consumers: API Gateway, arguably their worst product.

I agree, they really need to replace that product. It's not built to the standard that users expect from AWS. They have burned a lot of goodwill on that one.

That said, it's only truly necessary for Lambda and while it's frustrating and painful there, it's usually not a complete showstopper.

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

#112

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…

This. And also AWS showed they can delete your business infrastructure unilaterally, without notice, on a whim so it’s very risky to use them.

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

#113
post #69

Earlier quoted context omitted.

I'm not very familiar with AWS or The Cloud, but I'm having trouble understanding what you said about Amazon leaving money on the table by not directing customers toward specific-purpose services as opposed to EC2? Wouldn't (for AWS to make a profit anyway) whatever managed service have to be cheaper than some equivalent service running on an EC2 VM? I get the concerns re: pricing and predictability, but it still see…

For example: Managed Airflow Scheduler on AWS with "large" size costs $0.99/hour, or $8,672/year per instance. That's ~ $17,500 considering Airflow for at least non-prod and prod instances. Building it on your own on same size EC2 instance would cost $3,363/year for the EC2. Times two for two environments, let's say $6,700. $4,000 if you prepay the instance. That looks way cheaper, but then you have to do the enginee…

> Managed Airflow Scheduler

Management decided get rid of all the on-prem, capex-heavy HVAC systems (that are depreciating as-we-speak!) for budget-friendly cloud thermostats? Maybe they can send you the climate-controlled blown air on your office's Amazon Day. ;)

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

#114

Microsoft summarized it nice [1] : Advantages of public clouds: Lower costs No maintenance Near-unlimited scalability High reliability Advantages of a private cloud: More flexibility More control More scalability (compared to pure on-prem solution) [1] https://azure.microsoft.com/en-us/overview/what-are-private-...

Notice that neither list has "Reduce Complexity" as benefit.

Cloud can abstract away complexity. Shift managing the complexity behind the cloud. But, it's more likely that complexity increases rather than decreases.

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

#115

Earlier quoted context omitted.

All I can say is that this hasn't been my experience. Setting up a single server is much the same whether it's on-prem or at a colo facility or some VM in the cloud, but the amount of added complexity to set up non-trivial networking and security and redundancy/failover and backups and all that stuff in the cloud is far more complicated -- if you don't already know how to do it -- than just setting up a few servers d…

> but the amount of added complexity to set up non-trivial networking and security and redundancy/failover and backups and all that stuff in the cloud is far more complicated This complexity exists either way, is my point. Whether you're managing your own servers, or using barebones cloud VMs, or using a bunch of cloud fanciness, the complexity you just defined still exists. And if that complexity is a constant, why…

The thing is, I don't think the complexity is even close to the same in the two cases.

AWS and similar services are an abstraction over hardware, software and networking all at once. There are well over 100 different services available on AWS alone. Just to get a basic configuration up and running, someone new to the system has to figure out which of those services they actually need, which is a barrier in itself given the obfuscated names they have.

Then you have much the same network and security details to set up as you would have for on-prem or colo infrastructure, but now with lots of non-standard terminology and proprietary UIs, which are so cumbersome at times that an entire generation of overcomplicated "orchestration" tools has been developed, each of which typically adds yet another layer of leaky abstraction.

Hopefully some time before this all happened you tried to work out what it was going to cost, and maybe you were close or maybe you are in for a nasty surprise because those handy managed services cost several times what the equivalent server + software would have cost either running on real servers or just on cloud VMs.

And if you fall back to that latter case as your safe default, you still get all the same issues to deal with as you would have had on your own servers and network, except that now you need to figure out what is really going on behind all those virtualised systems and quasi-geographical organisation layers before you can tell whether one unfortunate event could take down all the instances of any vital services you need.

In comparison, literally every small business I have ever worked in as a tech worker has had several people at the office who were perfectly capable of buying a switch or firewall or router and spending the few minutes required to configure it or buying a server and installing Linux/Windows and then whatever server software it needed again very quickly. Cloud systems can make it faster to deploy new hardware and connectivity, because you save the time required for all the physical steps, but after that the time and knowledge required to get a small network's worth of equipment up and running really isn't that great. After all, we used to do that all the time until the cloud hype to hold, and it's not as if that has suddenly stopped working or all the people with that knowledge suddenly left the industry in the past 5 years.

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

#116
post #6

This shared responsibility principle that underlies cloud marketing speak sounds a lot like the self-driving mess we find ourselves in today - I.e. the responsibility boundary between parties exists in a fog of war and results in more exceptions than if one or the other were totally responsible. We have been a customer of Amazon AWS for ~6 years now, and we still really only use ~3 of their products: EC2, Route53 and…

Given the situation with Amazon Essentials, anyone who sells a product made substantially of stringing together AWS technology may find themselves cut out of the picture soon enough.

Many other companies have ended up competing with their own vendors. The only thing unique about Amazon is that they are boiling the frog much more slowly than previous generations of companies have.

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

#117

This person has never worked in a data center. He thinks he's managing a network because he sets a few vpc ips, that's an itsy tiny fragment of networking, and the cloud has indeed removex a great deal you previously had to manage on prem.

I'm guessing you mean things like STP, firewalls, rate-limiting, routing, DHCP, and link aggregation?

Or going back even further I started my career worrying about all that, plus HVAC, hardware acquisition, capacity planning, power management, distribution and managing gensets(fuel and maintenance); and all the fun crap associated with it like a burst water pipe in your data center on Christmas Eve

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

#118

Earlier quoted context omitted.

> but the amount of added complexity to set up non-trivial networking and security and redundancy/failover and backups and all that stuff in the cloud is far more complicated This complexity exists either way, is my point. Whether you're managing your own servers, or using barebones cloud VMs, or using a bunch of cloud fanciness, the complexity you just defined still exists. And if that complexity is a constant, why…

The thing is, I don't think the complexity is even close to the same in the two cases. AWS and similar services are an abstraction over hardware, software and networking all at once. There are well over 100 different services available on AWS alone. Just to get a basic configuration up and running, someone new to the system has to figure out which of those services they actually need, which is a barrier in itself giv…

> The thing is, I don't think the complexity is even close to the same in the two cases.

Agreed (but probably on the opposite end as you)

It seems a lot like you've been scorned in the past and that's driving a lot of your statements now (which is totally fine and fair). I'm trying to bring up that, for every problem you've just defined, the literal exact same problem exists for colo/managed servers, except it is now also your problem to keep the lights on and the machine running.

> literally every small business I have ever worked in as a tech worker has had several people at the office who were perfectly capable of buying a switch or firewall or router and spending the few minutes required to configure it or buying a server and installing Linux/Windows and then whatever server software it needed again very quickly.

I'm sorry, if you believe that building and deploying production-ready server infrastructure is as easy as "Just going out and buying a switch and spending a few MINUTES installing linux" (emphasis mine) - I feel like we aren't talking about the same thing at all. Not even close.

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

#119

Earlier quoted context omitted.

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.

AWS monitoring (and billing) is garbage because they make an extraordinary amount of money on unintentional spend. "But look at how many monitoring solutions they have in the dashboard! Why, just last re:invent they announced 20 new monitoring features!" They make a big fuss and show about improving monitoring but it's always crippled in some way that makes it easy to get wrong and time-consuming or expensive to get…

I’m genuinely curious. Which parts of monitoring is crippled or difficult to use?

Disclaimer: I work at AWS.

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

#120
post #50
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.

I've used Terraform for 4~ years.

the providers are ever changing (and so is the terraform language/features). So the "ever-changing" part is certainly still true for Terraform.

Post reply on HN