A cloud reality check

Some of the government's top cloud experts would really like everyone to stop talking about cloud. Not stop using it, mind you, because the benefits can be real and substantial. But when cloud technology is positioned as the end goal or magical cure-all, it's hard to keep the focus where it belongs: on mission execution.

FCW recently gathered a group of cloud specialists, CTOs and other agency leaders to discuss the cloud conversations they're having and the steps they believe will help agencies find a real and lasting return on investment in the cloud.

The conversation was on the record but not for individual attribution and the quotes below have been edited for length and clarity. Here's what the group had to say.

Top-level support, but for the wrong reasons

"Air cover" from an agency's top leaders is invariably cited as crucial to the success of any IT modernization effort. But several participants said today's executive-level buy-in on cloud is creating unrealistic expectations.

"We're getting a lot of pressure to just go to cloud — 'Go, go, go, go!' — irrespective of any mission drive," one said. "There's no sense of reality in some cases. They're approaching cloud as an IT thing, not as an enabler to a mission outcome."

That pressure can lead to rushed or poorly planned migrations with predictable consequences because "the modernization of an application requires a lot more than just the technological deployment pattern of cloud," the executive added. "At the end of the day, you can reengineer your crappy applications and your crappy processes back into the cloud and they would be no more effective or efficient that they were when they were on-prem. But again, we're getting so much ridiculous pressure from above."

He said the problem is that top agency leaders "are actually being told that is their No. 1 priority because the department is turning its reform initiative into an efficiency initiative, which is code for saving money."

Further down the organizational chart, however, the view has often shifted. "Three years ago, what started the cloud conversation was cost savings," another participant said. But "what we've found, through implementation across the department, is the real selling point isn't cost savings anymore."

Program managers and "the people who are doing the work" are focused on cloud's elasticity and agility and the mission benefits the technology can deliver, he said. "That's what they care about. But at the end of the day, you still have the senior leaders who look over your shoulder and go, 'That's great, but how much money am I saving?'"

The group agreed that such a mindset can short-circuit an agency's ability to achieve those mission benefits and possibly the cost savings as well. One participant recalled officials at a civilian agency who "moved a bunch of stuff into the cloud because they thought, 'Oh, let's go to the cloud.' They blew through their storage budget in a year and two months, and then had to take it down and move it back. They didn't understand what their cost was going to be."

Focusing on mission and managing expectations

Cost is absolutely a consideration, the group agreed, but most argued that agencies should take a broader view.

"We're going to spend a lot of money migrating," one executive said. "I told my management that they need to get over that fact. We will save money at some point, but it's not in year one." That is due in part to the fact that so much of the existing cost is wrapped up in the employees who manage the legacy systems, which means the true savings will come only if those people are let go or retrained and redeployed.

Another said the key is to define mission-driven ROI. "The conversation should be what is it that we're trying to achieve? How we are going to measure what we're trying to achieve in mission outcomes? Then you work backward to distributions."

Several participants said mission owners and agency IT shops increasingly seem inclined to approach the conversation that way. Price and internal efficiencies used to be the main drivers for cloud adoption, but "you don't really hear that anymore," one said. "Now I actually hear much more, 'How's it going to improve the mission?'"

Leaders are now saying, "OK, we've got the neat new cloud environment," another participant said. "Can we actually use it to solve a mission problem and find out more information that we didn't know before?"

Meanwhile, another executive said, more agency IT teams — which have often earned a reputation as change-averse "server huggers" — are making a big push for the cloud environment. "They're really trying to shove the application on the load side to the commercial cloud," the executive said.

That's not universal, of course. Although some participants noted that the IT team was leading the charge at their agencies and pushing to embrace cloud for its speed and agility, one executive reported the opposite: "Our business lines care about fast, but our IT folks sometimes are saying, 'But we've got this thing that works.'"

And a participant who works with a range of agencies reported that holdouts are not hard to find. "We've been out talking to a number of agencies, and what I'm hearing from folks is, 'Well, yeah, we'll delve into it. But we're not going to move our old stuff.' They're not going to redesign it. They're just not going to do it. They're saying, 'Well, maybe I can meet the spirit of this by starting to just build all-new stuff.' They're identifying very baby steps."

Better security and core competencies

The group also identified two arguments that resonate almost as well as cost savings: better security and allowing agencies to focus on what they do best.

Running IT infrastructure is not any agency's core competency, they argued. Companies can deliver "because that's their job," one participant said. "They're professional data center operators. My agency, to the best of my knowledge, in the last 50 years has not built the data center. We have taken a building and put servers into it."

"There's the fear of Microsoft or the fear of Amazon, saying, 'There's no way that you could possibly do better than we can,'" another participant said. "What we've demonstrated time and time again is that we're not so good at it."

