4 ms·

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 somethi

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.

AndrewKemendo 5y ago
>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).
- devonkim 5y ago
  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
- nonameiguess 5y ago
  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.
paulddraper 5y ago
As a former DoD contractor, you have my deepest sympathies.
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.
bottled_poe 5y ago
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.
- jjeaff 5y ago
  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.
  - bottled_poe 5y ago
    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.
    - dilyevsky 5y ago
      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
      - coopreme 5y ago
        Rook Ceph.
        dilyevsky 5y ago
        I mean that too but you’re probably not running it in cloud so not everyone can take advantage here
        5y ago
audit 5y ago
It seems that the more money are at stake, the more conniving manipulation (propaganda, 'legal moves') will take place. There has to be a 'behavior law' summarized by somebody, capturing this phenomena. You are right, Creating a 'technical' solution to this kind of problem -- is not going to work, unfortunately.
deleted 5y ago
[deleted]
Abishek_Muthian 5y ago
> 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/security-and-compliance.html https://docs.aws.amazon.com/whitepapers/latest/aws-overview/...
- nonameiguess 5y ago
  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.

AndrewKemendo 5y ago

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

devonkim 5y ago
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
nonameiguess 5y ago
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.

paulddraper 5y ago

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

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.

bottled_poe 5y ago

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.

jjeaff 5y ago
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.
- bottled_poe 5y ago
  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.
  - dilyevsky 5y ago
    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
    - coopreme 5y ago
      Rook Ceph.
      - dilyevsky 5y ago
        I mean that too but you’re probably not running it in cloud so not everyone can take advantage here
        5y ago

audit 5y ago

It seems that the more money are at stake, the more conniving manipulation (propaganda, 'legal moves') will take place. There has to be a 'behavior law' summarized by somebody, capturing this phenomena. You are right, Creating a 'technical' solution to this kind of problem -- is not going to work, unfortunately.

deleted 5y ago

[deleted]

Abishek_Muthian 5y ago

> 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/security-and-compliance.html https://docs.aws.amazon.com/whitepapers/latest/aws-overview/...

nonameiguess 5y ago
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.