Live data from Hacker News

Fuck the Cloud (2009)

ascii.textfiles.com

211–220 of 235 posts

Re: Fuck the Cloud (2009)

#211
post #209

Earlier quoted context omitted.

Eh... I think that the maybes you are using are a little bit misleading. When a company sells space in their "cloud", like maybe Microsoft or Amazon, there is a business guarantee that goes along with it. If Amazon were to randomly lose a big chuck of Netflix data, AWS's business would tank immediately. AWS is a giant system that uses its scale and number of customers to efficiently provide a more stable system at a…

That must be why Amazon's SLA is defined as follows[1] : If amazon loses more than 3 datacenters (only total loss of external connectivity for all of your instances in an entire availability zone, or total loss of hard disk access, again only counts if all your instances completely lose hard disk/EBS access) for more than 45 minutes in a month you get 10% of what you pay as a voucher for future ec2 usage. If they los…

You completely tunneled on the wrong portions of what I was saying. For one thing, Amazon's "real" liability extends far beyond their SLA. Yes, their immediate financial compensation is small. But there are two things wrong with your conclusion here. First, that is not indicative of how much they "trust" the service. They are always going to take the most conservative amount they can get away with, and they are "getting away" with it just fine so why up it? Second, if a company on AWS was severely impacted by a genuine Amazon screw-up, the compensation SLA is the least of Amazon's concerns. It would be like if UPS lost 20% of Amazon deliveries for one day. They wouldn't be nearly as concerned with the explicit liability of compensating Amazon for those deliveries, however much they guarantee for them contractually, they would be far more concerned with everyone immediately switch to another shipping company because they could no longer trust UPS. That is the motivation.

Second, you've completely ignored the actual key points. For one thing, "Cloud" companies make their business by providing a stable service. You have the "guarantee" based on thousands of other business using the exact same infrastructure without serious service failures. That is a huge amount of statistical reliability. Compared to hiring your own IT department and cobbling together your own system, that is actually really good indicator. Second, the cost difference is potentially massive. Again, it is for similar reasons that shipping via UPS is a much better deal than shipping via your own private distribution network. You might have to still pay some people to handle your own inventory from its source (like you'd have to have some people to work on your system in the cloud) but you'd be taking advantage of a much larger, more efficient system instead of having to build and maintain your own.

Re: Fuck the Cloud (2009)

#212
post #208

Earlier quoted context omitted.

Eh... I think that the maybes you are using are a little bit misleading. When a company sells space in their "cloud", like maybe Microsoft or Amazon, there is a business guarantee that goes along with it. If Amazon were to randomly lose a big chuck of Netflix data, AWS's business would tank immediately. AWS is a giant system that uses its scale and number of customers to efficiently provide a more stable system at a…

> If Amazon were to randomly lose a big chuck of Netflix data, AWS's business would tank immediately. http://www.theregister.co.uk/2015/09/20/aws_database_outage/ AWS is the new Microsoft / IBM, nobody ever got fired for picking AWS.

There is a difference between a service outages, which do happen and are unavoidable no matter who builds your system, and actually losing permanent data. Which is Amazon does guarantee only 99.95% uptime.

There is a difference in a discussion about trusting the Cloud with your data and services between it going down briefly on occasion (somewhat acceptable, within very narrow limits) and actually losing data or longterm traffic because of a service failure. Seriously breaching the SLA causes compensation as well as a big loss of reputation and business, going down for a couple hours once a year is hardly the type of instability that would terrify most online businesses, nor is it something that individual companies are able to avoid themselves.

Re: Fuck the Cloud (2009)

#213
post #8

While Jason Scott raises interesting points six years ago, the principles of data management remain the same as the days of dedicated servers with on premises systems. If you have only one copy of data and that machine goes down, then the data goes with it. In my experience in a business context 'the cloud' discussion is about the business' desire to expand capacity without the need for the capital expenditure needed…

