Re:On Internal Engineering Practices at Amazon
by coreyoconnor on Wednesday March 27, 2019 @01:27AM
(#19498361)
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 onboarded very, very quickly by already knowing nixpkgs and container management. The concepts translated well. A few aspects that didn't either were things Amazon handled that other tools have yet to encounter: Cool to learn about. Or historical bits that didn't matter: fine to ignore.
Re:On Internal Engineering Practices at Amazon
by ex_amazon_sde on Wednesday March 27, 2019 @06:28AM
(#19499520)
> 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
by Pfhreak on Wednesday March 27, 2019 @09:43AM
(#19500718)
As someone who worked on Apollo, I'd challenge this. Without divulging any details, Apollo is a non trivial system.
Re:On Internal Engineering Practices at Amazon
by amazon_throw on Wednesday March 27, 2019 @12:16PM
(#19502475)
Yeah, I work adjacent to the Apollo org (and have worked near Pfrheak, too. Hi!). I would love to see a HackerNews commenter's idea of what it would take to re-implement Apollo. I'll bring popcorn.
I know Apollo is their deployment tool. No idea how they plays into a Kubernetes or even container stack.