3 ms·

> 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 tal

by 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!

by lykr0n 6y ago

_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!