Hacker Newsnew | past | comments | ask | show | jobs | submit | FmrAMZN_TA's commentslogin

<highly biased take coming>

Citation(s) needed. They specifically work (publicly and privately) to undermine local taxes, enforce non-competes/NDAs, capital gains, income taxes, etc. Then they do small investments like Mary's Place and point at it as being big community efforts. In fact, one can argue that it's Amazon's extensive work behind the scenes to that causes many contorted decisions that the city council and others make.

MSFT is investing $500M in Seattle (many through loans, but $25M is outright grants). Where's Amazon's similar commitment?


You are correct. They ABSOLUTELY monitor customer spend usage, without using one iota of personally identifiable information.


You can't (and they don't promise) encryption such that AWS can't see everything, if they were in fact malicious. This is true of every cloud.

That said, it's not illegal for them to see that xxx vendor increased their storage costs/bandwidth costs by $yyy every month, and that you could look into it - without using one piece of encrypted data.

Disclosure: Former AWS


Thanks for the reply! Pretty much what I thought...just wasn't sure if the original comment knew of some process I wasn't familiar with that obviated my belief.


> This is true of every cloud.

It's true of anyone selling bare metal servers too, it is just harder to snoop but the technology exists to do so.


I was thinking client-side encryption and decryption, and if you need to run operations on the server, utilizing homomorphic encryption practices. Is this not feasible or just naive?


How do you stop the cloud provider from accessing ram or cpu cache. At some point the data has to be decrypted for it to be used. And if decrypted on Amazon equipment, then Amazon could in theory gain access to it.


They were saying all decryption would happen client side and the only operations done by the server would be ones where the server can operate on encrypted data and yield encrypted results. I suspect that the main sticking point in that plan would be that the current state of homomorphic encryption is fairly limited/slow, so if you need AWS for computation as opposed to storage, it's not a practical plan.


Yeah. AWS isn't the best for just plain old storage so I guess this just isn't quite feasible yet. I'm hopeful we'll figure out the fully-encrypted cloud within the decade.


I did some googling and came to the conclusion that homomorphic encryption is not quite as supported in consumer hardware as I had believed. I didn't even think about the CPU cache. I guess this remains an unsolved problem. If Walmart's motivations are truly that Amazon might peek into vendor data, then it's a reasonable request after all.


Ever? What if they had a 10 year deprecation policy?


10 years would be a reasonable good start for a deprecation policy for an API-providing infrastructure company.

It is not uncommon to have 5-year-old systems in production, and a factor of two above that sounds like a good minimum.


I think this is disingenuous. AWS keeps something running forever, that's true, but in what state?

https://forums.aws.amazon.com/thread.jspa?threadID=121711

(We were well aware of this thread, and others like it, internally)

Something that exists, but has absolutely no investment and unknown support is probably not a great thing. Given that EC2's recent outage was because they hadn't restarted their services in a long time[1], what problems exist here? I think that Google probably should have a SUPER long deprecation policy (24 months feels right), but a year isn't terrible - and I'd rather explicitly get a statement like this than the zombie services elsewhere.

Disclosure: I used to work at AMZN and am highly biased.

[1] https://aws.amazon.com/message/41926/


As a big and long time user of AWS I thought it was pretty obvious that SimpleDB was deprecated when DynamoDB came out, and am surprised you think it is somehow bad to maintain a service in a "zombie" state is somehow worse than killing it... the way AWS plays this allows customers using the service to decide to move to a new service because it is better or cheaper, and on their own time scale (!), rather than being forced to drop everything else they are doing to go back to some old project and plan a migration.

I am so sick of companies thinking "a year (or even two!) to migrate is long enough for anyone": do you realize how many services I use? Do you realize how many random products I have built? If every service deprecates their API once every five years and gives everyone two years to update, and you use 20 services (this is common!), that means that every few months you are having to go back through all of your projects you have ever built to rewrite them against some new API. That is absolutely insane.


See my new comment at https://news.ycombinator.com/item?id=14344415 (I'm on a plane, so late to the party). I'm disappointed in this particular service deprecation, but your broader point applies regardless of the specific service: once you start using several, there's the potential for burning a lot of your engineering budget just rewriting and retooling.

