Live data from Hacker News

Cloud.gov

cloud.gov

41–50 of 59 posts

Re: Cloud.gov

#41

Earlier quoted context omitted.

So we need BaaS? Bureaucracy as a service?

I’m sure AI in charge of organizing a process can build forms and reach BAAS naturally. What I wonder is, to output a mess process, would it be faster than actual government services, or do govt services effectively act as brownian agents?

Will AI BaaS work for the system or the bureaucracy itself as human systems do?

Re: Cloud.gov

#42

Considering this is only for FedRAMP Low/Medium, I'm not sure why any contractor or agency would pick this over AWS GovCloud, where finding people already familiar with the platform is easy.

I haven't used AWS's version, but the gov version of Azure is terrible. Missing so many features and limited in so many ways and there are so many "gotchas". And no matter how many times you tell a vendor that's what you have they won't admit their product isn't compatible until the second or third time they try to implement.

I worked on government projects at Azure for years. Their US Government cloud is a second-class citizen. Getting the average engineer to care about problems with their their offerings in government clouds relative to the commercial cloud is like pulling teeth.

Re: Cloud.gov

#43
While Cloud.gov had great fanfare years ago when introduced. Underneath it’s just Pivotal/CloudFoundry buildpacks and standardized security assurances. It’s exorbitantly costly for lower scale projects. Most three-letter agencies have their own security review processes on top of these assurances anyway. So the time-savings expected are quickly diminished.

Someone could do very well for our governments’ efficiency to STOP the redundant overhead in security controls currently. Preventing security teams becoming a gatekeeping police department and staffing/hiring with those more inclined to automate (SecOps) rather than to interpret policy inconsistently would be excellent.

Re: Cloud.gov

#44
post #39

Cloud.gov was really promising when it was announced years ago, but in practice there ended up being so many differing security requirements and security boundary tensions between them and purported customers of them that they didn’t end up having any real impact because while some could use them, many could not, and those who could often found it easier to just not use them. There were also issues getting needed per…

The issue is the business processes the government uses to contract, and purchase products and services as well as the processes for moving money between different agencies and departments are horrendous and involve a lot of people. This is true wether the value involved is $1 or $1 million. If any of the people involved is incompetent or decides they aren’t going to do their part in a timely fashion you are screwed.…

This is an interesting hypothesis and I’ll take it to mean that among all the things that need to be solved, the business process is the biggest one. Because clearly there are many problems that need to be solved.

But I think the hypothesis fails a bit on its face. Setting aside the question of whether an agency has money of the correct color to spend on something like Cloud.gov, interagency acquisitions are a fairly well-trodden path. It’s a very regular thing for an agency to purchase goods from another agency, and while software purchases still have wrinkles, it’s generally been done and can be done. Not always super easy, but easier than you seem to be implying. This goes for interagency transfers of money as well, but that’s really its own thing. It requires willingness from both parties.

Still needs to be made easier, but I would still argue that the personal liability that attaches to an agency official that comes with accepting the risk of a security breach or other information loss is the biggest blockage to change. Put more plainly, would you risk your personal interests that Cloud.gov is secure enough for you to deploy your agency’s application to? Most people would not take this risk, which is in my estimation the biggest reason among many you only see small, public projects like EPA’s AirNow tracker on cloud.gov and nothing more sensitive or closer to an agency’s core mission deployed there.

My understanding last I heard, which was a while ago, is that Cloud.gov team is scrambling to get new clients because that’s largely how it pays for or supports itself. I expect it will be deprecated eventually and that will regrettably chill any future initiatives like this.

Re: Cloud.gov

#45
post #24

Earlier quoted context omitted.

It still is AWS. The AWS GovCloud partition to me more precise. https://cloud.gov/docs/technology/iaas/

I'll have to look closer, if there is cost savings I would consider it. We put a lot of effort into achieving AWS "Well Architected" so I'd hate to end up in a lesser position by going in a potentially lesser known, lesser tested, lesser supported approach.

It seems like someone with an application up and running on AWS isn't really the target audience. (Although I'm still trying to figure out who _is_ the target audience, here.)

Re: Cloud.gov

#46

https://cloud.gov/docs/deployment/frameworks/ Not supported cloud.gov cannot run applications that use .NET Framework, or application binaries that require access to Microsoft Windows kernel or system APIs. Interesting that most container/cloud environments don't support .Net framework

.Net Core* is supported

> cloud.gov supports applications written in Go, Java, Node.js, .NET Core...

.Net framework is tied to Windows, and is now considered legacy tech. Both AWS and Azure support Windows containers if you really need them, but they're nowhere near as easy to use as Linux.

* I'd assume that .Net 5/6/7 are also supported (insert rant about dumb MS naming conventions).

Re: Cloud.gov

#47

Cloud.gov was really promising when it was announced years ago, but in practice there ended up being so many differing security requirements and security boundary tensions between them and purported customers of them that they didn’t end up having any real impact because while some could use them, many could not, and those who could often found it easier to just not use them. There were also issues getting needed per…

I can't speak for all departments but the one I worked for. There was huge mistrust between sections and other departments. If projects were joint and required working together it always stalled.

I believe that public servants more broadly see reforms and technology as threats to jobs and tend to be hostile to these implementations. Culturally it's not a place that welcomes reforms, and likes business as usual.

If you aren't a business and you have no incentive to be more productive and make profits. Why would you implement technologies that mean having to re-skill and more than likely bigger workload?

Re: Cloud.gov

#48

Cloud.gov was really promising when it was announced years ago, but in practice there ended up being so many differing security requirements and security boundary tensions between them and purported customers of them that they didn’t end up having any real impact because while some could use them, many could not, and those who could often found it easier to just not use them. There were also issues getting needed per…

So we need BaaS? Bureaucracy as a service?

welcome to Accenture/Deloitte etc. The professional services industry is big business

Re: Cloud.gov

#49

Earlier quoted context omitted.

I’m sure AI in charge of organizing a process can build forms and reach BAAS naturally. What I wonder is, to output a mess process, would it be faster than actual government services, or do govt services effectively act as brownian agents?

Will AI BaaS work for the system or the bureaucracy itself as human systems do?

You’re onto something. BaasAI is the new leader in pushing paperwork through administrations. It can untangle form dependencies, schedule reminders and even imitate a friendly voice after waiting 2 hours on the phone, searching through the database to find what topic will make the clerk laugh.

Only large corps will be able to afford BaasAI. The ground is still level, but peons won’t be able to have any paperwork processed because the services will be saturated with thousands of bots which do their job better. This is the future.

Re: Cloud.gov

#50
post #16

Earlier quoted context omitted.

It’s FedRAMP High: https://cloud.gov/docs/technology/iaas/

Just because you can run High workloads on AWS GovCloud, doesn't mean that Cloud.gov can run High. From their own front page: > We’re a great fit when: > - Your applications are Moderate impact level or lower

I stand corrected!
Post reply on HN