OpenStack Juno Summit From a Swift Perspective

Last week Anders wrote about the growth in the OpenStack community and the huge shift in people asking about the project to people talking about running it. This transition is fantastic to see. As the Project Technical Lead for Swift, my week was spent giving talks, meeting users, getting feedback from deployers, and coordinating upcoming project development. Altogether a busy week, but one that I think was very positive, overall, for the Swift community. The summit started with a great end-user story that clearly demonstrates how Swift solves problems for modern applications. is a site that provides visualization of ocean currents. Specifically, it shows a world map, and when you click anywhere in the ocean, it shows you the 10-year debris pattern as if something were spilled into the water at the point you clicked. It’s a fun little app to play with.   adrift.orgBut it’s more than a toy. When Malaysia Airlines flight 370 disappeared, the debris patterns shown by was used to know where to look for airline wreckage. Unfortunately, all the extra attention given to the website caused it to stop responding under the load. The site operators could have added more web servers into a load balanced pool in order to handle the load. However, adding that complexity simply to serve static data from storage isn’t needed since the data is already stored in Swift. The site administrators realized this, and the application was slightly changed to directly serve the data to the end-users. In other words, web browsers load the application and directly fetch the ocean current data from a Swift cluster. By doing this, was able to solve its scaling problems without needing to deploy new hardware or add additional complexity into the system. This story of how Swift solved scaling problems for a web application perfectly set the stage for the week. The entire week was full of people looking at Swift as a way to offload the hard problems of storage. And whether it was Swift 101storage policiesglobal clusters with very low TCO, or extending swift, we saw full rooms, dozens of questions, and overall massive interest from people with real-world problems to solve today. As we moved from the conference into the Swift design sessions, it was great to take these use cases, questions, and experiences into account during the technical discussions. Technical discussions this year could be broadly grouped into three different categories. First, there were quite a few discussions around measuring Swift’s performance and improving it. Second, there was a great deal of interest in integrating other storage systems (both open-source and proprietary) into Swift. Third, we spent a good bit of time discussing the community itself and what steps we can take to make it more healthy. As Swift continues to grow, we must ensure that we have a strong community that encourages new contribution, including from non-developer sources. To improve on this front, we’re going to try a few new things. First, we’ll be using a new ”’swift-specs”’ repo to track ideas and allow for a little collaborative up-front design. Second, we’ll be adding “core sponsors” to submitted patches to ensure that patches aren’t left behind or abandoned. I’ll be sharing more information about both of these as we implement them in the community. Coming home from the summit in Atlanta, I’m convinced that Swift is solving real-world problems today in production. This is a testament to the entirety of Swift’s contributors for producing a quality storage engine that powers some of the world’s largest storage clouds today.