Love this! Loved it so much I made it into a tampermonkey script: https://gist.github.com/ideasasylum/2d7518611ffaacbc5061
So now my Amazon dashboard looks like: https://dl.dropboxusercontent.com/s/iko1p8jdwdvjpaq/2015-09-...
Amazon Web Services in Plain English
141–150 of 237 posts
Re: Amazon Web Services in Plain English
#142Earlier quoted context omitted.
> S3 is not an FTP service it is a distributed object store. Not really, the only "object" you can store, Amazon's language notwithstanding, is effectively a file. It's not like you could give it something that needed to be serialized. And it's hard to see how it's "distributed" when your bucket price varies "based on the location of your bucket" as Amazon puts it. It's probably more redundant than FTP, but saying S3…
The only real resemblance at all to FTP is that you use GET and PUT instead of filesystem commands. I mean, I guess if you really don't understand what FTP is and have no desire to understand how S3 is different from posix, then saying you have to use S3 like you use FTP kind of works. But it would be misleading to everyone else. > It's probably more redundant than FTP FTP is a transfer protocol , it says nothing abo…
Using FTP as shorthand is better than "Object Store", which sounds like the marketing BS this is designed to avoid.
Re: Amazon Web Services in Plain English
#143Earlier quoted context omitted.
"Once you can afford to hire competent Ops staff" Here, that's the catch. Most companies simply can't. Competing against Amazon, Microsoft and Google for talent doesn't sound like a smart strategy.
Plenty of medium sized companies would work out better off overall, with a skilled Ops person to setup cost effective services > Competing against Amazon, Microsoft and Google for talent doesn't sound like a smart strategy. You don't have to compete. They are trying to make a profit . You just need to be better off, long term. That could be a mixture of lower service fees, more flexibility, improved productivity, les…
I don't see how a single "skilled ops person" can deliver "lower service fees, more flexibility, improved productivity".
On the other hand, Cloud Computing will, by definition, let you turn on and off services based on business demands. It doesn't get much more flexible and cost effective than that.
"You just need to be better off, long term." - This is a good one. Do you really think your homegrown Docker environment, Hadoop cluster and/or state-of-the-art Cassandra ring maintained by your one and only skilled Unicorn is a better long term plan than 100% managed alternatives? Let's see how well (and how secure) your in-house stuff work 2-3 years down the road and how it will then compare with the always "up-to-date" alternative.
The "vendor lock-in" part is your only valid argument, in my opinion. Costs/benefits will have be weighted properly. How much do you value business agility and pace of innovation vs. increased vendor dependency?
The proper answer will be different for all businesses, but I would argue that as long as a specific IT component/technology is not part of your core business, you might be better off buying it off-the-shelves instead of building it and maintaining it yourself.
Re: Amazon Web Services in Plain English
#144Earlier quoted context omitted.
I've found that nearly any use-case of AWS is like "stacking cash on the sidewalk and lighting it on fire". It's very overpriced and there's a lot of smoke and mirrors involved in figuring out how much you're paying. Disclaimer: I work at Linode, but have felt this way since before I started.
Running a business on AWS is like taking Uber to work every day. At some point it makes sense to just buy the car.
> Running a business on AWS is like taking Uber to work every day. At some point it makes sense to just buy the car.
To make the analogy accurate:
Running a business on AWS is like taking Uber to work every day. At some point it makes sense to just buy the car, hire a driver, find a good mechanic, lease a parking spot, purchase automobile insurance, remember to buy gas, deal with speeding tickets, schedule regular maintenance ....
At some point it makes sense, but it is way, way down the road for most startups.
Re: Amazon Web Services in Plain English
#145Love it. Keep it simple. It is too often the case that writes assume their readers have the same knowledge as they do. Always assume your reader knows nothing.
Re: Amazon Web Services in Plain English
#146Earlier quoted context omitted.
Running a business on AWS is like taking Uber to work every day. At some point it makes sense to just buy the car.
> Running a business on AWS is like taking Uber to work every day. At some point it makes sense to just buy the car. To make the analogy accurate: Running a business on AWS is like taking Uber to work every day. At some point it makes sense to just buy the car, hire a driver, find a good mechanic, lease a parking spot, purchase automobile insurance, remember to buy gas, deal with speeding tickets, schedule regular ma…
Empirically I've found that point to be at approximately the $30k/month spend rate (somewhere around 4-5 years in--arguably no longer strictly a "startup"). Of course it's pretty context-dependent, YMMV, etc.
Re: Amazon Web Services in Plain English
#147Come on, I expect HN posts to be much more thoughtful...
Re: Amazon Web Services in Plain English
#148Earlier quoted context omitted.
S3 (or any object store) "is like FTP" has been the best explanation I've used. Way too many people I've talked to think that it's a POSIX-compliant filesystem and "like FTP" is familiar enough to them to know that treating it like a standard filesystem is a terrible idea.
Yeah but just because a flawed analogy happens to work for people who are completely clueless about S3, doesn't mean you should deliberately misname your service to accommodate this lowest common denominator.
I did not read the article as literally suggesting that Amazon change the name of its service, but rather, as a means of conveying the crux of the idea behind the services.
I also did not take this particular description to indicate a literal FTP service.
Analogies do not have to be perfect to be helpful. I've never used Amazon web services, perhaps partly because I found their terminology too obfuscated to bother trying to figure out what it did. Similar services provided by other companies were more recognizable to me for what they were.
I found the post here helpful.
Re: Amazon Web Services in Plain English
#149Full of crap...
Re: Amazon Web Services in Plain English
#150The SWF description is pure garbage; it's got nothing to do with EC2, or IronWorker at all. Oddly, I think it's named sanely - it lets you setup and manage a workflow using small bits of code.