3 ms·

>the only managed services we use at all are the ones to deploy the basic network infrastructure and VMs. I don't know... that kind of sounds like a good idea

by catern 5y ago

>the only managed services we use at all are the ones to deploy the basic network infrastructure and VMs. I don't know... that kind of sounds like a good idea to me. Vendor lock-in is serious, and we don't need a 50-year DoD drip-feed going to whatever cloud vendor wins the contest today.

sirspacey 5y ago
Serious question - why not?
- rowanG077 5y ago
  Because it could become a serious issue once the gov starts challenging the big co at something. You most certainly don't want a situation where the government depends on the company it is fighting.
- ineedasername 5y ago
  Vendor lock-in makes switching if a better option comes along significantly more difficult. At the same time, the near-guarantee of the vendor that has the lock means they have far fewer incentives to be responsive to changing needs by the client. In addition, given the lock-in, whenever 3 or 5 years maintenance agreement contracts near their end, the Vendor has significant leverage to demand more $$$ for pretty much the same level of service. The overall result is a lower quality product that can eventually put the buyer years behind the current best-of-breed capabilities, all at a significantly higher cost.
- 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 ago
    I 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.
nonameiguess 5y ago
I don't actually disagree with that. My problem is in structuring these contract awards such that the only companies that can compete for them are those that offer a whole bunch of managed services, and then charge more for basic "turn on a VM" because of it, but then all we get to do is turn on a VM. If all we need is someone to host servers, award a contract to just host servers and be done with it. This is effectively what the NRO's AUE is. That was my wife's old program. But they're forcing everybody to leave that unless they can prove they need some kind of hardware Amazon doesn't provide and use the CIA's C2S instead, even if all you're ever going to use is VMs.
EricE 5y ago
Is vendor lock in really that significant, though? If it is to an organization I see that more as a management failing than a technology failing. An example of where I'm coming from: https://www.outsystems.com/blog/posts/vendor-lock-in/ https://www.outsystems.com/blog/posts/vendor-lock-in/ I think past vendor lock in wasn't so much about the technologies involved, but the inability of organizations to transform. If you have the right approach to application development/deployment/management there isn't a way any vendor can lock you in for any significant amount of time. I see more people wasting resources developing to avoid lock in when the applications they are developing won't live long enough to ever worry about having to move off of the systems they are developed on. I'm not saying we should never be concerned about vendor lock in, but I think the concerns need to be balanced against the costs (and complexity!) of engineering everything to be immune from "vendor lock in".

by catern 5y ago

sirspacey 5y ago

Serious question - why not?

rowanG077 5y ago
Because it could become a serious issue once the gov starts challenging the big co at something. You most certainly don't want a situation where the government depends on the company it is fighting.
ineedasername 5y ago
Vendor lock-in makes switching if a better option comes along significantly more difficult. At the same time, the near-guarantee of the vendor that has the lock means they have far fewer incentives to be responsive to changing needs by the client. In addition, given the lock-in, whenever 3 or 5 years maintenance agreement contracts near their end, the Vendor has significant leverage to demand more $$$ for pretty much the same level of service. The overall result is a lower quality product that can eventually put the buyer years behind the current best-of-breed capabilities, all at a significantly higher cost.
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 ago
  I 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.

nonameiguess 5y ago

I don't actually disagree with that. My problem is in structuring these contract awards such that the only companies that can compete for them are those that offer a whole bunch of managed services, and then charge more for basic "turn on a VM" because of it, but then all we get to do is turn on a VM. If all we need is someone to host servers, award a contract to just host servers and be done with it. This is effectively what the NRO's AUE is. That was my wife's old program. But they're forcing everybody to leave that unless they can prove they need some kind of hardware Amazon doesn't provide and use the CIA's C2S instead, even if all you're ever going to use is VMs.

EricE 5y ago

Is vendor lock in really that significant, though? If it is to an organization I see that more as a management failing than a technology failing. An example of where I'm coming from: https://www.outsystems.com/blog/posts/vendor-lock-in/ https://www.outsystems.com/blog/posts/vendor-lock-in/ I think past vendor lock in wasn't so much about the technologies involved, but the inability of organizations to transform. If you have the right approach to application development/deployment/management there isn't a way any vendor can lock you in for any significant amount of time. I see more people wasting resources developing to avoid lock in when the applications they are developing won't live long enough to ever worry about having to move off of the systems they are developed on. I'm not saying we should never be concerned about vendor lock in, but I think the concerns need to be balanced against the costs (and complexity!) of engineering everything to be immune from "vendor lock in".