Has AWS deprecated any of the services they've launched? If not, isn't that almost unprecedented in the worlds of either enterprise software and SaaS?
Amazon Web Services in Plain English
41–50 of 237 posts
Re: Amazon Web Services in Plain English
#42Thank you for this. I can't wrap my head around why Amazon would make names for some very useful services so inscrutable. It's like the developers were put in charge of naming everything.
To be fair AWS is much, much better than your average 'corporate crap'
Re: Amazon Web Services in Plain English
#43What should Lambda be called?
Amazon Computational Processes.
Re: Amazon Web Services in Plain English
#44OhFuckOhFuckOhFuck should have been called: Amazon GitScanner Use this to: search your online source code repos for injudiciously committed access keys It's like: Slamming the door in bitcoin miners' faces I'm surprised they don't offer this actually
They do, but it runs automatically so no need to name the service.
Re: Amazon Web Services in Plain English
#45"It's like: Stacking cash on the sidewalk and lighting it on fire" Is an accurate description of a large number of products that I have been forced to use after various CTOs have played golf with a vendors sales team.
It is not an accurate description, however, of the economics or value proposition of Direct Connect. When we're moving TB to an off-cloud location it's almost a no-brainer. Similar when latency sensitive.
The highest barrier, quelle surprise, is dealing with interconnect telcos.
Re: Amazon Web Services in Plain English
#46Thank you for this. I can't wrap my head around why Amazon would make names for some very useful services so inscrutable. It's like the developers were put in charge of naming everything.
It's like they started to create different products with their own identity and stopped here. Each product has the same doc, same yellow/white/black design, same marketing, but with a special name. So we have nothing to anchor our mind but that. They should continue to do what they were doing and do a whole sub-website for each one of their product with their own marketing identity. It will make more sense for newcomers to wrap their mind and will ease how they should think about them. They should do the same websites than Vault, Consul, Docker with Route 53, S3, Glacier...
Re: Amazon Web Services in Plain English
#47Earlier quoted context omitted.
Seems to work for Reddit, Zynga, Dropbox and Netflix.
Except when they suffer huge outages because of some upstream issue and HN/twitter/etc go stupid with "omg half the internet is offline" because everyone thinks AWS is indestructible. AWS makes even less sense at scale than it does for small companies. Once you can afford to hire competent Ops staff (and assuming you don't have developers who insist they know everything needed to run a complex system in a high traffi…
"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.
Re: Amazon Web Services in Plain English
#48This was orders of magnitude more helpful than the thousands of words that describe AWS on the AWS website. Thank you.
I found this video quite helpful. I hope it will help you.
Re: Amazon Web Services in Plain English
#49Let me preface this by saying I use AWS only when clients insist on it. I think there are much better options that don't lock their customers in anywhere near to the same level. I think AWS has plenty of badly named services, but some of these suggestions are much worse worse (and have a huge American influence - that fascination with using brand/implementation names for a generic/standard item) than the current actu…
What would you suggest as an alternative to AWS?
Re: Amazon Web Services in Plain English
#50Let me preface this by saying I use AWS only when clients insist on it. I think there are much better options that don't lock their customers in anywhere near to the same level. I think AWS has plenty of badly named services, but some of these suggestions are much worse worse (and have a huge American influence - that fascination with using brand/implementation names for a generic/standard item) than the current actu…
> * Amazon Memcached - I don't used the service so I don't know if it's only binary compatible with memcached but if its a generic cache that has multiple interfaces (the page references redis too) then more generic term like cache (and elastic implies it can grow/expand) seems more logical.
Considering all AWS ElastiCache is is "hosted Redis", that one confused me the most. Out of all the AWS services, this is the least 'magic' and custom and easiest to come up with a name.