11 ms·
Theres just no way Google/Microsoft can catch up to the AWS product, without some significant improvement in distributed systems theory. AWS has had too many ye
by ldjkfkdsjnv 4y ago
Theres just no way Google/Microsoft can catch up to the AWS product, without some significant improvement in distributed systems theory. AWS has had too many years of grinding tens of thousands of engineers to get things perfect. The customer obsession, rigorous on-call, and perfectionist work culture are what make AWS. The corporate culture of MSFT/Google would never allow for the working conditions at AWS and it shows in their respective inferior products.
- treesknees 4y agoCan you elaborate on what you mean by "without some significant improvement in distributed systems theory"? If it's as you suggest, that it's the work culture which hold back Google and Microsoft, I don't see how improvements to distributed systems theory would result in ever passing AWS or its market share.
- throwaway_4ever 4y agoProbably that if there's enough of a paradigm shift in best practices for managing software infra, it would deprecate a significant portion of existing AWS and give Google or someone else a huge headway into implementing the new paradigm. A smaller scale example of this is Kubernetes, where GCP is leading adoption.
- tester756 4y agoWhat's the "AWS" culture?
- tracker1 4y agoYeah... Google has no experience with global distributed operations, data centers and applications at all. Neither does Microsoft, they probably don't even know what a entwork is, am I right? /sarc Seriously though. AWS isn't the end all, be all here and there are incredibly smart and talented network and systems engineers at many companies. The UX for AWS is often pretty bad, and it's sometimes difficult to know HOW to configure something, even if you know WHAT to configure. Like allowing a higher usage threshold for redis caching instead of trying to keep 50% of memory open by default. You can find the actual redis configuration option, how to set it in AWS, who knows (at least when I was using it). At this point DynamoDB's autoscaling is probably a much better experience, but getting it to grow/shrink appropriately was very painful at one point. On Azure, some of the simpler services are some of the easiest to use and get started with... Data* (Tables, Queues, Blobs) in particular. Of the three, I found Google's Cloud the most interesting to deal with. All of that said, I don't think any of them are incapable of correcting course and making things better... but it's easy enough to let things get worse. I think Amazon's biggest problem is they now have so many competing and overlapping services, it's become harder to even know what's right. Same for Azure to an extent... I am finding DigitalOcean's offerings to be compelling and may find myself trying that path with a project, or at least part of a project in the future.
- JackFr 4y ago> The UX for AWS is often pretty bad, Why worry about UX? Shouldn't your infra be scripted, version controlled and repeatable?
- nkzd 4y agoBecause learning terraform or cloud formation takes time. I am an average developer and I understand foundational infra theory. I know I can click around AWS without help in order to deploy a CRUD app. Why bother with scripted infra if I am going to revisit it once a year to fix an issue?
- ldjkfkdsjnv 4y agoPeople writing/operating serious software never make config changes through the UI. AWS console then is mostly just to view/investigate what is already configured