[HN Gopher] Cloud.gov
___________________________________________________________________
Cloud.gov
Author : gmays
Score : 193 points
Date : 2022-08-14 15:05 UTC (7 hours ago)
(HTM) web link (cloud.gov)
(TXT) w3m dump (cloud.gov)
| anomie wrote:
| The UK equivalent has just announced it's closing down for many
| of the reasons people comment here -
| https://gds.blog.gov.uk/2022/07/12/why-weve-decided-to-decom...
| peyton wrote:
| It seems like this product could be better (less risky) as a
| set of shared config files or something.
| ris wrote:
| 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...
| cj wrote:
| (Off topic): this page linked at the bottom of cloud.gov is quite
| interesting. Visitor analytics for government sites.
|
| https://analytics.usa.gov/
| bXVsbGVy wrote:
| More impressive is the lack of google analytics.
|
| I was wrong. They are are using GA.
| emsixteen wrote:
| You sure? Mentions sampling limits for GA on the page.
| bXVsbGVy wrote:
| 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.
| tehlike wrote:
| "The Google Analytics account that powers analytics.usa.gov
| is experiencing issues with realtime reporting. Realtime data
| may be inaccurate."
| patrickmcnamara wrote:
| The vast majority of people using US gov websites are not in
| the US? It says 92.5% are international. Huh.
| bobthepanda wrote:
| 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)
| ethbr0 wrote:
| Also at the bottom of cloud.gov, and not surprising: "Built by
| 18F"
|
| Neat work on the architectural and regulatory compliance as a
| service angle, especially for smaller organizations and teams!
| Hooray_Darakian wrote:
| This is going to be a god send for a lot of smaller gov agencies.
| jason-phillips wrote:
| > This is going to be a god send for a lot of smaller gov
| agencies.
|
| Not quite. It's not exactly a pain-free experience in any way,
| shape or form.
| asn1parse wrote:
| i agree
| peyton wrote:
| It's been around for 7 years, so I wonder what adoption is like
| in the present day.
| victor106 wrote:
| 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
| kenniskrag wrote:
| .net core is not supported?
| jason-phillips wrote:
| Yes, but dollars to donuts they support Dot Net Core.
| cgrealy wrote:
| .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).
| [deleted]
| loceng wrote:
| Can this, how does this, get captured by industry leading it to
| become relatively stagnant with high prices?
| MOARDONGZPLZ wrote:
| 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.
| newsclues wrote:
| So we need BaaS?
|
| Bureaucracy as a service?
| ccbccccbbcccbb wrote:
| FaaF, failure as a feature
| eastbound wrote:
| 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?
| newsclues wrote:
| Will AI BaaS work for the system or the bureaucracy itself
| as human systems do?
| pmorici wrote:
| 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.
|
| Nothing will change until that changes.
| MOARDONGZPLZ wrote:
| 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.
| ec109685 wrote:
| Good overviews of how it is put together:
| https://cloud.gov/docs/technology/iaas/
| https://cloud.gov/docs/technology/responsibilities/
|
| 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.
| jason-phillips wrote:
| > 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.
| InvaderFizz wrote:
| 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.
| jpalmer wrote:
| Or the AWS commercial east/west regions. All of which have
| FedRAMP moderate ATOs.
| atonse wrote:
| It's FedRAMP High: https://cloud.gov/docs/technology/iaas/
| InvaderFizz wrote:
| 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
| wslack wrote:
| 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).
| jason-phillips wrote:
| > I'm not sure why any contractor or agency would pick this
| over AWS GovCloud.
|
| 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.
| bluedino wrote:
| 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.
| Bajeezus wrote:
| 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.
| AlbertCory wrote:
| While in Google's Patent Litigation dep't, I had a case (not a
| suit) about Google's Gov Cloud product.
|
| Without divulging too many details: the government is quite
| reasonably a bit sticky about where the data is stored
| _physically_.
| kyawzazaw wrote:
| Seems like this is by https://www.gsa.gov/
| vcryan wrote:
| 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.
| bXVsbGVy wrote:
| It still is AWS. The AWS GovCloud partition to me more precise.
|
| https://cloud.gov/docs/technology/iaas/
| vcryan wrote:
| 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.
| fn-mote wrote:
| 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.)
| aejnsn wrote:
| 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.
___________________________________________________________________
(page generated 2022-08-14 23:01 UTC)