Troy Toman Keynote at OpenStack Summit - October 2012
Troy Toman Keynote at OpenStack Summit - October 2012
Troy Toman Keynote at OpenStack Summit - October 2012
Troy Toman Keynote at OpenStack Summit - October 2012
Troy Toman Keynote at OpenStack Summit - October 2012
Troy Toman Keynote at OpenStack Summit - October 2012
Troy Toman Keynote at OpenStack Summit - October 2012
Troy Toman Keynote at OpenStack Summit - October 2012
Troy Toman Keynote at OpenStack Summit - October 2012
Troy Toman Keynote at OpenStack Summit - October 2012
Troy Toman Keynote at OpenStack Summit - October 2012
Troy Toman Keynote at OpenStack Summit - October 2012
Troy Toman Keynote at OpenStack Summit - October 2012
Troy Toman Keynote at OpenStack Summit - October 2012
Troy Toman Keynote at OpenStack Summit - October 2012
Troy Toman Keynote at OpenStack Summit - October 2012
Troy Toman Keynote at OpenStack Summit - October 2012
Troy Toman Keynote at OpenStack Summit - October 2012
Troy Toman Keynote at OpenStack Summit - October 2012
Troy Toman Keynote at OpenStack Summit - October 2012
Troy Toman Keynote at OpenStack Summit - October 2012
Troy Toman Keynote at OpenStack Summit - October 2012
Troy Toman Keynote at OpenStack Summit - October 2012
Troy Toman Keynote at OpenStack Summit - October 2012
Troy Toman Keynote at OpenStack Summit - October 2012
Troy Toman Keynote at OpenStack Summit - October 2012
Troy Toman Keynote at OpenStack Summit - October 2012
Troy Toman Keynote at OpenStack Summit - October 2012
Troy Toman Keynote at OpenStack Summit - October 2012
Troy Toman Keynote at OpenStack Summit - October 2012
Troy Toman Keynote at OpenStack Summit - October 2012
Troy Toman Keynote at OpenStack Summit - October 2012
Troy Toman Keynote at OpenStack Summit - October 2012
Troy Toman Keynote at OpenStack Summit - October 2012
Troy Toman Keynote at OpenStack Summit - October 2012
Troy Toman Keynote at OpenStack Summit - October 2012
Troy Toman Keynote at OpenStack Summit - October 2012
Troy Toman Keynote at OpenStack Summit - October 2012
Troy Toman Keynote at OpenStack Summit - October 2012
Troy Toman Keynote at OpenStack Summit - October 2012
Troy Toman Keynote at OpenStack Summit - October 2012
Troy Toman Keynote at OpenStack Summit - October 2012
Troy Toman Keynote at OpenStack Summit - October 2012
Troy Toman Keynote at OpenStack Summit - October 2012
Troy Toman Keynote at OpenStack Summit - October 2012
Troy Toman Keynote at OpenStack Summit - October 2012
Troy Toman Keynote at OpenStack Summit - October 2012
Troy Toman Keynote at OpenStack Summit - October 2012
Upcoming SlideShare
Loading in...5
×

Troy Toman Keynote at OpenStack Summit - October 2012

406

Published on

Troy Toman's keynote presentation at the OpenStack Summit on October 17, 2012.

