ex_amazon_sde

13 ms·

61.
by ex_amazon_sde 5y ago
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
62.
by ex_amazon_sde 5y ago
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. Ther
63.
by ex_amazon_sde 5y ago
> 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 dir
64.
by ex_amazon_sde 5y ago
I've never seen anybody using UML in Amazon, despite its culture for documentation, charts, metrics and diagrams.
65.
by ex_amazon_sde 5y ago
> 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 shorte
66.
by ex_amazon_sde 5y ago
I feel like this stuff should be posted in a Rust-specific site, not on HN.
67.
by ex_amazon_sde 5y ago
No, you are confusing containers with sandboxing and they are completely orthogonal.
68.
by ex_amazon_sde 5y ago
You are describing sandboxing and it's completely orthogonal to containers.
69.
by ex_amazon_sde 5y ago
As odyslam wrote, opt-out is unethical.
70.
by ex_amazon_sde 5y ago
> 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.
71.
by ex_amazon_sde 5y ago
> 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.
72.
by ex_amazon_sde 5y ago
> Hopefully one day its as cheap as writing a function is. When a network call is involved, never.
73.
by ex_amazon_sde 5y ago
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.
74.
by ex_amazon_sde 5y ago
> vs ten microservices or apps that require coordinating with others That's called the "distributed monolith" and it's worse than a monolith.
75.
by ex_amazon_sde 5y ago
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.
76.
by ex_amazon_sde 5y ago
Spot on! This is the right granularity.
77.
by ex_amazon_sde 6y ago
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 du
78.
by ex_amazon_sde 6y ago
Ex Amazon SDE here. You are absolutely right.
79.
by ex_amazon_sde 6y ago
Yes
80.
by ex_amazon_sde 6y ago
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 c
81.
by ex_amazon_sde 6y ago
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.
82.
by ex_amazon_sde 6y ago
> 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 b
83.
by ex_amazon_sde 6y ago
> 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: roughl
84.
by ex_amazon_sde 6y ago
> "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 w
85.
by ex_amazon_sde 6y ago
The first one, but I'm trying not to divulge too many details on the architecture of Amazon - as you can imagine.
86.
by ex_amazon_sde 6y ago
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,
87.
by ex_amazon_sde 6y ago
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 revi
88.
by ex_amazon_sde 6y ago
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.
89.
by ex_amazon_sde 6y ago
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 dependencie
90.
by ex_amazon_sde 6y ago
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

More ›