6 ms·

The only people worried about vendor lock-in are people who have practically nothing of value to be locked-in. "Lambda is horrible for lock-in, once you're hitt

by 013a 7y ago

The only people worried about vendor lock-in are people who have practically nothing of value to be locked-in. "Lambda is horrible for lock-in, once you're hitting billions of invocations a month you're going to wish you could cost optimize by shopping around with other providers! I've got my personal website hosted there, it gets a dozen hits a month, sure glad I'm inside the free tier." I've heard CTOs/CIOs of large companies express concern over it, but at the end of the day they'll sign that $100M contract with Amazon or Azure. It doesn't actually matter. Its a concern, but its not going to stop the sale or development. Today, if you're not locked in, you're leaving business value on the table. I hope that changes in the future, and maybe Kube will be the standard platform we've needed to push it forward (for example, I wish I could tell kube "give me a queue with FIFO and exactly once delivery", it knows what cloud provider you're on, if you're on AWS it provisions an SQS queue, if you're on GCloud it errors because they don't have one of those yet, and in either case I communicate with it from the app using a standard Kube API, not the aws-sdk). But for now, lean in. Don't fight the lock-in; every minute you spend fighting it is a minute that you should be spending fighting your competition.

cosmodisk 7y ago
Vendor lock-in isn't something anyone, especially at C-level should be ignoring. Yes, there are things to be gained and money to be made,but one should always have some sort of alternative,just in case. I happen to be in a business,which 100% relies on one vendor,which keeps hiking up prices every year way above inflation.
- HillRat 7y ago
  The flip side of vendor lock-in — at the megacorp level, anyway — is the “one throat to choke” principle; sure, it might be hard to migrate off AWS/Azure/IBM, but (a) your technology investments have a timespan measured in decade-long iterations; and (b) what you really want is to ensure reliable operations for your enterprise. Sure, you may be stuck with cloud vendor x for the next ten years, but at least you know who to scream at if the infra goes south — preferably someone who can mobilize enough engineers to get you back up and running right now. Having said that, if you’re a small company where cloud budgets are a significant portion of your overall spend, or a tech company that has a defensive need to be able to migrate providers, YM will definitely V.
- fnord123 7y ago
  There are loads of orgs trying to get off Oracle as we speak.
  - jessaustin 7y ago
    Lots of people were already trying ten years ago, and had wanted to try it twenty years ago!
    - dvtrn 7y ago
      Is "migrating from Oracle" the Enterprise equivalent of nuclear fusion? We're always 20 years away from production nuclear fusion, Enterprises are always a few quarters away from migrating out of Oracle %list_your_appliance_here%?
  - ravedave5 7y ago
    I'm the progress of doing that right now. It's sweet. So sweet.
- mc32 7y ago
  At the end of the day they need to increase revenue by adding customers or by increasing revenue per customer. Once the market is saturated they either buy competitors or they raise prices or try and sell you additional services...
mrep 7y ago
Don't forget you can play them against each other. Netflix and Snapchat both have contracts with AWS/GCP
NotAnEconomist 7y ago
I actually am a fan of the AWS CDK for this reason, and its concept of "constructs". My big application has a dozen packages, one of which defines generic cloud constructs that host and deploy the other packages as a distributed service. If we wanted to switch clouds, we'd just have to re-implement the constructs we use for a new cloud; generic things like "ingress data pipeline", which contain dozens of AWS resources each, but have a semantic grouping and defined permissions boundaries. But we'll burn that bridge when we come to it.
orf 7y ago
> give me a queue with FIFO and exactly once delivery https://bravenewgeek.com/you-cannot-have-exactly-once-delivery/ https://bravenewgeek.com/you-cannot-have-exactly-once-delive...
- scarface74 7y ago
  Done https://aws.amazon.com/about-aws/whats-new/2016/11/amazon-sqs-introduces-fifo-queues-with-exactly-once-processing-and-lower-prices-for-standard-queues/ https://aws.amazon.com/about-aws/whats-new/2016/11/amazon-sq...
  - dagenix 7y ago
    Well, not quite. What SQS actually offers is: exactly once delivery, except when the message is delivered multiple times. Quoting from the SQS docs [1]: > The visibility timeout begins when Amazon SQS returns a message. During this time, the consumer processes and deletes the message. However, if the consumer fails before deleting the message and your system doesn't call the DeleteMessage action for that message before the visibility timeout expires, the message becomes visible to other consumers and the message is received again. If a message must be received only once, your consumer should delete it within the duration of the visibility timeout. If a consumer receives a message and then loses its network connection to SQS, the visibility timeout will expire before it can delete the message and it will be delivered a second time to another consumer. I would very much suggest reading through the linked article by GP and maybe more about the Byzantine Generals Problem which establishes why exactly once delivery isn't just hard, but impossible. And Amazon's marketing department can't change that. [1] https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-visibility-timeout.html#configuring-visibility-timeout https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQS...
    - deleted 7y ago
      [deleted]
    - deleted 7y ago
      [deleted]

