I've always thought of Apollo environments as containers before kernel features for containers existed. With enough environment variables and wrapper scripts taking the name of real binaries to populate stuff like LD_LIBRARY_PATH, Apollo makes a private environment that is only _slightly_ contaminated by the host.
Apollo environments try to solve the same problem, but they're definitely not containers - one cannot depend on any fixed paths. I still bear scars from wrestling with various packages' autotools / glib / Python path dependencies trying and hoping desperately to find poorly / undocumented environment variable overrides to get them to let go of a static, build-time specified path and play nicely with Apollo's environment path shell-game.
And yeah, the other thing that made it work, I guess, was having the machine image be very minimal, very tightly controlled, and very infrequently changed - so you didn't have to worry about things changing all the time due to the upstream distro.
That's what it was. VM with a barebones deployment system that had a ton of hooks in it.
Really really smart idea that IMO helped Amazon in the 2010s immensely. While everyone else was figuring out k8s and whatnot, Amazon had a good system with CI in place for years.
I wonder how it's fared over time. Amazon was never known for internal tooling in many other places. I hope Apollo is still running strong today.
There's been a company wide effort to move everything to Native AWS. While many existing services still run on Apollo, virtually all new services are created on ECS, EC2 or Lambda.
