NASA's JPL Reaches for the CloudSpace Agency Sees Benefits from Cloud Computing
The NASA unit charged with deep-space exploration has created several public-facing cloud computing initiatives that didn't involve mission-critical data, but those experiences have given JPL as well as its cloud providers the background and understanding on how to secure data in the cloud. "The early explorers get hands on, and not hurt ourselves," Tomas Soderstrom, JPL IT chief technology officer, said in an interview with GovInfoSecurity.com.
"We've come in far enough where we're able to comfortably say that we'll be putting real mission data in the cloud ... we have validated that it can be secured if you do it right and it can certainly save a lot of time and money."
In the first of a two-part interview with GovInfoSecurity.com's Eric Chabrow, Soderstrom also addressed:
- Benefits of experimenting with a variety types of cloud offerings: public, private, hybrid and community.
- Importance of employing a cloud readiness levels, a 1-to-9 scale (thinking about a project through it becoming operational) that measures the stages of a cloud project. "Anything that can measured can be improved," he said.
- Identifying immediate gains cloud computing can offer NASA. "The challenge for us is to figure out what the low-hanging fruit is, and actually start using it and take real benefits from it now," Soderstrom said.
ERIC CHABROW: To start off, briefly tell us a bit about cloud computing initiatives at Jet Propulsion Laboratory and the National Aeronautics and Space Administration.
TOMAS SODERSTROM: Two years ago, we here at JPL looked for what are some of the emerging IT trends that we should be paying attention to, to try to get ready for them? The idea is to have it up and running by the time it becomes mission-critical. Cloud computing was one of those seven trends. Two years ago, we started looking at it, and of course, there was a lot of hype around cloud computing, and that should come as no surprise to anyone. But, two years ago, it was a little murkier. We decided to take an approach, a very simple approach that we called "Keeping It Real." And Keeping It Real meant that it needed to be real to the mission of JPL and NASA, which is not to do IT, but to enable the people who put rovers on Mars and explore outer space. We wanted to focus on mission application, and make it a collaborative approach, where it's a team effort between the JPL IT organization, the missions, the ones that put the rovers on Mars, etc., and our industry partners. That is how we went about it, and we've had some good results. Keeping It Real also meant to get hands-on experience with every cloud known to man at the time, and beyond.
CHABROW: Give us an example, or two, of some of these cloud initiatives.
SODERSTROM: The whole point here was there was a lot of hype, and there were some benefits that we laid out. But, also what would be the real obstacles that we would run into if we did this? An example of a successful foundation of the missions was we took 180,000 images from Saturn. They downloaded 180,000 images and we wanted to tile those, and put a mosaic around them, to process the images. We ran them through the lab and they took 15 days of straight 24 by 7 processing, and it still wasn't finished.
Then what we wanted to do was to "Let's tap Amazon's cloud," so we spun up 60 processors in Amazon's cloud, and we finished it in five hours for a total cost of $200. For us, that was a real validation. We took the real mission processing that missions would do, and we were able to start and stop it, and went from weeks to hours, and we were able to validate the costs, and we turned it off after it was done. But, that was on the missions side.
We also used it for outreach and crowd sourcing. We, for instance, partnered with Microsoft on something called "Be a Martian." If you type in beamartian.jpl.nasa.gov, it takes you to the website. It's essentially a game, and it lets us recruit citizen scientists, and what they can do is to peruse a quarter of a million pictures from Mars an identify craters, and hopefully find other evidence of water. It is a game, and it works very well, and all of that code and all of the images are stored in Microsoft's cloud.
We did the same thing in Google's cloud, where we are focusing on the next generation of explorers, so we partnered up with UCSD, the University of California at San Diego, and some of these college students wrote code, partnered with us, for elementary school kids, and those elementary school kids can now tag imagines on Mars and compete with each other. We have some other examples, in Amazon's cloud, where we recruited, basically, on eclipse, at EclipseCon, we had a contest where people could write code to drive a toy rover, a Lego rover that emulated Mars. And, it was fabulous, we got incredible code out of it, and also, people had fun, and they learned some things. It's a great example of crowd sourcing . The bottom line is we are Keeping It Real, and it's working out really well for us. We also have applications running in private clouds supplied by Lockheed Martin, and community clouds supplied by CSC-Terremark, and hybrid clouds, and of course, we're looking at an NASA Nebula Cloud, also. Lots of clouds going on.
Wheel of Security
CHABROW: What you just described is nonstrategic use of cloud computing, you weren't having, really any sensitive information on the cloud.
SODERSTROM: That's a very impressive takeaway because that was quite purposefully. In our strategy of looking at this, we said, What could we do in the clouds where the early explorers get hands-on and not hurt ourselves? We created what we called a "Wheel of Security," and the Wheel of Security essentially tags the public data, and then on another quadrant its sensitive data, and then it goes on to controlled information, private information, secure and top secret data.
What we did was we focused on the public data, to start, and we're now onto the sensitive data. In the meantime, we work with the vendors, to try to get them to take on some of the more difficult data, and by the time that they do, we will be ready for it. What we're now doing is we have come in far enough, where we are able to comfortably say that we will be putting real mission data in the cloud, and working with several project managers here at JPL, because we have validated that it can be secure, if you do it right, and it can certainly save a lot of time and money. The time factor is a huge deal. It's more than people anticipate. That is really, maybe, the biggest benefit of all, that you don't have to find space in the data center, that you can just rent time right now. So strategically, we're moving forward.
CHABROW: Your experiences working with Amazon and Google, Microsoft and others in the public cloud, are giving you a certain experience in learning how to validate data and other things that could maybe, eventually be useful, to deal with more sensitive information on a public cloud.
SODERSTROM: And, in fact, that's absolutely true. With each of the vendors, we met with their security teams, we met with expert control teams. They came down and visited and we visited them, to explain to them what we would have to pass, what kinds of audits, Federal Information Management Act certifications, etc., that we would need to pass, so that they can ready to take that on by the time we spin the wheel of security.
One of the exciting examples, for instance, is Amazon's virtual private cloud. It's like a hybrid cloud, and it lets us put more sensitive data, because we can encrypt it, and it's going through our own secure network, to get to the data. That's a good combination of a bridge between the private cloud, which is very secure and the public cloud, which is getting more and more secure. So, for real mission critical data, we'll encrypt all of it. The encryption keys will not live in the cloud but in our application. So, we feel comfortable that that will work.
CHABROW: You also mentioned that you are doing things with hybrids and product cloud, and community cloud. Let me just ask you, first of all, the community cloud - does it mean that you are sharing servers with similar types of organizations. Would these be other NAS organizations?
SODERSTROM: Other government organizations in this case. We have tested quite extensively with CSC-Terremark cloud, and we are comfortable that that is quite secure, and we can pass the audits that we need to pass.
When you look at our real goal, in addition to Keeping It Real, is to run the data and storage and computing where it's most appropriate, and the appropriateness is in terms of security, but also in terms of cost, longevity, latency, network speed, and things like that. What we needed to do is to figure out how to go about that. A year and a half ago, I went out looking to buy what we call a Cloud Application Suitability Model, or a CASM, and I couldn't find it, so we built our own. You basically fill out a questionnaire, the end user does, and it says, "What cloud should I put my application in?" You describe the application and this CASM, the Cloud Application Suitability Model essentially guides the user into going into this cloud. That then transfers into the IT organization of JPL, who fine tunes it a little bit. But, having this CASM is a real eye opener, so that we can then take on more and more mission-critical information as we move forward, in a more objective way, and having a way of evolving it, as opposed to it being somebody's personal judgment of the day, if you will.
CHABROW: And I gather this is a process that needs to be continuously updated, or not continuously, but periodically?
SODERSTROM: Continuously is too strong, but it's ... virtual control, but it's moving forward very quickly. The cloud is an old/new idea. If you don't virtualize, you really can't take advantage of a cloud, at last infrastructure as a service. Virtualization was the precursor, and there is lots of computerization and control that needs to go into it. The CASM is one new way of being able to both put the application in the right place, and then monitor its performance.
What we really need to be able to do is to avoid vendor lock-in. We want to be able to say, "This application currently runs in Cloud A, but for some reason we are not happy with Cloud A anymore, let's put it in Cloud B." And that needs to be automatic, push the button, and it puts it into that cloud. That is what our goal is, to avoid vendor lock in.
We're not real big believers in service level agreements, because what we really want to do is, this is so cheap anyway, that getting the money back is not the point, but being able to get the data back is the point. Having a service level understanding is better, but if it falls out of the understanding, then we will put it in somebody else's cloud. That is why we are experimenting with multiple clouds, because they are good at different things.
Initially, they are all good at something. Amazon is infrastructure service, Microsoft is platform service, Google is software service, but they are all going to be merging into being able to supply the whole thing. And of course, NASA Nebula is going to handle lots and lots of mass data. Being able to have a portfolio of applications, and a portfolio of applications and a portfolio of cloud offerings is the key and it happens, and it's right in the middle of that.
We have two other very key concepts, and we came up with lots of concepts. One of the benefits of working for NASA is there's lots of smart people, a whole lot smarter than I am. We've come up with some interesting topics. The Cloud Application Suitability Model was one. The Wheel of Security was another. The third one, which may be even bigger, we noticed that we needed some measurable way of making progress. We needed some way of measuring the maturity of cloud. So, we came up with something we call "Cloud Readiness Levels," or CRLs, and that's a takeoff on NASA's Technology Readiness Levels, or TRLs. And what that is, it goes from 1 to 9, and at a TRL 1, it's somebody is just thinking about it. When it goes all the way to stage 9, it means it's operational. We are applying the same thing to clouds, and then we can score ourselves and make measurable progress. And that was the key of CMMI (Capability Maturity Model Integration), it has a number to it. And anything that can be measured can be improved.
We have Cloud Readiness Levels for the institution. For instance, can you call the help desk and get help on your cloud, whether it's inside or outside or hybrid? And, there's levels 1 through 9 there. We have CRLs to apply readiness levels for applications, and that is cloud, the CASM is really the key to that. Can you put the application into the right place, and track it. And then, the most interesting one that came out of this was a cloud readiness level for the developers. What we found was, in order to really take advantage of the cloud of the future, we have to retool and change the way we develop applications. We need to mimic what the large public cloud vendors are doing, the Amazons and Googles, etc., expect that some of the applications will fail, and just restart them. That's not how we write applications today. We have to think about distributive applications in small unit chunks, and that is going to take a while to get there, but one way of getting there is to measure it and educate around it, and get the right tools in. Three Cloud Readiness Levels: institutions, applications and developers, and that will help us keep this thing from being a flash in the pan, but keep moving it forward, especially since we are seeing the real benefits, the net benefits, plus you take all the drawbacks. And we could have some unexpected obstacles pop up.
CHABROW: I'm listening to you, and it sounds like, with the cloud, this new paradigm, if you will, of developing applications, it sounds like constant beta testing.
SODERSTROM: You know, Google came up with a term - I don't know if they came up with the term, or somebody writing about them came up with the term - "perpetual data." When we write space applications that will live for 30 years, and our space crafts are, literally, Voyager is something like 15 billion, with a "b," miles away, those, and it's lasted for over 30 years, perpetual data is a little scary. But, there is something to it, and the something to it is you have to write in incremental ways these days, so that you can keep improving it. We can at least keep improving the ground system side of it. Yes, I think we are looking at the perpetual data of the clouds while it's shaking out. And we can take one of two approaches. One would be to wait and say we're not going to do anything until it's finished. We did not take that approach. We wanted to be early explorers of enabling concepts. We tested it, and we can now put new pieces into the cloud. The cloud matures, whereas the cloud vendors of choice matures. And that is the approach we took. It's perpetual data in the sense of what we put into the cloud.
CHABROW: Because you also write code for spacecraft that lasts, you know, literally decades, I guess, now, with some of your successes there ...
CHABROW: ... it's like a different mindset from one part of NASA to this newer area.
SODERSTROM: I think it is. One thing we came to realize pretty early on is there isn't a thing, really, called "The Cloud." It's all different offerings with different benefits, and the challenge for us is to figure out what the low hanging fruit is, and actually start using it, and take real benefit from it now. We've done that. We can take advantage of the cloud today, without retooling the developers. The future belongs to a different model of programming and partitioning and allocating. My boss is the CIO of JPL, and his name is Jim Renaldi, and he coined early on, he said, "What I really want to do is replace the procurement screen with a provisioning screen, and that means we don't want to buy, we want to rent, and we want to rent and change our mind quickly. Turn on, turn off, pay on, pay off." I sound like the Karate Kid there.
CHABROW: (Laughter) Hold on, I'm picturing now the brush going up and down, up and down.
SODERSTROM: Yeah, cloud on, cloud off.