On a meta level, I've seen an incredibly high number of risk averse companies just using EC2/S3 or GCE/GCS. That's not to say I disagree with using tons of services (that's how you get value!), but it's clearly food for thought.

I'd love to see historical data on the various cloud service turndowns, though I suspect there's too little track record to draw meaningful conclusions (and for some folks, abandonware is just as bad as turndown).

[Edit for disclosure since I wasn't in this thread before]

Disclosure: I work on Google Cloud.


So, then your answer is never deprecate?


And a huge ad business they support. Oh, they didn't tell you about that?


Amazon makes $3B a year selling ads. You think they're just guessing about personal information? Please. They lay cookies everywhere (including off site) to target you properly.


And they're doing a crap job of it - all they ever try to sell me seems to be something I just already bought.


It's funny you say the second paragraph - it feels like it directly contrasts the first (OK Google was first by a good margin).


I'm a highly biased former Amazonian.

I was expecting some real wisdom in this story, but I don't think this qualifies him as a technical leader in any way. I don't even think this needed the cargo-cult-y "leaving the room and coming back with a paper that changes everyone's mind." Couldn't he have just asked for a plan? And the ROI? That seems like management 101.

I have no love for him, but he is a genius. This story doesn't do him any justice (nor is the paper particularly compelling).


My point was not to qualify Jeff as a technical leader (though he is an excellent technical leader, IMO). Rather, my goal was to give people a sense for his leadership style, and what it's like to be in a high level meeting at Amazon.

I'm sorry you find the Rickover memo uncompelling. Speaking as an experienced engineer, I happen think it's among the best pieces of engineering writing ever produced.


I disagree. There are many leadership principles which are contradictory either in part or in whole (e.g. Dive Deep vs. Bias for Action; Insist on the Highest Standards vs. Invent and Simplify). You can squint and see how these would be the same, but often they're just used as arrows in a quiver to knock someone down and/or put someone on a PIP (performance improvement plan).

Example I witnessed during people review (obviously anonymized):

A: I think X is one of the best members of the team, he took a bunch of customer requirements and put out something super fast that addressed some customer needs. (Invent and Simplify, Bias for Action)

B: I disagree. His product didn't think about scenarios a, b and c [ed: these would be things that caused the product to slip a year, and would leave customers in pain during that time] and he did not investigate g, h and i [which would have taken 3 months to figure out, still with customers in pain]. I think he needs to be put on a PIP. (Dive Deep; Insist on the highest standards)

Yes, I'm highly biased here - this person was on my team, and I endorsed his plan, as did person B, until we got into People Review. One of the most brutal and subtle things about the entire process is the fact that you're consistently asked for negative feedback about EVERYONE... even if you don't have it.

I moved from that group (AWS) to new businesses shortly thereafter.


Leadership principles (LPs) are not contradictory so much as they are in tension with one another. That's not a bad thing, it's a good thing. Navigating the tension is what helps discover good outcomes. For example, if a customer calls up wanting a refund, then granting the refund supports Customer Obsession but contradicts Frugality. When deciding between options, there is always a tradeoff, and the LPs provide a lexicon for identifying and reasoning about what you're trading off. Amazon strives to be the world's most customer-centric company, and hence will generally choose the approach consistent with customer obsession. Identifying and discussing that tension and how to resolve it is constructive.

I don't see them as arrows to knock people down. I see them rather as, well, principles to use when reasoning about a situation. Giving a name to a concept is a good way to reason about it and discuss it. They are used when reasoning about performance, it's true, but it's used across the board: when justifying a promotion, when praising a high-performer who excels within their level, when identifying areas of growth, as well as while discussing job performance with people who are doing less well.

Performance and leadership in a creative job like software engineering cannot be perfectly objective (it's not like an assembly line where you process N units per hour), but the LPs provide some objective concepts and terminology to apply while discussing performance; they break down performance into dimensions that can be discussed individually in the context of examples, which is an advantage over just vaguely discussing things at a high level. For example, "Bob found a creative way to pack more software onto existing servers without harming performance (Frugality)" or "Sally spent two hours on the phone helping our biggest customer (Customer Obsession)" or "After causing an outage, Joe wasn't able to identify anything he'd do differently next time. I'm concerned that he's not vocally self-critical." I'd much rather have a discussion of my performance or leadership in concrete terms like these, rather than vague ones.


It is impossible to create a total ordering of preference when you have conflicting priorities (or "tension" between priorities). This reflects reality. Humans often get in weird situations where they prefer A to B, B to C, and C to A. The issue is not that the principles are incorrect, but that their application is confused for objectivity.


You get it.


You get it.


We'll agree to disagree. Tension is good, when that's all it's used for. When it is specifically used to tear people down (either with a purpose, or just for vindictiveness), I think the original benefit is lost.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: