 All right, well, we'll go ahead and get started. OK. So hello, everyone, and welcome to Enabling Business Agility with OpenStack. My name's Dave Pitzley. I lead the infrastructure architecture team at Comcast. I'm Mark Becker. I'm the OpenStack product manager at Canonical, the Ubuntu people. I'm Leong. I'm principal engineer for Liberty IT. So we are part of the Enterprise IT for Liberty Mutual Insurance Group. And we're a pretty diverse group. How do we come to meet each other? We met through the Enterprise Working Group, the OpenStack Working Group. You may have heard it mentioned during the keynotes. The goal of the Enterprise Working Group is to, it's two-sided. One is to help drive more enterprise adoption of OpenStack. And the other side of it is really driving more enterprise requirements into the OpenStack community to really further along the platform. So with that, let's get started. We prepared a lot of content for you, which I hope you enjoy. And we've saved some time at the end for questions. We've also, we'll sit outside as well if you want to ask us some questions or get an autograph headshot. Absolutely. We're available for that. That's right. Whatever you guys like. So now what? The purpose of today's talk is you've decided to move forward with OpenStack. Now what? So there's quite a few things to consider. And our goal for today is to walk you through, hopefully, some of the, how to avoid most of the pitfalls and really accelerate the time to deliver real business value from OpenStack implementation for the enterprise. So with that, the first step on our journey is how do you pay for this thing? OpenStack is free, right? Free like a puppy. So Mark, what are some of the financial considerations that people need to keep in mind? So certainly there is no such thing as free, right? As everybody knows, free software, whilst it may be available for free download, implementing free software takes people and people cost money. The three broad categories that we've looked at in terms of cost considerations, migration, right? How do you get applications into OpenStack? Nobody does OpenStack just for fun. That may be the exception here this week actually. But most businesses don't do OpenStack for fun, right? So they're looking to solve business problems. People don't, the old ad is people don't buy service because they want servers. They buy servers to run business applications and solve business problems. And so putting applications into OpenStack, working out where the economics lie in terms of migrating existing applications, obviously new apps, cloud native apps applications. People, the role of obviously how do you get your OpenStack environment up and running? And it's pretty clear that even though OpenStack has come a long way in the four years, it still needs smart, experienced people to get it up and running and then to run it operationally and effectively. And then vendors, right? I work for an OpenStack vendor. There are many here, all of them with various claims about how they can make your lives better and save you money and do things faster and change your business. So the role of these three cost considerations really migration on people and vendors are areas that we're gonna drill down into. Click. So a lot of the goal with OpenStack is to try and save money, right? Who was trying to use OpenStack to save money? Good, how's that working out? This is good. Good, good, good. So a lot of the current infrastructure is costing you money, right? And that's whether it could be based on proprietary technologies, it could be based on vertically integrated monolithic applications that are costly to scale, costly to upgrade, costly to manage. On the other side, and do we have, is this a build, we see another piece coming up here? Okay, so thank you. A lot of those moving, we want to downscale that. We want to decrease the cost of that environment by moving into an open cloud environment. That's the goal of OpenStack. And so some of those, we want to move to an OpenStack environment to give us cost savings. However, monolithic applications can be expensive to re-architect to move to an environment and a cloud native environment. And so depending on, if you look at this from a pure ROI perspective, it can be very easy to say, well, migration costs are prohibitively expensive and therefore any efficiency savings that I'm gonna get from my fantastic new OpenStack OpenCloud are more than offset by the migration costs. And so there has to be a process that you look at determining where the balance lies, right? What's the ROI I'm gonna get from migration versus the complexity and cost involved with migrating those applications. So as a general rule of thumb, and we'll talk about, it's very easy to say for specifics where this will not apply. But as a general rule of thumb, obviously the longer the lifespan of the application, the greater there is the opportunity to save money over the long term with an open cloud infrastructure. Because of the complexity of implementing OpenStack today and because of the cost, I think I saw today some of the average cost of an OpenStack developer and engineers about $130,000 a year that resonate with people. No one's gonna own up to that. So there's definite costs involved with this. And so in general, if your application only has another six months or two years to run on it, you need to look very carefully at where it's gonna run. But if it's something that's gonna be in place for the next 10, 15 years, then clearly it's gonna make much more financial sense to move into an OpenStack environment. Another guiding rule, a rule of thumb if you like here, is that if your application is virtualized, it's gonna be much easier to pull it into an OpenStack environment, right? This doesn't mean that you can take a VMDK from VMware, just drop it into OpenStack, have instant cloud goodness and operational efficiency. But it does mean that if it's virtualized already, that the application is happy running in a virtualized environment. And that certain aspects of that are gonna be more appropriate to re-architecting for a scale out, more sort of software defined flexible infrastructure. If it's not virtualized already, if you have applications that, where virtualization is verboten, you're not allowed to do that, it compromises vendor support, then that's gonna be much tougher for you, right? There's gonna be a lot of re-architecting or negotiations with that application vendor. So not virtualized today, look very, very carefully at whether that's gonna be applicable. People problems, right? It's very interesting in doing this research to find that who actually came up with this quote, the all problems, the people problems. But it's certainly true. And I think if you look at some of the OpenStack survey data and I can't remember the exact numbers off the top of my head, but often it is, people are seen as being the biggest barrier to adopting OpenStack, right? Change can be hard. A lot of people have this sort of learned helplessness where they don't wanna move away from what they know. This new areas can be scary. But of course the good news is, we're surrounded by 6,000 people here this week that are all very excited about the prospect of moving to OpenStack. So all of these things are completely manageable. With people though, if we move on to the next slide, you have a number of options that you need to consider. All staff need to be trained, right? Any good company, Comcast, I'm sure does this, will invest in its people. So you need to train existing staff. However, that can take time, right? You can't take all of your team out for three months, get them all trained up on OpenStack. Can't take all of your team out for a week even and train them up on OpenStack, send them on the course and expect them to be experts in OpenStack. So you need to train those existing staff, but you may need to hire experienced people in conjunction with them. Who's hiring OpenStack expertise here? Everybody. So you need to hire those experienced people, but good luck with that. Because not only are you competing with your peers in your industry, but you're competing with HP and Rackspace and IBM and Red Hat and everybody, right? Everybody's looking for OpenStack experience. And so that's the tool order. You can use consulting of course to help get up and running and there's a great many companies that will help you do that that are here this week. You can use combinations of all those things. And I think that's typically the approach that most enterprises or most companies that we see are doing, right? They're training their existing staff at the same time, hiring new people in and poaching people from their competitors and at the same time, bringing consultants in. The fifth option, and it's very interesting to see Blue Box and others talking about this this week is outsource it, right? Sort of throw your hands up and say, right? One, two, three is gonna take us a little while and but we want a cloud today and so this could bring somebody else in to do that. And there are other providers from Blue Box, so too. So outsource everything. And I think that's an increasingly attractive option for many people. Vendors. So are they a necessary evil in this world or are they helpful value-added providers? So yeah, I think you need to understand how vendors can help you if they can help you and the criteria that you can use to select them because there's a number of factors that can influence your choice and a number of benefits that they can bring but only if you make sure that what they're delivering is gonna be aligned with your long-term vision for the cloud and your needs for that. So we'll talk about some of those kind of criteria. Vendors can help you save time. Is Martin Meekos at MySQL a long time ago said with open source you can spend time to save money or you can spend money and save time, right? The choice is yours and as any organization just needs to think about how it gets that balance right. And the same is obviously true, I think with many of the vendors in the open-stack world. You can pay a ton of money and have a complete bespoke off the shelf system delivered to you, but it could be expensive. Likewise, you can do it all yourself and not spend any money externally, spend perhaps a lot of money internally, but so again, need to look at where that balance lies. Our experience as a distribution is in talking to people in parenting open-stack is that kind of the, one of the, I don't know if it's the biggest concern, but certainly a big concern is how you avoid lock-in, right? So most people see open-stack as being a strategic decision, business-led decision, and that infrastructure is gonna be in place for a period of time. And that period of time could be three years, five years, 10 years, who knows? But it's gonna be in the place for a while and that means that they need to understand, you need to understand, think about the flexibility and options that you want in the future. It's very hard to say what the open-stack world is gonna look like in five years' time, right? Who's the dominant vendor, if any, and the way in which it's going. So you need to try and think about how do you maintain flexibility? How do you keep your options open as you go forward? And that means understanding if there are proprietary add-ons in a distribution, understanding what those are and how they're gonna benefit for you, make that decision, be aware of any of those sort of vendor-specific modifications. Doesn't mean don't use anything that's proprietary because often that could, may save you money, it may save you time in the long term, but understand what you're getting yourself into if you go down that path. There's also a big change in culture, coming back to the people problems. I think this is probably less of a problem now than it was 18 months or two years ago, but a lot of that traditional enterprise mentality is about put it in place, if it ain't broke, don't fix it, don't touch it, just leave it running, humming along, doing its thing, and look for support cycles from vendors that span five years or 10 years, right? That doesn't work in the open stack world. Change is, when you release every six months, mid-cycle sprints that you can go and participate if you want with new stuff, getting stuff on the roadmap very quickly. So if you try and implement that same methodology, the same process, you're gonna end up, and you see some open stack users like this today that are stuck on Essex or Folsom thinking it's too scary to upgrade, I don't know what I'm gonna do, but each cycle they leave it, the harder and worse it's gonna get, right? Because jumping from Essex to Juno is gonna be a lot more painful than jumping from Icehouse to Juno, right? So that mindset needs to change. People need to understand that things move faster, and that's a good thing, right? Each release gets hopefully more stable, touch wood, hopefully more stable, more featureful, and better for you and your business. Now Mark, you were gonna ask me about application selection. Yes. I'm so glad you did. So we've got... So for application selection, this is tricky. I mean, this is probably one of the most overwhelming decisions. Every enterprise has a massive pipeline of functionality to deliver, finite resources, and just all of these aggressive timelines, where exactly do you inject this revolutionary change? So the advice here is really start at home. You wanna look at something that's traditionally within the sphere of influence of a CIO. No, your company may not have a CIO, but within that general influence, so document repositories, collaboration software, system management tools, you really wanna start there before you expose this out to all of your business partners. And the reason being, they're going to be failures. You're rolling out a new design pattern on new infrastructure and theoretically, probably a new engineering team or an engineering team dealing with this technology for the first time. So you really wanna shake all that out a little closer to home. So from that, let's say, now that you've kind of vetted this out a little bit, and you feel like you've shaken this out, now you've got this, I don't know, put your left arm out, Leona. So this many applications. See if we can try to shriek. This is your application portfolio from here to Leong's hand. Scott Alcott, who's the CIO of Comcast, refers to this as Jurassic Park. It's the who's who of technology over a series of decades, and how do you really kind of dig into this and try to shift it? This is a really difficult question to ask, and there's no simple answer. So I'll give you some patterns and anti-patterns. So number one is, if you go after it, could you move vertically scaled applications into the cloud in general? Absolutely, but you're gonna spend a tremendous amount of time, you're gonna spend, oh, that was real bad. You're gonna spend a tremendous amount of time, and the yield will be very low. At the end of the day, the application will likely not perform as well as it did originally, and you may have issues with availability. You really wanna focus on some lower hanging fruit. So just some basic examples here is like, if you have your classic ERP systems or financial systems, probably not the best candidate for your first out of the gate. Variable volume workloads. So if you have, you know, people who've been in the enterprise for a while, remember when like SOA was the new hotness, that infrastructure exists out there. And these are great, like highly transactional systems that you can move, make great candidates for moving. Data analytics, event mediation, anywhere where you're doing advertisement, click through data, that type of thing. These are highly variable, highly scaled. These, you could get tremendous benefit out of. So the next big question is, do I try to take this application and move this up? So I guess I've narrowed it down to, I guess this amount of applications. So now I take my application, do I try to just pick it up and move it into a cloud design pattern, or do I kind of cap functionality, let that live and start building Greenfield over here in the new design pattern? So this is the right question, but the scope is wrong. You really want to try to avoid and resist end to end rewrites. This is probably the biggest pitfall. You really want to look at it as a component by component basis. Let me give you an example. I just so happen to have a slide ready. So this is just a fictitious application and it's very arbitrary. Any of this can be debated, I'm sure. But there are web components and there are middleware components that today lend themselves to horizontal scaling. This isn't a lot of applications. And then I have a messaging component there and that may or may not. But in general, data persistence is hard. It is the hardest part and it's one of the hardest things to wrap your mind around when you're designing cloud applications. So if you have that, if you're taking an existing application, don't mess with that first. Leave it where it is. If you have a vertically scaled appliance that's running your database server, leave it there for now. Don't make that the first out of the gate. Start with some of the simple things. Start with the web front ends, moving those in. Messaging gets hard as well. Leave messaging alone. Maybe you have an opportunity there. Like I said, it all depends on the apps. There's no clear answer. But the big takeaway here is don't try to move the entire application. Try to move it in pieces and straddling these different technologies is not a bad thing, especially. There's gonna be an evolution. Your infrastructure should follow that same evolutionary path. The other big benefit that you can gain is through non-productivities. Functional testing environments, development environments, integration environments. These are great. Those who attended the keynotes, you saw that eBay and PayPal are 100% of their dev, all of their dev activities are running an open stack. It gives developers a tremendous amount of power to create and destroy at will and recreate all with simple interfaces and predictable APIs. Something to consider there is if you're using a follow the sun type model where however you're supporting open stack, whether you provide a vendor or you build a team, that really needs to follow the same model. If your dev is follow the sun, you need to have support that falls the sun. Dev is gonna need help and when they do, they really need it. You don't wanna stop, you don't wanna stop dev from creating, you don't wanna stop if you're doing formal QA, you don't want to stop QA from testing. There are gonna be issues, you do need to support them. And this is the last point here is developers are really key to your success. Absolutely, you can't stress that enough. One of the big pitfalls here is really moving so far in the direction of getting the infrastructure up and running that you go after and try to sell the concept of cloud after the fact. You've seen company after company do this. And you really need to start that journey early on in parallel to building this. You have to evangelize cloud design patterns. You need to make sure that developers are comfortable moving that direction. They have some input, they have some buy-in and that you're providing that level of support throughout the process. So with that in mind, Leong tell us about what are some of the things you really need to stick the landing for dev acceptance? Well I think if you guys remember the Monday keynote sessions, everything is moving towards software. So as Dave mentioned, developers are very important. So it's very important to get your developers on board throughout your open-stack cloud journey. So nowadays people, a lot of companies talk about CICD. So in this CICD pipeline, there's a lot of different tools that are inside. So you really have to think about how can you empower your developers with the right tool set. So open-stack itself, as infrastructure as a service, provide the right platforms for developers. The API model, the cell service model, really help you to empower the developers to do what they want. And using open-stack, you can provide a consistent environment across developments, QA, staging, or production environment. And that really helps a lot for your developers. And having tool set itself is not enough. And culture is also very important. Because this is totally a new development model for a lot of enterprise companies. And you really have to get the developers and also the operation people to think about the DevOps movement. And you have the mindset changes and culture changes. And one of the key things here is, the changes of mindset or culture has to be driven from the leadership, the senior leadership. So a lot of time when we talk about culture, we always have to challenge your existing status quo, including your enterprise-assisting processes, so things like your asset management or incident management, those kind of processes. You really have to get the senior leadership, the C-level people to drive the changes. So another thing is about design mentality. So you have to get your people, your developers, even the operation people to understand the differences between traditional, deploy the application on traditional infrastructures and the cloud-based environment. So, but I'm not going to talk too much details about this slide because tomorrow at five o'clock we have another session talking about enterprise strategies for cloud-aware app. So we'll talk about discuss more about tomorrow. So the next thing, other recommendation I would suggest is, especially if you are first deploying OpenStack in your company, if you're having a close physical proximity between your developers and the operation people or the deployment team, that will help a lot. I'm not saying that it's a must, but if you can get people to be in the same place, that will give you a lot of benefits. And another thing is the support channel. So traditionally we think about a lot of ticket-based model. We go to help that and there's a longer turnaround time. So you have to think about providing some sort of real-time model so we can use things like IRC channels and we should provide a quick and real-time response. And you also have to think about the self-service, make it self-service for developers. So make sure your documentation, your user manager, user guide, easily and widely accessible for the developers. So these are things that I think is quite important for developers. So maybe you want to talk something about the political perspective. Oh yeah, yeah. So the political aspect is one of the dicier aspects of Naval Agility that we're going to talk about, I think. This is an uncommon. So if you kind of take a look at it from most business owners' perspective, we're basically proposing we're going to pull resources away from incremental functionality. We're going to make this investment and oh, by the way, things may be a little unstable during this entire journey. So it's really easy to see the perspective of a business owner who's like, look, that's great. This is a nice little science project, but not in my backyard. A big tip here is you really need to be cognizant of pain tolerance. So the goal here is you really want to be selective about your business partners and how you're going to go about moving forward those applications that we talked about, which applications you're going to use. You really want to get your business partner tightly aligned with you and go into this together as a true partnership. You know, when you're trying to select your applications, this is the part that's kind of a little dicey. There's no real formula for. You want to kind of stay away from the extremes. So if you have an application that is this hot button between the IT organization and the different business units, what's failing all the time or it's having issues, that may not be the best candidate for this. Similarly, on the other side of the spectrum, you want to take the absolute most rock solid application that's never having any issues and target that either because that may draw unwanted attention in those areas. The other tip is watch your language. Not that you would lose your cool. This is more along the lines of, you're not moving XYZ application to open stack. What you're trying to do is you're trying to make XYZ elastically scalable. That's the language you need to use. What you don't want to do is you don't want to have a tight coupling between some application and the underlying infrastructure because when something goes wrong, that could cause you even greater headaches later on. You need to set some realistic expectations. So there's going to be instability and when you're working with your business partners, like you got to know that upfront. You got to really focus on where you're headed. We're really trying, like what are the actual goals and know that it's going to get worse before it gets better in a lot of cases, but then that's okay. Be transparent. So if the good and the bad. So if your goal is you want to, like this is going to improve availability overall and lower the total cost of ownership for an application, you need to have some metrics that show that and you need to review it on a constant basis. So you know whether or not, and I said when I say review it, I mean you need to review that with your business owners so that it's clear whether you're heading in the right direction or the wrong direction. So take the good, take the bad, take them both. There you have. That's an American reference probably. I don't know if that's what I'm going to make it across. So how do we, oh yeah, that's right. So you really want to be clear about the business value and like I mentioned the TCO piece, but there are way more ways to measure business value and Leon, why don't you talk us through that? Yeah. So I think every technology must create value to the business. But the key thing is how can we map this kind of technical capabilities into the business value? So when we talk about open stock, we always talk about open source able to reduce commercial license fee and can run on commodity hardware can with different kind of hardware vendors is give you open architectures and open design can potentially move into the hybrid cloud or multi-cloud models having a supporting by a wide ecosystem. But how are we going to map this technical capabilities into the business value? So there's one company, not my company, there's one company that published an article talking about analyzing the value of implementing open stock in their environment. So they compare three different deployment with 25 servers, 150 servers and 500 servers and compare the cost, the benefits and measure the ROI. And what I want to emphasize here is the next slide. The cost considerations is something that you can consider because those are things that you need to show to your CFO people. But I want you to focus on the benefit side. So the colors a bit weird. So the benefit side I think is what you need to focus on because for example, things like the IT efficiency improvement. So by using open stock, basically you can automate a lot of different things. So potentially you save a lot of maintenance and efforts. You can actually reallocate your operation resources to do some more value added activities rather than spending time doing all the routine job, daily routine job because those things you can automate through open stock. And also about user productivity, you also need to look from the user productivity perspective. So by putting the applications in a self-service model, so the user is able to get whatever they need in a more faster way. And other things like application value which I want to talk about here, application value, your applications will not... Okay, I phrase it this way. Your application will not be delivering any value to the company as long as it is not deployed. The application will only be able to add value to the business once it is deployed. So the key thing is, this is what I call time to value. So your formula developments up to the point of deployed application. Some people call it time to market but I'll phrase it in a way that it's time to value, time to add value to the business. You can measure that the shorter the time to value period is the value. So using open stock, when you try to measure the value of open stock, you really have to think about not just about a course. You focus on application value, the time to value. I think that's very key important pieces. So being able to be agility, able to do innovation faster, you can run different kind of experiments. The time to market, as I say, those kind of things is actually much more greater than a cost considerations. And one thing I want to discuss here is about reliability. And traditionally, I think a lot of companies use to buy a lot of expenses hardware to increase this mean time between failure. And they also use a lot of hardware-based redundancy to improve your availability. But when coming to the open stock plot environment, it gives us an option to think about using or maximizing the automation choose to reduce the mean time to repair. And they can use a lot of different kind of software-based redundancy model in the open-stack environment such as using multiple region availability zone using heat orchestration or auto-scaling features, auto-healing features to help you to increase the system availability or system reliability using a different way. So we are looking at a shift from using hardware to increase the mean time to between failure to using software solution to reduce your mean time to repair. So next thing I think probably Mark want to talk about the wide wide funding. Yeah, so because this is an investment over a period of time and because it's based on open source really available software, the way in which it's funded changes. Now it is obviously there is funding involved, there is cost involved, but typically there's not going to be by pick on a proprietary vendor, the big proprietary vendors of database software, for example, that have these very expensive could have upfront license fees, CAPEX license fees. The considerations here are different. You need to plan for there being much more operations, much more operational expense. And therefore when you're applying for funding or you're seeking your budget approvals, this funding is going to appear in different buckets. And it's also going to be harder for your purchasing teams to wrap their heads around, because they can't go and necessarily negotiate with a vendor and take a $10 price and turn it into a $5 price because it's operational expense. It could be consulting, it could be hiring people, it could be training, it could be all of these things. Investing in community, which is how do you put a price on that? But we know we need to do it when you're implementing OpenStack. So be prepared to start to switch some of that funding discussion away from, you know, for budgetary approval for upfront. People like decreasing upfront fees, of course, but they need to understand that some of that money is gonna need to be freed up for that ongoing operational expense. Some companies will talk about chargeback model. Yeah, so we can use chargeback model to a different department to fund your future and further improvement for OpenStack environment. Right? Yeah. Absolutely. The key takeaway there is, like really need to consider that upfront. Yes, exactly. Don't wait till you're deep into it, right? Yeah. So some final takeaways, you know, developer adoption is key. Couldn't stress that enough. You really wanna start that early, start that conversation early, start evangelizing early and be really diligent throughout. The political aspects. So being cognizant of the political landscapes, pick your business partners wisely. Define and measure value. So be really crisp about what you expect to get out of the transition. Be prepared to measure it. And be transparent. Good or bad. You'll start to lose respect if everything's all sunny day and exciting, even though it doesn't necessarily feel that way. If there's a general feeling that things aren't going well, you really need to address where it's not going well and what the plan is to make it through it. So with that, we'll open it up for questions. I think we've got a couple minutes. Hey, got two questions for you. The first one, when modeling out the business case, when you look at sort of the usage part of it, because I've seen business cases in my own company where people are like, well, when we're fully pattern-based and everything's cloud and elastic, we'll have fewer things sitting around because developers want to leave it there because it's hard to rebuild. So sort of the idea that persistent images in a DevTest environment will go down, so you'll, if you have a metered service through a cloud provider, that your costs will go down overall. But I think I've heard a couple of times this week that expect when everything gets magical and pattern-based and push-button to deploy, that developers will just deploy more and usage will just go up. So I was wondering if you guys had any thoughts on the usage patterns when you make things easier to consume? Yeah. Oh, yeah. So like Leong mentioned, they had one way to try to combat that sprawl, that free candy. It's like you can get as much as you want and there's no real repercussion. Is really, as you start to pursue showback and chargeback, those types of models where you can try to push that cost back into different business units and make it visible. The showback model, the thing you have to be careful about is that becomes politically charged as well. Sometimes when you do the showback and you're totally transparent with what those costs are, you need to make sure that you're cost competitive in the market and that you're showing folks information that is gonna actually be used. So do you think, I think you're saying it's smart to model increased usage, not reduced usage as a result of putting all the time? Yeah, that's right. I think a good open stack cloud should consume multiple workloads and will grow, right? I mean, that's the role is to provide a platform that's gonna encourage your developers to innovate, right? And I think that means increasing, right? True. But it's experimentation, right? Yeah, innovation. Yeah. What we'll do is, I'm sorry, I didn't mean to catch you off. We'll answer your question, we'll end because we're getting played off, but we'll stick around and we'll answer your question absolutely. So thanks everybody for attending and enjoy the rest of the conference. Hey.