|
I sympathize with what you're trying to do, but I'm not convinced by this approach. You're either fully, 100%, completely radically anti-vendor-lock-in, or you're fooling yourself. Either you're doing stuff like: * You're running your own databases. You use Multy to bring up raw virtual machines, you install e.g. PostgreSQL on it, and you do all the DBA work yourself.
* You're running your own DNS infrastructure within the VPC, so that you're not reliant on the VPC's provided DNS.
* You're running your own network edge. You use Multy to bring up a raw virtual machine with a public IP, you install e.g. Caddy on it, and you set up the proxy yourself. Or you end up writing code that implicitly takes advantage of stuff like AWS RDS's IAM authentication, or DNS at 10.0.0.2 pointing to i-0123456789abcdef.us-west-2.compute.internal, or AWS Time Sync Service, or using AWS load balancers, with AWS-issued TLS certificates, etc. The simple truth is, there isn't a startup on the planet that delivers additional value to customers by mucking around with anti-vendor-lock-in measures. Period (and if you really think you have a counter-example, I'm VERY curious to hear about it). And by the time you've grown to the size where cloud vendor lock-in matters (because of cost vs. deploying your own on-premise infrastructure), basically, it's too late, and your migration project is going to be rather expensive. And Multy doesn't help you migrate to on-premise infrastructure, because it only abstracts the various cloud providers! So you're in for a massive migration project either way. |