4 ms·

I think "lock-in" is a terrible term. You can avoid all lock-in by ignoring all sorts of proprietary features of any vendor, and leave ENDLESS benefits and opt

I think "lock-in" is a terrible term. You can avoid all lock-in by ignoring all sorts of proprietary features of any vendor, and leave ENDLESS benefits and optimizations on the table for the hypothetical likelyhood that you might one day have to "free yourself". Conversely, if you embrace those things wholeheartedly, and at some point find yourself wanting to break the relationship and do a full egress migration, even if your costs end up monumental, I would bet anything that over the time you were "locked in" you will have gained more from that cloud than whatever "one-time migration costs" you have to pay. If your core business proposition is literally something like storage (e.g. Dropbox) where with time you will want to vertically integrate your whole technology stack rather than relying on a 3rd party, yeah avoid lock-in. If you have a frivolous C-suite that will want to change cloud providers every 24 months depending on what discount they can negotiate on the golf course, yeah avoid lock-in. Everyone else? Throw that word out from your vocabulary, and embrace the idiomatic capabilities of your cloud vendor.

oneplane 5y ago
I'd expand on that a little: 'lock-in' is not always what people think it is. Having all your 'stuff' in a binary database of an unknown format that only the vendor can read/write would be a lock-in, or if it's a known format but you don't have access to it. If you have access to all the details of your systems you can always 'go elsewhere' but it becomes a matter of cost, knowledge and time. The balance is how much you want to spend on those, and what it gives you in return. As an anecdote: I and the teams I manage avoid CDKs like the plague, they end up a version of IaC self-lock-in that makes it nearly impossible to integrate between vendors. Using tools like Terraform or perhaps Ansible or SaltStack (or Idem) still means you write your abstractions against a specific provider, but the code and data formats are standard enough that you can retain and re-use your knowledge and skills and depending on how much layering you apply you can reasonably easily migrate wherever you want to (from an infra perspective). Contents (unique data, that is) are always a different issue, even with full access you'll be thinking about egress cost. All of those issues are of course mostly annoying at scale, but that's also one of the reasons you'd go to AWS: for scaling options.

oneplane 5y ago

I'd expand on that a little: 'lock-in' is not always what people think it is. Having all your 'stuff' in a binary database of an unknown format that only the vendor can read/write would be a lock-in, or if it's a known format but you don't have access to it. If you have access to all the details of your systems you can always 'go elsewhere' but it becomes a matter of cost, knowledge and time. The balance is how much you want to spend on those, and what it gives you in return. As an anecdote: I and the teams I manage avoid CDKs like the plague, they end up a version of IaC self-lock-in that makes it nearly impossible to integrate between vendors. Using tools like Terraform or perhaps Ansible or SaltStack (or Idem) still means you write your abstractions against a specific provider, but the code and data formats are standard enough that you can retain and re-use your knowledge and skills and depending on how much layering you apply you can reasonably easily migrate wherever you want to (from an infra perspective). Contents (unique data, that is) are always a different issue, even with full access you'll be thinking about egress cost. All of those issues are of course mostly annoying at scale, but that's also one of the reasons you'd go to AWS: for scaling options.