> So I guess one could ask, why should it be any different in software? Since the software world does not generally work this way, we could also ask why the architect/brick layer model should be applied in this world.…
> Amazon clearly does not compete by hiring the best engineers. Rather, they compete by throwing money at the problem and undercutting everyone else, getting by with mediocre engineering. Evidence please. Amazon has a…
It depends on what "locking up" means. If we are talking about US-style prisons then letting (possibly innocent and for that matter even guilty) people languish there _is_ cruel and unusual punishment. However, there…
> they 996 just because they earn much more. Maybe in absolute terms but their per-hour income is lower. They're working 1.8 times longer than a 40 hour week but not earning 1.8 times as much as they would when working…
I am afraid that I missed the link where running a business in China is equivalent to turning a blind eye to their human rights abuses. There is a spectrum between doing nothing and quitting that falls under "not being…
By all means, stop idealizing. Learn what you can but please don't idealize anyone or any company. But I hardly think that I or most of my colleagues are an insult to any discipline. Apple, Amazon and Google each has…
Sure and this is to be expected. It costs time and money to align yourself with someone else's implementation and unless your customers demand alignment (e.g. S3-compatible storage interfaces), you're probably not going…
Having worked at AWS, I have to disagree with you. No-one that I worked with saw containerization as a threat. And why would they? At the VM level you can already paper over differences between cloud providers and I…
I'm not sure why you think that striving only to achieve business objectives could be considered to be a moral duty. Are you perhaps perhaps thinking of fiduciary duty? If a company decides that technical development of…
Some Amazon teams have multiple services of varying sizes. What Amazon and similar companies get right is by (generally) insisting on good engineering/business/regulatory reasons for splitting out services.
Your job is whatever you agreed to when accepting that job. Some companies require managers to aid in the technical development of employees, some don't. Some provide a lot of latitude in how that's done, some don't.
What is different about breaking an application into services is that because services run as different processes: * you have an immediate natural failure domain (the process) as well as resource isolation between…
Isolated changes aren't a myth. FAANG and others leverage the isolation brought by service separation every day. For very large services, a monolith makes it difficult to test services independently. I personally don't…
I worked at AWS before moving to Google. AWS is not perfect (their oncall story being a good example) but they have _a lot_ of very talented engineers and are _really_ good at doing ops (and cloud systems are…
> So I guess one could ask, why should it be any different in software? Since the software world does not generally work this way, we could also ask why the architect/brick layer model should be applied in this world.…
> Amazon clearly does not compete by hiring the best engineers. Rather, they compete by throwing money at the problem and undercutting everyone else, getting by with mediocre engineering. Evidence please. Amazon has a…
It depends on what "locking up" means. If we are talking about US-style prisons then letting (possibly innocent and for that matter even guilty) people languish there _is_ cruel and unusual punishment. However, there…
> they 996 just because they earn much more. Maybe in absolute terms but their per-hour income is lower. They're working 1.8 times longer than a 40 hour week but not earning 1.8 times as much as they would when working…
I am afraid that I missed the link where running a business in China is equivalent to turning a blind eye to their human rights abuses. There is a spectrum between doing nothing and quitting that falls under "not being…
By all means, stop idealizing. Learn what you can but please don't idealize anyone or any company. But I hardly think that I or most of my colleagues are an insult to any discipline. Apple, Amazon and Google each has…
Sure and this is to be expected. It costs time and money to align yourself with someone else's implementation and unless your customers demand alignment (e.g. S3-compatible storage interfaces), you're probably not going…
Having worked at AWS, I have to disagree with you. No-one that I worked with saw containerization as a threat. And why would they? At the VM level you can already paper over differences between cloud providers and I…
I'm not sure why you think that striving only to achieve business objectives could be considered to be a moral duty. Are you perhaps perhaps thinking of fiduciary duty? If a company decides that technical development of…
Some Amazon teams have multiple services of varying sizes. What Amazon and similar companies get right is by (generally) insisting on good engineering/business/regulatory reasons for splitting out services.
Your job is whatever you agreed to when accepting that job. Some companies require managers to aid in the technical development of employees, some don't. Some provide a lot of latitude in how that's done, some don't.
What is different about breaking an application into services is that because services run as different processes: * you have an immediate natural failure domain (the process) as well as resource isolation between…
Isolated changes aren't a myth. FAANG and others leverage the isolation brought by service separation every day. For very large services, a monolith makes it difficult to test services independently. I personally don't…
I worked at AWS before moving to Google. AWS is not perfect (their oncall story being a good example) but they have _a lot_ of very talented engineers and are _really_ good at doing ops (and cloud systems are…