Live data from Hacker News

On Internal Engineering Practices at Amazon

jatins.gitlab.io

51–60 of 130 posts

Re: On Internal Engineering Practices at Amazon

#51
post #36

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?

Games are automatically considered to be competing with the company.

Re: On Internal Engineering Practices at Amazon

#52
post #10

Based 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.

I left Amazon a little over 3 years ago, having worked there for over 3 years. I would agree that this article seems misleading. Some of the things the article complains about were fixed while I was working there. The article compares Apollo to Kubernetes/Docker but Apollo predates Docker by years.

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

#53
post #8

Earlier 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!"?

GP's comment may have been true at one point, but AWS is extremely mainstream within Amazon now and has been for several years.

Re: On Internal Engineering Practices at Amazon

#54

Earlier quoted context omitted.

I agree. Disclaimer: Also ex-amazonian, left like one year ago.

What happened like one year ago?

Amazon is a giant company with tens of thousands of employees. People are joining and leaving all the time.

Re: On Internal Engineering Practices at Amazon

#55

Earlier 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…

I can confirm that the claim "you can't even use a language other than Java" is completely false. Java is often the best tool for the job because of how much institutional inertia there is behind it, but certainly nobody will stop a team from using a better tool.

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

#56
I was once pitched a startup founded by some ex-amazonians whose big idea was "Apollo for everyone". They were nonplussed by my spit take.

For 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

#57
post #41

Earlier 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?

Containers are just namespaces for things within the Linux kernel. Unlike with VMs, you're not running separate instances of the OS, it's all run by just one kernel instance, and that kernel usually runs directly on the hardware, that is, on "bare metal". That "ubuntu" base image you can spin up does not actually run the Ubuntu kernel. As a result, bare metal containers incur none of the "virtualization penalty" that VMs do.

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

#58
post #41

Earlier 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?

I think GP meant in the sense that Docker containers are just normal programs whose instructions are being executed directly by the CPU (just like how my laptop is executing Firefox as I type this) without relying on hardware virtualization features.

Re: On Internal Engineering Practices at Amazon

#59

Earlier 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…

The Java claim is just factually false.

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.

Post reply on HN