Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

On Internal Engineering Practices at Amazon

jatins.gitlab.io

Post reply on HN
Print view View original

71–80 of 130 posts

Re: On Internal Engineering Practices at Amazon

#71

Post by richardwhiuk »

jhayward wrote: post #68
m0zg wrote: post #57

Earlier quoted context omitted.

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…

Ah, you're using it to mean "no virtualization". Got it, thanks. I tend to use the term to mean single-tenant, user-supplied OS, non-virtualized myself but I see where you're coming from.

All of that may be true as well - if the user picks the underlying OS (i.e. kernel) to run the container engine and installs on bare metal, then literally everything you wrote applies.

Re: On Internal Engineering Practices at Amazon

#72

Post by torqueTorrent »

In my career I've experienced alot of engineers that had a desire to shy away from command line or command prompt tools, shell, CMD.exe, batch, scripting, cron and related 'traditional' automation, in favor of GUI, IDE, html, browser etc.

I've even had some young sexy angular-wizard type engineers that had the ear of mgmt sarcastically respond with statements like "I don't do command line".

This article and my experience with AWS development and Amazon leads me to believe this entire company is led and staffed by such engineers.

Re: On Internal Engineering Practices at Amazon

#73

Post by ex_amazon_sde »

Ex-Amazon SDE checking in. The article is quite misleading.

The author confuses "shiny" with "good".

Amazon does package-based deployments because it scales well and allow engineers from many different teams to work on packages and also provides fast security updates.

Amazon used VMs more than a decade before container engines and the latter are still lacking security and stability.

Having worked in many companies, I would take Amazon's engineering practices over the modern shiny devops tool ecosystem every day.

I agree that Apollo is slow (due to the implementation) and has an ugly UI, and that the company has a very poor track record of contributing to OSS.

Re: On Internal Engineering Practices at Amazon

#74

Post by ex_amazon_sde »

coreyoconnor wrote: post #47
konspence wrote: post #40

Earlier quoted context omitted.

Any take on how this looks for someone who doesn't work at Amazon? I know Apollo is their deployment tool. No idea how they plays into a Kubernetes or even container stack.

Conceptually, there is a lot of overlap. Apollo had a few layers to it but would, more or less, matched kubernetes plus additional tooling. Dare I say closer to openshift? Brazil, the build tool, infrastructure and repository was similar to using nixpkgs. Brazil had some features beyond nixpkgs that were absolutely essential for an business like Amazon, but otherwise the goals and even techniques overlapped. I onboar…

> Apollo had a few layers to it but would, more or less, matched kubernetes plus additional tooling

Have you looked at the codebase? Apollo and Brazil are tiny compared to Kubernetes & friends. You could reimplement them with a small script on top of traditional Linux package management (modulo the web UI).

Re: On Internal Engineering Practices at Amazon

#75

Post by amzn-throw »

just_passing_by wrote: post #45

What amuses me is that most of retractions come from ex-Amazonians not from the current staff. This is the only company i know dealing with that much criticism from engineering. Even more to add is that the article is more or less fresh and at Amazon's scale i doubt any major changes had undergone in the last 10 months.

There is a comment above you from an Amazon Principal Engineer: https://news.ycombinator.com/user?id=jcrites

His profile says "Architect and cofounder of Simple Email Service. Creator of Cloud Desktop, a cloud-based development environment used by most Amazon engineers. Technical lead for Amazon's strategy for using AWS."

Can't get more "From the horse's mouth than that"

We are generally asked not to comment on stuff like this because of how easy it is to reveal confidential internal details.

For the record, the article is mostly wildly out of date, but others have already corrected the record.

Re: On Internal Engineering Practices at Amazon

#77

Post by just_passing_by »

amzn-throw wrote: post #75
just_passing_by wrote: post #45

What amuses me is that most of retractions come from ex-Amazonians not from the current staff. This is the only company i know dealing with that much criticism from engineering. Even more to add is that the article is more or less fresh and at Amazon's scale i doubt any major changes had undergone in the last 10 months.

There is a comment above you from an Amazon Principal Engineer: https://news.ycombinator.com/user?id=jcrites His profile says "Architect and cofounder of Simple Email Service. Creator of Cloud Desktop, a cloud-based development environment used by most Amazon engineers. Technical lead for Amazon's strategy for using AWS." Can't get more "From the horse's mouth than that" We are generally asked not to comment on stuff…

I'm aware current employees comment over here. Two things to mention: principal/architect roles are always based not only on a merit of skill but politics. So, taken with a grain of salt.

Moreover, if you inspect the person's comments you will notice how "legally" clean they are. Even the phrasing looks the same for both comments "based on my experience", "this information if wrongful" etc. Looks like those were refined by the legal team before posted.

I wonder all that, because since my first engagement with AWS and Amazon recruiting around five years ago the engineering tone did not change. That concerns in a way that putting an effort to get a job there may turn out a major disappointment.

The cutthroat approach is nice sometimes as it adds the taste of competition but the whole noise seems like you're about to get buried rather than played or burned out.

Re: On Internal Engineering Practices at Amazon

#79

Post by bethling »

jcrites wrote: post #17
kerng wrote: post #11

I like how Amazon has an MAWS movement internally, meaning "Move to AWS". I think most people think that they use AWS mostly, but they dont. Its an interesting look behind the scenes at Amazon and how antiquated they appear to operate. Makes you wonder if Azure and Google have pretty good chances beating them down the road. Edit: Interesting, further down one person commented that Amazon doesn't use AWS broadly becau…

Based on my experience, that information and some of the comments about it in the thread are out of date or inaccurate. 'Move to AWS' was a program focused on accelerating AWS adoption that was primarily active something like 5-7 years ago. The program achieved its goals and concluded: virtually all infrastructure was running on AWS. I worked on the program for part of that time, in the last couple of years it was ac…

This is very true. I left Amazon in 2014, by that time I had to explain why (at least twice a year) I had some services that could not feasibly be moved to AWS. At least in the org I was a part of, that they were not running on AWS stood out enough that it raised questions.
Post reply on HN