> 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

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