4 ms·
Vendor lock-in gives a lot of leverage to the vendor. Migrating away from vendor lock-in after years of development over their platform is a major project (been
by piva00 5y ago
Vendor lock-in gives a lot of leverage to the vendor. Migrating away from vendor lock-in after years of development over their platform is a major project (been there, done that, twice).
Using standardised primitives, like the case with Kubernetes, leaves your infrastructure prepared to be migrated to a different cloud provider with much less friction and effort. You will still probably need some shims and/or abstractions for common patterns (caching, persistence, etc.) but if you can decouple completely your platform from the vendor's platform your organisation gets much more leverage, both for negotiation purposes as for regulations, in case there is a need to swap cloud providers your work is more-or-less cut out for you. When you didn't prepare for a cloud agnostic environment you will have years of migration to be done, for services, libraries and so on.
It's a major pain in the ass to be vendor locked-in and a huge cost, in time, opportunities and money.
- nonameiguess 5y agoI should mention that, while I said above I agree about trying to avoid vendor lock-in as much as possible, there is additional consideration when talking about government projects and especially classified projects. Even if your software and infrastruture setup is as vendor-agnostic as you can possibly be, you can only ever possibly migrate to another provider that actually has data centers certified to host classified data and connect to a classified network. Building that data center is at least as much of a bottleneck to a government agency trying to change cloud providers as the actual software migration is.