 Excellent. Hello, everybody. How are you guys doing today? Have a good conference. I know we're nearing end of day. So these sessions are tough late in the day. So I can't see very many of you because of the bright lights, but if you have any questions, feel free to wave your arms and hopefully I'll see you at some point. So for today's session, I haven't planned the typical analyst session that kind of walks through a bunch of things, trying to make this interesting, a little bit entertaining, and then also talk a little bit specific on OpenStack specifically. So I'm Lauren Nelson. I'm a senior analyst at Forrester, and I've been covering Private Cloud for quite some time. So I believe this is year six. I've been writing on the space and seen its kind of ebbs and flows where it's been successful and not so successful over the years. So to kick off today, last year around this time, I had written a report called OpenStack is Ready. Are you sassy title? Guarantees a lot of readership. But more importantly, it was around how do you cut through a lot of the hype and talk around the conversation about OpenStack today and talk about real-time OpenStack usage for enterprises? What are people actually doing with OpenStack? Where are they facing challenges? And a realistic perspective of what you can expect from OpenStack today as an enterprise adopter. Trying to get past the hype of it's great, it's not so great, and talk about it in practice today as it's being adopted by enterprises. And today I've got a bit of an update for that and also some data around where the private cloud market is going. So first off, for those that aren't familiar with Forrester, Forrester is a market research company. And a lot of our research as of late has been focusing on this larger transformation at play. So we may be looking at OpenStack today, but at the ground, at the very basis of what organizations are trying to do with cloud technology is to enable bigger things. We're not just adopting cloud to adopt cloud, since it's the latest technology of choice. We have a bigger picture in mind. We're looking at enabling our big data strategy, trying to figure out how do we make customer data more valuable. We're looking at transforming our IT environment to be more operational efficient. We're looking at IoT, we're looking at bigger picture ideas where cloud just happens to be the platform that that's running on. So as we're talking about today's conversation, take a step back and constantly challenge yourself to put that back in the customer framework and thinking about real-time use cases and how we might be enabling a bigger picture. And that's a great place to start off because that's where private clouds tend to get lost, is taking a step back and looking at the bigger picture. Back in 2012, I wrote a report called The Four Types of Private Cloud. And what I kept on seeing in the market is we talk about the journey to cloud, as if it's one solid journey that every organization goes through and just it wasn't resonating with what was actually happening in the market. There are some folks, when you asked about private cloud, they had a very different thing in mind than other organizations. And so I categorized it into four types. Today I've kind of recategorized those a little bit just to make them a little sassier. First off, you've got enhanced virtualization. So today, a lot of people, when you talk to them about private cloud, it still means enhanced virtualization. It means the sphere environment with some chef and puppet. It's the she's all that of the tech space where you take the same product, the same solution, you throw some makeup on it, add in some automation capabilities, and you still have a virtualized environment that's slightly improved depending on who you're talking to. But essentially, not much has changed. It's the same virtualization staff. They're still looking at operational efficiency as their primary goal. They're trying to do things faster, but they're not really leveraging net new technology, and they haven't really seen this bigger vision about really enabling a cloud solution internally. They have no intention ever of passing those reins over the keys over to the developers. We also have the test and dev cloud. I don't know how many people here have seen Mean Girls, but it's the cool mom approach where essentially you've got all these tech staff that essentially are like, we don't want our developers to use the public cloud. The public cloud is gonna get them in trouble. It's like teenagers and drinking. We need to keep them away from that, so we're gonna provide a safe alternative. And so they build this small test dev cloud, very small purpose built environment that is essentially trying to make a small self-service access environment only focused on test dev. Once that app moves out, once it progresses past in production, it moves into your existing system. This is not a journey to cloud story. This is a very purpose built developer focused story with a lot of need for control. We also have the public cloud light model, which takes the public cloud as the innovator and tweaks it. I don't know how many of you here have Steve Jobs known by some as the tweaker, taking good ideas from the competitor, the public cloud, from other things in the market to change it to be purpose built for themselves. And if you look at some private clouds today, they are very much about how do we take the fundamental characteristics and components of the public cloud market and bring that internal and make that our private cloud story, focusing on green field and net new applications only. And that is the public cloud light model. This is most open stack use cases today. And then finally, we have the transformational cloud model, where they view it as the Superman, the great old purpose being of clouds. This is your journey to cloud story, where it is going to do everything and it's going to be magical. We're going to transform everything we've got. It's going to be operationally efficient. We're going to standardize. We're going to implement automation. We're going to fix everything we have and we're going to enable self-service access, enable all net new resources. We're going to connect it to the public cloud. And this is what a lot of IT business cases have centered their private cloud story around, is here's the laundry list of all the benefits you can get from private cloud. We hand that over to the IT team and say enable our journey to cloud. And it sounds great. It sounds wonderful. It's a lot of benefits that we all would love to have. The challenge with it is that it's slow. And a lot of the early private cloud implementations had this as their vision. They saw this transformational cloud as what their whole private cloud would eventually become. But fast forward three to five years, there's no self-service access. We're still getting through the internal political channels of, you know, we need to reduce the number of touch points from actual idea to provisioning of a resource, in some cases from 95 different steps to six. And then look to automate. And within between all of that, there's a ton of political battles at play. There are cultural shifts needed. There's technology expertise to gain. You're asking your IT team to become a cloud specialist. When you look at the full list of all the challenges that lie ahead, typically at this point, and when I'm working with customers, I bring up the Lord of the Rings slide where Frodo is just about to leave the shire with Sam and he says it's the farthest we've ever gone before. And so much more lies ahead. That's what a lot of private clouds feel like for organizations, that there's just so many different things that they have to learn. They have to become a service provider. They have to enable a cultural shift. They need to become a manager and connect all of these different clouds together. They have to think about the developer experience. They have all of these things stacked against them and in the meantime have to deal with all the social challenges of this as well. And so it becomes very difficult. And so a lot of the early implementations of private cloud were not very successful. In fact, you saw a lot of the public cloud providers out there publish articles being like, private cloud is filled. It's not successful. And when we looked at a lot of our own data, when we asked those that identified as having a private cloud in place, if we asked them about basic characteristics, self-service access, automation, tracking and modeling of resources, back in 2014, 96% of private clouds fell short of basic capabilities. And today that picture is much more promising. But you still see folks stuck in this transformational cloud mode where they are doing the leg work trying to do all of these different tasks at once without focusing their efforts. And in the meantime, having a ready-made public cloud alternative that is providing self-service access for their developers and business units today. So it made it very difficult to be successful with private cloud. OpenStack, as a community, has greatly benefited from this. OpenStack was the public cloud light model where they provided a community, they provided a technology that fed in and provided a way forward for that particular vision where private cloud was a public cloud environment internally and that if you were going to be successful you needed to provide the same fundamental characteristics of what a public cloud provider does internally. You need to be worried about licensing costs. You need to be worried about the infrastructure and the cost you're paying for that infrastructure resources. You can't be looking at best-of-breed infrastructure if you're going to be keeping these costs down. You need to be thinking about your user, your customers that are going to be interacting with this and prioritize that over fixing what you've got. And yes, many of these applications will connect into what you've got. But OpenStack really benefited from bringing these like-minded individuals together to change the private cloud model as we know it today. When we look at the data in terms of what people are doing, back in 2014 when we asked people which of these models that they associated with, that they felt matched their private cloud vision, you saw that 32% admitted it was advanced enhanced virtualization. Or she's all that model. 29% saw it as the Superman, the journey to cloud story. With only 26% looking at Test Dev, the cool mom approach, and public cloud light at only 12%. When we look at that journey just one year later, we see that the numbers change. We see those looking at it from an enhanced virtualization and transformational cloud story goes down. And we see a substantial amount of increase in these smaller, more purpose-built clouds. So when we look at the 2015 data together, you see that the most popular approach to private cloud is Test Dev. Followed by still enhanced virtualization and transformational clouds. You still see a lot of organizations focusing on these bigger environments. But you see a huge increase in public cloud light vision. And this is OpenStack taking off. This is OpenStack starting to reach the enterprise audience. When we look at the actual initiatives that are on top of mind for organizations, whether that's continuous delivery for their development teams, whether that's expanding globally, operational efficiency, IOT, you name it. They've got a lot of things top of mind. And one of the interesting things that myself and my colleague, Paul Miller, had recently discovered in one of our surveys where we asked software decision makers about their futures, their priorities in the next 12 months. One of the things that came up is that 41% said that increasing the use of open source was a critical or high priority for the next 12 months. So everyone in this room is probably pretty bought into open source. You should probably be like only 41%. This is a duh moment for some. But for a traditional enterprise audience, this is significant. This is a wider enterprise-offing audience. The software decision makers, do we build, do we buy, seeing that open source has a substantial amount of value, that it's going to increase the rate in which we can innovate moving forward. And this is a huge change. Today, the fact that enterprises are considering open source to be a huge component of their plants, moving it from the idea of open source as being some kid in his basement developing code to a place where there are 50-plus developers at some of the largest tech companies in the world contributing to these open source projects makes a huge transition and is being recognized by enterprises today as a very viable approach. Today, we saw a few things in the keynotes. We talked about some of the numbers about Fortune 100. So I think OpenStack claims the 50% of Fortune 100s using OpenStack today. We recently did our own count and found that there were 12, at least 12 out of the Fortune 50 that were using OpenStack today. And it had public examples of doing so. And we started to see other open source technology taking off as well, whether that's Cloud Foundry with eight publicly using that today within the Fortune 50. And when we look at their developer responses within the organization, a substantial amount using Cloud Foundry, Red Hat OpenShift, or various other Cloud Foundry implementations like Pivotal, or OpenStack today. We saw a substantial amount of interest in that large enterprise class audience. That is yet another win for the OpenStack community. For those that are here, you know, you might be, oh, yes, whatever, now the big guys are buying in. This was inevitable. This is a huge win for the OpenStack foundation to get enterprise adoption at this level, where we're seeing recognition at this level to being a central part of their private Cloud strategy, to being a central part of their software strategy. Now, when we look at that, whoops, in context with OpenStack today and where it's at, there's some interesting things to look at. So, first of all, OpenStack for the most part today is very centric around Greenfield use cases. That's part of the original success of the OpenStack foundation in that it targeted its efforts. It focused on NetNew. It focused on delivering NetNew value today. We're starting to see this change a little bit. I know there's a keynote this morning and some other examples where they're expanding this into the existing. But for the most part, a lot of organizations are still focused on that NetNew Greenfield story for OpenStack. And a lot of these enterprises are starting to understand that. Starting to understand that there's a place for OpenStack, regardless of whether they're using other large players today for other parts of their stack, for their traditional systems. We're seeing that there's a big interest in OpenStack in terms of potentially reducing hypervisor licensing costs. And this one's big. For NetNew applications, this makes sense. We'll expand our future footprint on KVM instead of expanding that future footprint on our hypervisor provider of choice. We're also seeing some early examples of people converting off their existing hypervisor for some existing workloads. Some of the earliest use cases where they actually are using private cloud as a cost-saving story in a very realistic way. A few years ago, I wrote a report, Top 10 Things I Know Leaders Should Know About Private Cloud. And one of my top things is you won't save money with private cloud. This is an opportunity, this is one of the rare choices in private cloud where there is an opportunity to do so. Where there is a potential cost savings that you could see on top of what you're already experiencing today. We also see that distro costs have scared away some organizations. One of the original value pitches they give you for open sources. If you use open source technology, think about how much cheaper it's going to be. When you actually look at the software licensing costs, a lot of the major distros today are actually quite comparable with some of the proprietary solutions today that are outside the OpenStack community. Enterprises are willing and adopting OpenStack regardless of the fact that it's an equal cost. There's enough value pitch in the community, enough value add in this kind of six-month release cycle and shared innovation center that they're paying it anyway. One of the biggest reasons why I see them making that decision is the peer-to-peer opportunity. And I am definitely not the first one to state that. But if you talk to a lot of the user groups, I know Tim Bell has been saying this for years, one of the biggest advantages of being part of the OpenStack community is the peer-to-peer learning resource you have. A lot of groups out there in order to get the exposure to that level of kind of peer-to-peer conversation, you have to pay a substantial amount of money to do so. To belong to some membership group or to try and get access to the right level of folks that are in the same conversations as you are today. OpenStack provides that in a much more cost affordable way. To those that have bought in, that have drunk the Kool-Aid, they are essentially adopted to that cultural shift. You also see that OpenStack not only serves different groups, but they are targeting a specific developer group. So how many people here have heard the term cloud developer used synomously as one particular skill set where cloud developer is defined as cloud developer with no nuance, no descriptions about how they interact, and just talked about them as just one person, one skill set. Few people can kind of make out the hands. But essentially, often times when it's referred to in the market, it's just one person they're describing if in reality cloud developers are very diverse today. They interact in different ways, they have different expertise. Those who are writing your infrastructure config, your application templates for other developers to use are going to interact through a drag and drop interface. Those that are going to essentially do tweaks on your website on color and very minimal incremental changes that don't require a lot of development background. And by classifying cloud developer as just one person, one skill set, we're doing it to service for enterprise audience today because it means that we're telling them that their enterprise audience is just this one person, this one role, and that what meets the demands of one organization should apply to your entire development workforce. And that's very different from the truth. Your developer is going to interact in very different ways. And if Amazon AWS does anything, well, they do many things well, but one thing they do particularly well is understand the developers that are interacting with its solution and understanding there are multiple types and different abstraction layers that are good for different developer types. And OpenSec today has done a really good job with DevOps professional. And I use the term DevOps to describe a developer with operations experience. Someone that's probably sitting in your tech team that is going to be innovating and developing some of your most technical, net new applications that are customer facing for millions of simultaneous users. They are some of your top talent in your group. It's very different than somebody that wants to do hands to code that's doing very lightweight development capabilities. And this morning actually during the keynote session, we talked about the different tiers. We talked about the infrastructure services. We talked about application services that surround that. And then finally an abstraction layer for developers to interact. Platform as a service offerings target that top layer, where you're talking about consolidating and optimizing that developer experience at the right abstraction layer. For a lot of DevOps folks, they don't want to interact at that layer. That's where they're most valuable. And so OpenStack really targets a lot of that community. And a lot of its more recent projects and integrations with some external projects focus on other classifications of developers to expand its usage beyond just that one type. We also see that there's essentially more cloud enabled use cases being rolled out in OpenStack today. So particularly if we look at some of the use cases that are being used today, you see a lot of production. I think the latest survey said 65% of all OpenStack users are using essentially OpenStack in production today. You're also starting to see applications that are customer facing, internal. You're starting to see heterogeneous environments being implemented, and you're starting to see a lot more traditional workloads coming about. All speaks very highly to enterprise use cases regardless of what industry you're in. Greater consistency between vendors and the platforms. So behind the scenes and most open source foundations is this interesting political play of how quickly do you provide standardization without pushing away your audience, without pushing away the vendors that differentiate with your solution. And so part of the dance that foundations like OpenStack have to do is figure out how quickly to do that standardization. How quickly do we make sure that we have consistent APIs across those and compatibility tests across our vendors and our community without pushing them away too quickly. And so that's part of what OpenStack has been doing over the years is slowly trying to increase the consistency between its platforms. And so we've reached a point where we have an API test. There are scenarios, there are ways to increase that standardization even more, whether that's scenarios, whether that's some of the integration points around containers, whether that's increasing the core or having another layer of BigTent where there's increased compatibility as well. And around those application services layers as well. We also see that there's greater insight into infrastructure resources today. So a lot of organizations, when they're looking at OpenStack environments, they integrate with solutions like vSphere, like Hyper-V to provide a level of integration and capability so that you don't have to rely on those element management monitoring tools directly as much. And so that gives some freedom for business users to interact and run their OpenStack environment without feeling like they have to work for that central IT team up to a certain point. And that has certainly benefited a lot of organizations that were trying to build a private cloud within their business units for large enterprises that may have had multiple private cloud environments at play, but being able to essentially enable a smaller private cloud that's more purpose-filled for a particular business unit's need. One of the big questions I get a lot is, is OpenStack ready? So I talked about a little bit about why OpenStack is unique and kind of why organizations are being driven towards it. In terms of the big question, the elephant in the room is always, is it ready? And one of the things I keep on talking about organizations on is that number, 65% in production today. I also talk a lot about organizations primarily using it for Greenfield. I mentioned that before, but that is a huge thing that a lot of enterprises don't understand. They'll look at the maturity of neutron. They'll look at, you know, some of the questions around whether you can do quality of service or HA or upgrades while skipping a version. All these components that are typically talked about about being shortcomings of OpenStack today, and they'll kind of quickly skim over the fact that a lot of the usage today is for net new. A lot of these capabilities and shortcomings of OpenStack are enhanced by the community that surrounds it and have drivers and capabilities that are in advance of what the actual solution provides today and plans to roll that into future drivers and implementations they have long term. The other big thing that we typically talk about with folks is the concept of low cost. So looking at an organization that's thinking about their future, about whether they want to be in the data center business, whether they want to invest in becoming a cloud provider, one of the top conversations that come up is the cost story. About over time I'm going to be developing a certain number of net new applications. Do I invest in building a private cloud today to do that for the bulk of those workloads? Or do I leverage an external provider? And there's a lot of organizations today that look at this picture and think long term it makes sense for me to invest in this because I'm going to have so many net new applications and the need to continue this development process over time that it makes sense for me to invest in this. And if I'm going to do that, I'm going to do that in a low cost environment that is built on KVM and is not built on my proprietary solutions. They're thinking about it, about building it as if they were a public cloud provider. When we look at interoperability and portability, that's a big thing that comes up in terms of is it ready? We talked a little bit about API standardization and steps towards that. But the other big question we get with folks is can it be interoperable and portable to AWS? And there's certainly places that it's more interoperable and portable today. I did a report a few years ago about state of the cloud, portability, interoperability, and migration capabilities. And I've updated in this past year where essentially looking at the state, can you move an application that exists today in a platform, pick it up and move in another platform? The answer is yes. One-way migration is available. There are tons of tools out there that allow you to migrate from one environment to another. The only challenge is it's mainly a one-way migration in that you can't go back and forth. It's not actual portability of moving wherever you want, when you want. It is essentially a, we made a bad investment. We want to try and switch solutions. It's very much enabled. There is some challenges around network configuration. It takes some custom work around that. And the big challenges is you lose the services that surround the application. Some of the more interesting parts of your application are typically the services that surround the offering. It's your use of the surrounding products of OpenStack that we'll tie you in or a particular vendor's set of services that they provide. Or AWS's large list of services that are surrounding it. And that's something that's not going to change anytime soon. There's certainly the potential and the hope of containers helping us with that over time. But there's a lot of challenges with the management today, with applying context to containers and being able to do so in a way that's going to leverage the same type of services in multiple platforms. Today's services are very proprietary to a single platform. They surround the future of portability and it's not yet solved, but that's okay. It's not stopping a lot of organizations. Organizations are realizing that there's value that comes with vendor lock-in. Interoperability, almost any vendor out there today, exposes their APIs to some extent. You should be able to build up those integrations. The big challenge, it is time intensive. So a lot of organizations, that's where they spend the bulk of their time. Once they've got their private cloud up and running, they spend a lot of their work on the weeds. The key value adds that we definitely see when we talk to folks, open means choice. So you're starting to see a lot of the market provide critique of vendors in the space talking about who's purer than the others and who's truly open and what open means. But in general, when you look at the concept, open provides a lot of choice. You have a ton of innovators, innovating together and providing development in a cohesive manner, especially in the way foundations are run today. And this is a big advantage for a lot of organizations. They feel that the decisions and choices aren't tied to a single vendor's future and that they're not, and it is above that of the interests of one particular vendor or another. That new launch point, a lot of people love that. What I've talked about before is essentially starting Greenfield. That's a huge value add that not many other solutions in the market really target today. Cost of minimization potential, we already talked about all these active and engaged communities, but this is the most common things that are listed out when we talk to enterprises about why are you even thinking about OpenStack today. And then finally some OpenStack caveats. So this is the what is, the questions and the concerns from those in the community. The running list. So a lot of challenges around upgrading, especially if you're skipping releases or if you're going to upgrade one project but not the others. It's certainly doable today. Many organizations do this without issue. The only challenges is you've got to prepare. You've got to test. You've got to essentially make sure that you're not doing anything incorrectly. There's a lot of folks that do a ton of testing before they actually are able to upgrade. So this is going to be time intensive. But many people have done it successfully today. Provisioning more than 50 VMs at once. This has been known first quite some time. Most people just do batch provisioning to overcome this. It's not a deal breaker, but it's something to be aware of if you're a new OpenStack user. Keeping up with releases and updates. So this one's a cultural challenge. So there's a number of organizations out there that don't like six months release dates. A lot of organizations keep six months behind the latest release. There's a lot of pressure to essentially delay. To not have that six month release cycle to delay to one year release cycles to essentially encourage stability within a project. And that's a tough one. A lot of these enterprises have never worked with an open source community before. A lot of these enterprises are used to putting their feet down and saying we're not going to do this and having open source communities change their practices because of it. And this is actually fundamental to enabling continuous delivery within an organization. This is fundamental towards moving us closer to a SaaS-based model where we are trying to have updates pushed frequently and constantly. And a lot of enterprises, this is their first foot in the door when it comes to open source projects like this. And it's something that's going to be hard for them to try and get used to. The other big one that comes up a lot is networking. And this is no surprise. There's a report coming out in a couple weeks about this. But Neutron. A lot of folks have concerns. There's no shortage of press releases out there about the challenges and soundfalls of Neutron. Neutron's had a tough history. It essentially, we started off with Nova Network which was a flat network design. We then had Neutron. We had it renamed at one point. It's been slow in progress and it's matured much less rapidly than some of the other projects. But the other challenge being that the SDN market is quite immature as well. So these combined have really made it difficult for Neutron to progress as quickly. And that's a known factor. As the user survey results show, there's a substantial amount of usage of Neutron today. I think the latest stat is 90% using Neutron today. A large portion of those using it in development instead of in production today. But many folks are enhancing their Neutron use because of the drivers and ecosystem solutions that surround it. That are working on the integration points between vCenter and Neutron. That are delivering quality of service for Neutron that's not available in Neutron yet today. That is looking at service chaining. That is looking at all of these very basic capabilities that should be in a networking solution today. But today you do need these ecosystem solutions to supplement Neutron. They're being added in and they're in the pipeline of our future capabilities that are coming. But today is delayed. And so as organizations are thinking about getting into the OpenStack community, that's certainly something that they should be aware of. SDN is immature. One of the biggest complaints I've heard from OpenStack adopters is, well, you start off with a certain amount of SDN technologies, whether that's a little bit of Cisco ACI or a little bit of NYSERA. And you've got some sort of mix of hardware slash software combined, SDN with a true software-only based SDN solution. And the right mix of those two offerings at any given point in time is going to change as your OpenStack environment evolves. And so it's very difficult to set out with one plan, with one structure and have that consistently develop and build over time. You're going to find that that map to what SDN solution, what assortment of SDN solutions is going to evolve over time. Direct adopter competency takes four to six months. And that's a tough one. I know that there's a lot of appliances, a lot of managed services, hosted private clouds, public clouds, a lot of things that are trying to accelerate your journey to get there faster. But when you talk with those that are adopting OpenStack today or previously, they say over and over again, do not put it on yourself to have a production level workload in OpenStack within the first four to six months. And if you have a certain amount, I think there was a session last year where some gentleman said if you plan a certain amount of time for design, times that by five and that might be a more realistic estimation of how much time it's going to take you for design. So that's something that organizations getting started should be aware on and should build into their pipelines. In general, enterprise roadmaps are far too aggressive for what they should be expecting in a realistic manner, and OpenStack this applies tenfold. Vendor participation is not altruistic. This may sound obvious, but a lot of organizations sometimes struggle with that. They realize they forget about the incentives behind a vendor in an open source community. That if there's not some sort of direct value or differentiation or market perception of them being a big player, very rarely do they invest in that. One of my biggest examples of this last year was reference architectures. The reference architectures for OpenStack were severely out of date and no vendor really wanted to contribute to that because that was one of their proprietary things. Their reference architecture was a way in which they could draw on customers and essentially differentiate themselves in some small way. That has since been updated post my report. So that is not as true of an example anymore, but you'll see that where there's less money, where there's less incentive for vendors, you're going to see less participation. So with the potential of SDN and the fact that every SDN player is participating in the OpenStack community, you see that there's a substantial amount of interest and contribution to the projects associated with that. Same thing goes with containers since there's a substantial amount of opportunity in the container space for OpenStack and OpenStack tends to be a community of very early adopters, you see a substantial amount of effort towards that. So something to be aware of vendor participation is certainly not altruistic and the desires and the contributions are going to follow that. Some other things to keep in mind. The user community encourages to upstream your code. If you're building custom code today for a functionality that doesn't currently exist in OpenStack, upstream it so you don't have to redesign it in the future. It may sound like it's tough for some organizations legally speaking, some organizations are not allowed to contribute their code but fight through that, try and advocate for your organization to truly upstream that code. Not only are you participating in a community far more but you're also going to be saving yourself a lot of legwork. Don't fight the community. This is a big one, a lot of the users that participate in the OpenStack community. If you are dead set on something that you really want to change but the OpenStack community has taken a big stance on not doing it that way, don't waste your time. Has been the general advice from a lot of the users in the community. A lot of the user community say spend your time on things that you're not fundamentally fighting however many people that are in the OpenStack user community on trying to change. It's very difficult to change especially as OpenStack has gotten bigger. You're dealing with huge vendors that may have taken one approach and have a lot of marketing muscle behind that and said a lot of the users recommend you to put your efforts elsewhere. Don't be alarmed by transparency of bugs. For those that are familiar with OpenSource communities, this must be a duh for many of you but for a lot of enterprises today, that is new. Even though every vendor solution out there has bugs, the fact that they're not exposed or shown a list of them makes them feel for some reason more safe or that the solution is more stable or better in one way or another rather than looking at a list of bugs that are known and documented and saying I like this transparency. The fact that we know these bugs exist and we're working on them and we have full transparency about what might go wrong but that in itself is a very difficult change, a very difficult thing for a lot of organizations to kind of accept and buy into. Embrace the community. I mentioned this before is about one of the biggest drivers to use OpenStack is the user community and essentially all of that value add you get about being in this community with everybody else that's working in on the same type of initiatives and have drunk the Kool-Aid but you've actually got to take advantage of it. Some of the users say that have been in the community for years and years say that is by far the number one thing they get out of OpenStack and that has not diminished over time. That going to not necessarily these summits but the user community events has been huge for their organization to keep progressing and keep talking and learning from others in the community about how to leverage this technology better and how to take on other tech initiatives. Just like the SDN vendors are getting into the OpenStack community because it's a great place for early adopters those early adopters are part of this community and as a user in this community you're going to be able to leverage that group that same group of early adopters that same group of innovators to progress tech projects even past and beyond OpenStack into the future. Go to the user events. I mentioned that summits are nice but the user events people say they learn so much more from and they get way more peer to peer interactions from. So leverage those in your particular groups. And then finally the last thing I'll kind of end on today is this concept of services. Earlier today I mentioned that in the keynote there was this articulation of infrastructure services, surrounding application services and abstraction for your developer types. One big thing that a lot of the public cloud vendors are trying to emphasize with your public cloud focused cloud strategies is the value of the services in their communities. The fact that they maintain these list of services to enhance your cloud adoption over time such that you don't have to maintain them yourself. When you look at providing a cloud for your developers you need to be thinking about that same thing the competition for your private cloud and you may be leveraging both types of services but your stacking your environment up against is something that has a ton of services that surround it. And as we look at these projects that surround OpenStack and the core projects, as we look at other solutions that are being built out by vendors and by users that is where you're going to provide a better developer experience. And I know that Boris from Morantis earlier today mentioned the challenges of going through provisioning and the user experiences that go along with that. And that if you have a poor user experience or there's a lot of challenges or roadblocks in the way you're going to quickly lose your audience. And I would very much encourage you to think about that developer experience and the services that surround it that make them more productive. This is going to be the single biggest thing that happens in 2016 about differentiation for the private cloud versus public cloud space. The success of the private cloud market very much depends on vendors in this space, users in this space having confidence in these services that surround the offering similar to the way that the public cloud space does today. So strongly encourage you to take a look at that as part of your private cloud story, as part of your journey. And with that here's my information. If you have any questions feel free to reach out to me via email or catch me along the hallways. Any questions while we are here? I don't know how we're doing on time. Do we have a time check anybody? Was it? Five what? Five 24? Okay, we're a bit over. Can I take one question? Anybody? If we're over, okay cool. Alright, well if you have any questions please feel free to catch me, reach out to me via email. That's my Twitter hashtag. Everyone good? Alright, thank you guys. Have a good day.