3 ms·

> "Those are all AWS services you can't use outside AWS" What does that mean? You can absolutely run an application hosted on Azure or GCP that uses DynamoDB

> "Those are all AWS services you can't use outside AWS" What does that mean? You can absolutely run an application hosted on Azure or GCP that uses DynamoDB or SQS as it's backing database, or queueing system? These are just APIs on the public internet... > If you design for those services, you're locked into using AWS. Is that not the case with any software - including open source? If you design for Active MQ, you're "locked in" to MQ interfaces. If you design for Kafka, you're "locked in" to Kafka interfaces. Now, your argument about imbalanced data transfer rates MAY have aspects of lock-in - AWS does make it easier to onboard than offboard. But, that's also the case with any service provider, and I don't even mean software. Stock brokerages charge a fee for transfering portfolios out of their management, and the stock brokererage you transfer your stocks TO will usually cover those fees. Data transfer isn't free, it makes sense that AWS would charge for it, and it would make sense that it would charge more for one direction. Unless your expectation is that every software or SaaS company's API is open-source and interoperable with every other provider, I just don't see how you can avoid the kind of "lock-in" you describe.

lykr0n 6y ago
> These are just APIs on the public internet... I could run my load balance on GCP, send traffic to applications hosted in Azure, which use AWS services to talk to each other. Sure, that's something I _could_ do. but that's drastically more expensive then if I run everything inside of AWS. They're not just APIs on the public internet. You also need to worry about latency and cost. Talking to/from an AWS service from outside AWS is more expensive from talking inside AWS. > If you design for Active MQ, you're "locked in" to MQ interfaces. Being locked into a paid product, vs a free product are two completely different things. I can take the Kafka code base and do whatever I want to it. It's an open system. I can't do the same with DynamoDB or SQS. You can't cut ties with AWS and still have your DyanmoDB dependent systems function, while I could cut all ties with Apache and still have a functional kafka cluster. > But, that's also the case with any service provider Yes. That doesn't make it a good thing. Having to pay to move stocks from one broker to another isn't a good thing. > Unless your expectation is that every software or SaaS company's API is open-source and interoperable with every other provider, I just don't see how you can avoid the kind of "lock-in" you describe. I'm not presenting a way to avoid it. I'm stating that AWS offers a bunch of vendor lock-in type products. They're like Oracle. Oracle DB is an amazing piece of software, but they know this and charge an arm, a leg, and your soul for it. The only difference between AWS and Oracle is that AWS havn't asked for your soul yet.
- _msw_ 6y ago
  If your threat model includes having to address a concern of historically unpredictable or unreliable vendor behavior or performance (which makes sense, in a robust professional engineering practice), it can make sense to take matters in your own hands. Open Source is a great way to do that. While past performance does not guarantee future results, there is some empirical evidence that you can use when evaluating which vendors you trust, and can rely on to be customer obsessed, including always looking for sustainable ways to save you money. You are, of course, entitled to an opinion about what "sustainable" means to you, and how you measure your choice of vendor. To me, it means specific things in how I professionally practice as an engineer. [edit: small clarification, saving customers money is only one way to deliver value for their money. But, in my experience ]
- sigstoat 6y ago
  > Sure, that's something I _could_ do. but that's drastically more expensive then if I run everything inside of AWS. oh no! engineering tradeoffs!

lykr0n 6y ago

> These are just APIs on the public internet... I could run my load balance on GCP, send traffic to applications hosted in Azure, which use AWS services to talk to each other. Sure, that's something I _could_ do. but that's drastically more expensive then if I run everything inside of AWS. They're not just APIs on the public internet. You also need to worry about latency and cost. Talking to/from an AWS service from outside AWS is more expensive from talking inside AWS. > If you design for Active MQ, you're "locked in" to MQ interfaces. Being locked into a paid product, vs a free product are two completely different things. I can take the Kafka code base and do whatever I want to it. It's an open system. I can't do the same with DynamoDB or SQS. You can't cut ties with AWS and still have your DyanmoDB dependent systems function, while I could cut all ties with Apache and still have a functional kafka cluster. > But, that's also the case with any service provider Yes. That doesn't make it a good thing. Having to pay to move stocks from one broker to another isn't a good thing. > Unless your expectation is that every software or SaaS company's API is open-source and interoperable with every other provider, I just don't see how you can avoid the kind of "lock-in" you describe. I'm not presenting a way to avoid it. I'm stating that AWS offers a bunch of vendor lock-in type products. They're like Oracle. Oracle DB is an amazing piece of software, but they know this and charge an arm, a leg, and your soul for it. The only difference between AWS and Oracle is that AWS havn't asked for your soul yet.

_msw_ 6y ago
If your threat model includes having to address a concern of historically unpredictable or unreliable vendor behavior or performance (which makes sense, in a robust professional engineering practice), it can make sense to take matters in your own hands. Open Source is a great way to do that. While past performance does not guarantee future results, there is some empirical evidence that you can use when evaluating which vendors you trust, and can rely on to be customer obsessed, including always looking for sustainable ways to save you money. You are, of course, entitled to an opinion about what "sustainable" means to you, and how you measure your choice of vendor. To me, it means specific things in how I professionally practice as an engineer. [edit: small clarification, saving customers money is only one way to deliver value for their money. But, in my experience ]
sigstoat 6y ago
> Sure, that's something I _could_ do. but that's drastically more expensive then if I run everything inside of AWS. oh no! engineering tradeoffs!