 Okay. I know seating is a little bit limited, so if you do need to make room for anybody else, no, I'm kidding. Thank you, everybody. I know this is one of the later sessions in the day of day three of what is already a very action-packed summit, so I know if you're anything like myself, you might be a little bit tired, but I really appreciate you guys coming. We're here today to kind of run you through some of the experiences or learnings and how it's informed some of the things that we do from the vantage point of operators of OpenStack Private Clouds. By way of introduction, my name is Brian Thompson. I lead the product management group for the Rackspace OpenStack Private Cloud Practice, an area that we've been building and deploying and operating private clouds built on OpenStack for several years now. Thank you guys. Team endurance. Welcome. Steve Ribble, Senior Manager of Operations, and I work on the support side, serving our customers, looking to give them a great customer experience. So the topic of our session, and hopefully it wasn't misleading, but I thought being in Tokyo was a great opportunity to leverage or instill a little bit of Japanese culture into our presentation. So the concept or the tagline, if you read through the abstract of this presentation, we called it the difference between mud and clouds, which is built on a Japanese proverb saying there's a big difference between these two things. And the concept that we're really portraying with this is there's a very big difference in our view between installing and configuring OpenStack. I can deploy OpenStack and operating OpenStack. What does that journey look like? How do I think beyond what it takes to actually run these clouds? And this is an area that we focus very hard on in our business and serving our customers in supporting that. The first facet of this journey, if you will, and the things that I want to kind of talk through is how does that focus on the operating experience and what does it take to operate private clouds? How does that inform what we do as a product team within the Rackspace private cloud business? It kind of starts with this approach to product management. So you think of what we're providing and what many other entities here at the OpenStack Summit are providing, I'm going to start with a somewhat controversial statement, or it may seem as controversial, and it's this. Our product, what we provide, is not the software we write. It's not to take away from the importance of the software we write, it's not to diminish the work that goes into that, the resources that we put into it, but it fundamentally is not the product that Rackspace is providing. Our product is our ability to provide our customers with a support and operations experience around these private clouds. The software we write earns us the right, the privilege to provide that product to our customers. It's an important distinction because that's what we do as a company. We're focused on operating these clouds for customers, not just building them. It's a big piece that informs what we do and how we form that product. The other key statement that I'll make is our customer is not just who we invoice. It's not the person that we're asking to pay for our services. Again, this is from that product perspective of how are we defining and building these clouds and the services that we focus on. Our customer is really enabling those engineers, those empowered Rackspace engineers, that provide that experience. We're also enabling tooling and services that allow them to then deliver on that promise of an operational experience of that cloud and to be able to support our customers and grow and scale and upgrade and manage those cloud environments. These are important foundational components, if you will, as we start to think about what is our product and how do we inform product management around an open-stack private cloud solution. Some of the design principles to kind of build on that theme, again, it's that tail of two customers. One aspect of feature and functionality. We want to leverage what's coming from the community in open-stack. How do we enable the new services as they become available? But I need to do so in a way that I can provide that support experience around it. So as we think about the product offering and how we define these things, it's as much about enabling these functions to our customers as it is about enabling our support teams and operational teams to then deliver on that promise. It has to be a key focus. The other piece is we are heavily focused on not just day one. How do I install open-stack? What does day two look like? What does day 20 look like? What does this look like two years from now? I need to build a cloud that I can scale over time. I need to build a cloud that I can upgrade with new versions, new releases. I need to do that in a way where I don't have to tear it down and rebuild every time. That's a very important premise of what we do in a key area of focus that we bring. The next piece is if you've worked with Rackspace or one of the things that we really talk about when we build private clouds, we refer to it as an opinionated deployment. Open-stack, if you're familiar with it already or if you've learned through the course of this conference, is massive. I don't remember how many projects at any given point that keep evolving. If you look at NOVA itself, this foundational project around compute, there are over 700 configurable attributes of NOVA alone. You could build an open-stack cloud in a million different ways. There are literally an infinite number of combinations that you could build out. We have to be very opinionated to make sure we're doing it in a way that we can support our customers and that philosophy has to feed back into how we think about product management, how we're building and designing these clouds and how we're building a support offering around that so it can be done in a consistent, repeatable fashion while, again, still enabling those features that are ready for our customers and that we can support them. Part of this, and you'll see this as a recurring theme as we go through some of this presentation, is this life cycle of learn, deploy, test, learn, deploy, test, learn. We're growing with this, right? We continue to grow with Open-stack. We learn along the way. If you look at our offerings and things that we've done from a private cloud space over Open-stack release to Open-stack release, even our own architectures, we're learning from our customers. It informs what we do with the next one. How do we make it better? How do we continue to improve on this? And it's important to embrace that cycle and get that feedback loop as tight as you can. Lastly is this concept of release holder and stakeholder engagement. I'll talk about this a little bit further. We have, as you can imagine, a fairly large team between developers and engineers and product managers. We also have, of course, our support and operations teams, but we also have documentation folks and training folks. There's a lot of parties that need to be part of this cycle and they all have a voice at the table. So we continue to grow in this space and learn along the way. We've done some things to help enable them and make sure that we can get those feedback loops as well as plug them into the process early on to reduce and remove friction along the way. So let's talk about the virtuous cycle. So I came long ago. I feel like I'm aging myself. I came from Amazon earlier in my career. This was before the Amazon Web Services or AWS. I don't want to confuse that. I came from the retail side. And I came from Amazon at a time when Amazon was about to start to enable third parties to sell on the Amazon platform. In about 2001, Jeff Bezos became somewhat famous and this is actually post on the beginning of their earnings announcement each time they produce it. But he had this cocktail drawing that he called this virtuous cycle. He had the vision that if I increase selection, I create a better customer experience which drives more traffic, which then makes it more attractive for more sellers to come to the platform. And that in turn drives growth. The more growth I drive, lower cost structure, I pass on that pricing to my customers. I get a better customer experience. I drive more traffic. It continues and that velocity grows. I'm going to build on that metaphor because I think it's applicable in the open stack arena. So here's my own cocktail napkin drawing. But my concept to this is open stack continues to grow, right? Release after release. You can see even just from the participation in these summits, the community is growing. Open stack is maturing. Open stack is expanding. That feeds part of this life cycle that informs our product. So as open stack grows, the platform capability continues to expand. This feeds a better customer experience. There are more use cases I can support. I can support higher scalable use cases. Customers can get more and more value out of those features and functionality that we make available to them. That in turn drives more adoption and growth of open stack, both globally across, you know, overall open stack usage, but certainly for us and the customers that we see, the more growth that we've seen from our customer base, and we saw this growing from early days of a few customers to now serving hundreds of clouds for our customers, this feeds more operational experience for our teams, the support and operations teams that are running these clouds. We learn from that. That then informs our product, right? How do we improve that? How do we enhance our product, which then further improves that customer experience? The cycle continues. It grows. The analogy is very applicable in the open stack ecosystem and certainly where we look to learn from it and has that fuel and build better and better customer experiences. Let me use that same virtual life cycle, if you will, or virtuous cycle into how we kind of approach this cycle of development deployment and rolling out new releases of our own product offering that we provide to our customers. It, of course, starts with the open stack community development. We, of course, have a number of upstream developers. We have a number of folks engaged in that community. As a product organization, we look at what's coming from the community. What are the new services? What are the new features that are being enabled? What do we think this can do to provide those customer experiences? That starts to inform for a simple analogy, product requirements. What are the things that we're looking to build in this next release or bring out to our customers along that way? We move on and work with our engineering and architect teams to validate the requirements that we propose. How do we move against scaling? How do we deploy that? How do we configure it? How does that start to feed the backlog of work that our engineers would use to add that into our tooling and enablement? They, of course, go through the normal development and test cycles, as you'd expect. The outcomes from that can be, hey, this great community feature is not quite ready yet. We need to feedback into the community, contribute upstream, or tag that this is something that we need to enhance to make sure it's ready for our customer offering. Of course, those things that do move through, we then move into that document and train. We have to enable our operators to take this new release and be able to provide that support experience behind it. Ultimately, go through the deploy and operate phase. We're rolling this out for new customers. We're upgrading existing customers onto the new platform. And then how do we start to get that operator feedback from our teams? How's it going with this? What are we running into? Are there new issues that we need to address? And then, of course, we have the feedback from the customer in their experience. This might feel like a very vanilla product life cycle, right? There's nothing revolutionary here. One of the keys that we've started to learn from in our own practices, how do we improve this, is where we get the different teams engaged. I'm not going to pretend we've been doing this from day one. These are things that we've learned along the way. How is this starting to improve our experience and the things that we do? So it starts with where and when we have folks being engaged into the various phases. We, of course, have product managers in that traditional role that are looking to define what are the things we're looking to build in our next release? How are we trying to bring these things out? We work closely with our engineering and architect teams to, again, validate what's coming from the community, validate where these requirements are. How would we architect these together to provide that customer experience? We, of course, continue to be engaged with those developers through the dev and test phase with use case development, acceptance criteria, and helping in that feedback as they work through the details of it. But here's where we start to also engage other resources. Again, looking at the community itself is the work that needs to be contributed upstream. We even have product members that participate in the community. So some of our product team participate in the OpenStack users, not to use the product working group, the enterprise working group. These are key forms for us to participate in upstream community development as well. We also start to engage early on our documentation team and our training team. So rather than wait until the end of the development cycle and hand it over to our docs teams, say, here, figure it out, they're actually entrenched with the development team as we're building this. As we get into the later phase of it, we're pulling in the training team early on so they can understand what's new, what are the things that I need to be building out curriculum to help enable our support teams and serve that function. We also then start to pull in our operations team. So the support folks will be stakeholders and are part of what we call our tactical team that goes through each release as part of this release cadence. So they're plugged in early. They understand the use cases that they've been presented. They're able to input and add value to that conversation. They know what's coming. We're not just waiting and throwing a release over the fence to them. A very important part of that engagement, if you will. Through that documentation and training process, the support team and the operators continue to be part of that as well, helping make sure that we're building out the right curriculum. What are the things that are important to them that are going to be coming up in that release that they need to be trained on? Through the deployment process, here's where the engineering team continues to overlap. They remain engaged with those same team of operators. Now they're deploying this for customers. They're available for escalations and supporting them as they're starting to use the newest releases. Feeding into the operator experience and feedback, we have a role of account managers that are kind of that quarterback for the customer relationship. They're interfacing with the technical teams, understanding feedback from our own operators as well as the customer experience. And all of that, including the direct customer feedback, gets fed back into our product team. So in a way, we're being informed by not just the market, not just what's coming from the community, not just from our customers, not just from our operators, it's from all of them. They're all kind of adding that insight or influence into things that we do. I'm actually going to hand this over to my partner in crime. Let him talk through how we approach the operations side of this. All right, thank you, Brian. So when we talk about operators and their enablement, the very first thing I'm going to say is, this is not easy. There's no magic outline or statement that I have for you to bring simplicity. So we recognize that, hopefully you do as well. But what I want to do is talk a little bit for the next 10, 15 minutes about our philosophies and methodologies that we found out have served our customers well and kept our team pretty engaged. So first and foremost, we want to give direction to our team, create a framework for them to really buy into, something that inspires them, something that allows them to feel valued, something that lets them buy into something that they're a part of a winning team. So as you see here in our operator mission statement, to be recognized as the world's foremost operators of OpenStack private clouds. So it's a lofty goal, but it's one that we're bought into and we're working towards. So we speak of goals towards this mission. These first two goals I call the boring or the boredom goals, their predictability and repeatability. Sometimes you want excitement in your support organization, in your service offering. When you speak of maintenance and upgrades and environment optimization, you don't want surprises, you don't want exciting. You want it to work like plumbing. You want it to be boring, predictable. These things just need to work. And so those are two of our biggest goals with our team. The next two, we look at scalability and excellence. So in scalability, we want to mirror our offering to our customers, align with their business objectives in a cost-effective way. And we want to deliver a great customer outcome from them. That's a huge goal for us. One really important thing, customers define excellence. So no matter what your KPIs are, no matter what your metrics are, what you're internally thinking about your business, the customer has the say. So I would submit that you're only good when your customers are telling you you're good. So there are different ways to measure how good you're doing or how well you're doing. One of the mechanisms we use is called Net Promoter Score, or NPS. And it's a pretty simple system. And it's asking our customer stakeholders, our customer decision makers and influencers, two simple questions. One, how are we doing? Getting that feedback. And then two, would you recommend us? And through that, we get a rating of zero through 10 with nine and 10 being considered a promoting score, zero through six being a detracting score. And we take the scores very, very seriously. But for me and my team, we look a little bit beyond the scores. And I think the free text that we get and the feedback we get from our customers being a gift is invaluable. So it gives us a chance to improve and iterate upon the operate. You see number two there, NPST. We're not just looking at the macro customer experience, but we want to look at it from a day-to-day granular perspective. So the NPST is just our way of saying through our ticketing system and those work requests, how are we doing? So our customers get to rate that as well. And we do evaluations and look at our themes there. So organizational philosophy. I want to start with our talent sourcing. It really starts with people for your business. We look at energized, self-starter, motivated folks who are experts in their technical trade. And we want them on our team. Account dedication and affinity. We want to make sure that we're aligning business and technical operators to accounts, not just understanding OpenStack, but understanding the customer's business objectives and what their business looks like and really aligning that effectively there. Applications don't sleep, so we can't. So a 24 by 7, 365 experience we think is a must. Looking at development and career paths for our team members. So on the development side, I'll talk a little bit more about it, we've created a mentorship program for them. So our level 3's and our level 4's are pouring back into our level 1's and 2's, really enabling them to become more efficient and proficient operators for our customers. And then looking at career pathing as well. We want to keep our talent. So are there different areas for them to grow, whether it be product engineering or development ops, SMEs within a particular OpenStack component or project. So very important to be thinking about their career pathing. And we want to establish boundaries, it's an upstart business or your mature business. Sometimes we want to be everything to everybody. So it's important again to iterate on your business but really understand within your organizational boundaries and what your capabilities are, are you operating within those confines. And then lastly, big for me is enablement without encumbrance. And it's an idea that process and rigidity are important, especially as you look to grow your business and your support organization. But if you're doing it in an encumbering way to your team members, it drives disengagement. So really look at that balance between process, rigidity and enabling them to serve customers well. So this is something we call the social contract and it's kind of a mental mind frame that we want to operate under. When I first got married, my wife would ask me, she would come up to me and she goes, who's your very favoritist? And I would say, you are babe, absolutely. You're my favoritist. And then not 20 minutes later, she's coming back up to me and she says, who do you love the mostest? I said, well, I love you the mostest just because you're my favoritist. And I was just thinking through, am I doing this right? But what it really taught me a couple things, sometimes what's hopefully clear and something that should be clear, it can't be understated. So you want to make sure that you're stating the obvious at times and so that's what that really taught me. So a couple things, even though the social contract may seem obvious, I think it's important to state. So one is engage and a couple of the ideas under our team's engagement is be present. When you're at meetings, maybe put the phone down, put the email away and really be present with one another and give them your best time for that time. Also have fun and celebrate wins. If we're not having fun with what we're doing and we're not celebrating each other, I don't know if we're really engaged. So there's another important component to engage there. Lead. One of my biggest things for my team is don't ask something of someone if you're not willing to do it or you haven't done it before and it's not always appropriate but it really gets people moving for your calls when they know, hey, you've done that before, hey, I know you'd be willing to do it. Looking at operate, this is just a simple one under the context of social contract. Make your mark, make us better. Let's operate our business in ways that grow our business. And then communicating, one of my statements to my guys is go ugly early. And what that's saying is if you recognize a problem, don't wait. Really bring it to light so we can solve it. There's a school of thought that says, don't come to me with a problem unless you have a solution. And I would challenge that because what that could potentially do is suppress the problem. And we're a very collaborative organization so I challenge my guys. I don't want to leave you on an island to try to solve our problems. We're going to do that together collectively. So bring us your problems. Let's get them out on the table and let's solve for them. So customer philosophy, we look at what are the lighter moments for our customers. And I'd submit that as time goes on. Today's delighter moment becomes tomorrow's must do. So you really have to figure out how are we iterating our business. So if you look for instance at, let's say monitoring and alerting. If you're setting up monitors for your customers, it's one thing to set up awareness across their systems to make sure they're healthy. But what's the next level of that? That may have been a delighting moment at one point in time. But how are you becoming advisory through that awareness opportunity with them with the alerting and monitoring? So just be aware that the must do line is going to change. Figure out how to adapt and adjust and iterate. So I'm not going to go through each one of these but this is just a way that we've decided to set up our support organization that we found effective. One thing I do want to note though that OpenStack engineers and architects are very unique as you guys may know. Back in their day they may have been a technical expert across a particular siloed technical trade, for instance networking or system administration on the Linux side or storage. With OpenStack architects and engineers they've got breadth and depth to all of those technical trades. So instead of the or being able to do storage or networking or system administration, it's really an and. And so with our level ones and level twos in our architects what we're trying to do is keep that and where they have the breadth but we're continuing to add depth to their knowledge to the degree that they want to learn on. So we find that that drives engagement and retention for our team and again delivers a great customer experience. So a couple programs that we've come up with that we find are also pretty valuable. The recognized peer champions there is a peer recognition system. It's kind of a play on what we call our business where RPC, Rackspace, Private Cloud and we find this a way for teams to just recognize the right type of behaviors, what's delivering the right results for our customers and again driven by our team members. Not by me, I'm not dictating this. So finding that it's driving engagement and really establishing the right behaviors. Those two little pink and blue bunny things right there. When you grab them and squeeze them they squeak and they drive me nuts. But somehow this is kind of the identity the team built themselves upon to really look at what is engaging our team and what's driving the right behaviors. So it's really a neat thing that they've embraced. And then lastly just I mentioned the mentorship program but it's a wonderful opportunity for our level 3s and level 4s and our SMEs to pour into in a developmental way to our level 1s and level 2s and have them growing and feeling engaged and feeling like one day they will be the SME, a subject matter expert in a particular trade. But the mentorship program's been really great, a lot of effective feedback. We've even crossed the lines with our different shifts. We offer first, second and third shifts the 24 by 7 support and aligning first and second shift mentors and mentees has been really effective to keep the collaboration and growth between those team members. So with that Brian summary last thoughts. Obviously again we've been focused very hard on that. What does it take to build an operations team? What does it take to operate a cloud? We obviously come to this from that vantage point of a service provider. How does it inform our products? But I would challenge even as an individual enterprise looking to do this on your own you are your own product team. OpenStack moves at a fast pace in innovation or evolution if you will. You as a team need to be thoughtful about how you consume that and enable that for your users and I think the same principles apply. So from a product perspective it's kind of that real key theme of love of the loop. How do you iterate and learn? What is the real methodology even to this underlying infrastructure platform? How do I try new things and learn quickly and feedback into what I'm providing or enabling to my internal users? And so you've heard me talk a little bit about customer experience and just delighting them. I think important in that is creating and defining your identity and your culture for your team. Starting with a mission statement setting some goals at a high level inspired something that they want to come and give their very best every single day to. And then just balancing process and empowerment. Again I can't overstate this enough and one of the ways we've been able to do that is allow their fingerprints to be a part of the decision-making process on how we're structuring and creating our organization. What are some of their thoughts? And as you find, you'll find that as they're making some of those decisions or having the input and putting their fingerprints on what you're offering ready versus you creating in an ivory tower some of the rules and processes you want it to be about. Have them involved, engage them and get their buy-in right there. So with that, we will open the room up for questions. It's that lull of silence. I'm not sure what to ask or it's end of the day, day three. Everybody's exhausted. Ah, it is. It's the latter. That's what it is. Wonderful. We can leave it. Steve and I will be here. We'd love to entertain one-on-one conversations if you do have follow-up questions you'd prefer. But honestly, thank you for your time. Thank you for attending this session late in the day. We certainly appreciate it. And hopefully it was helpful as you start to think about things of building and operating clouds in your own and the types of things that you would think about as you organize it and build a team and the philosophies that you would bring into how you operate that yourself. Thank you. Thank you, guys.