Earlier quoted context omitted.
Working on a side project is super easy. Just file a TT (or I guess SIM now?). As long as it isn't competing and not a game, it's generally quick approval.
What is the issue with games?
On Internal Engineering Practices at Amazon
51–60 of 130 posts
Re: On Internal Engineering Practices at Amazon
#52Based on my experience, the article contains a lot of misinformation. Some of the statements might have been true at one point in the past, but are now out of date by years, while others have never been true in the time I've been around. Without getting into a point-by-point rebuttal, my reaction to each section/Exhibit is "that's wrong/misleading".
Isn't that a bit disingenuous? Your role at Amazon is nothing like the typical engineer at Amazon. You live in the shiny new world while the majority of engineers are stuck on something that's not too far from the article.
The article complains about CloudWatch and log aggregation, but when I started Amazon internally had a mature log aggregation and monitoring solution that I would say is still unquestionably superior to the public version of CloudWatch.
Re: On Internal Engineering Practices at Amazon
#53Earlier quoted context omitted.
Speaking of twitchy lawyers and Move to AWS... one of the weirdest things we had to deal with inside Amazon was that, for many years after AWS launched, we weren't allowed to use it because it "wasn't secure enough". Given that we were actively shopping it around to major financial institutions at the time, doesn't that strike you as particularly hypocritical? :)
So wait, when I need to convince customers why AWS is secure for their data, I can't say "It's good enough for Amazon!"?
Re: On Internal Engineering Practices at Amazon
#54Re: On Internal Engineering Practices at Amazon
#55Earlier quoted context omitted.
Isn't that a bit disingenuous? Your role at Amazon is nothing like the typical engineer at Amazon. You live in the shiny new world while the majority of engineers are stuck on something that's not too far from the article.
I was an intern at AWS this past summer(and will be returning as a new grad in May) and this article is not accurate based on my experience. My code (which was part of our team's actual production system, not a toy project) ran on EC2 instances in an autoscaling group. There was no manually provisioning servers. I worked with a Kinesis Stream and several other resources and there was a way for us to programmatically…
PHP is banned at Amazon, and that's the exception that proves the rule: a language being banned is so unusual that I'm aware specifically of the example of PHP.
Re: On Internal Engineering Practices at Amazon
#56For the people saying "I worked there and it wasn't like that" I wonder if you worked in retail. It's a very different world from the more modern bits of the company.
Re: On Internal Engineering Practices at Amazon
#57Earlier quoted context omitted.
> you would want to use bare metal for Amazon's scale Containers are "bare metal".
> Containers are "bare metal" Please explain this use of jargon. Are you saying that a Docker container is "bare metal" in some culture? A VM is bare metal? What do you mean by container, and bare metal?
Cloud is, in fact, abnormal in terms of how containers are used in that it wraps them into VMs. That's in part because VMs were already there and they simplify provisioning of something that looks like "machines" from the outside, and in part because containers do not offer much in the way of security guarantees (precisely because all containers running on the same host share the kernel), whereas VMs do.
Re: On Internal Engineering Practices at Amazon
#58Earlier quoted context omitted.
> you would want to use bare metal for Amazon's scale Containers are "bare metal".
> Containers are "bare metal" Please explain this use of jargon. Are you saying that a Docker container is "bare metal" in some culture? A VM is bare metal? What do you mean by container, and bare metal?
Re: On Internal Engineering Practices at Amazon
#59Earlier quoted context omitted.
Isn't that a bit disingenuous? Your role at Amazon is nothing like the typical engineer at Amazon. You live in the shiny new world while the majority of engineers are stuck on something that's not too far from the article.
I was an intern at AWS this past summer(and will be returning as a new grad in May) and this article is not accurate based on my experience. My code (which was part of our team's actual production system, not a toy project) ran on EC2 instances in an autoscaling group. There was no manually provisioning servers. I worked with a Kinesis Stream and several other resources and there was a way for us to programmatically…
Java/C++/Python/Ruby/Go/Perl/Scala, even Rust, are used in Amazon for various projects. What might be true is that, consider how critical your service would be, the more it is, people will lean towards to more conservative/mature/enterprise-ish languages, not exotic ones, because that inherently means risk. And Java is the go-to option under that consideration, just because, it is Java, the least controversial choice if you had asked me.
But Amazon comparing with other companies I worked with, except extremely small startup, where tech guidance is like non-existent, the least restrictive when it comes to languages. It fits the Amazon's self perception, it is pragmatic, non opinionated, moral-agnostic. It cares about customer, because customer means potential of eventual profit. However you achieved that, is not Amazon's concern.