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.
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.
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.
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.
[ec2-user@ip-1-1-1-1 ~]$ sudo fdisk -l
Disk /dev/xvda: 8 GiB, 8589934592 bytes, 16777216 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: 0D7E094F-1C63-43F2-AC82-3316E992075B
Device Start End Sectors Size Type
/dev/xvda1 4096 16777182 16773087 8G Linux filesystem
/dev/xvda128 2048 4095 2048 1M BIOS boot
Partition table entries are not in disk order.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.
Imagine my disappointment when I learned that no actually, Terraform will need to know which type of EC2 instance you want, you need to configure an AWS load balancer, not just "a load balancer".
Terraform does NOTHING to help you move between cloud platforms aside from providing a language that will work across providers. You still need to understand how everything ties together and is configured in each platform, now you just can use the examples in the documentation or the newest features.
Instead, it allows you to use the same tool and management model for resources on any of the 3 big cloud providers, about a 100 assorted SaaS providers, and most importantly, wire them together (e.g. create a Mailgun configuration, and set up its verification DNS records on AWS), all in code, and in the same workflow.
Even the almighty Terraform which for some reason people still think makes it easy not to experience “cloud lock-in” has cloud specific provisioners.