Earlier this year Tom Soderstrom, IT CTO at NASA JPL, wrote a wonderful article called Six Ways to Avoid Cloud Missteps. In the article Mr. Soderstrom gives advice to enterprises who are either adopting cloud, or have already done so and are looking for guidance on how to best handle their cloud vendors.
We’ve talked about how JPL uses Scalr for cloud management before, but in honor of the release of our latest case study, I thought we could revisit JPL’s cloud journey and see what lessons can be learned.
So here are 5 lessons from JPL’s cloud journey, distilled from the collective knowledge offered by Mr. Soderstrom’s article, our JPL Case Study and the “How NASA Does Hybrid Cloud” talk that was given at the Vancouver OpenStack summit this last May.
1. Go hybrid: each cloud has a sweetspot
It’s going to be impossible to find one cloud vendor that answers your organization’s every need. JPL’s hybrid cloud is comprised out of OpenStack, AWS and Azure, and each plays a different role. JPL moved its entire public outreach website to AWS back in 2012 to accommodate the huge amount public interest (although it took one very specific photo to quite literally “break the internet” for JPL…). Public cloud is great for bursting and handling heavy workloads, but private cloud will make your life easier when it comes to compliance, data locality and reachability.
2. Hybrid cloud is hard
Having sung our songs of praise to hybrid cloud, it’s important to acknowledge the many problems it presents you with. You might have went with hybrid cloud to get the best of both worlds, private and public, but now you have to deal with issues like diverse APIs, multiple identities, security, governance and vendor lock-in. We need to make sure we’re not spending more time managing our clouds than actually reaping their benefits. JPL, much like many other organizations, found that there’s a need for an API abstraction layer to act as the point-of-contact for the entire hybrid cloud. The use of a Cloud Management Platform allows JPL to make sure everything is properly tagged, and conveniently portable. Which leads us to our next lesson…
3. Be ready to move
Like we mentioned previously, different clouds are good at different things. To be able to make the most out of your clouds of choice, and to avoid vendor lock-in, your applications need to be portable and cloud-agnostic. You need to be able to move your applications easily from one cloud to another. The aforementioned API abstraction layer can help you make sure that when you design an application blueprint, it’s deployable on multiple clouds.
4. Know who’s paying for what
This one is taken right out of Mr. Soderstrom’s article:
“Users only want to pay for what they used, so internal charge-backs become important.”
Have a clear way to communicate to end-users the costs of their infrastructure, and a way to keep track of general cloud spend. Mr. Soderstrom claims that in this case, perfection is the enemy of progress, and that you should focus on the things that constitute 80-90% of your overall hybrid cloud bill. For the remaining 10-20%, he recommends drafting a memorandum of understanding with your users to share evenly.
5. Success is measured from the end-user’s point of view
JPL measures success by the internal adoption of their programs and services. At the end of the day, if users use something, it means it works. Explaining the value of hybrid cloud and training your users to leverage it, along with bringing in all of your stakeholders together to a cloud partnership - will make your life easier down the line as the success of the cloud in the organization because a shared responsibility.
For more information, please check out our JPL Case Study.
For any questions or feedback, please don’t hesitate to contact me directly at firstname.lastname@example.org .
Thanks for reading,