4 ms·

Disclosure: I work for Amazon as a VP and Distinguished Engineer building our cloud infrastructure. My professional opinion is that is a very poor strategy. Cu

by _msw_ 6y ago

Disclosure: I work for Amazon as a VP and Distinguished Engineer building our cloud infrastructure. My professional opinion is that is a very poor strategy. Customers want to have freedom, not lock-in. When designing infrastructure services, it's good to carefully consider what abstractions are going to preserve freedom and flexibility. For example, adopting the Arm architecture, and further using the Arm developed Neoverse N1 core, provides the broadest capabilities and compatibility thanks to the investment in a common ecosystem. The optimizations we are able to put in our silicon design, and the design of the Nitro system, let us deliver better price/performance without resorting to such customer unfriendly tactics of "lock-in".

api 6y ago
I hope I'm just being cynical, but I base my attitude on the general trend in the industry at least in any realm related to either cloud or mobile. Everything is about herding people into some kind of closed silo and then locking the door, or on the consumer front about invading peoples' privacy in new and creative ways. I do agree in principle that it's harder to pull off this kind of lock-in with knowledgeable customers of the sort that deploy things on AWS.
- _msw_ 6y ago
  I hope you are too. As technologists and professionals I think we need to be ever-vigilant to build in responsible ways that support the public good. That includes being mindful of safety, security, and privacy concerns. And also creating or extending inequities.
lykr0n 6y ago
But that's what AWS offers. All the big products- SQS, DynamoDB, Aurora, S3, Beanstalk. Those are all AWS services you can't use outside AWS (sure, there are API compatible alternatives out there). If you design for those services, you're locked into using AWS. There is a reason bandwidth in is free while out costs money- it needs to be easy for people to move onto AWS without being east to move out. Customers are clearly choosing vendor lock-in over freedom. And AWS encourages this. If you want to migrate to AWS, Amazon will send an army of developers to help you adopt their technology. Will they do the same if a big customer wants to migrate away down the road? https://e.lvme.me/kmw2hs1.jpg https://e.lvme.me/kmw2hs1.jpg
- _msw_ 6y ago
  As you point out, others implement compatible open source software versions of S3 and DynamoDB. Aurora already adopts (via adapting the open source software) the protocols and semantics of MySQL and PostgreSQL. Elastic Beanstalk helps you orchestrate the deployment of your application via a selection of supported "platforms" that are nearly all open source (except for .NET on Windows Server + IIS). In all of these, you could argue that SQS stands alone as something that doesn't have a "drop in" replacement. Developers that have a concern about that might want to adopt an open source alternative instead. There is nothing that prevents a developer from doing so. In my experience, developers are adopting open source more than ever, and they also show an adept ability to know (as a crowd) what they should worry about, versus what is modular / abstract enough such that it could be replaced.
  - lykr0n 6y ago
    You're right. There are open source replacements for most AWS services, but that's like saying Wine under Linux is the same as Windows. For the most part, it works well enough to run most application but there are some that just don't work. PostgreSQL vs CockroachDB. Both speak PostgreSQL, but once you start using any advanced functionality you're going to run into issues. If you're building on AWS S3 heavily, you're going to encounter features that might not be there in the "open source" version, things that behave differently, or just don't work as well. So while it's a nice thought to have, it's the same logic behind internet competition in the US for some areas. You can pick Comcast cable or DSL/WISP. They're the same, right? Nothing prevents a developer from not adopting a technology, but we both know there are usually business decisions driving it. If you're already using S3 or DynamoDB heavily, you're already trapped. It's a cult. You're free to leave any time, but why not stay here with all your friends? If you leave you would have to spend millions in bandwidth moving your terabytes of data, hundreds of developer hours to update code, and knowledge building around new products. You can always replace something with something else. But sometimes it's just not practical.
    - _msw_ 6y ago
      You're absolutely right with an API/ABI with the size and complexity of Win32 there is a risk to have compatibility challenges. Just like WSL v1 and gVisor, as re-implementations of Linux syscalls and subsystems. To me, well designed web services are more intrinsically decoupled compared to general purpose operating system runtimes or SQL implementations. As for when and why a group of people decide to exit various relationships, I've personally observed that sometimes cost and practicality is not evaluated completely by decision makers [1], despite various clear economic benefits of remaining. [1] https://en.wikipedia.org/wiki/Brexit https://en.wikipedia.org/wiki/Brexit

