Comment by GuB-42
11 hours ago
While it is a "massive endeavor", it is not impossible, it essentially amounts to writing portable code. A computer is a computer, and most of the tech stack in US cloud providers is based on open source projects.
Not depending on Chinese manufacturing is borderline impossible even if you are starting from scratch. Not only it will be way more expensive, with potentially longer delays and lesser capacities, but just finding some company that can and wants to do the job can be a nightmare. From what I have seen, many local manufacturers in the US and Europe are really there to fulfill government contracts that requires local production.
Most hardware kickstarter-like projects rely on Chinese manufacturing as if it was obvious. It is not "find a manufacturer", it is "go to China". Projects that instead rely on local (US/Europe) manufacturing in order to make a political statement have to to though a lot of trouble, and the result is often an overpriced product that may still have some parts made in China.
Anyone who thinks migrations at scale is just about “writing portable code” has never done a migration at scale.
A large corporation just migrating from everything hosted on VMs can take years.
And if you are responsible for an ETL implementation and working with AWS and have your files stored on S3 (every provider big and small has S3 compatible storage) and your data is hosted on Aurora Postgres, are you going to spend time creating a complicated ETL process or are you going to just schedule a cron job to run “select outfile into S3”?
And “most” of the services on AWS aren’t based on open source software and you still have to provision your resources using IAC and your architecture. No Terraform doesn’t give you “cloud agnosticism” any more than using Python when using AWS services.
I don't think anyone here is arguing that. Just that you can make things less painful with portable code. It still won't be easy, as everybody in this chain agrees with. But we don't put things that need to be done off because it's "difficult".
If it takes a year and half to migrate from plain old VMs to AWS as the first part of “lift shift and modernize” and you have to to do it in “waves” how much difference is the code going to make?
Are you going to tell your developers to spend weeks writing ETL code that could literally be done in an hour using SQL extensions to AWS?
Are you going to tell them not to use any AWS native services? What are you going to do about your infrastructure as code? Are you going to tell them to set up a VM to host a simple cron job instead of just using a Lambda + Event Bridge?
And what business value does this theoretical “cloud agnosticism” bring - that never is once you get to scale.
It took Amazon years to move off of Oracle and much of its infrastructure still doesn’t run on AWS and still uses its older infrastructure (CDO? It’s been a while and I was on the AWS side)
I have yet to hear anyone who worries about cloud agnosticism even think about the complexity of migrations bring at scale, the risk of regressions, etc.
While I personally stay the hell away from lift and shifts and I come in at the “modernization” phase, it’s because I know the complexity and drudgery of it. I worked at AWS ProServe for 3.5 years and I now work as a staff consultant at a 3rd party consulting company.
This isn’t me rah rahing about AWS. I would say the same about GCP, Azure, the choice of database you use, or any other infrastructure decision.