18F launches cloud.gov(18f.gsa.gov) |
18F launches cloud.gov(18f.gsa.gov) |
EDIT: USDS/18F folks, you're doing phenomenal work. Thank you.
I personally didn't get it until I saw Docker a couple of years ago and wondered "how will we operate all of these apps, services or even the servers they run on without playing yet another shell game and resorting back to traditional shit IT?". And that brought me back to Cloud Foundry and BOSH, to the point where I quit my old job and joined Pivotal.
That's the goal with CF and Bosh, and it's clear that it pays off.
I've looked quickly at it, but unlike (say) Heroku, found it hard to know where to start to host a simple app.
CF is very good if you want to run a cloud native / 12 factor app. It's also rapidly evolving to run rich workloads (TCP router is coming, .NET is in beta).
I would say CF is more flexible at the kinds of apps and services it can run as the buildpacks tend to be more sophisticated forks of the Heroku buildpacks, or new from scratch buildpacks (like PHP, Or Java). Docker images should be hostable in the near future as well.
Whereas the service levels and instance sizing flexibility available from Heroku tends to be richer.
This is a function of where both companies make their money. Heroku only makes money from their public cloud, whereas Pivotal is focused on selling high end subscriptions for those who want to run their own private CF on Amazon or VMware or OpenStack.
The same procurement rules and regulations remain in place with all the issues they cause. 18F is a nice experiment, and they do have some wins, but they are just a drop in the bucket.
The whole procurement and management process is so broken that it's a wonder any project gets completed. The same few bad actors keep winning contracts over and over again, fail, but then don't have any repercussions. In fact, their failures actually net them more money more often than not as contracts get extended now that the contractor has the government by the balls.
IMO the best thing the government could do is a massive in-housing of functions. So much infrastructure within the Federal sphere has contractors essentially acting as PMs, the rank and file builders, the maintenance staff, etc., all with many layers of prime contractors and subs stuffed with middlemen.
This doesn't go just for IT. Lots of simple functions are outsourced to little benefit. Some of it I think might be because it's hard to fire Federal workers and contractors aren't unionized, but it would be better to fix those issues than hire the same person for twice the salary (when accounting for middlemen, margins, etc.)
1. Aren't government positions notoriously underpaid compared to their private-sector counterparts? 2. Doesn't that mean that "government software" would end up being written by below-average developers and be significantly worse than private-sector software?
Not that #2 isn't possible/likely/a fact under the current system depending on who you speak to.
EDIT: After viewing Noah's FISMA guidance vid (nice work) there is definitely possibility to expedite but to really grease things you'd want to create a certification arm within GSA that can sign off the risk or perform a "certified" risk assessment on behalf of the customer agency so you could do things your way while still allowing them to sleep at night. Once you get into sensitive data loads and non-public stuff people start to get even more risk averse. / End Edit
That said, I'm hopeful that it does pave the way for change because this kind of platform is critical to reducing the barriers to experimentation in government. Perhaps because 18F is committing to supporting / upgrading the platform it will allow Federal CIOs and CISOs to shift some of the risk to 18F and sign the paperwork more quickly.
[shameless plug to join public service for a year or two]
If you're interested in joining 18F or the U.S. Digital Service (which has an HQ office in the White House but also has teams across government), this application works for both teams: https://www.whitehouse.gov/usds/apply
[0] http://i.imgur.com/3q9Ujy0.png
[1] https://chrome.google.com/webstore/detail/butt-to-butt-plus/...
http://i1.wp.com/gcaptain.com/wp-content/uploads/2013/06/ku-...
The blueprint for USDS was the UK digital service, this is hitting some issues as they have started a ball rolling but now look like a bottleneck. Some of the "agile" restrictions and some of the centralised nature of development teams are likely to go - but the essence is a fantastic opportunity and landscape ahead
(See my site gratuitous I know but http://www.oss4gov.org/manifesto)
I like this statement - how do you deal with educating team members on areas that require deep expertise? (e.g.., security, accessibility, localization).
Do you offer training, brown-bags, educational videos, or do you say "don't worry about it - if you do this in $x way, magic[1] will take care of you".
[1] Magic being defined as the compiler, automated tests, etc., feeding into a central feedback system (bugs, tickets, email, or whatever you use) telling you what you did wrong, and hopefully how to fix it.
Accessibility and L10N are app-level concerns, not something that cloud.gov is going to be able to help with. However, 18F works on other efforts aimed at helping people do those things better, eg https://18f.gsa.gov/2015/09/28/web-design-standards/
As for security and other devops concerns, which is what cloud.gov is about: This is why we're in a scaling/pilot phase now. A successful PaaS should reduce the depth of expertise needed to do those things right. That said, there are things like awareness of 12factor.net app design principles which are very unevenly distributed in government once you get outside of 18F. We will be concentrating on generating materials and documentation to make learning about those things in the context of cloud.gov as self-service as possible, and expand the pilot outward to those who need help even approaching the concept of a PaaS once we have more of those materials.
I wonder how many agencies will allow developers to jump into this; seems many of the agencies have a "must be built internally here" attitude about some of this stuff. Still, looks like a good step forward.
_Member of 18F._
EDIT: See sailfast's comment below. I think we're quibbling over semantics.
My understanding is that some of what 18F does is short-term, project-based consulting for other government agencies, but that that isn't all of what 18F does.
The limited employment term things is a real concern for non-consulting, ongoing functions, but may have salutary effects, if it means that design for shared maintainability and succession planning aren't the kind of afterthoughts that they are many places in government.
EDIT: Which is here, by the way! https://www.youtube.com/watch?v=n6u4WjYaX2Q
1) The agency in question has a hard cap on the number of employees, but has more work than it can accomplish with just this allowed staff. Contractors are the only option.
2) The government is building something and doesn't need (or thinks it doesn't need) to keep the experts around afterwords. For instance, you're building a bridge and won't need all of the construction workers when it's finished.
3) To get around the broken hiring process
4) To get around the broken union rules
5) To theoretically save money vs. doing it in house
Yes.
> 2. Doesn't that mean that "government software" would end up being written by below-average developers and be significantly worse than private-sector software?
Assuming that that is the case, the fact that government positions are notoriously underpaid compared to private-sector counterparts would also imply a significant skill deficit in those overseeing and managing government contracts for outsourced work compared to the people employed by the private contractors to exploit the contracting system for maximum profit.
So, if we assume that public sector pay deficits mean, on average, public sector skill deficits, then so long as you don't address the pay deficits, you're stuck with either :
(1) Government software being substandard quality because its made by people with substandard skill working in government, or
(2) Government software being substandard quality because of substandard controls and quality assessment being exercised in the process of contracting out the work to private firms seeking to profit from government contracting process.
Direct Federal hires could be underpaid compared to the private sector, yes. The government uses the General Schedule (GS) scale, which tops out at ~$160K after adjusting for cost of living (there's a base salary and a CoL adjustment). There are rules over who can go in what grade and what step which would likely preclude most SE folks from being compensated appropriately. Those with PhDs and masters degrees would find it easier to get into the appropriate pay band.
Contractors can make good money, and, accounting for not having the middlemen, the Feds should be capable of paying higher salaries for technical fields and still save money. If we're already magically reforming the government by bringing stuff in house (taking an act of Congress in many places; lots of agencies have caps on the number of employees, forcing contractor usage), then we should be able to also reform the pay scale.
>2. Doesn't that mean that "government software" would end up being written by below-average developers and be significantly worse than private-sector software?
Sadly, that's exactly what's in place now. The developers in general are already worse than in the private sector. It's not because of money, it's because of incentives. The Feds aren't good at killing bad projects or disciplining companies they hire.
What you'll see on your typical Booz Allen, Leidos, SAIC, Lockheed, etc. team is a lot of highly educated and experienced people--the government highly incentivizes both education and experience in bidding processes--that are useless. The process beats them down. It's not that they're dumb; they're usually not.
It's difficult to get through the government processes, especially when getting into cleared work. The hiring processes tend to highly favor previous government work, so you end up with the same pool of people. You can't easily hire new people, so you stick with what you've got.
18F is basically a contracting agency, run by and for the government. They basically take on work that's assigned to them by the USDS. The USDS does work as well, but typically more with a leadership and policy role.
I'm an 18F employee.
Here's more info on how we came from the Presidential Innovation Fellows program: https://18f.gsa.gov/2015/03/20/one-year-in-and-looking-forwa...
http://ben.balter.com/2015/04/22/the-difference-between-18f-...
I wouldn't say it's a philosophical difference. We're definitely tackling the problem in two different ways, but that's not because either group thinks the other is wrong, it's because this is a big problem that requires attacking it from many angles.
Morale is really high. Culture and work/life balance is super important to the team and to management. People feel compelled to tweet about how much they like their job. I haven't worked at a startup, but many have and are happy to be here. There are plenty of government frustrations, but the size of the impact of our mission greatly outweighs any day to day annoyances. For me, the best thing is that when there is a problem, whether it's management, bureaucracy, or technology, the attitude is to address it openly and head on. And 18F has a group of really smart people, so those problems rarely last very long.
It's the best job I've had - I have autonomy, flexibility, and the ability to make an impact on a daily basis. It's really nice to think about how many people you reach on a daily basis. The problems you get to work on are challenging and complex - I'm learning new things every day.
I came from the journalism world, not a startup - so I can't speak to whether it's similar. I will say this: We have a "Yes, how can I help you do that?" philosophy, which I find refreshing and really delightful.
For example, right now I'm working on an onboarding Slack bot (code: https://github.com/18F/dolores-landingham-bot) that will help acclimate new employees to 18F. Got the idea. Threw it around. Everyone liked it. We're building it. And then we plan to write up how we did it, so others can use it too.
That's the best feeling - sharing what you learn, and not being afraid to go public with every bit. Happy to say more.
Mel (@mkramer on Twitter)
(I also work at 18F, and I highly recommend it)
