Cloud.gov
cloud.gov
cloud.gov
Truly a great idea and noble thinking, but government problems are rarely about the actual infrastructure and almost always about the bureaucracy surrounding things, as was the case with Cloud.gov. I think this is partially proven by its current customer list, which seems to be largely smaller or discrete projects of agencies rather than wholesale agencies moving to their PaaS, despite Cloud.gov being around since I believe at least 2015-2016.
Bureaucracy as a service?
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?
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.
Nothing will change until that changes.
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.
if they don't handle the compliance hassle of FARS (and maybe DFARS), what is their value proposition?
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?
The latter sounds nice except for the lack of appetite (on both sides of the atlantic) for doing what's necessary to recruit and keep SREs as actual government employees rather than just contracting everything out...
On top of that, how can the maintainers know if a change they make will be safe in the environments of the consumers?
IMO you either offer the whole service (i.e. a PaaS), or you form technical groups within the organisation which regularly share their learnings and experiences. Sharing code (aside from the smallest modules) when you don't have control or influence over the consuming team just doesn't work in the long run.
Using open source Cloud Foundry as the basis. Seems well thought out.
However, I wonder if a better approach would be to offer this PaaS but also lower level baselines that make using AWS easier and more secure so it’s not all or nothing to take advantage of their services.
That's what I was working on for a little sub-agency.
You have to start somewhere, with a menu of cloud services that you'll offer to anyone who wants to deploy their app for the federal government to use. You can make that menu selection larger or smaller depending on what services are on the approved list.
Platform One, for example, is PaaS built around Kubernetes deployments. Mine was built using a much larger approved list of services (Kubernetes, Fargate, and so on) that an entity could select to deploy their app/service.
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.
From their own front page:
> We’re a great fit when:
> - Your applications are Moderate impact level or lower
Because (theoretically) faster path to ATO, which is a huge pain in the arse. That's what all these federal private clouds try to accomplish.
There are a surprising number of agencies and departments that meet the above description, but either they don’t know what cloud.gov is, or equally likely, their IT department would rather spend a lot more money on a contractor and feel like they have more control. There is zero incentive to take a chance, even if you can be reasonably sure you’ll get as good or better infrastructure for 1/5 or 1/10th the cost. No one will be impressed that you saved the money and you’ll live in fear for years that something will go wrong and you won’t get promoted because you chose a scary new thing and it backfired.
They’re (IT) also likely to understand a “web app” as something tightly coupled to their existing systems (meaning they cannot imagine their existing systems securely communicating with an external, independent API, even they themselves built it) which pretty much excludes all modern software practice and excludes using cloud.gov to build additional capability.
If a potential client already knows how to build, deploy, secure and get their IT dept to authorize an aws-hosted modern web server, they’re not (at least right now) a target audience for cloud.gov, but I don’t think that describes most agencies or departments
Without divulging too many details: the government is quite reasonably a bit sticky about where the data is stored physically.
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
> 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).
Neat work on the architectural and regulatory compliance as a service angle, especially for smaller organizations and teams!
I was wrong. They are are using GA.
Not quite. It's not exactly a pain-free experience in any way, shape or form.