3 ms·

> 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

> 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.
- pritambaral 5y ago
  > It seems that you are wrong at every turn. At this point, I don't know what you're talking about. My point has been simple — and correct — from the beginning: AWS promotes vendor lock-in by making network egress obscenely costly. > This scenario where we migrated clouds ... That's your scenario, not mine. I did not make this thread about migration, you did. I did not follow you down your strawman path, but you seem to be believe I have. > ... we don't migrate using network egress anyway, we migrate using physical bulk exports/imports using trucks Good for you, I guess. Doesn't serve my purpose. Also, still on the wrong track about one-time, total migration. > The article is also not about migration egress but about operational egress. You almost came back on to the right track here, but quickly jumped back to you strawman path. > Maybe you could come up with some real-world examples where your point was a reality, because I'm not seeing it You're ignoring use-cases that aren't similar to ones you've had before, largely because you keep trying to see everyone else's needs through your "terminology" and comparing them to your "scenarios". Here's a real-world use-case #1: 1. I started building an industrial-IoT analytics product for a client when it wasn't clear which cloud (private or public) they were going to run it on. Think lots of data, and lots of ad-hoc compute for the analysis. 2. I built it in a cloud-agnostic way, with all cloud-provider interaction safely nestled away behind a common API. It also had first-class live data replication across deployments. (If you're wondering, this kept most of the "migration CAPEX" down, in case the client wanted to move workloads after deployment.) 3. The client initially deployed it on AWS. 4. Later, the client's physical DC (closer to HQ) was upgraded and became capable of running our stack with nearly no changes. 5. Eventually, the client wanted to run some workloads in their physical DC. Some, mind you, not all. 6. Even including the cost of running their DC, it'd have been cheaper to run some compute workloads in it than on EC2. It seemed like it made perfect business sense to go through with it. Until network egress costs of the data were calculated. 7. Snowmobile was more expensive than biting the bullet and paying the egress tax. Not that it'd have mattered anyway, because ... 8. Snowball didn't exist, but even if it did, repeated usage to keep moving deltas of updated data was too operationally onerous. 9. They owned the data. They were willing to pay the price of a normal data transfer. Had they deployed to their DC first, the situation would have been so much better. They'd have to pay egress costs to their DC's ISP, and they'd still be saving money on splitting workloads across AWS and DC. ---- Real-world use-case #2: 1. While building the above, I gave every developer on my team a dedicated environment to work on, with a beefy shared server in our office; all this for low-latency dev work. 2. To mimic production scale and behaviours as closely as possible, I set-up a live sync of (anonymized) production data (back when it was small) to our dev environments. 3. Going from beta (~ 100-1000 devices) to GA (>70k devices) necessitated cutting off the umbilical cord, because our calculations showed the cost would be ridiculous. ---- Real-world use-case #3: Same client as above. Wanted to keep their devices' data around for seven years, for auditing purposes. Didn't know if they'd still be on AWS in seven years. It appeared ending the contract would've been costlier than just paying for another year, because they weren't large enough to justify the expense of Snowmobile and Snowball didn't exist back then. ---- You see, AWS knows that if you can get your data out, you can get your compute out too. Of the two things keeping compute on any platform — data and code (including platform features like IAM) — only one is sticky. Other vendors can catch up on the code front, but if a customer even thinks about a partial migration, they'd see that the costs can get high enough that they might as well go for a complete migration, which is a significantly higher expense and much harder to justify.

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.

pritambaral 5y ago
> It seems that you are wrong at every turn. At this point, I don't know what you're talking about. My point has been simple — and correct — from the beginning: AWS promotes vendor lock-in by making network egress obscenely costly. > This scenario where we migrated clouds ... That's your scenario, not mine. I did not make this thread about migration, you did. I did not follow you down your strawman path, but you seem to be believe I have. > ... we don't migrate using network egress anyway, we migrate using physical bulk exports/imports using trucks Good for you, I guess. Doesn't serve my purpose. Also, still on the wrong track about one-time, total migration. > The article is also not about migration egress but about operational egress. You almost came back on to the right track here, but quickly jumped back to you strawman path. > Maybe you could come up with some real-world examples where your point was a reality, because I'm not seeing it You're ignoring use-cases that aren't similar to ones you've had before, largely because you keep trying to see everyone else's needs through your "terminology" and comparing them to your "scenarios". Here's a real-world use-case #1: 1. I started building an industrial-IoT analytics product for a client when it wasn't clear which cloud (private or public) they were going to run it on. Think lots of data, and lots of ad-hoc compute for the analysis. 2. I built it in a cloud-agnostic way, with all cloud-provider interaction safely nestled away behind a common API. It also had first-class live data replication across deployments. (If you're wondering, this kept most of the "migration CAPEX" down, in case the client wanted to move workloads after deployment.) 3. The client initially deployed it on AWS. 4. Later, the client's physical DC (closer to HQ) was upgraded and became capable of running our stack with nearly no changes. 5. Eventually, the client wanted to run some workloads in their physical DC. Some, mind you, not all. 6. Even including the cost of running their DC, it'd have been cheaper to run some compute workloads in it than on EC2. It seemed like it made perfect business sense to go through with it. Until network egress costs of the data were calculated. 7. Snowmobile was more expensive than biting the bullet and paying the egress tax. Not that it'd have mattered anyway, because ... 8. Snowball didn't exist, but even if it did, repeated usage to keep moving deltas of updated data was too operationally onerous. 9. They owned the data. They were willing to pay the price of a normal data transfer. Had they deployed to their DC first, the situation would have been so much better. They'd have to pay egress costs to their DC's ISP, and they'd still be saving money on splitting workloads across AWS and DC. ---- Real-world use-case #2: 1. While building the above, I gave every developer on my team a dedicated environment to work on, with a beefy shared server in our office; all this for low-latency dev work. 2. To mimic production scale and behaviours as closely as possible, I set-up a live sync of (anonymized) production data (back when it was small) to our dev environments. 3. Going from beta (~ 100-1000 devices) to GA (>70k devices) necessitated cutting off the umbilical cord, because our calculations showed the cost would be ridiculous. ---- Real-world use-case #3: Same client as above. Wanted to keep their devices' data around for seven years, for auditing purposes. Didn't know if they'd still be on AWS in seven years. It appeared ending the contract would've been costlier than just paying for another year, because they weren't large enough to justify the expense of Snowmobile and Snowball didn't exist back then. ---- You see, AWS knows that if you can get your data out, you can get your compute out too. Of the two things keeping compute on any platform — data and code (including platform features like IAM) — only one is sticky. Other vendors can catch up on the code front, but if a customer even thinks about a partial migration, they'd see that the costs can get high enough that they might as well go for a complete migration, which is a significantly higher expense and much harder to justify.