ex_amazon_sde

Ex-Amazon SDE here.

> Then again, we're not servicing any life critical systems.

Reminder: you almost never increase reliability by adding layers of abstraction.

You increase reliability and security by removing complexity/code as much as possible and implementing redundancy in few crucial places.

Complexity never comes for free.

Running a bunch of services creates all sort of failure modes unrelated to the tests you are running and requires maintenance in the long term.

Adding docker to it only increases the overall complexity.

There are good reasons for doing unit and functional testing with mocks.

> we did get a little more complicated and create a SystemD script to launch it at startup

If only there was a tool to:

- bundle, distribute and deploy applications

- ...and configuration files

- ...and systemd unit files

- ...even directories containing a Python virtualenv

- keep track of what is installed and in what version

- roll forward or roll back

I would call it Advanced Packaging Tool.

I've never seen anybody using UML in Amazon, despite its culture for documentation, charts, metrics and diagrams.

> we are now living in a much more stable time than when these memes were created

Quite the opposite. The cambrian explosion of tools and SaaS is getting faster and the average useful lifetime of anything released today is getting shorter.

I feel like this stuff should be posted in a Rust-specific site, not on HN.

No, you are confusing containers with sandboxing and they are completely orthogonal.

You are describing sandboxing and it's completely orthogonal to containers.

As odyslam wrote, opt-out is unethical.

> I might be working on an accounting software for a big company and never use it.

Obviously. But you are using other FOSS directly or indirectly.

> The freedom of users is more important than the freedom of developers.

This is misleading. All developers are users as well. Having to use closed source services and tools impacts us a lot.

> Hopefully one day its as cheap as writing a function is.

When a network call is involved, never.

Quoting some book does not change the fact that most people understand SOA as being team or domain-bound and microservices as being much smaller.

> vs ten microservices or apps that require coordinating with others

That's called the "distributed monolith" and it's worse than a monolith.

YES and this is why deployments to prod should go though many stages and have long bake-in time for critical applications.

The idea of deploying every commit all the way to prod is is very questionable.

Spot on! This is the right granularity.

Ex-Amazon SDE here: SOA is good, team boundaries are good, tiny microservices are bad, distibuted monolith is really bad.

> performance/flexibility/scaling of microservices

Tiny microservices tend to perform and scale poorly due to their granularity.

Ex Amazon SDE here. You are absolutely right.

Yes

It's way more than "just a configuration".

> A function call or a remote call won't change the domain logic

Understanding performance and minimizing failure modes and their impact on larger systems makes for a whole career as "SRE". Making remote calls all over a codebase creates behaviors that are practically impossible to debug or optimize. But the blocker is the network impact of large applications and the emergence of cascading failures.

The majority of retail is dog-fooding AWS, but a lot of code was written before AWS existed or before it provided many of the required services.

> programming for distributed environments as if you had one giant single-thread computer, and function calls could arbitrarily happen over IO or not

Ex-Amazon SDE here. Message-passing libs like 0mq tried to push this idea.

They never became very popular internally because passing data between green threads vs OS threads vs processes vs hosts vs datacenters is never the same thing.

Latencies, bandwidths and probability of loss are incredibly different. Also the variance of such dimensions. (Not to mention security and legal requirements)

Furthermore, you cannot have LARGE applications autonomously move across networks without risks of cascading failures due to bottlenecks taking down whole datacenters.

Often you want to control how your application behaves on a network. This is also a reason why OTP (in Erlang or implemented in other languages) is not popular internally.

> I have been saying the same for years but have either been punished by my managers or mercilessly downvoted on HN.

Ex Amazon SDE here. I've been saying many times that Amazon tends to have the right granularity of services: roughly 1 or 2 services for a team.

A team that maintains the service in production autonomously and deploys updates without having to sync up with other teams.

[Disclaimer: I'm not talking about AWS]

> "let's evaluate and simplify where we can?"

Amazon has "Invent and Simplify" as one of the leadership principles. However, each team has its own hiring bar and culture, so some will take it seriously and some will not.

> I find AWS a huge pile of overcomplicated offerings

I fully agree. I'm speaking exclusively about the internal infrastructure, not about AWS.

The first one, but I'm trying not to divulge too many details on the architecture of Amazon - as you can imagine.

Ex Amazon SDE here. I would pick the first method a hundred times.

People would be surprised at how simple the internal infra is, given the fleet size, compared to stuff like k8s.

(I'm talking about the infra that runs on bare metal, not AWS)

I'm not sure what point you are making.

Yet, reviewing hundreds of thousands SLOCs (across different languages) and also checking legal compliance requires significant skills, time and efforts.

As an individual, you cannot justify reviewing the entire dependency tree across all your projects.

Thankfully you can rely on the packages reviewed and built internally by your colleagues - or use a Linux distribution that does thorough vetting.

This is not correct.

Installing packages only from a trusted (and signed) source protects against typosquatting, misread or confusing package names and many other risks.

Ex-Amazon SDE here.

> a unique design flaw of the open-source ecosystems

This is a big generalization.

Inside Amazon, as well as in various Linux distributions, you cannot do network traffic at build time and you can only use dependencies from OS packages.

Each library has its own package and the code and licensing is reviewed. The only open source distribution that I know to have similar strict requirements is Debian.

[I'm referring to the internal build system, not Amazon Linux]

[Disclaimer: things might have changed after I left the company]

Leetcode focused on tricks and memorizing algorithms.

I've rejected a good bunch of candidates that can pass coding tests while not having any good understanding of theory, hardware, OS, networking, security