ex-aws-now-goog
ex-aws-now-goog on Hacker News
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. The decider/implementer model might be a common organizing principle in other industries; that does not mean that it's useful to software.
Brick layers cannot manipulate more than small chunks of a building at a time. Software engineers in contrast can perform the equivalent of turning the Empire State Building on its head.
Software architecture is difficult to get right and too important to leave to one or two senior folks who may or may not have the insight required to make the right decisions.
Evidence please. Amazon has a lot of freaking fantastic engineers and "throwing money at the problem" is definitely not how they solve problems.
It's a huge company and not every single engineer is excellent and there are definitely rotten bits but that's true of _every_ company that's large enough.
That looks to me like a surprise discovery.
However, there are better "prisons" (see e.g. what Norway does) and it is possible to let (dangerous) people live lives that are dignified, fulfilling and productive (when they are able to work) under the constraints of captivity.
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 in e.g. Europe.
There is a spectrum between doing nothing and quitting that falls under "not being neutral in situations of injustice". If our only tool for reforming systems (such as countries or companies) is to abandon them, progress would hardly be possible. Tutu understood this and worked hard to enable reconciliation after Apartheid.
But I hardly think that I or most of my colleagues are an insult to any discipline. Apple, Amazon and Google each has tens of thousands of engineers (and many more folks if you consider other roles). In most companies, there will be parts of the company engaging in behaviour you disagree with.
Expecting people to resign from company X because some people at company X do bad things is a very black and white way to think about the world.
Again, this comes down to cost-benefit calculations. If some companies find that proprietary feature X from cloud Y provides a bigger (perceived) return on investment than not using feature X, then they are likely to use it. If company X later shafts them, they have to swallow more costs to migrate away but hopefully (for them) they took this possibility into consideration when they made their original decision.
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 don't think that anyone at any of the large cloud providers lies awake at night worried about this.
I also don't understand why serverless would couple you to a particular cloud provider. All the big cloud providers provide serverless features and it never takes long to see feature parity.
What ties you to a cloud provider (or any company) is when you use features unique to that provider. And presumably you're using those features because the value they add outweighs the perceived costs of lock-in or the cost of implementing it yourself.
If a company decides that technical development of engineers is good for retaining engineers and you as a manager refuse to do that, then no moral argument is going to help you when you get dinged in your performance review.
edit: Upon rereading the thread, I suspect that we may agree more than we disagree. My comment was directed at asknthrow's comment and I wanted to make the point (which other posters have more eloquently made in the meantime) that if technical development is part of your job as manager, you don't have a choice in the matter and your job is not just "to lead the team in the most effective direction in order to fulfil business objectives" (to quote asknthrow).
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.
The statement that service orientation "... just replaces internal calls between services of your monolith with flaky and slower network calls" is correct in that network calls are flaky and slower but incorrect in its assessment that you gain nothing from using services.
I personally don't like the word "microservices" since it implies that services have to be micro. For the last few years I have worked on service oriented systems where the individual components are sometimes pretty big - one could say almost monolithic :).
Splitting a monolith into separate services exacts an operational price. Engineers should be honest in assessing whether it's worth it. Sometimes it is, sometimes it isn't.
Perhaps your corner of AWS isn't as nice as the one I worked in but to generalize that to AWS management "death marching mediocre talent to ship untested and brittle things" is a very inaccurate assessment of AWS and its customers' perceptions of their products.