"You can imagine," Shams says, "IT security tells me something, I tell it to the procurement guys, who will then tell talk to the sales guy, who will then talk to IT security guy, who will then come back to them, then go to procurement who will then go to Khawaja who will then go to security. This is completely inefficient."
In the wake of the lengthy negotiations over the first contract, Tom Sodastrom, NASA IT CTO at JPL, figured out what Shams describes as a "magic formula": Bringing stakeholders on each side face to face to discuss the issues involved.
When Amazon established its GovCloud Region, NASA needed to sign a new contract with AWS. This time, it only took a month. This idea of approaching a cloud vendor as more of a partner has continued, with peers on each side having meetings with each other to foster a collaborative relationship.
Shams believes this approach, of bringing together peers across the customer and the vendor, is applicable for large enterprises beyond NASA. It stops things getting lost in translation as communications go up and down the chain, and removes bottlenecks.
He cites as an example the collaboration between JPL's security team, and AWS's. "The IT security team's goal has been identified as, well, you're going to make cloud computing secure or tell me why it can't be done. So it's now part of their pay cheque ... to go figure this out. So they have to go to talk to the IT security team [at AWS].
"The IT security team [at AWS] has to make cloud computing secure anyway at Amazon because that's their bread and butter. Now you've got two teams with the same motive, right, and they're going to talk to each other without any bottlenecks. So I do think for any large enterprise, this is a magic formula: to identify the peers and to talk to them as much as you possibly can."
Cloud means enterprises need to move beyond a routine customer-vendor relationship, requiring a deeper level of collaboration. Shams and Sodastrom sit on cloud vendors' customer advisory boards, letting them have input into the direction of product development.
"We provide insights into how cloud is being used in our organisation and what are the features that are missing, or what are the key enablers that are missing, that will allow us to adopt cloud more effectively," Shams says.
NASA also has relationship with some cloud vendors' internal product teams. "They'll bounce some ideas off of us, and that helps us influence them, but it also helps us understand where things are going and it helps us get guidance to ensure that we're using the best practices."
The cloud changes IT
Shams says that Sodastrom's approach to IT at JPL has been a key factor in the shift to cloud. His approach and that of the Office of the CIO is to treat IT as an enabler of new capabilities, rather than a hindrance. Shams cites the example of cloud security — "IT security would be very cautious of, 'Hey! You mean you're going to tell your data on whose servers?!"
"So what's Tom's doing with them for instance," Shams says, "is he's telling them don't say no — say how? Or say, why not? So rather than 'Hey guys, don't do this', it's more like 'How do I do it more securely, more effectively and if really I can't, if I'm really doing something very stupid, tell me what else I can do to still meet my requirements.'"
JPL is still adjusting to the impact that cloud has on how IT operates, for example the shift from capital expenditure to operational expenditure. At first this shift made some project managers uneasy, Shams says, because of the impression that this would make their budgets more unpredictable. However, "they quickly realised they have more control of the budget now all of sudden because they can control how much capacity they can invest in."
"Typically if you bought a bunch of hardware before the mission started producing data you might not even realise that you've bought too much or too little," Shams says.
"So now, based on the amount of money you have available and based on the changing requirements, you have the agility to redefine how much infrastructure you're actually going to use and pay for.
"We are noticing so, for instance, for some of the projects I'm working on, when I'm putting the budgets [together] I'm actually putting in operational cost — this is how much money we're intending to spend every month — rather than at the start of the project I'll go buy these 40 terabytes of hard drives and set them up accordingly."
"It's literally: as the project progresses we'll continue to pay a monthly [fee]," Shams says.
Although it was AWS's cloud that did the heavy lifting for Shams data pipeline, NASA has a multi-cloud approach.
The agency has an internal document that sets out its strategy for cloud computing, as identified by Soderstrom. The idea boils down to 'Use the right cloud for the right job'.
Soderstrom developed a tool called CASM: the Cloud Applicability Suitability Model. It's a simple questionnaire that NASA stuff can fill in, answering questions about their project's needs — latency requirements, regulatory requirements and the data to compute ratio, for example.
"Based on these questions, we assess whether their data belongs in our private cloud or in the public cloud, and within the public cloud, it's 'Which public cloud?" Shams says.
"And within the private cloud, does it belong in the supercomputer centre, does it belong in our regular data centre does it, belong in a virtualized environment with VMware, or does it belong in an Openstack environment... things like that."
"So these questionaries help us asses where to place the environment," he says.
"But there's no edict from NASA or anybody that says 'use Amazon' or 'use Microsoft' or 'use Google'. It's literally about having the right cloud for the right job, and it's literally on a per application basis that we make this decision."