 Good afternoon. I'm Peter Burkholder. I don't know if I'm getting introduced, but it's 1245. And so, oh, Dermain is still here. Can we go ahead and roll on? Great. I think it's just, I think it's just good operational and contingency planning practice whether you need to or not to think about where the fire exits are. They are in the back of the room. And if someone's lithium ion, ion battery explodes, then just calmly walk out the back of the room and we'll all get out faster and safer. Thanks to, welcome to Enabling Innovation in Government with Cloud Foundry. I'm Peter Burkholder with the Cloud.gov team, and I spend most of my days working with agencies, helping them adopt Cloud.gov and explaining what it means to work in a platform as a service model. So it's exciting to be here with people who already understand what Cloud Foundry is and are already using it in government or perhaps some other highly regulated sector. Now, to understand Cloud.gov and its mission, the key ingredient is to move forward through the slides is trust. Research has been showing that the best outcomes in technology come from teams that have a high level of psychological trust and that are empowered to deliver value from concept to production. Now, there's two facets to this. One is that psychological safety, which is internal to a team. Can you trust that your voice is being heard? Can you trust that you can fail without blame or shame within your team? And the second, then, is the context in which the team works. Are they trusted to operate in the domain of their expertise? Can they trust that if they fail, they won't be punished but will be seen as an opportunity for learning? Now, this ladder trust is very much in tension with the whole idea of a regulatory setting. And within government, trust is rare by design. Our constitution is predicated on the notion of the people not trusting the government. The three branches of government provide checks upon each other. Our procurement system, the 3,000 pages of the FAR, are predicated on not trusting the people doing the procurement to avoid favoritism or the contractors themselves. So trust is replaced by regulation and audit. That's good. It enables a bureaucracy to operate on the behalf of the people. Now, the framework in which we operate is governed by the process of getting authority to operate, ATO, ATO, ATO. Hear this over and over again. It's the 200 to 1,000 pages that you need to address these regulations, which total some 6,600 pages roughly. So three years ago, our group at 18F was in a quandary. 18F is a digital consultancy housed within the GSA. And we partner with other agencies working from the principles of user-centered design, agile development, lean product design and open source. And in conjunction with our agency partners, we're building great product. And the challenge, though, of complying with these regulations and documenting that compliance, would leave product stranded. Because typically, they were looking at six to 14 months to obtain the authority to operate and actually ship. And that's when the idea of cloud.gov began to coalesce. One shortcut to an ATO is reuse. But in January of 2015, the reuse of configuration management tooling within our cloud environment wasn't scaling to the needs of this product that needed to ship. So at that time became a process of assessing the trade-offs between various commercial and cloud offerings to address more and more of those regulations out of the box. And it was decided to experiment with building a platform as a service based on cloud foundry. And it was such a success that product was started getting shipped. They called it cloud.gov. And in October 2015, it was launched for federal users. Now, if you were present at the 2015 or 2016 summits, you may have heard Brett Mogolepsky or Diego Lapidiz talk about cloud.gov. And this is how it looked then. But it's been a while and a lot is new. This is how it looks now. And there's a lot more under the covers. But before we go to there, I want to tell about my journey to cloud.gov. Because it took me a while to realize that it is a paramount necessity to have a high level of paths for success in highly regulated environments. I started my career as a geophysicist doing field work and data analysis, and then went into system administration, working in research labs, and then the private sector. I caught the DevOps bug pretty early in 2010 because it tied together the things I'd already been working on in terms of automation and infrastructure testing with the framework for working together in teams. So before coming to 18F, I spent two years working with an automation vendor where we'd go to insurance agent, insurance companies, financial institutions, highly regulated environments, and try to nurture DevOps with automation at the core of that. But we'd see these weird anti-patterns emerge where the teams wouldn't trust each other's code. I joined 18F before I'd really cracked what was going on with these barriers to adoption. And when I started, I was confession Brett, a little dismissive of cloud.gov. I thought, oh, it's just Heroku for the government. I'm a real DevOps. I'm a real sysadmin. I want the tools, the terraform, the chef, the ansible to solve all the big problems. My first engagement with 18F was with an agency partner where they were making their first sort of big move into the cloud, and they wanted to build out a development environment, and we wanted that to be designated in code, going through testing, and built in repeatable fashion. It took us nine months to get to the point where we actually had a pipeline running, but at no point did we actually have a line of developer code running in that environment. To me, this was a disappointment to them. We had exceeded their expectations because they actually had something working in the cloud. And meanwhile, I was looking at my 18F colleagues who were shipping product thanks to cloud.gov. And that's when I joined the cloud.gov team with two key principles that had gelled in my mind, which I'll share with you now. One, a pass is a prerequisite for DevOps outcomes in regulated environments. People want these outcomes. They want the speed and stability that comes with delivering at velocity. Now, that core idea we talked earlier about empowering teams to deliver on value, that can work in places such as startups or mature DevOps organizations where you can grant the team authority to make changes on behalf of the organization. Yes, you can run that Terraform plan to stand up a new environment. Yes, you can run that Chef recipe to install Tomcat. But in government and other regulated industries, the trust just isn't there. Even with infrastructure as code, they won't trust you to write the code to deploy Tomcat, even though you may be trusted to write the code that handles credit card or other sensitive transactions. It doesn't make sense, but just the way it is. Meanwhile, the product teams and developers are saying, please, can I just have an app server and a database server in a shared environment? So there's this prerequisite, an absent to real pass, organizations will attempt to build their own. You have these mature automation tools. You want the guardrails for the development and product teams, and it's tempting to start building your own bespoke tool chain to enable that. And this intentional or not, let's build a pass, fever takes hold. And it might take the form of something like, and I've seen this, you'll open up a remedy ticket, you'll get sent a Pop Chef Terraform template, you fill it out, check it in to get that will get reviewed by Pat or Steve, and then it will go to a validation environment will stand up a copy of it will go through security scans and so on and so on. Now tool chains are awesome, but not at scale and not in an organization that hasn't yet learned to move at velocity. And inevitably it devolves into additional bottlenecks where human work or rework has to occur. We need to stop this, make it possible for people to do their work, and give them a pass that can solve the 80% use case so those tools and expertise can go to the edge cases which may not be as suitable for platform as a service. And this is what cloud.gov provides. Well, what is it? It's not absent a real pass. It is cloud foundry 100% open source. There's an asterisk there because we do have some commercial security scanning software running within our infrastructure that I haven't replaced yet, but in terms of the functionality 100% open source. We provide the standard build packs. We have brokers for AWS relational databases as three buckets, elastic search redis, and some others I'll touch on a few. We're running a top AWS cloud. And at this point, we're only for US government. We can't yet offer to state and localities anyone with a validated US government email address can sign up for a stand box account and kick the tires. And we focus a lot on making compliance easier and also secure choices by default. Something like you created S3 bucket, it's either public at the time of creation or private, and you can't change it. So no risk of stashing something in a bucket you think is private and then later on have someone misconfigure it so it's exposed because that's never happened in the history of cloud services. From a government perspective, our killer feature is security and compliance. And first among this is FedRAMP authorization. We have a FedRAMP JAB provisional authority to operate the FSMA moderate level as of January 2017. That's a lot of legal leads. Let's unpack that a bit. Who here is familiar with FedRAMP? Most of you know, but to revisit that, it's a program, the federal risk authorization and management program that will keep tabs of the cloud providers that are available for agencies to use. Agencies can do their whole authorization of all the compliance work, of all the compliance requirements that a cloud provider has, but those don't get a whole lot of reuse. The higher standard is to get one that's from the joint authorization board, which is a joint effort between GSA, Department of Homeland Security, and Department of Defense. When you go through their authorization processes, then have a provisional authority to operate, other agencies can use your cloud service. It's upon them to review your security documentation to make sure it comes into play for their situation. And then they build their information service on top of that. We can host work up to FSMA moderate, which includes personal moderate amounts of personal information. We can't host life limit property, but to be a FedRAMP high authorization. And it took us 23 weeks to have solid work to get the authorization, but it has given us then this ability for control reuse. I mentioned FedRAMP moderate impact levels. If you're hosting such an application, you have 325, I think maybe it's 327 now, security controls that you need to document. If you use a out-of-the-box infrastructure as a service, you will get about somewhere between 85 and 120 different controls that you can inherit and reuse in your authority to operate documentation. Things like physical security and that there's a shutoff valve in a particular place to use retina scans. And then you're responsible for the remaining 225 controls. How is your logging happening? Where is your patching process, et cetera, et cetera. When you run up topcloud.gov in the ideal situation, there should be tillies next to some of these numbers, you can inherit as many as 269 of our controls, things like separate execution domain, and then it's a shared responsibility for things like information spillage, and that's wholly on you to take care of the PIV credentials for the people working on your platform in your application development. We inherit FedRAMP controls ourselves, as I mentioned, on top of AWS, so we completely reuse 54 of their security controls. This work to obtain FedRAMP taught us a number of lessons. First, it's definitely been good for people who want to adopt Cloud Foundry within government, because they can come to cloud.gov and do that. It's given us the chance to reflect on what we run, and there were some features in our application, in our platform that we pulled, not because they weren't secure, but they weren't worth the effort of documenting and continuing to prove they were secure throughout their life cycle. It has forced us to stay at a level of discipline we would want to have anyhow, so we have quarterly meetings about what's our contingency plan and what's our security plan, et cetera. It's given us a great level of empathy for everyone else as to go through a compliance process, including our customers, and it's helped our communication, particularly because FedRAMP needed some convincing about what it means to have an open source cloud offering. They have brought into that been very receptive as we've moved forward, because we have open source all the things, and the background here is just a partial listing of everything we have available in GitHub. I'll highlight a few. When we launched, there wasn't any open source cloud foundry dashboard, so we wrote one. It provides visibility into organizations and spaces, the broker marketplace, managing environment variables as a feature, which was contributed by our Australian colleagues at the digital technology agency there, and things like stopping and stopping applications. It's mostly focused now in the needs of people who are not developers but who may come in as a manager and need to invite users, add new roles to them, or change them, and things at that level. So we're likely to replace it with Stratos or some other open source offerings instead of having to maintain our own, but it certainly suits our customers now. We also wanted to make it really easy, not just for customers to stream logs and have them stored someplace for 180 days, but a way to access them in a feasible manner. So we already had cloud.gov set up to authenticate against an agency's single sign-on. Why not reuse that to give people access to their logs? So Adam Kendall in our team wrote a UAA plug-in for Kibana, so that once authenticated, it would grab all of your orgs and spaces and filter all of your searches in Kibana against those so you could only see the logs that you were authorized to see. So it's not just useful, but it's also another step forward of making it easy to get compliance. Likewise, since we had UAA working with single sign-on, why not make it easier for customers to reuse that in their own applications? And this is an example application that I used to request the funding, the credit card ability to purchase the workshop that I came and attended yesterday. In the circle there, it says sign in with log cloud.gov, and then I'm directed to a screen where I go ahead and log in with my GSA credentials. The broker, the identity provider broker provides a single sign-on OAuth client plan. You provide the redirect URI in the scope, and then the app provider gets access to using that with the credentials that are available as service keys. Behind the scenes, we have a lot of Bosch releases. We've made public arterial form plans and the concourse pipelines, including how we continuously deliver the platform itself through development staging and production pipelines. And we've participated in one of the early bug bounty programs within the U.S. government pleased to say that the pot of money we set aside was in far and excess of what we actually needed. Most it was things like some potential cross-site scripting attacks and mostly comments that's like pretty solid platform here. So with all this work behind the scenes, let's take a look at how it's been used to make a difference. These are the agencies that have been or currently are very active in cloud.gov, National Oceanic and Atmospheric Administration, the Air Force, Forest Service, FDIC, Education IRS, FBI, EPA, Office of Management and Budget, National Science Foundation, U.S. Digital Service, Alcohol, Tobacco and Firearms, Federal Election Commission, Department of Interior and GSA. One of the case studies you'll find is the Federal Election Commission and the case study in our site largely focuses on the fact that the use has been $1.4 million a year on their data center because they had to have enough servers for the few times when everyone before an election cycle was checking out how much their neighbors gave to which candidate. I do that. By moving to cloud.gov they saved 85% on their operations budget and they have all the elasticity to meet those needs. But I found particularly delightful is the way that they've been able to change the way they work. They had a complete culture change as the product owner said about how to do user-centered design in Agile. Other teams at 18F were responsible and coaching them in those processes, but it was made possible by having an agile platform that supported the way they wanted to move in terms of doing user-centered design and rapid prototyping. We've seen similar results with Department of Education and College Scorecard, the FDIC, and the Forest Service as premier examples. Sometimes it's the little things like our fourth graders when they get their free passes to national parks are using cloud.gov. The site was tied to a presidential announcement. Once those are announced they can't actually be changed. So with a 90-day deadline 18F was able to partner with the Department of Interior to build a site that launched people through what the program offered and how to get their own pass for their family to print out and go to a national park or other federal land. It also turns out that static sites have been an issue for many federal offices. They don't need a CMS. They just need a way that's accredited to launch their static sites. So Federalist is an 18F project that lets people edit their website code locally, upload it, and share it with their colleagues on GitHub. It gets generated to a site that's pushed to an S3 bucket, and then they can preview it live at a preview URL and then publish it. They now host 119 different sites for eight different federal agencies, including when you get the BOD directives from the Department of Homeland Security, that's a Federalist site. And more generally, within GSA, many of our products are now written with cloud.gov in mind, so we have a team adept at generating the required documentation and working with the auditors. So it used to be a 6 to 14 month ATO process. We now have down to a month as the auditors are familiar with cloud.gov, and we have this ironed out. So all this has us looking forward to the road ahead. We definitely want to tackle things like getting to FedRAMP high, supporting Windows workloads, offering CICD as a service, and other productivity services, and getting the upstream container run time available. But a particular interest is looking at what we can do for vendor adoption in multiple clouds, because if you're an agency wanting to buy some quality product to get your work done as an agency, it can be hard to get a SaaS, because if they haven't gone through the FedRAMP process, and many of them aren't willing to do this if they're small and have other markets, then the other option, then you probably can't use that service. If they run within a data center, then you're looking at the whole process of the old way of getting the real or virtual machines provisioned and set up and running. If vendors can certify that their product works on cloud.gov, then they can go to the agencies and say, look, we can perhaps sell this to you as something that's available on cloud.gov. Agencies get the product they need. Vendors are able to connect to potential customers. And of course, as Abby pointed out in the keynote, 48% of enterprises are running multi-cloud. We want to go there, too. There's a huge opportunity in terms of things like getting workload closer to where specialized services might be running, like artificial intelligence services in Google or Azure, AWS, in terms of contingency planning. And then for moving workload to the place that's most cost and feature effective for stewardship of tax dollars. So technical excellence in highly regulated environments and government is challenging. But when we think about trust that's enabled by providing a high level of automation, we can see that change has actually happened. We've demonstrated with that with cloud.gov. We're moving forward with ways to provide velocity, compliance, and stewardship of tax dollars without vendor lock-in. So on behalf of our team, thank you very much. And if you need to get in touch with us, please reach us at cloud.gov, cloud.gov inquiries at gsa.gov, or you can tweet at 18F if you want to broadcast this out. Thank you. We have a microphone for questions because there's a live stream and the recording, so it makes it easier for that to get captured. I work for FDIC and we are your customers. Just want to check you've been working something with security from scanning perspective. Is there something that is already available for the customers or what exactly is it? I'm going to give that to Brad. So hi, I'm Brad Moglevskaya, the product lead for cloud.gov. My talk later today is about scanning. So the short answer is that we are working on something, but it's fairly difficult if we don't control more of your pipeline. You know, the best answer is that you should be doing more, you know, everybody at the show is saying, move that to the left, move it to the left. What they mean is like move it from the operations or production side back to the development pipeline. That is definitely the wisest thing you can do, but we definitely are hearing some people wanting the platform itself to handle scanning and like gating deployments. So my talk later today is all about that and some of the exploration we've done in that area. The short answer is, and I don't want to spoil my talk, but it's not easy in cloud.gov, sorry, in cloud foundry at all. It's a missing extension point and something I think that needs to be addressed and hopefully is addressed in the V3 API, but I haven't talked to the CAPE folks to find out for sure. But we're exploring it for you. So thank you. My question is probably going to be boring to people because I already asked the question before, but I heard you say something about Department of Homeland Security. So do you have a contact of somebody that I could talk to in Department of Homeland Security about what their plans are for the future for cloud foundry or cloud development? It's a big department. We're talking with people in their CIO office and CTO office about complimenting the work they're doing, particularly with cloud.gov, and I mean it would probably be best if I just got your contact information and then in some context I can make sure that I'm talking to the right people and putting you in touch with them then. Well, what is your timeline for getting to multi-cloud and what's your take on where cloud foundry is in terms of making that possible? And do you see Kubernetes, for example, as a way of enabling that or other types of stuff? Right. So we would like to move to any cloud that has a mature support for the Bosch cloud provider interface, and that also has already received sufficient FedRAMP authorization itself so we can host our workload. That's sort of the first gate. Second is we then need to go climb what's called procurement mountain because it takes a bit to say we want to use this cloud and then there's the whole question of how much we need to pay and where the money comes from for the initial pilot before we can move forward with it. Long story short, we thought we would already be well along with our pilot in Azure already and we're not because of those procurement gates. So we're hoping to have progress later this quarter or next quarter on that. Yeah, I think that's the thing to remember is that Cloud.gov, part of the reason we can do what we do and offer this as a short source is that we are FETs. We're federal employees. We're at the GSA. But that does mean that we operate a little bit with one arm behind our back, especially when it comes to things like procurements. But again, as Peter said, that's about empathy. Now we understand all of our agencies that we're helping. We're making it so they don't have to do those things. So one of the painful things we're going through is the procurement of these other IS providers and working with them. The good news is the community is working hard on the CPI and there's lots of examples and see if deployment's made things easier. So we're anticipating it'll go pretty smoothly. But right now it's just gated on access, not technical work. There's additional stuff on the far side of that for compliance with FedRAMP. FedRAMP, you kind of don't come through it and then you're done. You have to have what's called a significant change process, which requires more third-party auditing and so on. So we're gated not on the technical work. We're gated just like most of our customers are, fundamentally, once you have access to the tech. We're gated more on the procurement side and the compliance side. So we're hoping that we can get through that. We're going as fast as is possible, which is faster at the GSA, when with FedRAMP than a lot of other agencies, but we're still gated by it. But it is a major priority for us. And this is where we provide a real value add that's unique and that really only a government group could offer a platform that runs government workloads on multiple clouds because there wouldn't actually be a vendor space for that. And then it gives people the ability to say, oh, this is what it's like to move at velocity. This is what it's like to have speed and stability and get them culturally forward on saying I can take this and run it other workloads, not on cloud.gov, because our mission is to change not where people run their workloads, but how they think about modernization. And we're just providing a technical platform to enable that. Reducing the friction, friction for procurement, friction for provisioning, friction for development, for testing, friction for compliance, and friction for operations, I mean. So it's all about reducing friction in that whole pipeline and making it so people can go through it fast and then do it again and again and again and now they can be iterative. That's the whole goal. And we'll use whatever we have to do that. And we'll try and do that by being good stewards of the taxpayer money and making sure that agencies don't get, you know, too tied in with one vendor. And I think that's one thing that Cloud Foundry has really given us, is the ability to be, you know, a little bit more agnostic about our IS provider, a little more agnostic in terms of the technology direction, and enabling, and that's part of what the certification is about, enabling all the people at the show who are vendors or in this space to potentially offer their services to government agencies and know that, okay, they're working with Cloud Foundry, that's a baseline assumption. Let's work on the value above that. So you want another question? More concentration across Clouds? I would love to take more questions, but I don't want to stand between people and lunch and going through that awkward phase of standing up while someone's still talking, talking to you, Dermain. So thank you very much. It's been a great pleasure and have a great conference. Okay, I'll answer your question real quick.