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

121–130 of 131 posts

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

#121

Post by glogla »

Silhouette wrote: post #105
bird_monster wrote: post #103

Earlier quoted context omitted.

> And diving into complicated cloud infrastructure with a small business, if you're not already an expert on it, is a very uncertain endeavour in terms of whether you'll get everything set up right I do not agree. The entire point of using cloud offerings as opposed to rolling your own, is cloud offerings are usually several orders of magnitude easier to configure. Using Event Hub, as an example, means that you're ge…

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…

Watching your discussion I think the truth might be somewhere in the middle - the Cloud can do things for you but you still need to learn how to use it.

So once you know your way around, it can be a force multiplier but learning cloud can be as much work as learning how to do it on your own.

Or said from a different angle, it help you outsource (part os) operations but it does not actually help you to engineer and architect things correctly, and you can shoot yourself in the foot pretty easily.

Personally, I think the cloud is most transformative for large companies with dynosaur internal IT, where it brings a lot of engineer self-service into the picture - where I work I can have RDS in minutes, or internally provisioned on-prem Oracle in a week, and the Oracle ends up being more expensive because 24/7 support has to be ordered from a specific list of vendors ... but that's not going to be the case in agile company with strong engineering culture.

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

#122

Post by Aeolun »

dimitrios1 wrote: post #110
ak217 wrote: 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.

What is so terrible about API gateway? Aside from the price, but they kind of solved that with HTTP gateway.

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

#123

Post by Aeolun »

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…

AWS has like 10 times more regions than any of the alternatives. If you want something close to home AWS is best.

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

#124

Post by Silhouette »

bird_monster wrote: post #118
Silhouette wrote: post #115

Earlier quoted context omitted.

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…

Not scorned, just a little bored of being told by advocates how the cloud will do wonders for my businesses or my clients and then seeing the end results not live up to the hype.

I'm not saying there are no benefits to cloud deployment. It does have some clear advantages, and I've repeatedly cited the rapid deployment of the hardware and connectivity in this very discussion, for example. It hasn't come up much so far in the parts of the discussion I've been in, but I would never claim there is no-one with a good use for the more niche services among the hundreds available from the likes of AWS, either.

However, I mostly operate in the world of smaller businesses, and in this world simplicity is king when it comes to infrastructure. We are interested in deploying our software so people can run it, whether that's for a client's internal use or something that's running online and publicly accessible. Setting up a new server is mostly a case of installing the required OS and hosting tools, and then our software will take over (and that work would be essentially the same wherever it is hosted), once you have the hardware itself installed and connected. Configuring a new office network is something you'd probably do in a day, again once the physical aspects have been completed. You slightly mangled the timescales I actually suggested in your quote, BTW.

These systems are often maintained by a small number of team members who have the relevant knowledge as a sideline to their day jobs. And this approach has been working for decades, and continues to work fine today. Perhaps I have just never met the bogeyman where the operational requirements to maintain the IT infrastructure for a small business (say up to 50 people) are somehow unmanageable by normal people with readily available skills in a reasonable amount of time, so the arguments about somehow radically improving efficiency by outsourcing those aspects to cloud services have never resonated much with me. It's a big world, and of course YMMV.

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

#125

Post by Silhouette »

glogla wrote: post #121
Silhouette wrote: post #105

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…

Watching your discussion I think the truth might be somewhere in the middle - the Cloud can do things for you but you still need to learn how to use it . So once you know your way around, it can be a force multiplier but learning cloud can be as much work as learning how to do it on your own. Or said from a different angle, it help you outsource (part os) operations but it does not actually help you to engineer and a…

I suspect much or all of this is true, including the observation about large companies with dinosaur IT. The comment I originally replied to was specifically talking about the environment in small companies, which is the environment I'm most familiar with, and my comments should be read in that context.

In my own businesses or the clients we work with, we too could add RDS quickly for something we were hosting on AWS. On the other hand, we could also spin up a pair of Postgres instances and configure streaming replication quickly if we were running on-prem or colo. Each approach has its pros and cons, and we'd look at each situation on its merits and choose accordingly. But IME, it's more like choosing from a restaurant menu depending on what looks most appealing at the time. The way some people talk about cloud, it's like they see it as choosing between a gourmet restaurant with a Michelin-starred team and the local burger van.

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

#126

Post by bdavis__ »

twistedpair wrote: post #100
zoomablemind wrote: post #60

Subjectively, it increasingly feels that while the complexity has been increasing, the notion of longevity of the underlying products and services has been degrading. While updates to software were expected, general outlook would be that they would not be breaking the core features. The emphasis on backwards compatibility was in a way an assurance to businesses that building their operations on vendor's products is n…

> the notion of longevity of the underlying products and services has been degrading. Is eternal longevity even a relevant concept in computing ops any more? I think businesses must grok that all services are living things that will require eventual maintenance. If you roll your own service, eventually the OS, even an LTS, will need upgrading when the prior release goes EOL. If you're higher up on a FaaS, the languag…

Kind of depends on "eternal". I propose 10 years is possible, and realistic. 5 years should not be rare. 20 years is probably a fantasy.

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

#127

Post by hinkley »

mumblemumble wrote: post #5
ChicagoDave wrote: post #3

Reducing complexity should never be about platform (on-prem vs cloud). It should be about constructing software in partnership with the business and reducing complexity with modeled boundaries. You can leverage the cloud to do some interesting things, but the true benefit in is _what_ you construct, not _how_.

I honestly believe that hiding complexity behind a closed door does not eliminate it. However, a lot of software and service vendors have a vested interest in convincing people otherwise. And, historically, they've had all sorts of great platforms for doing so. Who doesn't enjoy a free day out of the office, with lunch provided? It's also much easier to hide complexity than it is to remove it. One can be accomplished…

> It's also much easier to hide complexity than it is to remove it.

There are multiple ways to hide complexity. Some of them make it easier to remove (eg, refactoring), others make it nearly impossible to remove. In a service market there’s a perverse incentive to move toward the latter.

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

#128

Post by tgtweak »

ithrow wrote: post #48
dilyevsky wrote: post #44

Earlier quoted context omitted.

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.

Internally maybe, but AWS external connectivity is so shakey I wonder if it's intentional.

From a cisco ASA firewall to AWS vpg - there is weekly and even daily issues with things either plain timing out or experiencing latency spiking on AWS side. Cisco is not a small vendor or use case for creating a vpn bridge. We moved from this to cloudconnect - essentially a network connection directly to aws. Same instability issues only they moved to weekly/monthly instead of daily/weekly. This was from a provider that had fiber to AWS.

I will also say that when putting particular load on AWS's internal services from a single ec2 instance you can often see requests that fail (s3 being the one I see the most).

I can't speak on the merits or lack thereof on Linode, but I will say vultr and DO have - by comparision to AWS - leagues better public wan stability. I've had ssh sessions open for months on both and that includes to some POPs in europe. I'm comparing AWS which is <20ms away to something overseas... for reference that's about 20 additional hops and trans-atlantic fiber in between.

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

#129

Post by malinens »

Aeolun wrote: post #123
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…

AWS has like 10 times more regions than any of the alternatives. If you want something close to home AWS is best.

very very few need so many regions to choose from

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

#130

Post by nelsonenzo »

rubatuga wrote: post #107
nelsonenzo wrote: post #37

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?

to start, yes :)
Post reply on HN