5 ms·

> Words have meanings, and have existed for a long time. Their meaning is well understood at exec, management and engineering levels and don't need to be redefi

> Words have meanings, and have existed for a long time. Their meaning is well understood at exec, management and engineering levels and don't need to be redefined. The world progresses. Language evolves (yes, even legal language, often understood to move glacially). But I'm not redefining anything here. "Vendor lock-in" is well understood at exec, management, and engineering levels and doesn't need to be artificially restricted to your limited reading of it. > I am writing about the ability to use a different vendor. The word "ability" also has meaning. It does not mean "absolute ability". E.g., Nearly every human has the "ability" to fly, through the modern technology of airplanes and the commonly provided services of airlines; but those (say, in countries like mine) who cannot afford a flight ticket are said to not have the ability to fly. > Not about runtime cost or integration. > Known runtime cost is part of normal OPEX. Migrating off of one vendor is not "runtime cost" or "normal OPEX". By making it more expensive to migrate away, a vendor raises OPEX costs of such an "abnormal" move. Such weaponisation of OPEX costs is made to price-out the option, and is absolutely a denial of ability for business who cannot afford or justify such high abnormal OPEX costs. ---- > Having to reverse engineer something because your MRI vendor won't give you the specs to write drivers for the 64-bit PCI-X acquisition card is vendor lock-in. If you need more examples, just ask around in any organisation of reasonable size. Look, no one is taking away your use-cases of the term "vendor lock-in". No one is disagreeing with you that those examples you cite absolutely are "vendor lock-in". But those are not the only cases or methods of it. While intentional incompatibility is a far too common method of creating vendor lock-in, it is not the only method. For example, vaporware by dominant vendors used to deny market access to competitors is an accepted form of vendor lock-in. > If you want to change the meaning of what vendor lock-in means (it already has a definition, which I have written down a few times for your ease of not having to look it up yourself) I'm not trying to do any such thing. I have seen your "definition" and explained to you how the AWS egress tax is a means for promoting vendor lock-in, _within your definition_ of it. > Just for the sake of completeness, here is a random paper that explains it in extra detail I have read your "random paper"; it is a document explaining some history of economic literature. It does not define "vendor lock-in" (itself being careful to often use the phrase "lock-in" in scare quotes), but restricts itself to describing "lock-in by historical events". What it does define, though, is _path dependence_. And what does it define it as? "... a minor or fleeting advantage or a seemingly inconsequential lead for some technology, product or standard can have important and irreversible influences on the ultimate market allocation of resources ..."; or, simply put, "sensitive dependence on initial conditions." ---- > If an explanation, reference or paper isn't good enough for you, why bother posting at all? If an explanation, reference, or paper isn't even pertinent to the topic, and doesn't illustrate your point, why bother posting it at all?

