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 performance out of underlying Cloud Foundry infra and highly delayed updates, including security patches I believe.
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.
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.
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?
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?
if that were true it would have already happened in healthcare, so they can extract more from sick people in the States; these existing systems optimize around different problems, goals and bounds
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.
You are not the only one to have this thought. The problem is - who comes and fixes the mess when the inevitable customizations needed have been done by a contractor who is now long gone? It seems like a great idea at the beginning, but at some point someone ends up responsible for a fleet of AWS accounts that have diverged in different odd ways. Who is that someone? Individual departments? A centralized department?
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...
I don't think it ever quite works in practice. Letting teams come pick up the config module off the shelf in January is all well and good, but when the maintainers of the module issue a security fix in October how can you ensure the consumers apply it?
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.
> 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.
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.
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.
There are different levels at the infra/platform/application layer. cloud.gov is built on top of AWS IaaS (though the PaaS could also be deployed on other infra).
As someone who runs 20+ cloud based government applications it is unclear to me how this is easier to secure, more performant, or cheaper than AWS. My first impression is this adds a lot of risks and unknowns in a critical area where there are existing and well-known best practices.
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.)
You need a low/moderate impact web app, you only need bread and butter infrastructure, django/ruby/node app, postgres, redis, basic autoscaling. You (your agency) does not have experience doing this (for example, you’ve never built something on remote-hosted infrastructure before, you’ve never built anything that wasn’t locked to windows before, you’ve never done anything that wasnt hardcore waterfall before, etc). You wouldn’t know where to start if someone asked you to build a web app that would be easy to find technical talent to support going forward (you just assume this means a building into a Microsoft product). You don’t know why open source software makes your life easier when maintaining a software system. More charitably, you want try this “agile development” thing that everyone is talking about, and you need air cover to keep your IT dept from demanding that you give a contractor 500k-1.5m to put up a “secure” boilerplate, ‘hello world’ modern web app deployment that will kick off your agile dev process, which ought to take one person a week to deploy and another person a week to lock down.
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
I am curious, do you own a business that bids on govt contracts? This is something i am interested in learning but i am not sure if this is feasible for an individual
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).
Thanks for pointing this out. I looked for the domain of fetched resources, and assumed they weren't. It seems they are using, but from their own domain.
That doesn’t really surprise me, I don’t know that I visit .gov sites quite often, but people located internationally probably do lots of things that would require it (e.g. visas & immigration, talking to the embassy)
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.