0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
406
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
0
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide
  • Good morning. I’m really honored to be up here and to share the room with so many OpenStackers. It’s really incredible how quickly and profoundly OpenStack has changed the future of computing and demonstrated the power of community.\nI feel a very personal attachment to the story of OpenStack. When OpenStack was formed, I was off in a corner of Rackspace working on data center automation software. Like many of you, I was excited by the potential of this new initiative and began looking for ways to get involved. In January of 2010, I was given the opportunity to lead Rackspace’s Cloud Servers engineering team. Since that day, I have become an OpenStack contributor, an OpenStack operator, an OpenStack user, a member of the OpenStack Foundation Board of Directors and now an OpenStack Summit keynote presenter.\nIt’s been an amazing journey and an incredible experience.\n\n
  • \nToday, I’d like to share some thoughts about this journey and where it’s leading us. \nFirst, I want to talk a bit about Rackspace’s journey and how we arrived at OpenStack.\nThink of this as OpenStack’s past.\nSecond, I will share some insights on key decisions we’ve made that have influenced how we contribute to, operate and consume OpenStack services at Rackspace today.\nThis will be OpenStack in the present. Lastly, I want to frame some of the challenges we as a community need to tackle going forward. While things have a come a long way in two years, it’s up to all of us to continue to push the OpenStack project into the future. \nSo, let’s take a few steps back and talk about the journey that got us here.\n\n
  • Rackspace’s interest in OpenStack was born out of a key inflection point for our cloud efforts... a crossroads. \nWhile we’re proud to have been one of the two founders of the project, along with NASA, we don’t think of ourselves as having “invented” OpenStack. That was done by the people in this room, and other OpenStack contributors who couldn’t be here, some of whom are sleeping right now in distant time zones or might be coding as we speak. Instead, I’d say that we’ve used OpenStack to re-invent Rackspace.\nBy early 2009, we had successfully bootstrapped our first generation cloud. We had put it together through acquisition and through homegrown engineering. It was the second largest public cloud in the world — and the one with the world’s best support. We were proud of it. It had great momentum and growth was exploding. We had learned a great deal about the space. But, we also realized where our weaknesses were. We had some foundational limitations. To be frank, we feared hitting a wall down the road. It didn’t take long to realize we had hit a cross roads and we had to do something different – we knew we had to rebuild significant portions – especially in the compute arena. We decided to start from scratch.\nWhat do you do when someone gives you the permission to start with a blank sheet of paper? As an engineering team, it’s both exhilarating and scary. After lots of thought and analysis of the best software and services we could find, we realized there were three core principles that would be at the heart of our project: open source, continuous delivery and leveraging the cloud to run the cloud. It was bold and ambitious. And we knew that if we did it right it would start a revolution.\nBut we had no idea how big and how fast it would grow… \nOPEN SOURCE\nThe inspiration for open source in our next generation cloud was easy. You only had to look at examples like Linux and Android to see the potential. Here were two open source projects that quickly became serious, disruptive competitors to the closed, proprietary incumbents. There were strong communities advancing systems quickly. We knew an open source cloud was the natural choice. We also know that a vibrant, truly open community was essential and that the ‘openness’ had to be real – not faked or manipulated. There were plenty of other so-called “open source” projects that were only open in the sense that source code was seen. We wanted much more. Our engineers at Rackspace were committed to build out the core of the cloud and have a global community of the best and the brightest contribute code to make it better. Make it a level playing field where everyone’s contributions were treated the same. \n\n
  • Please raise your hand if you were at the first OpenStack summit in Austin two years ago. \nWow. This thing has grown a little bit, right? \nFrom what I’m told, it was 100 or so people in a small room. The energy in the room was the first indication of how this was going to take off.\nI mention the first OpenStack gathering because that’s where the community first got together to discuss its plans. It was Rackspace and NASA teaming up with a global community of developers to launch an open cloud – a cloud built on open source software that would free users from the threat of vendor lock in, and leverage the vast wisdom and insight of the larger community, not just the two founding entities. \nI’m happy to say that we’ve done that. It’s something the community can be proud of. It’s a massive accomplishment that has altered the course of cloud computing and is paving the way for the future.\n\n
  • Fast forward a year to October 2011. Rackspace stood before many of you again. Who remembers the Boston OpenStack Summit? That’s where Diablo was released. It was a little rough around the edges and it took some advanced knowledge to really dig into it, but it was the first release that people really used. We launched our public cloud alpha based on OpenStack. That’s when it truly became clear just what momentum OpenStack had.\n\n
  • We’ve also come a long way from Diablo. Folsom was just released last month. Folsom is by far the most robust OpenStack release to date. It adds a host of new features that make OpenStack even more ready for primetime. Folsom contains updates to the OpenStack object storage, compute and dashboard systems. It features security enhancements like role-based access controls, trusted messaging and more. Folsom also delivers support for two highly-anticipated OpenStack projects that are integral to its continued growth: Quantum and Cinder. Quantum sets the stage for an exciting evolution of cloud networking capabilities which are crucial to making Infrastructure-as-a-Service a reality while Cinder raises block storage services to an appropriate level and help round out the OpenStack service architecture. \n\n
  • If you look over the lifespan of OpenStack leading up to Folsom, you’ll notice that Rackspace’s percentage of commits has gone down. That’s a good thing.It’s awesome It shows that the community is taking charge of the project and everyone is playing an active role. I want to be clear that Rackspace is committed to developing and making time to contribute more to OpenStack. We're hiring across areas that touch all projects. We’re staffing up to give our engineers more time to focus on the community and the promise of much bigger open cloud than any one company could produce. That is something our team deserves and is very excited about. If it excites you too, you should find me later.\n\n
  • Boston was also where we unveiled our plans to create an independent OpenStack Foundation to run this amazing project. It needed to be independent and not driven by corporate interests. I can tell you that my team was one of the loudest voices pushing for this independence. One year later, with the community is backed by a fully funded independent foundation that has a new board of directors, a technical committee and the start of a user committee. This is something that all of us have done as a community -- and everyone deserves to celebrate this significant milestone. At the same time, we must recognize the responsibility lies with all of us to make this community strong and keep it moving forward. \n\n
  • So with Folsom as the cornerstone, here’s a simple look at how we use OpenStack to power the Rackspace public cloud. \n\n
  • Since the last summit, here’s what we’ve launched at Rackspace, all powered by OpenStack. We know have Cloud Servers, Cloud Files, Cloud Databases and Private Cloud all of which run on OpenStack.\nLet’s dive into a couple of these in more detail.\n\n
  • Since the last summit, here’s what we’ve launched at Rackspace, all powered by OpenStack. We know have Cloud Servers, Cloud Files, Cloud Databases and Private Cloud all of which run on OpenStack.\nLet’s dive into a couple of these in more detail.\n\n
  • Since the last summit, here’s what we’ve launched at Rackspace, all powered by OpenStack. We know have Cloud Servers, Cloud Files, Cloud Databases and Private Cloud all of which run on OpenStack.\nLet’s dive into a couple of these in more detail.\n\n
  • Here’s what we do with cloud servers. We start with the building blocks of a standard OpenStack deployment. We’re running Cinder, Quantum, Nova, Swift, Glance and Melange. The compute and storage APIs are available to our customers. Glance leverages Swift for image storage. Nova talks to hundreds of hypervisors. That’s where we start. \n\n
  • Here’s what we do with cloud servers. We start with the building blocks of a standard OpenStack deployment. We’re running Cinder, Quantum, Nova, Swift, Glance and Melange. The compute and storage APIs are available to our customers. Glance leverages Swift for image storage. Nova talks to hundreds of hypervisors. That’s where we start. \n\n
  • So in each region, that allows us to run Cloud Servers, Cloud Files and Cloud Databases.\n
  • We repeat this deployment pattern in our data centers in Chicago.\n
  • We repeat this deployment pattern in our data centers in Chicago.\n
  • To get us here, we did some unique things. Like I mentioned before, along with our push for open source, we adopted these concepts of cloud on cloud and continuous delivery.\nWhen we dove head-first into open source, we knew that if an open cloud was going to take hold, we needed to not just sell it to customers, but to use it inside our company. We have to be operators and users. \n
  • Think of it as our own version of the movie Inception, based on OpenStack. Like a dream within a dream, we have to have a cloud on the cloud, or run Nova on Nova . We have to eat our own dog food.\nWe built our public cloud infrastructure to run on a private cloud instance of OpenStack. We call this Cloud on Cloud. We use OpenStack to run the control systems for our next generation public cloud. That’s a major difference compared to our first generation cloud. In that cloud, all control infrastructure ran on dedicated hardware. With Cloud on Cloud, if we need more API nodes or additional scheduling capacity, we can spin up more instances in our infrastructure cloud, which we call iNova. When upgrading nodes, we spin up new instances with the updated software and roll those into the load balancer. If things work as expected, the old instances are deleted. If there are issues, rollback is as simple as putting the old instances back in rotation. This blue/green deployment approach is a well known pattern. But, doing it in the cloud means we don’t have to have two sets of physical hardware standing around for the task. iNova gives us the ultimate insight into our own technology. We see what our customers see.\n\n
  • Another unique characteristic of our open cloud is the use of continuous integration, or continuous delivery. Continuous integration is a shining example of Rackspace’s commitment to OpenStack and its stability. It helps us stay close to the leading edge of the code. At any given time we’re only days off of trunk. In fact, our production system right now is based on October 10th. \n\nThat means we can have code vetted and tested with great speed. It ensures that the code that’s being put into production is stable and ready. It’s a model that makes sure every code change is run through automated tests so we can quickly make changes and confidently deploy updates. In the Folsom cycle, we’ve run thousands of tests and had roughly a million builds. Ultimately, this gives our customers the benefit of near-instant open innovation and lets us have the latest updates in production at lightning speed. It was the model that helped us run on Folsom before its commercial release.\nNow, we’re developers putting on our operators’ hats. With continuous integration we know that the code is tested and production ready. We can have updates ready to deploy from trunk to production within an hour if everything works correctly. We’re failing fast, fixing fast and moving fast. \nSo now we’ve built our public cloud on open source using cloud on cloud and continuous delivery. It was risky, to say the least. So, how’s it working out for us so far?\n\n
  • Another unique characteristic of our open cloud is the use of continuous integration, or continuous delivery. Continuous integration is a shining example of Rackspace’s commitment to OpenStack and its stability. It helps us stay close to the leading edge of the code. At any given time we’re only days off of trunk. In fact, our production system right now is based on October 10th. \n\nThat means we can have code vetted and tested with great speed. It ensures that the code that’s being put into production is stable and ready. It’s a model that makes sure every code change is run through automated tests so we can quickly make changes and confidently deploy updates. In the Folsom cycle, we’ve run thousands of tests and had roughly a million builds. Ultimately, this gives our customers the benefit of near-instant open innovation and lets us have the latest updates in production at lightning speed. It was the model that helped us run on Folsom before its commercial release.\nNow, we’re developers putting on our operators’ hats. With continuous integration we know that the code is tested and production ready. We can have updates ready to deploy from trunk to production within an hour if everything works correctly. We’re failing fast, fixing fast and moving fast. \nSo now we’ve built our public cloud on open source using cloud on cloud and continuous delivery. It was risky, to say the least. So, how’s it working out for us so far?\n\n
  • Another unique characteristic of our open cloud is the use of continuous integration, or continuous delivery. Continuous integration is a shining example of Rackspace’s commitment to OpenStack and its stability. It helps us stay close to the leading edge of the code. At any given time we’re only days off of trunk. In fact, our production system right now is based on October 10th. \n\nThat means we can have code vetted and tested with great speed. It ensures that the code that’s being put into production is stable and ready. It’s a model that makes sure every code change is run through automated tests so we can quickly make changes and confidently deploy updates. In the Folsom cycle, we’ve run thousands of tests and had roughly a million builds. Ultimately, this gives our customers the benefit of near-instant open innovation and lets us have the latest updates in production at lightning speed. It was the model that helped us run on Folsom before its commercial release.\nNow, we’re developers putting on our operators’ hats. With continuous integration we know that the code is tested and production ready. We can have updates ready to deploy from trunk to production within an hour if everything works correctly. We’re failing fast, fixing fast and moving fast. \nSo now we’ve built our public cloud on open source using cloud on cloud and continuous delivery. It was risky, to say the least. So, how’s it working out for us so far?\n\n
  • Another unique characteristic of our open cloud is the use of continuous integration, or continuous delivery. Continuous integration is a shining example of Rackspace’s commitment to OpenStack and its stability. It helps us stay close to the leading edge of the code. At any given time we’re only days off of trunk. In fact, our production system right now is based on October 10th. \n\nThat means we can have code vetted and tested with great speed. It ensures that the code that’s being put into production is stable and ready. It’s a model that makes sure every code change is run through automated tests so we can quickly make changes and confidently deploy updates. In the Folsom cycle, we’ve run thousands of tests and had roughly a million builds. Ultimately, this gives our customers the benefit of near-instant open innovation and lets us have the latest updates in production at lightning speed. It was the model that helped us run on Folsom before its commercial release.\nNow, we’re developers putting on our operators’ hats. With continuous integration we know that the code is tested and production ready. We can have updates ready to deploy from trunk to production within an hour if everything works correctly. We’re failing fast, fixing fast and moving fast. \nSo now we’ve built our public cloud on open source using cloud on cloud and continuous delivery. It was risky, to say the least. So, how’s it working out for us so far?\n\n
  • Another unique characteristic of our open cloud is the use of continuous integration, or continuous delivery. Continuous integration is a shining example of Rackspace’s commitment to OpenStack and its stability. It helps us stay close to the leading edge of the code. At any given time we’re only days off of trunk. In fact, our production system right now is based on October 10th. \n\nThat means we can have code vetted and tested with great speed. It ensures that the code that’s being put into production is stable and ready. It’s a model that makes sure every code change is run through automated tests so we can quickly make changes and confidently deploy updates. In the Folsom cycle, we’ve run thousands of tests and had roughly a million builds. Ultimately, this gives our customers the benefit of near-instant open innovation and lets us have the latest updates in production at lightning speed. It was the model that helped us run on Folsom before its commercial release.\nNow, we’re developers putting on our operators’ hats. With continuous integration we know that the code is tested and production ready. We can have updates ready to deploy from trunk to production within an hour if everything works correctly. We’re failing fast, fixing fast and moving fast. \nSo now we’ve built our public cloud on open source using cloud on cloud and continuous delivery. It was risky, to say the least. So, how’s it working out for us so far?\n\n
  • Another unique characteristic of our open cloud is the use of continuous integration, or continuous delivery. Continuous integration is a shining example of Rackspace’s commitment to OpenStack and its stability. It helps us stay close to the leading edge of the code. At any given time we’re only days off of trunk. In fact, our production system right now is based on October 10th. \n\nThat means we can have code vetted and tested with great speed. It ensures that the code that’s being put into production is stable and ready. It’s a model that makes sure every code change is run through automated tests so we can quickly make changes and confidently deploy updates. In the Folsom cycle, we’ve run thousands of tests and had roughly a million builds. Ultimately, this gives our customers the benefit of near-instant open innovation and lets us have the latest updates in production at lightning speed. It was the model that helped us run on Folsom before its commercial release.\nNow, we’re developers putting on our operators’ hats. With continuous integration we know that the code is tested and production ready. We can have updates ready to deploy from trunk to production within an hour if everything works correctly. We’re failing fast, fixing fast and moving fast. \nSo now we’ve built our public cloud on open source using cloud on cloud and continuous delivery. It was risky, to say the least. So, how’s it working out for us so far?\n\n
  • Well, let’s dig a little deeper into the numbers. In the last 12 months\n
  • we’ve built more than 1 million Nova instances. \nAnd since launching our open cloud on August First, \n
  • we’ve had well over 120 million API hits across our three regions. That’s a pretty impressive number. And we’re happy with the scale. Now let’s look at the stability. Our average API availability across all three zones is higher than ever. \n\nIt is currently better than 99.97 percent including scheduled maintenances. The API is more responsive, and servers are building faster.. This isn’t hype. It is a real, live testament to all the work this community has done. \n\nRackspace is now the open cloud company thanks to OpenStack and the contributions from many of you here today. This is a time for all of us to be proud as a community. Something that was just an idea two years ago is now powering the world’s largest open cloud. This is huge.\n\n\n
  • This is all real and in production today. We launched this on August 1st to all Rackspace cloud customers. And our customers are voting with their feet. We’ve never turned off the option for customers to choose between our two cloud platforms, but from the day that we turned on our open cloud offering, all of our cloud growth has moved to the OpenStack based environment. We are so confident in this new platform that we will be doing more to accelerate the move to OpenStack. And we’re doing phased rollout of a new feature that helps our customers move from our first generation cloud to the open cloud. With the push of a button in our control panel, you can now snapshot a first generation cloud server directly into Glance \n
  • and relaunch that server in the open cloud. Some of our customers are already taking advantage of this option. \n
  • Customers are using this, they love it, and we’re just starting the rollout.\n\n
  • And we’re not stopping at the public cloud. Rackspace’s OpenStack innovation goes well beyond that. We want to drive OpenStack adoption everywhere. In August, we released our Private Cloud Software powered by OpenStack – code named “Alamo.” \n\n
  • The free, downloadable software offers the ability to go from bare metal to a private OpenStack cloud in less than an hour. You get the same OpenStack cloud that we run at Rackspace, but in your own data center. \nAlamo has proven itself as one of the easiest way to start using OpenStack today. \nAlamo eliminates the headache of having to worry about dozens of different configurations. We’re basically providing an open cloud environment that marries the speed and scalability of our OpenStack-based public cloud with the control and reliability of a private, dedicated cloud environment. This delivers on another one of our promises: The ability to deploy an open cloud anywhere, whether it’s in our data center, your data center or in another data center altogether.\nAnd it’s important to note that Alamo deploys directly from trunk. It is based on pure community OpenStack. We have believed since the project was launched that customers should always be able to use community code to stand up a cloud. They should not be required to buy a proprietary licensed version. Proprietary solutions play critical roles too, but we believe that the core compute, storage and network capabilities of OpenStack form an important kernel that should be commoditized and open. The ecosystem should build its services and solutions under, around and on top of that. That is exactly what we are doing at Rackspace.\nSo what’s been the reception for this? \n\n\n
  • In less than two months, Alamo has already been downloaded by at least a quarter of the Fortune 100 and by organizations \n
  • in 125 countries on all seven continents – yes, that includes Antarctica. There are international household names across all major verticals and sectors that have downloaded Alamo already, and more than 100 colleges, universities and research centers are excited about the proposition of an OpenStack private cloud.\nWhat’s more? It’s been downloaded by at least 10 percent of Amazon’s reference customers. If that’s not a sign that Amazon’s customers fear lock-in, I don’t know what is. Why else would they be looking at an alternative? These companies are publicly recommending AWS, yet quietly looking for a way out. That’s affirmation that we’re on the right path. When their most vocal customers are start plotting an escape route, you know you’ve got something.\nAlamo has proven itself as one of the easiest way to start using OpenStack today. \n\nAlamo eliminates the headache of having to worry about dozens of different configurations. We’re basically providing an open cloud environment that marries the speed and scalability of our OpenStack-based public cloud with the control and reliability of a private, dedicated cloud environment. This delivers on another one of our promises: The ability to deploy an open cloud anywhere, whether it’s in our data center, your data center or in another data center altogether.\nAnd it’s important to note that Alamo deploys directly from trunk. It is based on pure community OpenStack. We have believed since the project was launched that customers should always be able to use community code to stand up a cloud. They should not be required to buy a proprietary licensed version. Proprietary solutions play critical roles too, but we believe that the core compute, storage and network capabilities of OpenStack form an important kernel that should be commoditized and open. The ecosystem should build its services and solutions under, around and on top of that. That is exactly what we are doing at Rackspace.\n\n\n
  • in 125 countries on all seven continents – yes, that includes Antarctica. There are international household names across all major verticals and sectors that have downloaded Alamo already, and more than 100 colleges, universities and research centers are excited about the proposition of an OpenStack private cloud.\nWhat’s more? It’s been downloaded by at least 10 percent of Amazon’s reference customers. If that’s not a sign that Amazon’s customers fear lock-in, I don’t know what is. Why else would they be looking at an alternative? These companies are publicly recommending AWS, yet quietly looking for a way out. That’s affirmation that we’re on the right path. When their most vocal customers are start plotting an escape route, you know you’ve got something.\nAlamo has proven itself as one of the easiest way to start using OpenStack today. \n\nAlamo eliminates the headache of having to worry about dozens of different configurations. We’re basically providing an open cloud environment that marries the speed and scalability of our OpenStack-based public cloud with the control and reliability of a private, dedicated cloud environment. This delivers on another one of our promises: The ability to deploy an open cloud anywhere, whether it’s in our data center, your data center or in another data center altogether.\nAnd it’s important to note that Alamo deploys directly from trunk. It is based on pure community OpenStack. We have believed since the project was launched that customers should always be able to use community code to stand up a cloud. They should not be required to buy a proprietary licensed version. Proprietary solutions play critical roles too, but we believe that the core compute, storage and network capabilities of OpenStack form an important kernel that should be commoditized and open. The ecosystem should build its services and solutions under, around and on top of that. That is exactly what we are doing at Rackspace.\n\n\n
  • So that’s what we’ve done so far with OpenStack, but what would a keynote be without something new? Let’s go back to our public cloud for a moment. We’re putting the finishing touches on Cloud Block Storage. This service, based on Cinder, gives our customer flexible volumes that can be attached or detached from servers and give customers a choice between high performance SSD storage and standard block storage.\n\n\n
  • We’re also in the final stages of our Cloud Networks preview. Cloud Networks extends our use of Quantum, and software defined networking to let users build and manage on-demand layer 2 private networks leveraging network isolation and port filtering. Think of it as private VLANs in the cloud. We have select customers running Cloud Block Storage and Cloud Networks in production now and both will be generally available in coming weeks. You’ll hear a lot more about them soon.\n\n
  • We’re not just delivering product. We also investing a lot in making these technologies more widely available and accessible.\nTo better prepare the IT world for this OpenStack boom, we just released a new set of training opportunities with the Rackspace Training Program for OpenStack. We’re offering developers and engineers the ability to showcase their OpenStack expertise by becoming Rackspace Certified Technicians, which proves they have the skills to leverage and operate an OpenStack Cloud.\nAnd more Rackspace training opportunities for various roles are on the horizon.\n\n
  • Another new thing we’re doing here at the Summit is launching a pair of new SDKs – for Java and for PHP – to give developers the language bindings they need to utilize open-source solutions and to truly embrace the open cloud. The Rackspace open cloud SDK for Java is based on the jclouds library and currently supports our Cloud Servers and Cloud Files offerings; while the open cloud SDK for PHP is based on an internally-developed library called php-opencloud that supports Cloud Servers, Cloud Networks, Cloud Files and Cloud Databases. I’d like to encourage developers to start contributing to these SDKs today. More SDKs are in the pipeline as we take a more active role in open source development versus just going it alone.\nIf you want to learn more about the SDKs, Rackspace’s Everett Taves is holding a session Thursday afternoon.\nThat’s a lot to digest in just a short time, but I think these advancements show how serious we at Rackspace are about OpenStack and open source.\n\n
  • We didn't get into OpenStack just to rebuild our cloud. To be honest, that would be a really expensive proposition. I can assure you that just rewriting our cloud for our customers would have been easier without design summits and mailing list arguments. We did this to help create a thriving community and ecosystem that is much larger than anything we could have done on our own. This community is incredibly important to us - not just to the royal 'us' as in Rackspace the company. But, 'us' as in the engineers at Rackspace who are committed to leaving their mark on the industry. At Rackspace, we've probably been a little distracted in the last six months as we had to hit our product milestones. We do have some obligations at the office, after all. But, going forward, we are going to double down on OpenStack and the community. As I said before, we’re actively hiring and we’re urging our engineers to focus on the community to build the open cloud.\nThis strong focus on the community will help us all bring OpenStack to the next level. With that in mind, I want to close by highlighting two areas where we, as a community, need to focus during the next year. Put bluntly: It’s time to stop driving major new features or new OpenStack projects. Instead, we need to really solidify what we have and make sure the open cloud is more than a marketing slogan.\n\n
  • Most of us in this room have heard the FUD that some analysts and others have been slinging lately about OpenStack. There have been some claims that OpenStack is not ready for the enterprise. I’m here to tell you that it is, and that’s thanks to everybody in this room. As I demonstrated earlier, it’s being widely used today. The product is solid and reliable. You don’t need to be as aggressive as we are at Rackspace. You can run the latest trunk – just start with Folsom. \nHowever, there are still too many hugely disruptive changes happening in the code. It’s moving so fast that we actually had to ratchet back how often we pull trunk into our pipeline. The constant influx and volatility of code prompted us to take a step back and let it slow down and stabilize. We as a community need to embrace a mindset that stability isn’t just a six month goal or something that a single release enables. Instead, we’re charged with ensuring that OpenStack’s path continues to be reliable and stable and show enterprises that it’s trustworthy for their cloud environments.\nWe need to smooth out some of the lumps. The velocity of this project is such that we need to be cautious in how we move forward. We’ve taken advantage of the velocity and provided an OpenStack platform that is stable for this point in time, but we need to ensure it’s stable for the long haul. We have to make it easy. If you’re moving to the cloud, you have to embrace change. It’s not going to be a once a year, forklift upgrade. It’s going to be a continuous path. We need to band together to make that road less bumpy. (MFI – comment on internal contract changes and taking these more seriously, making API robust and more stable, and data migration upgrade paths). \nI don’t expect to pull nightly builds without some bumps just yet. However, assuring users of a seamless upgrade experience as we move from Folsom to Grizzly should be priority number one and a bare minimum starting point. It’s hard to imagine anyone but early adopters wanting to use OpenStack without seeing that commitment. As developers, we need to also keep in mind that any changes we make inflict pain on the community that has already deployed the code. Let’s be more mindful of that. I hope that the whole community, led by the newly formed Technical Committee, the User Committee, and the Board, will make user concerns our top priority during this release cycle.\n\n
  • We at Rackspace are going to work hard to do our part. You will see us push more tests drive up the stack and into the standard OpenStack CI environment. \nWe’re going to expand the reach of Rackspace testing. \nWe also want to work on to provide visibility to our pipeline across the community. Our commitment to have more resources engaged in the community extends to our QE teams. We don’t expect to gate trunk based on our downstream testing – but more visibility can only help and we’ll invest the resources to make that real. \nAnd we want our pipeline to include a deployment model that incorporates private cloud and our own platform services. In particular, we’ll do more gated testing at Rackspace around KVM and container-based Nova deployments.\n\n
  • Along with ensuring OpenStack’s stability, we need to engage as a community to realize the potential of a truly open, community driven cloud.\n\n\n\n\n\n
  • By this time next year we should be able to talk in depth about seamless hybrid cloud functionality. I’m not just talking about tying Rackspace customers together. I mean we need environments that marry public and private clouds from multiple OpenStack providers. We’ve got a lot of work to do to get our own house in order at Rackspace. We run different API extensions, network models and hypervisors. But, we’re working furiously to integrate our public and private clouds more seamlessly. Our users are demanding this. This is not just something we at Rackspace want to do, it’s something that users want for all of OpenStack. To get there, we have to solidify API compatibility and sharpen the network model to allow for seamless compatibility. \nTo achieve these hybrid capabilities, it’s critical that we work toward a vision of federation across OpenStack clouds. OpenStack provides a core framework for managing and provisioning compute, networking and storage. And we should all push for that core to stay robust and stable. But we must also push to drive real interoperability. That’s where the ultimate value of OpenStack will emerge and it will play a major role in pushing the open cloud forward. The core concepts and the native APIs must be robust and consistent to enable interoperability. Everyone has to become interested in the idea of interoperability. The OpenStack board realizes this and it’s among our most important initiatives. Interoperability will be key to OpenStack’s advancement.\nWe’re starting this at Rackspace, but the goal is to have it spread throughout all of OpenStack. The real open cloud occurs when you have OpenStack everywhere and it all works together. Like I said, we’re starting our work on this at Rackspace and we’re doing what we can control. \n\n
  • By this time next year we should be able to talk in depth about seamless hybrid cloud functionality. I’m not just talking about tying Rackspace customers together. I mean we need environments that marry public and private clouds from multiple OpenStack providers. We’ve got a lot of work to do to get our own house in order at Rackspace. We run different API extensions, network models and hypervisors. But, we’re working furiously to integrate our public and private clouds more seamlessly. Our users are demanding this. This is not just something we at Rackspace want to do, it’s something that users want for all of OpenStack. To get there, we have to solidify API compatibility and sharpen the network model to allow for seamless compatibility. \nTo achieve these hybrid capabilities, it’s critical that we work toward a vision of federation across OpenStack clouds. OpenStack provides a core framework for managing and provisioning compute, networking and storage. And we should all push for that core to stay robust and stable. But we must also push to drive real interoperability. That’s where the ultimate value of OpenStack will emerge and it will play a major role in pushing the open cloud forward. The core concepts and the native APIs must be robust and consistent to enable interoperability. Everyone has to become interested in the idea of interoperability. The OpenStack board realizes this and it’s among our most important initiatives. Interoperability will be key to OpenStack’s advancement.\nWe’re starting this at Rackspace, but the goal is to have it spread throughout all of OpenStack. The real open cloud occurs when you have OpenStack everywhere and it all works together. Like I said, we’re starting our work on this at Rackspace and we’re doing what we can control. \n\n
  • By this time next year we should be able to talk in depth about seamless hybrid cloud functionality. I’m not just talking about tying Rackspace customers together. I mean we need environments that marry public and private clouds from multiple OpenStack providers. We’ve got a lot of work to do to get our own house in order at Rackspace. We run different API extensions, network models and hypervisors. But, we’re working furiously to integrate our public and private clouds more seamlessly. Our users are demanding this. This is not just something we at Rackspace want to do, it’s something that users want for all of OpenStack. To get there, we have to solidify API compatibility and sharpen the network model to allow for seamless compatibility. \nTo achieve these hybrid capabilities, it’s critical that we work toward a vision of federation across OpenStack clouds. OpenStack provides a core framework for managing and provisioning compute, networking and storage. And we should all push for that core to stay robust and stable. But we must also push to drive real interoperability. That’s where the ultimate value of OpenStack will emerge and it will play a major role in pushing the open cloud forward. The core concepts and the native APIs must be robust and consistent to enable interoperability. Everyone has to become interested in the idea of interoperability. The OpenStack board realizes this and it’s among our most important initiatives. Interoperability will be key to OpenStack’s advancement.\nWe’re starting this at Rackspace, but the goal is to have it spread throughout all of OpenStack. The real open cloud occurs when you have OpenStack everywhere and it all works together. Like I said, we’re starting our work on this at Rackspace and we’re doing what we can control. \n\n
  • By this time next year we should be able to talk in depth about seamless hybrid cloud functionality. I’m not just talking about tying Rackspace customers together. I mean we need environments that marry public and private clouds from multiple OpenStack providers. We’ve got a lot of work to do to get our own house in order at Rackspace. We run different API extensions, network models and hypervisors. But, we’re working furiously to integrate our public and private clouds more seamlessly. Our users are demanding this. This is not just something we at Rackspace want to do, it’s something that users want for all of OpenStack. To get there, we have to solidify API compatibility and sharpen the network model to allow for seamless compatibility. \nTo achieve these hybrid capabilities, it’s critical that we work toward a vision of federation across OpenStack clouds. OpenStack provides a core framework for managing and provisioning compute, networking and storage. And we should all push for that core to stay robust and stable. But we must also push to drive real interoperability. That’s where the ultimate value of OpenStack will emerge and it will play a major role in pushing the open cloud forward. The core concepts and the native APIs must be robust and consistent to enable interoperability. Everyone has to become interested in the idea of interoperability. The OpenStack board realizes this and it’s among our most important initiatives. Interoperability will be key to OpenStack’s advancement.\nWe’re starting this at Rackspace, but the goal is to have it spread throughout all of OpenStack. The real open cloud occurs when you have OpenStack everywhere and it all works together. Like I said, we’re starting our work on this at Rackspace and we’re doing what we can control. \n\n
  • By this time next year we should be able to talk in depth about seamless hybrid cloud functionality. I’m not just talking about tying Rackspace customers together. I mean we need environments that marry public and private clouds from multiple OpenStack providers. We’ve got a lot of work to do to get our own house in order at Rackspace. We run different API extensions, network models and hypervisors. But, we’re working furiously to integrate our public and private clouds more seamlessly. Our users are demanding this. This is not just something we at Rackspace want to do, it’s something that users want for all of OpenStack. To get there, we have to solidify API compatibility and sharpen the network model to allow for seamless compatibility. \nTo achieve these hybrid capabilities, it’s critical that we work toward a vision of federation across OpenStack clouds. OpenStack provides a core framework for managing and provisioning compute, networking and storage. And we should all push for that core to stay robust and stable. But we must also push to drive real interoperability. That’s where the ultimate value of OpenStack will emerge and it will play a major role in pushing the open cloud forward. The core concepts and the native APIs must be robust and consistent to enable interoperability. Everyone has to become interested in the idea of interoperability. The OpenStack board realizes this and it’s among our most important initiatives. Interoperability will be key to OpenStack’s advancement.\nWe’re starting this at Rackspace, but the goal is to have it spread throughout all of OpenStack. The real open cloud occurs when you have OpenStack everywhere and it all works together. Like I said, we’re starting our work on this at Rackspace and we’re doing what we can control. \n\n
  • By this time next year we should be able to talk in depth about seamless hybrid cloud functionality. I’m not just talking about tying Rackspace customers together. I mean we need environments that marry public and private clouds from multiple OpenStack providers. We’ve got a lot of work to do to get our own house in order at Rackspace. We run different API extensions, network models and hypervisors. But, we’re working furiously to integrate our public and private clouds more seamlessly. Our users are demanding this. This is not just something we at Rackspace want to do, it’s something that users want for all of OpenStack. To get there, we have to solidify API compatibility and sharpen the network model to allow for seamless compatibility. \nTo achieve these hybrid capabilities, it’s critical that we work toward a vision of federation across OpenStack clouds. OpenStack provides a core framework for managing and provisioning compute, networking and storage. And we should all push for that core to stay robust and stable. But we must also push to drive real interoperability. That’s where the ultimate value of OpenStack will emerge and it will play a major role in pushing the open cloud forward. The core concepts and the native APIs must be robust and consistent to enable interoperability. Everyone has to become interested in the idea of interoperability. The OpenStack board realizes this and it’s among our most important initiatives. Interoperability will be key to OpenStack’s advancement.\nWe’re starting this at Rackspace, but the goal is to have it spread throughout all of OpenStack. The real open cloud occurs when you have OpenStack everywhere and it all works together. Like I said, we’re starting our work on this at Rackspace and we’re doing what we can control. \n\n
  • By this time next year we should be able to talk in depth about seamless hybrid cloud functionality. I’m not just talking about tying Rackspace customers together. I mean we need environments that marry public and private clouds from multiple OpenStack providers. We’ve got a lot of work to do to get our own house in order at Rackspace. We run different API extensions, network models and hypervisors. But, we’re working furiously to integrate our public and private clouds more seamlessly. Our users are demanding this. This is not just something we at Rackspace want to do, it’s something that users want for all of OpenStack. To get there, we have to solidify API compatibility and sharpen the network model to allow for seamless compatibility. \nTo achieve these hybrid capabilities, it’s critical that we work toward a vision of federation across OpenStack clouds. OpenStack provides a core framework for managing and provisioning compute, networking and storage. And we should all push for that core to stay robust and stable. But we must also push to drive real interoperability. That’s where the ultimate value of OpenStack will emerge and it will play a major role in pushing the open cloud forward. The core concepts and the native APIs must be robust and consistent to enable interoperability. Everyone has to become interested in the idea of interoperability. The OpenStack board realizes this and it’s among our most important initiatives. Interoperability will be key to OpenStack’s advancement.\nWe’re starting this at Rackspace, but the goal is to have it spread throughout all of OpenStack. The real open cloud occurs when you have OpenStack everywhere and it all works together. Like I said, we’re starting our work on this at Rackspace and we’re doing what we can control. \n\n
  • By this time next year we should be able to talk in depth about seamless hybrid cloud functionality. I’m not just talking about tying Rackspace customers together. I mean we need environments that marry public and private clouds from multiple OpenStack providers. We’ve got a lot of work to do to get our own house in order at Rackspace. We run different API extensions, network models and hypervisors. But, we’re working furiously to integrate our public and private clouds more seamlessly. Our users are demanding this. This is not just something we at Rackspace want to do, it’s something that users want for all of OpenStack. To get there, we have to solidify API compatibility and sharpen the network model to allow for seamless compatibility. \nTo achieve these hybrid capabilities, it’s critical that we work toward a vision of federation across OpenStack clouds. OpenStack provides a core framework for managing and provisioning compute, networking and storage. And we should all push for that core to stay robust and stable. But we must also push to drive real interoperability. That’s where the ultimate value of OpenStack will emerge and it will play a major role in pushing the open cloud forward. The core concepts and the native APIs must be robust and consistent to enable interoperability. Everyone has to become interested in the idea of interoperability. The OpenStack board realizes this and it’s among our most important initiatives. Interoperability will be key to OpenStack’s advancement.\nWe’re starting this at Rackspace, but the goal is to have it spread throughout all of OpenStack. The real open cloud occurs when you have OpenStack everywhere and it all works together. Like I said, we’re starting our work on this at Rackspace and we’re doing what we can control. \n\n
  • By this time next year we should be able to talk in depth about seamless hybrid cloud functionality. I’m not just talking about tying Rackspace customers together. I mean we need environments that marry public and private clouds from multiple OpenStack providers. We’ve got a lot of work to do to get our own house in order at Rackspace. We run different API extensions, network models and hypervisors. But, we’re working furiously to integrate our public and private clouds more seamlessly. Our users are demanding this. This is not just something we at Rackspace want to do, it’s something that users want for all of OpenStack. To get there, we have to solidify API compatibility and sharpen the network model to allow for seamless compatibility. \nTo achieve these hybrid capabilities, it’s critical that we work toward a vision of federation across OpenStack clouds. OpenStack provides a core framework for managing and provisioning compute, networking and storage. And we should all push for that core to stay robust and stable. But we must also push to drive real interoperability. That’s where the ultimate value of OpenStack will emerge and it will play a major role in pushing the open cloud forward. The core concepts and the native APIs must be robust and consistent to enable interoperability. Everyone has to become interested in the idea of interoperability. The OpenStack board realizes this and it’s among our most important initiatives. Interoperability will be key to OpenStack’s advancement.\nWe’re starting this at Rackspace, but the goal is to have it spread throughout all of OpenStack. The real open cloud occurs when you have OpenStack everywhere and it all works together. Like I said, we’re starting our work on this at Rackspace and we’re doing what we can control. \n\n
  • By this time next year we should be able to talk in depth about seamless hybrid cloud functionality. I’m not just talking about tying Rackspace customers together. I mean we need environments that marry public and private clouds from multiple OpenStack providers. We’ve got a lot of work to do to get our own house in order at Rackspace. We run different API extensions, network models and hypervisors. But, we’re working furiously to integrate our public and private clouds more seamlessly. Our users are demanding this. This is not just something we at Rackspace want to do, it’s something that users want for all of OpenStack. To get there, we have to solidify API compatibility and sharpen the network model to allow for seamless compatibility. \nTo achieve these hybrid capabilities, it’s critical that we work toward a vision of federation across OpenStack clouds. OpenStack provides a core framework for managing and provisioning compute, networking and storage. And we should all push for that core to stay robust and stable. But we must also push to drive real interoperability. That’s where the ultimate value of OpenStack will emerge and it will play a major role in pushing the open cloud forward. The core concepts and the native APIs must be robust and consistent to enable interoperability. Everyone has to become interested in the idea of interoperability. The OpenStack board realizes this and it’s among our most important initiatives. Interoperability will be key to OpenStack’s advancement.\nWe’re starting this at Rackspace, but the goal is to have it spread throughout all of OpenStack. The real open cloud occurs when you have OpenStack everywhere and it all works together. Like I said, we’re starting our work on this at Rackspace and we’re doing what we can control. \n\n
  • By this time next year we should be able to talk in depth about seamless hybrid cloud functionality. I’m not just talking about tying Rackspace customers together. I mean we need environments that marry public and private clouds from multiple OpenStack providers. We’ve got a lot of work to do to get our own house in order at Rackspace. We run different API extensions, network models and hypervisors. But, we’re working furiously to integrate our public and private clouds more seamlessly. Our users are demanding this. This is not just something we at Rackspace want to do, it’s something that users want for all of OpenStack. To get there, we have to solidify API compatibility and sharpen the network model to allow for seamless compatibility. \nTo achieve these hybrid capabilities, it’s critical that we work toward a vision of federation across OpenStack clouds. OpenStack provides a core framework for managing and provisioning compute, networking and storage. And we should all push for that core to stay robust and stable. But we must also push to drive real interoperability. That’s where the ultimate value of OpenStack will emerge and it will play a major role in pushing the open cloud forward. The core concepts and the native APIs must be robust and consistent to enable interoperability. Everyone has to become interested in the idea of interoperability. The OpenStack board realizes this and it’s among our most important initiatives. Interoperability will be key to OpenStack’s advancement.\nWe’re starting this at Rackspace, but the goal is to have it spread throughout all of OpenStack. The real open cloud occurs when you have OpenStack everywhere and it all works together. Like I said, we’re starting our work on this at Rackspace and we’re doing what we can control. \n\n
  • By this time next year we should be able to talk in depth about seamless hybrid cloud functionality. I’m not just talking about tying Rackspace customers together. I mean we need environments that marry public and private clouds from multiple OpenStack providers. We’ve got a lot of work to do to get our own house in order at Rackspace. We run different API extensions, network models and hypervisors. But, we’re working furiously to integrate our public and private clouds more seamlessly. Our users are demanding this. This is not just something we at Rackspace want to do, it’s something that users want for all of OpenStack. To get there, we have to solidify API compatibility and sharpen the network model to allow for seamless compatibility. \nTo achieve these hybrid capabilities, it’s critical that we work toward a vision of federation across OpenStack clouds. OpenStack provides a core framework for managing and provisioning compute, networking and storage. And we should all push for that core to stay robust and stable. But we must also push to drive real interoperability. That’s where the ultimate value of OpenStack will emerge and it will play a major role in pushing the open cloud forward. The core concepts and the native APIs must be robust and consistent to enable interoperability. Everyone has to become interested in the idea of interoperability. The OpenStack board realizes this and it’s among our most important initiatives. Interoperability will be key to OpenStack’s advancement.\nWe’re starting this at Rackspace, but the goal is to have it spread throughout all of OpenStack. The real open cloud occurs when you have OpenStack everywhere and it all works together. Like I said, we’re starting our work on this at Rackspace and we’re doing what we can control. \n\n
  • By this time next year we should be able to talk in depth about seamless hybrid cloud functionality. I’m not just talking about tying Rackspace customers together. I mean we need environments that marry public and private clouds from multiple OpenStack providers. We’ve got a lot of work to do to get our own house in order at Rackspace. We run different API extensions, network models and hypervisors. But, we’re working furiously to integrate our public and private clouds more seamlessly. Our users are demanding this. This is not just something we at Rackspace want to do, it’s something that users want for all of OpenStack. To get there, we have to solidify API compatibility and sharpen the network model to allow for seamless compatibility. \nTo achieve these hybrid capabilities, it’s critical that we work toward a vision of federation across OpenStack clouds. OpenStack provides a core framework for managing and provisioning compute, networking and storage. And we should all push for that core to stay robust and stable. But we must also push to drive real interoperability. That’s where the ultimate value of OpenStack will emerge and it will play a major role in pushing the open cloud forward. The core concepts and the native APIs must be robust and consistent to enable interoperability. Everyone has to become interested in the idea of interoperability. The OpenStack board realizes this and it’s among our most important initiatives. Interoperability will be key to OpenStack’s advancement.\nWe’re starting this at Rackspace, but the goal is to have it spread throughout all of OpenStack. The real open cloud occurs when you have OpenStack everywhere and it all works together. Like I said, we’re starting our work on this at Rackspace and we’re doing what we can control. \n\n
  • By this time next year we should be able to talk in depth about seamless hybrid cloud functionality. I’m not just talking about tying Rackspace customers together. I mean we need environments that marry public and private clouds from multiple OpenStack providers. We’ve got a lot of work to do to get our own house in order at Rackspace. We run different API extensions, network models and hypervisors. But, we’re working furiously to integrate our public and private clouds more seamlessly. Our users are demanding this. This is not just something we at Rackspace want to do, it’s something that users want for all of OpenStack. To get there, we have to solidify API compatibility and sharpen the network model to allow for seamless compatibility. \nTo achieve these hybrid capabilities, it’s critical that we work toward a vision of federation across OpenStack clouds. OpenStack provides a core framework for managing and provisioning compute, networking and storage. And we should all push for that core to stay robust and stable. But we must also push to drive real interoperability. That’s where the ultimate value of OpenStack will emerge and it will play a major role in pushing the open cloud forward. The core concepts and the native APIs must be robust and consistent to enable interoperability. Everyone has to become interested in the idea of interoperability. The OpenStack board realizes this and it’s among our most important initiatives. Interoperability will be key to OpenStack’s advancement.\nWe’re starting this at Rackspace, but the goal is to have it spread throughout all of OpenStack. The real open cloud occurs when you have OpenStack everywhere and it all works together. Like I said, we’re starting our work on this at Rackspace and we’re doing what we can control. \n\n
  • By this time next year we should be able to talk in depth about seamless hybrid cloud functionality. I’m not just talking about tying Rackspace customers together. I mean we need environments that marry public and private clouds from multiple OpenStack providers. We’ve got a lot of work to do to get our own house in order at Rackspace. We run different API extensions, network models and hypervisors. But, we’re working furiously to integrate our public and private clouds more seamlessly. Our users are demanding this. This is not just something we at Rackspace want to do, it’s something that users want for all of OpenStack. To get there, we have to solidify API compatibility and sharpen the network model to allow for seamless compatibility. \nTo achieve these hybrid capabilities, it’s critical that we work toward a vision of federation across OpenStack clouds. OpenStack provides a core framework for managing and provisioning compute, networking and storage. And we should all push for that core to stay robust and stable. But we must also push to drive real interoperability. That’s where the ultimate value of OpenStack will emerge and it will play a major role in pushing the open cloud forward. The core concepts and the native APIs must be robust and consistent to enable interoperability. Everyone has to become interested in the idea of interoperability. The OpenStack board realizes this and it’s among our most important initiatives. Interoperability will be key to OpenStack’s advancement.\nWe’re starting this at Rackspace, but the goal is to have it spread throughout all of OpenStack. The real open cloud occurs when you have OpenStack everywhere and it all works together. Like I said, we’re starting our work on this at Rackspace and we’re doing what we can control. \n\n
  • By this time next year we should be able to talk in depth about seamless hybrid cloud functionality. I’m not just talking about tying Rackspace customers together. I mean we need environments that marry public and private clouds from multiple OpenStack providers. We’ve got a lot of work to do to get our own house in order at Rackspace. We run different API extensions, network models and hypervisors. But, we’re working furiously to integrate our public and private clouds more seamlessly. Our users are demanding this. This is not just something we at Rackspace want to do, it’s something that users want for all of OpenStack. To get there, we have to solidify API compatibility and sharpen the network model to allow for seamless compatibility. \nTo achieve these hybrid capabilities, it’s critical that we work toward a vision of federation across OpenStack clouds. OpenStack provides a core framework for managing and provisioning compute, networking and storage. And we should all push for that core to stay robust and stable. But we must also push to drive real interoperability. That’s where the ultimate value of OpenStack will emerge and it will play a major role in pushing the open cloud forward. The core concepts and the native APIs must be robust and consistent to enable interoperability. Everyone has to become interested in the idea of interoperability. The OpenStack board realizes this and it’s among our most important initiatives. Interoperability will be key to OpenStack’s advancement.\nWe’re starting this at Rackspace, but the goal is to have it spread throughout all of OpenStack. The real open cloud occurs when you have OpenStack everywhere and it all works together. Like I said, we’re starting our work on this at Rackspace and we’re doing what we can control. \n\n
  • By this time next year we should be able to talk in depth about seamless hybrid cloud functionality. I’m not just talking about tying Rackspace customers together. I mean we need environments that marry public and private clouds from multiple OpenStack providers. We’ve got a lot of work to do to get our own house in order at Rackspace. We run different API extensions, network models and hypervisors. But, we’re working furiously to integrate our public and private clouds more seamlessly. Our users are demanding this. This is not just something we at Rackspace want to do, it’s something that users want for all of OpenStack. To get there, we have to solidify API compatibility and sharpen the network model to allow for seamless compatibility. \nTo achieve these hybrid capabilities, it’s critical that we work toward a vision of federation across OpenStack clouds. OpenStack provides a core framework for managing and provisioning compute, networking and storage. And we should all push for that core to stay robust and stable. But we must also push to drive real interoperability. That’s where the ultimate value of OpenStack will emerge and it will play a major role in pushing the open cloud forward. The core concepts and the native APIs must be robust and consistent to enable interoperability. Everyone has to become interested in the idea of interoperability. The OpenStack board realizes this and it’s among our most important initiatives. Interoperability will be key to OpenStack’s advancement.\nWe’re starting this at Rackspace, but the goal is to have it spread throughout all of OpenStack. The real open cloud occurs when you have OpenStack everywhere and it all works together. Like I said, we’re starting our work on this at Rackspace and we’re doing what we can control. \n\n
  • By this time next year we should be able to talk in depth about seamless hybrid cloud functionality. I’m not just talking about tying Rackspace customers together. I mean we need environments that marry public and private clouds from multiple OpenStack providers. We’ve got a lot of work to do to get our own house in order at Rackspace. We run different API extensions, network models and hypervisors. But, we’re working furiously to integrate our public and private clouds more seamlessly. Our users are demanding this. This is not just something we at Rackspace want to do, it’s something that users want for all of OpenStack. To get there, we have to solidify API compatibility and sharpen the network model to allow for seamless compatibility. \nTo achieve these hybrid capabilities, it’s critical that we work toward a vision of federation across OpenStack clouds. OpenStack provides a core framework for managing and provisioning compute, networking and storage. And we should all push for that core to stay robust and stable. But we must also push to drive real interoperability. That’s where the ultimate value of OpenStack will emerge and it will play a major role in pushing the open cloud forward. The core concepts and the native APIs must be robust and consistent to enable interoperability. Everyone has to become interested in the idea of interoperability. The OpenStack board realizes this and it’s among our most important initiatives. Interoperability will be key to OpenStack’s advancement.\nWe’re starting this at Rackspace, but the goal is to have it spread throughout all of OpenStack. The real open cloud occurs when you have OpenStack everywhere and it all works together. Like I said, we’re starting our work on this at Rackspace and we’re doing what we can control. \n\n
  • By this time next year we should be able to talk in depth about seamless hybrid cloud functionality. I’m not just talking about tying Rackspace customers together. I mean we need environments that marry public and private clouds from multiple OpenStack providers. We’ve got a lot of work to do to get our own house in order at Rackspace. We run different API extensions, network models and hypervisors. But, we’re working furiously to integrate our public and private clouds more seamlessly. Our users are demanding this. This is not just something we at Rackspace want to do, it’s something that users want for all of OpenStack. To get there, we have to solidify API compatibility and sharpen the network model to allow for seamless compatibility. \nTo achieve these hybrid capabilities, it’s critical that we work toward a vision of federation across OpenStack clouds. OpenStack provides a core framework for managing and provisioning compute, networking and storage. And we should all push for that core to stay robust and stable. But we must also push to drive real interoperability. That’s where the ultimate value of OpenStack will emerge and it will play a major role in pushing the open cloud forward. The core concepts and the native APIs must be robust and consistent to enable interoperability. Everyone has to become interested in the idea of interoperability. The OpenStack board realizes this and it’s among our most important initiatives. Interoperability will be key to OpenStack’s advancement.\nWe’re starting this at Rackspace, but the goal is to have it spread throughout all of OpenStack. The real open cloud occurs when you have OpenStack everywhere and it all works together. Like I said, we’re starting our work on this at Rackspace and we’re doing what we can control. \n\n
  • By this time next year we should be able to talk in depth about seamless hybrid cloud functionality. I’m not just talking about tying Rackspace customers together. I mean we need environments that marry public and private clouds from multiple OpenStack providers. We’ve got a lot of work to do to get our own house in order at Rackspace. We run different API extensions, network models and hypervisors. But, we’re working furiously to integrate our public and private clouds more seamlessly. Our users are demanding this. This is not just something we at Rackspace want to do, it’s something that users want for all of OpenStack. To get there, we have to solidify API compatibility and sharpen the network model to allow for seamless compatibility. \nTo achieve these hybrid capabilities, it’s critical that we work toward a vision of federation across OpenStack clouds. OpenStack provides a core framework for managing and provisioning compute, networking and storage. And we should all push for that core to stay robust and stable. But we must also push to drive real interoperability. That’s where the ultimate value of OpenStack will emerge and it will play a major role in pushing the open cloud forward. The core concepts and the native APIs must be robust and consistent to enable interoperability. Everyone has to become interested in the idea of interoperability. The OpenStack board realizes this and it’s among our most important initiatives. Interoperability will be key to OpenStack’s advancement.\nWe’re starting this at Rackspace, but the goal is to have it spread throughout all of OpenStack. The real open cloud occurs when you have OpenStack everywhere and it all works together. Like I said, we’re starting our work on this at Rackspace and we’re doing what we can control. \n\n
  • By this time next year we should be able to talk in depth about seamless hybrid cloud functionality. I’m not just talking about tying Rackspace customers together. I mean we need environments that marry public and private clouds from multiple OpenStack providers. We’ve got a lot of work to do to get our own house in order at Rackspace. We run different API extensions, network models and hypervisors. But, we’re working furiously to integrate our public and private clouds more seamlessly. Our users are demanding this. This is not just something we at Rackspace want to do, it’s something that users want for all of OpenStack. To get there, we have to solidify API compatibility and sharpen the network model to allow for seamless compatibility. \nTo achieve these hybrid capabilities, it’s critical that we work toward a vision of federation across OpenStack clouds. OpenStack provides a core framework for managing and provisioning compute, networking and storage. And we should all push for that core to stay robust and stable. But we must also push to drive real interoperability. That’s where the ultimate value of OpenStack will emerge and it will play a major role in pushing the open cloud forward. The core concepts and the native APIs must be robust and consistent to enable interoperability. Everyone has to become interested in the idea of interoperability. The OpenStack board realizes this and it’s among our most important initiatives. Interoperability will be key to OpenStack’s advancement.\nWe’re starting this at Rackspace, but the goal is to have it spread throughout all of OpenStack. The real open cloud occurs when you have OpenStack everywhere and it all works together. Like I said, we’re starting our work on this at Rackspace and we’re doing what we can control. \n\n
  • By this time next year we should be able to talk in depth about seamless hybrid cloud functionality. I’m not just talking about tying Rackspace customers together. I mean we need environments that marry public and private clouds from multiple OpenStack providers. We’ve got a lot of work to do to get our own house in order at Rackspace. We run different API extensions, network models and hypervisors. But, we’re working furiously to integrate our public and private clouds more seamlessly. Our users are demanding this. This is not just something we at Rackspace want to do, it’s something that users want for all of OpenStack. To get there, we have to solidify API compatibility and sharpen the network model to allow for seamless compatibility. \nTo achieve these hybrid capabilities, it’s critical that we work toward a vision of federation across OpenStack clouds. OpenStack provides a core framework for managing and provisioning compute, networking and storage. And we should all push for that core to stay robust and stable. But we must also push to drive real interoperability. That’s where the ultimate value of OpenStack will emerge and it will play a major role in pushing the open cloud forward. The core concepts and the native APIs must be robust and consistent to enable interoperability. Everyone has to become interested in the idea of interoperability. The OpenStack board realizes this and it’s among our most important initiatives. Interoperability will be key to OpenStack’s advancement.\nWe’re starting this at Rackspace, but the goal is to have it spread throughout all of OpenStack. The real open cloud occurs when you have OpenStack everywhere and it all works together. Like I said, we’re starting our work on this at Rackspace and we’re doing what we can control. \n\n
  • By this time next year we should be able to talk in depth about seamless hybrid cloud functionality. I’m not just talking about tying Rackspace customers together. I mean we need environments that marry public and private clouds from multiple OpenStack providers. We’ve got a lot of work to do to get our own house in order at Rackspace. We run different API extensions, network models and hypervisors. But, we’re working furiously to integrate our public and private clouds more seamlessly. Our users are demanding this. This is not just something we at Rackspace want to do, it’s something that users want for all of OpenStack. To get there, we have to solidify API compatibility and sharpen the network model to allow for seamless compatibility. \nTo achieve these hybrid capabilities, it’s critical that we work toward a vision of federation across OpenStack clouds. OpenStack provides a core framework for managing and provisioning compute, networking and storage. And we should all push for that core to stay robust and stable. But we must also push to drive real interoperability. That’s where the ultimate value of OpenStack will emerge and it will play a major role in pushing the open cloud forward. The core concepts and the native APIs must be robust and consistent to enable interoperability. Everyone has to become interested in the idea of interoperability. The OpenStack board realizes this and it’s among our most important initiatives. Interoperability will be key to OpenStack’s advancement.\nWe’re starting this at Rackspace, but the goal is to have it spread throughout all of OpenStack. The real open cloud occurs when you have OpenStack everywhere and it all works together. Like I said, we’re starting our work on this at Rackspace and we’re doing what we can control. \n\n
  • By this time next year we should be able to talk in depth about seamless hybrid cloud functionality. I’m not just talking about tying Rackspace customers together. I mean we need environments that marry public and private clouds from multiple OpenStack providers. We’ve got a lot of work to do to get our own house in order at Rackspace. We run different API extensions, network models and hypervisors. But, we’re working furiously to integrate our public and private clouds more seamlessly. Our users are demanding this. This is not just something we at Rackspace want to do, it’s something that users want for all of OpenStack. To get there, we have to solidify API compatibility and sharpen the network model to allow for seamless compatibility. \nTo achieve these hybrid capabilities, it’s critical that we work toward a vision of federation across OpenStack clouds. OpenStack provides a core framework for managing and provisioning compute, networking and storage. And we should all push for that core to stay robust and stable. But we must also push to drive real interoperability. That’s where the ultimate value of OpenStack will emerge and it will play a major role in pushing the open cloud forward. The core concepts and the native APIs must be robust and consistent to enable interoperability. Everyone has to become interested in the idea of interoperability. The OpenStack board realizes this and it’s among our most important initiatives. Interoperability will be key to OpenStack’s advancement.\nWe’re starting this at Rackspace, but the goal is to have it spread throughout all of OpenStack. The real open cloud occurs when you have OpenStack everywhere and it all works together. Like I said, we’re starting our work on this at Rackspace and we’re doing what we can control. \n\n
  • By this time next year we should be able to talk in depth about seamless hybrid cloud functionality. I’m not just talking about tying Rackspace customers together. I mean we need environments that marry public and private clouds from multiple OpenStack providers. We’ve got a lot of work to do to get our own house in order at Rackspace. We run different API extensions, network models and hypervisors. But, we’re working furiously to integrate our public and private clouds more seamlessly. Our users are demanding this. This is not just something we at Rackspace want to do, it’s something that users want for all of OpenStack. To get there, we have to solidify API compatibility and sharpen the network model to allow for seamless compatibility. \nTo achieve these hybrid capabilities, it’s critical that we work toward a vision of federation across OpenStack clouds. OpenStack provides a core framework for managing and provisioning compute, networking and storage. And we should all push for that core to stay robust and stable. But we must also push to drive real interoperability. That’s where the ultimate value of OpenStack will emerge and it will play a major role in pushing the open cloud forward. The core concepts and the native APIs must be robust and consistent to enable interoperability. Everyone has to become interested in the idea of interoperability. The OpenStack board realizes this and it’s among our most important initiatives. Interoperability will be key to OpenStack’s advancement.\nWe’re starting this at Rackspace, but the goal is to have it spread throughout all of OpenStack. The real open cloud occurs when you have OpenStack everywhere and it all works together. Like I said, we’re starting our work on this at Rackspace and we’re doing what we can control. \n\n
  • By this time next year we should be able to talk in depth about seamless hybrid cloud functionality. I’m not just talking about tying Rackspace customers together. I mean we need environments that marry public and private clouds from multiple OpenStack providers. We’ve got a lot of work to do to get our own house in order at Rackspace. We run different API extensions, network models and hypervisors. But, we’re working furiously to integrate our public and private clouds more seamlessly. Our users are demanding this. This is not just something we at Rackspace want to do, it’s something that users want for all of OpenStack. To get there, we have to solidify API compatibility and sharpen the network model to allow for seamless compatibility. \nTo achieve these hybrid capabilities, it’s critical that we work toward a vision of federation across OpenStack clouds. OpenStack provides a core framework for managing and provisioning compute, networking and storage. And we should all push for that core to stay robust and stable. But we must also push to drive real interoperability. That’s where the ultimate value of OpenStack will emerge and it will play a major role in pushing the open cloud forward. The core concepts and the native APIs must be robust and consistent to enable interoperability. Everyone has to become interested in the idea of interoperability. The OpenStack board realizes this and it’s among our most important initiatives. Interoperability will be key to OpenStack’s advancement.\nWe’re starting this at Rackspace, but the goal is to have it spread throughout all of OpenStack. The real open cloud occurs when you have OpenStack everywhere and it all works together. Like I said, we’re starting our work on this at Rackspace and we’re doing what we can control. \n\n
  • But there are three key areas that will push interoperability forward: \n•working toward API compatibility. \n•releasing interchangeable image formats;\n•and true cloud networking that leverages the full potential of Quantum. \nThrough interoperability and federation the open cloud becomes an OpenStack concept, not just a Rackspace concept. Let’s not blow this opportunity.\n\n\n\n\n\n
  • Let me finish here by thanking all of you for making this amazing journey possible. Together, we’ve all built a viable, well-funded foundation. Many of us have built products and services around OpenStack and have become part of a vibrant community of contributors.\nAt Rackspace, we continue to champion OpenStack and we continue to innovate. We’re not just along for the ride. Through continuous integration and our cloud on cloud initiatives, Rackspace is making unique contributions to the OpenStack movement. Contributions that we’re proud of, and contributions that are moving the project forward.\nWe want OpenStack to succeed. We’ve built our open cloud on it. We’ve bet our business on it. OpenStack is ready. It’s stable, and it keeps getting better.\nOver the next six months, we as a community must ensure a smooth upgrade path for OpenStack and ensure that interoperability is high on the agenda. This will foster the era of true cloud openness. We have to work together to counter all the FUD that gets slung at any technology that disrupts a comfortable, profitable status quo. And we have the code to shut that FUD down for good.\nToday, we run the biggest OpenStack implementation at Rackspace. It took everyone in this room to give us the confidence to trust our business to OpenStack. We knew that we wouldn’t go it alone. None of us will go it alone. We’re all in this together.\nAnd the best is yet to come. I can’t wait to dig in this week at the Summit. That’s what we’re all here for today; to really dig in and get to work. Let’s do it.\nThank you.\n\n
  • \n
  • ×