Hacker News Reader

Comment by nonameiguess | Hacker News Reader

This whole thing is a joke. I don't think any of us working as DoD developers give much of a crap what cloud provider you force us to use. But just pick something, anything. Quit switching the ground out from underneath us every couple years. The present state being the way it is, we're forced to be provider-agnostic to effectively everything, which means we need to stand up our own self-hosted services down to running our own Kubernetes engines and deploying our own NFS servers and database servers, and the only managed services we use at all are the ones to deploy the basic network infrastructure and VMs.

Linode can give us servers for probably 1/10th the cost of AWS or Azure if you're not going to actually let us use any managed services.

And people want to know why all defense projects are constantly behind schedule and over budget.

View on HN

>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.

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.

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/

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".

Serious question - why not?

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.

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.

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.

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.

>I don't think any of us working as DoD developers give much of a crap what cloud provider you force us to use

The fundamental problem is that you aren't the one choosing or buying these services. The "people who give a crap" is some mix of political and industrial people with a very light sprinkling of high level program management which are driving the requirements.

So it has nothing - literally nothing - to do with what you as the actual person who is doing the work, want or need to be effective.

This is how the government acquisitions process is written into law unfortunately and I've pushed hard within the government to change that in the past (to some very limited success).

Yes. Unfortunately, I'm way too aware of this problem. As far as I'm concerned, it's the biggest problem facing government acquisitions, the fact that any provider's "customer" is always an acquisition office and not its actual users. It's even worse for IC enterprise services, because only your acquisition office has any say in what you prioritize for work and they're the only group of people in the government you're authorized to talk to, but then when you release something, any one of potentially hundreds of external stakeholders can all veto you from going into ops, but you can't solicit their feedback during development.

The purchaser / decision maker is not the user / practitioner dichotomy exists to a lesser extent in private commercial sector. It’s part of the problems of enterprise software in general

Agreed. Kubernetes is eating the cloud and those big cloud providers should be scared. The future of these cloud platform providers is as a utility for virtualised hardware, storage and networking, firewall - and that’s about it. The software layer belongs in the kube.

Amazon, MS, and GCP all have managed Kubernetes services so these two things are not mutually exclusive.

Yes, and some of those are paid services. Why?

Companies like to pay for bills, and not pay for own responsibility of own staff.

Is it? Seems like it's eating the sunset of services that allow you to scale containers. But I don't see it eating any of the big services that cloud providers like aws care about. Like managed databases, queuing services (sqs), messaging services (ses), etc.

It is. Those can deployed quite easily on k8s these days. Persistence is not trivial, but can be done. Admittedly, at this point I wouldn’t put my databases in k8s, but keep an eye on this space as it’s becoming easier.

If your db is already replicated (cockroachdb, tidb, foundation,etc) running it in k8s is a breeze and can be considerably cheaper and more reliable than managed stuff

Rook Ceph.

I mean that too but you’re probably not running it in cloud so not everyone can take advantage here

We are. Running EC2/EBS.

They don’t have to be scared, there are tons of corporations that can’t manage any kind of infrastructure effectively and are begging to get to the public cloud.

True now, 5-10 years time though? When they finally get to the cloud and realise the costs, they will look at opportunities to reduce their bills.

I anticipate many “we have to get off the cloud” projects in the future for sure, but I think it’s clear that the demand for “public cloud” has not been met by a long shot. There is much more room for the market cap of public cloud to grow.

As a former DoD contractor, you have my deepest sympathies.

> I don't think any of us working as DoD developers give much of a crap what cloud provider you force us to use.

I thought AWS's Security & Compliance features[1] was the reason why it was selected before for such purposes. Do any of the low-cost alternatives offer similar security and compliance levels?

[1] https://docs.aws.amazon.com/whitepapers/latest/aws-overview/...

Honestly, I don't know. Raytheon stood up a very simple cloud platform for the RROC to run on based on Open Stack, and still provides the AUE, which is just bare metal and VMs and no managed services. But it's hard to say if they're cheaper because the charging model is so different. Application providers need to order their equipment, but get someone else to install it and run it for them.

Reply on news.ycombinator.com