by 013a 7y ago

cosmodisk 7y ago

Vendor lock-in isn't something anyone, especially at C-level should be ignoring. Yes, there are things to be gained and money to be made,but one should always have some sort of alternative,just in case. I happen to be in a business,which 100% relies on one vendor,which keeps hiking up prices every year way above inflation.

HillRat 7y ago
The flip side of vendor lock-in — at the megacorp level, anyway — is the “one throat to choke” principle; sure, it might be hard to migrate off AWS/Azure/IBM, but (a) your technology investments have a timespan measured in decade-long iterations; and (b) what you really want is to ensure reliable operations for your enterprise. Sure, you may be stuck with cloud vendor x for the next ten years, but at least you know who to scream at if the infra goes south — preferably someone who can mobilize enough engineers to get you back up and running right now. Having said that, if you’re a small company where cloud budgets are a significant portion of your overall spend, or a tech company that has a defensive need to be able to migrate providers, YM will definitely V.
fnord123 7y ago
There are loads of orgs trying to get off Oracle as we speak.
- jessaustin 7y ago
  Lots of people were already trying ten years ago, and had wanted to try it twenty years ago!
  - dvtrn 7y ago
    Is "migrating from Oracle" the Enterprise equivalent of nuclear fusion? We're always 20 years away from production nuclear fusion, Enterprises are always a few quarters away from migrating out of Oracle %list_your_appliance_here%?
- ravedave5 7y ago
  I'm the progress of doing that right now. It's sweet. So sweet.
mc32 7y ago
At the end of the day they need to increase revenue by adding customers or by increasing revenue per customer. Once the market is saturated they either buy competitors or they raise prices or try and sell you additional services...

mrep 7y ago

Don't forget you can play them against each other. Netflix and Snapchat both have contracts with AWS/GCP

NotAnEconomist 7y ago

I actually am a fan of the AWS CDK for this reason, and its concept of "constructs". My big application has a dozen packages, one of which defines generic cloud constructs that host and deploy the other packages as a distributed service. If we wanted to switch clouds, we'd just have to re-implement the constructs we use for a new cloud; generic things like "ingress data pipeline", which contain dozens of AWS resources each, but have a semantic grouping and defined permissions boundaries. But we'll burn that bridge when we come to it.

orf 7y ago

> give me a queue with FIFO and exactly once delivery https://bravenewgeek.com/you-cannot-have-exactly-once-delivery/ https://bravenewgeek.com/you-cannot-have-exactly-once-delive...

scarface74 7y ago
Done https://aws.amazon.com/about-aws/whats-new/2016/11/amazon-sqs-introduces-fifo-queues-with-exactly-once-processing-and-lower-prices-for-standard-queues/ https://aws.amazon.com/about-aws/whats-new/2016/11/amazon-sq...
- dagenix 7y ago
  Well, not quite. What SQS actually offers is: exactly once delivery, except when the message is delivered multiple times. Quoting from the SQS docs [1]: > The visibility timeout begins when Amazon SQS returns a message. During this time, the consumer processes and deletes the message. However, if the consumer fails before deleting the message and your system doesn't call the DeleteMessage action for that message before the visibility timeout expires, the message becomes visible to other consumers and the message is received again. If a message must be received only once, your consumer should delete it within the duration of the visibility timeout. If a consumer receives a message and then loses its network connection to SQS, the visibility timeout will expire before it can delete the message and it will be delivered a second time to another consumer. I would very much suggest reading through the linked article by GP and maybe more about the Byzantine Generals Problem which establishes why exactly once delivery isn't just hard, but impossible. And Amazon's marketing department can't change that. [1] https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-visibility-timeout.html#configuring-visibility-timeout https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQS...
  - deleted 7y ago
    [deleted]
  - deleted 7y ago
    [deleted]