by _msw_ 6y ago

api 6y ago

I hope I'm just being cynical, but I base my attitude on the general trend in the industry at least in any realm related to either cloud or mobile. Everything is about herding people into some kind of closed silo and then locking the door, or on the consumer front about invading peoples' privacy in new and creative ways. I do agree in principle that it's harder to pull off this kind of lock-in with knowledgeable customers of the sort that deploy things on AWS.

_msw_ 6y ago
I hope you are too. As technologists and professionals I think we need to be ever-vigilant to build in responsible ways that support the public good. That includes being mindful of safety, security, and privacy concerns. And also creating or extending inequities.

lykr0n 6y ago

But that's what AWS offers. All the big products- SQS, DynamoDB, Aurora, S3, Beanstalk. Those are all AWS services you can't use outside AWS (sure, there are API compatible alternatives out there). If you design for those services, you're locked into using AWS. There is a reason bandwidth in is free while out costs money- it needs to be easy for people to move onto AWS without being east to move out. Customers are clearly choosing vendor lock-in over freedom. And AWS encourages this. If you want to migrate to AWS, Amazon will send an army of developers to help you adopt their technology. Will they do the same if a big customer wants to migrate away down the road? https://e.lvme.me/kmw2hs1.jpg https://e.lvme.me/kmw2hs1.jpg

_msw_ 6y ago
As you point out, others implement compatible open source software versions of S3 and DynamoDB. Aurora already adopts (via adapting the open source software) the protocols and semantics of MySQL and PostgreSQL. Elastic Beanstalk helps you orchestrate the deployment of your application via a selection of supported "platforms" that are nearly all open source (except for .NET on Windows Server + IIS). In all of these, you could argue that SQS stands alone as something that doesn't have a "drop in" replacement. Developers that have a concern about that might want to adopt an open source alternative instead. There is nothing that prevents a developer from doing so. In my experience, developers are adopting open source more than ever, and they also show an adept ability to know (as a crowd) what they should worry about, versus what is modular / abstract enough such that it could be replaced.
- lykr0n 6y ago
  You're right. There are open source replacements for most AWS services, but that's like saying Wine under Linux is the same as Windows. For the most part, it works well enough to run most application but there are some that just don't work. PostgreSQL vs CockroachDB. Both speak PostgreSQL, but once you start using any advanced functionality you're going to run into issues. If you're building on AWS S3 heavily, you're going to encounter features that might not be there in the "open source" version, things that behave differently, or just don't work as well. So while it's a nice thought to have, it's the same logic behind internet competition in the US for some areas. You can pick Comcast cable or DSL/WISP. They're the same, right? Nothing prevents a developer from not adopting a technology, but we both know there are usually business decisions driving it. If you're already using S3 or DynamoDB heavily, you're already trapped. It's a cult. You're free to leave any time, but why not stay here with all your friends? If you leave you would have to spend millions in bandwidth moving your terabytes of data, hundreds of developer hours to update code, and knowledge building around new products. You can always replace something with something else. But sometimes it's just not practical.
  - _msw_ 6y ago
    You're absolutely right with an API/ABI with the size and complexity of Win32 there is a risk to have compatibility challenges. Just like WSL v1 and gVisor, as re-implementations of Linux syscalls and subsystems. To me, well designed web services are more intrinsically decoupled compared to general purpose operating system runtimes or SQL implementations. As for when and why a group of people decide to exit various relationships, I've personally observed that sometimes cost and practicality is not evaluated completely by decision makers [1], despite various clear economic benefits of remaining. [1] https://en.wikipedia.org/wiki/Brexit https://en.wikipedia.org/wiki/Brexit