"I love what the Defense Digital Service guys and the U.S. Digital Service guys have done," a third said. "They don't give a crap about the network. The network is just a commodity — no offense to anyone who runs a network. I'm working on the application layer. I'm working on where the data's going, discovery and the integration and retrieving of data."

The commercial cloud infrastructure options are there, the second official said. "It's cheaper. It's there. Use it, and bill everyone on top of it."

Actively exploring such options can force a valuable reassessment of an agency's existing processes, said another participant who brought USDS into a civilian agency. "You don't realize your culture until you have somebody show it back to you. The USDS folks said, 'Do you know it takes 180 days to spin up an environment around here?' And I said, 'Really? Is that too long?'"

As for security, one executive put it this way: "As long as you do it right, if you go to the cloud, you're more secure than you were before. You have better visibility into it to see exactly what your environment's doing, where it used to be, 'Well, do we have a data center over here?'"

Other participants said that's one of the core reasons for shared services like Cloud.gov (a platform as a service that handles much of the required security compliance) and Federalist (a PaaS tailored to hosting and managing websites). "We want to take all that burden off you so that you can focus on your mission," one said.

That participant also argued that the visibility a well-designed cloud service offers can help overcome resistance from IT employees who fear migrating themselves out of a job. There is more important work for them to do "because guess what? Before they were in the cloud, they didn't know they had 20,000 servers that were unmaintained. Once they're in the cloud, now they know that they have 20,000 servers. You probably want to keep an eye on that."

"They will do that with higher-level tools," the participant added. "They will do that writing software. They will do that with automation. They will figure out how to redeploy their infrastructure from scratch every 60 minutes so that a hacker can't really gain a foothold. That's more fun than figuring out network cabling in a server room, right?"

One executive went further by arguing that the government should be running toward software-as-a-service (SaaS) solutions as quickly as possible.

"I hate to be the bad guy in the room," that participant said, "but everybody who answered is five years behind the times. We talked about how to solve infrastructure. We talked about how to solve platform. We talked about how to solve DevOps and developing software. I don't even understand why we're talking about any of that."

Instead, the executive said, "we need to buy SaaS, just like the commercial industries do, [because then] we don't have platform problems. We don't have infrastructure problems. We don't have to do DevOps. Why are we doing DevOps on an HR system when we could go buy it for $30 a seat?"

Others objected, saying that countless government systems will never be supported off the shelf. "The software that runs those tanks should never be SaaS-ed," one quipped.

And even where commercial solutions do exist, another noted, "people don't know what they're buying when they go out and purchase it, and then they figure out, 'Oh, I can't really use this.' Then they want to modify it. And now you have something that's modified, and you cannot upgrade."

There was little argument, however, that the government adds value below the platform layer. "We don't need to run the infrastructure as a service," a participant familiar with the government's IaaS experiments said.

Split opinions on SLAs

Outsourcing to service providers — whether it's for infrastructure, platforms or software — requires a clear allocation of risks and responsibilities, which the group acknowledged was still a work in progress. The government's own compliance and reporting requirements have not fully kept pace with as-a-service realities, some participants said, but agencies are also struggling to craft appropriate service-level agreements with cloud providers.

One executive questioned the fundamental premise of an SLA: "What's the SLA going to accomplish? If the vendor doesn't meet their SLA, the only thing they can do is give you credit. They can't give you your money back. That's against the law."

Others questioned that interpretation and argued that certain performance-based contracts can refund money without running afoul of the Antideficiency Act. But they agreed that, even for services authorized by the Federal Risk and Authorization Management Program, SLAs are not doing enough to simplify risk assessments or the required compliance efforts.

Although a limited set of physical and maintenance controls can be inherited, one participant said, "for the rest of it, you've got to look at it line by line and ensure your portion of the job is properly done and accounted for."

And although much of the foundational security is handled by the cloud service provider, another said, it's the agency that must report on the status of those efforts. When the Department of Homeland Security wants proof of appropriate patch levels, for example, "we turn around and ask the PaaS or SaaS providers. They are like, 'Why are you asking about servers? That's our business.' But when they are asked, 'Are you going to report it?' the response is: 'No, that's not our job. DHS did not ask us. They are asking you.'"

Others, however, said negotiating the SLA can prompt those conversations upfront. "It really forces you to think: What are your operational procedures for certain things?" one executive said. "What is your incident response procedure? Let's write it down and figure it out."

Another participant, who works with a broad range of stakeholders on their cloud efforts, praised SLAs for a different reason.

"I use SLAs every single day, believe it or not, for engineering purposes," the official said. "When they screw up that architecture, I can use their SLA number and calculate what the uptime is going to be. I say, 'You are at 98 percent availability right now. Your architecture sucks.'"