In my opinion, being cloud-agnostic is today’s being database-agnostic.
In more than two decades of professional software development, I have only once encountered a situation where an existing application was migrated to a different RDBMS instead of just being rewritten. Using an ORM framework for the sake of database independence seems hardly justified in that case.
I suppose that things will turn out much the same with cloud agnosticism.
Similar to the RDBMS case, being agnostic of the underlying technology prevents you from using that technology’s more interesting features, to the extent that you’re treating a database as a dumb data store or cloud hosting as a mere space for hosting your files.
I mostly agree with you but we definitely reduced reliance on AWS specific functionality after starting to offer on-premise software installations. Most of them don’t gain you THAT much and then the software really isn’t very portable.
I question this logic - there seem to be fundamental differences in even the basic services between various cloud providers. For example you can resize a compute-attached disk size live in GCP while you can't in AWS. Many intricacies like this are annoying, but at the same time advantageous if you know and use them. If you are primarily trying to just offer another layer on top of these cloud services, (like snowflake) where cross-cloud compatibility is part of your selling point, then it makes sense to abstract the cloud layer. Otherwise, I feel like it's better to choose a reliable vendor and stick to them, optimizing according to their strengths/weaknesses. Or go cross cloud but for very specific technologies (iirc BuzzFeed did this).
Not the person you are replying too but some industries have regulatory mandates for vendor diversity in cases like this.
In addition, when your bills get to millions per month, the provider supplies quite a bit of TAMs and technical resources to your account. This can be helpful, but they also get a good understanding of where you are and are not in a position to dip out if things get sideways in billing. (Also, other providers will throw 6-7 figure credits your way to earn your business, being in a position to leverage them is a good thing.)
>Many intricacies like this are annoying, but at the same time advantageous if you know and use them.
This is very true. Building services or features that depend upon these is a good idea. Enshrining them deep within your assumptions and requirements about how you operate cloud-based workloads can work against you.
When your build gets to be “millions per month”, you are already locked in. Any migrations is going to be a painful multi year progress. “Infrastructure has weight”.
Have you been part of an integration with a health care system? They are so tightly locked in to their existing EMR/EHR system it would make you cry. Every third party vendor that comes along has to integrate with it.
Part of the work I did at the company that I mentioned where I was a dev lead involved migrating our company from Workday. Their entire process was integrated into it.
You're definitely locked in at some level, but if you are able and even demonstrate the ability to swing 30% of your workload over to another provider in a quarter, you're going to maintain some leverage.
Yes, have worked in healthcare on and off over the past 20 years and know precisely of what you speak. That's a different situation IMHO, same with ERP/HR/etc.
You can create/resize/delete non-root EBS volumes without any downtime of the attached host(s), as far as I'm aware? Pretty sure I've done so in the past. You'll have to resize2fs or whatever but it shouldn't take any downtime.
EBS “appears to be local” but it is actually networked attached storage. Instance storage (is that the correct name?) is where the VM and the storage are on the same physical server and it should be faster.
In more than two decades of professional software development, I have only once encountered a situation where an existing application was migrated to a different RDBMS instead of just being rewritten. Using an ORM framework for the sake of database independence seems hardly justified in that case.
I suppose that things will turn out much the same with cloud agnosticism.
Similar to the RDBMS case, being agnostic of the underlying technology prevents you from using that technology’s more interesting features, to the extent that you’re treating a database as a dumb data store or cloud hosting as a mere space for hosting your files.