(Tedious disclaimer: not speaking for anybody else, my opinion only, etc. I'm an SRE at Google.) The key piece that's missing here is the idea that risk is something you have to compare, and can combine in interesting ways, then trade off against costs. There are a bunch of ways in which you can do compute, storage, and networking. You get to pick zero or more of these ways. One of them is "buy a bunch of iron and ma…

There should exist an option that is between those spectrum endpoints. One that runs a lot more free (inspectable, trustworthy) software than present cloud services. One that leaves some control with the owner of the data.

Re: Fuck the Cloud (2009)

#214
post #150

The points in this article also apply really nicely to websites and other services, many of which seem to make the mistake of outsourcing everything to other people's platforms. Oh sure, you may be using 'the cloud' to host your webmail, or your forums, or your chat, or anything else... but what if that goes missing? You're in an even worse situation than the individuals using these services to host their personal fi…

> like Dropbox or the likes... Millions of people would lose most of their files overnight. That's false. Files in Dropbox are also stored locally on all your Dropbox-enabled computers. They would simply stop syncing, and you'd plug in another syncing service. If Dropbox disappears, your Dropbox folder just becomes a regular folder.

I think it is an accurate assessment that many (potentially millions) people would lose their files in such an event. Many people use cloud storage (e.g. Dropbox, Google Drive) without a native client. Even on mobile, it is common to delete photos from the device after they have been synced/uploaded.

Re: Fuck the Cloud (2009)

#215
post #207

Earlier quoted context omitted.

> These days that's often the cloud. For plenty of use cases I actually agree with that conclusion. With the caveat that I would add: accompanied by a suitable non-cloud back-up of critical data, code and configuration data held on a medium that is not accessible by the same people that administer the cloud stuff.

I think for most levels of safety you would target, a pure cloud solution is going to be cheaper. E.g. if you decide you need a backup that's independent of your primary cloud provider and any staff with access to that, you can probably accomplish that more cheaply with a second cloud provider than by self-hosting.

Yes, a second cloud provider is a valid option, if you take a number of precautions (see elsewhere in this thread).

Re: Fuck the Cloud (2009)

#216

Salutations, ass-end of the Tech Elite. As someone who has generated a pretty hefty sandbag of verbiage over my decades online, it's always amusing to see what the Grand Eye of internet arbitration decides is an incredibly important and pertinent subject to discuss in my back catalog. Whether it's my work in guiding volunteers for in-browser emulation ( http://archive.org/details/softwarelibrary ), my delightful cote…

I could have done without your insulting tone, no matter how proud of your opinions you are.

You are an adult. If you miss the message for the messenger you've got no one to blame but yourself.

Re: Fuck the Cloud (2009)

#217
post #216

Earlier quoted context omitted.

I could have done without your insulting tone, no matter how proud of your opinions you are.

You are an adult. If you miss the message for the messenger you've got no one to blame but yourself.

So is textfiles an adult. If he/she is a jerk, he/she has nobody else to blame.

Re: Fuck the Cloud (2009)

#218

Salutations, ass-end of the Tech Elite. As someone who has generated a pretty hefty sandbag of verbiage over my decades online, it's always amusing to see what the Grand Eye of internet arbitration decides is an incredibly important and pertinent subject to discuss in my back catalog. Whether it's my work in guiding volunteers for in-browser emulation ( http://archive.org/details/softwarelibrary ), my delightful cote…

[deleted]

Re: Fuck the Cloud (2009)

#219
post #196
post #121

Earlier quoted context omitted.

"TL;DR I hear this argument all the time. The cloud isn't perfect but its a hell of a lot closer to anything I could achieve. "not invented here" syndrome won't save your data." I think there is an easy rebuttal that should be considered... First, the "nines" rating of any service or resiliency is just gibberish. Go find the statistical likelihood of money market funds "breaking the buck" or of CDS blowing up - both…

> I don't care who does the calculation and how many nines they come up with - if you load FreeBSD on two bare metal servers and put them in two different datacenters and run them with any kind of conservative and cautious sysadminning you'll have a better solution. Yes, it will be more expensive.[1][2] Nonsense. It's very easy to have that kind of setup fail - remove one from the load balancer, take it down for main…

"Nonsense. It's very easy to have that kind of setup fail - remove one from the load balancer"

I'm sorry - you're already missing the point.

There is no load balancer. There's no firewall. There's no services running except for sshd.

I guess I should qualify what I mean by "better", though. What I mean is, "I know exactly how this will fail and it won't be interesting or surprising. Or take any thought or time to fix."

It will be comprehensible. "FreeBSD on a basic AWS setup - four EC2 nodes (multiple AZs), and an ELB" is not. You have no idea (nor do I, nor do probably most folks at Amazon) the different and fascinating ways that will fail.

(disclosure: we use EC2 instances for backup DNS. We are not anti cloud or anti amazon)

Re: Fuck the Cloud (2009)

#220

Jason's follow up post to this: http://ascii.textfiles.com/archives/4352

tl;dr Renting remote computational power is cool (AWS), but renting remote storage is not. I have a complete history of email archives since I started using gmail (ie cloud), but have lost years of archives from the years I managed email myself. It turns out that companies focused on data storage and retrieval do a better job than me. And that's fine. I pay someone to do my taxes and I don't build my own furniture. S…

I still have the archives for years before gmail, but probably 1/3 of those are in a proprietary format long since not supported that ran on a proprietary OS that ran on proprietary hardware. So that sucks because those old emails are almost certainly more interesting than the current pile of madness.
Post reply on HN