oneplane 5y ago
Nothing in your world salad has anything to do with lock-in; you first describe network egress cost (which is OPEX) and then you describe it as lock-in, which it isn't (migrations are CAPEX). Make up your mind before you try again.
- pritambaral 5y ago
  > Nothing in your world salad ... I see that you don't like others contributing to your salads. My bad. > network egress cost (which is OPEX) ... (migrations are CAPEX). Make up your mind before you try again. You're the one pushing the agenda here that migration cost off of AWS is a "known" network cost, and thus OPEX, and thus missing the point. I don't care how you pencil down the money; the point is that migration costs are often NOT a "known ongoing network cost" at the beginning of service, and have been artificially inflated. I should've seen the signals before venturing this far down this thread, trying to engage with you, but this drives the nail in the coffin. I no longer believe you're engaging in honest discourse; or worse, that you don't actually understand the business terms you're talking about. ---- From your other comments, you appear like you're an AWS apologist; or at the very least, that your business depends on people using AWS. I have a strong feeling I should have listened to Upton Sinclair's advice about getting someone to understand something, but it's not too late for me yet. Good day to you.
  - oneplane 5y ago
    It seems that you are wrong at every turn. This scenario where we migrated clouds has been pretty similar between IBM, Oracle, Azure, GCP and also AWS. Most businesses we're migrating (from/to arbitrary clouds) are using 2 of them, some more, and every time network egress cost is just a small factor in the CAPEX for the one-time migration during a vendor switch. While vendor switching has generally just been for arbitrary reasons, vendor lock-in was never a parameter conjoined with network egress costs. Besides, we don't migrate using network egress anyway, we migrate using physical bulk exports/imports using trucks and only do a small delta update afterwards. Even if in theory network egress was so expensive that people can't pay for migration anymore, you wouldn't be migrating that way anyway making the whole concept moot. The article is also not about migration egress but about operational egress. Example: for small migrations we order an IBM Cloud Mass Data Migration device and an Azure Data Box, transfer between boxes, wipe the IBM box, send both back to their vendors, then do a delta transfer of the remaining updates. Other Example: For acquisitions where we can't retain IAM between AWS accounts, order a snowball or snowmobile between them, all your RDS and bucket data goes from A to B in a matter of days. Not weeks or months over some slow 10Gbit link. Maybe you could come up with some real-world examples where your point was a reality, because I'm not seeing it, the terminology doesn't match, and none of the scenarios from small to large have seen egress OPEX as a migration CAPEX issue. We've been running successful migrations with no vendor lock-in woes between clouds for over a decade, egress and transfer costs has been a very small fraction of the whole operation, and never has been an ongoing pain point during post-migration usage. And none of this is AWS-specific, except the egress cost element the article linked here in HN. But hey, you do you.

oneplane 5y ago

Nothing in your world salad has anything to do with lock-in; you first describe network egress cost (which is OPEX) and then you describe it as lock-in, which it isn't (migrations are CAPEX). Make up your mind before you try again.

pritambaral 5y ago
> Nothing in your world salad ... I see that you don't like others contributing to your salads. My bad. > network egress cost (which is OPEX) ... (migrations are CAPEX). Make up your mind before you try again. You're the one pushing the agenda here that migration cost off of AWS is a "known" network cost, and thus OPEX, and thus missing the point. I don't care how you pencil down the money; the point is that migration costs are often NOT a "known ongoing network cost" at the beginning of service, and have been artificially inflated. I should've seen the signals before venturing this far down this thread, trying to engage with you, but this drives the nail in the coffin. I no longer believe you're engaging in honest discourse; or worse, that you don't actually understand the business terms you're talking about. ---- From your other comments, you appear like you're an AWS apologist; or at the very least, that your business depends on people using AWS. I have a strong feeling I should have listened to Upton Sinclair's advice about getting someone to understand something, but it's not too late for me yet. Good day to you.
- oneplane 5y ago
  It seems that you are wrong at every turn. This scenario where we migrated clouds has been pretty similar between IBM, Oracle, Azure, GCP and also AWS. Most businesses we're migrating (from/to arbitrary clouds) are using 2 of them, some more, and every time network egress cost is just a small factor in the CAPEX for the one-time migration during a vendor switch. While vendor switching has generally just been for arbitrary reasons, vendor lock-in was never a parameter conjoined with network egress costs. Besides, we don't migrate using network egress anyway, we migrate using physical bulk exports/imports using trucks and only do a small delta update afterwards. Even if in theory network egress was so expensive that people can't pay for migration anymore, you wouldn't be migrating that way anyway making the whole concept moot. The article is also not about migration egress but about operational egress. Example: for small migrations we order an IBM Cloud Mass Data Migration device and an Azure Data Box, transfer between boxes, wipe the IBM box, send both back to their vendors, then do a delta transfer of the remaining updates. Other Example: For acquisitions where we can't retain IAM between AWS accounts, order a snowball or snowmobile between them, all your RDS and bucket data goes from A to B in a matter of days. Not weeks or months over some slow 10Gbit link. Maybe you could come up with some real-world examples where your point was a reality, because I'm not seeing it, the terminology doesn't match, and none of the scenarios from small to large have seen egress OPEX as a migration CAPEX issue. We've been running successful migrations with no vendor lock-in woes between clouds for over a decade, egress and transfer costs has been a very small fraction of the whole operation, and never has been an ongoing pain point during post-migration usage. And none of this is AWS-specific, except the egress cost element the article linked here in HN. But hey, you do you.