 All right, I guess I get an extra minute. That's good news Open stack in the wild. Thanks for coming you guys This is kind of a fun topic for me to talk about I've been attending these open stack summits for a long time and It's just in the last couple years. It's starting to got to the point where we're out talking with customers And they say hey, we're trying this open stack stuff in our in our enterprise and it's pretty exciting So we're seeing spottings in the wild And we've kind of shifted our company shifted from evangelist to now We're going and actually implementing stuff when clients are asking us to so it's pretty excited Exciting times. That's why I called this open stack in the wild But this is really all about how to make open stack a reality within your own company So quick kind of show of hands. How many people are in here are? Hosting or managed service riders hosting companies man. Okay, so a few and then how many are from enterprise end users Okay, cool So hopefully you're going to find this interesting just a quick introduction My name is Grant Kirkwood and I'm the chief technology officer of Unitas global and we are an enterprise cloud service provider We serve primarily mid to large enterprise organizations worldwide operations on pretty much every continent except Antarctica and We build large-scale cloud environments for companies that are looking to leverage open stack and other technologies So First thing first thing we're going to talk about is a little bit about the kind of things that we hear out in the space But first the four phases of open stack adoption within the enterprise We think that this generally starts with an idea within the enterprise It then moves into a proof of concept Then you're actually building for production and then the fourth most important step is driving adoption So I call it kind of the four stages of open stack So then what do we actually hear from our customers? So we go in and talk to a large global enterprise about what they're looking to do in in terms of technology And there's one theme that we hear over and over and over again It's that they're they're not really making a whole lot of strategic progress They're kind of keeping up with the day-to-day demands, you know The email system went down and so they're going to go fix that and then you know The F cluster blew up and now they're trying to rebalance data But they're not making a lot of strategic process progress. We hear this a lot Particularly in enterprise companies that aren't necessarily Technology companies themselves really it's it's manufacturing and retail and finance so then you come to the open stacks on it and And this has really been true in previous years not as much this this year But you you watch the keynotes and there's these success stories these really big companies that have made huge progress with open stack At the at the last summit Walmart was one of the main presenters And they made the announcement that they went all in for their entire global retail operation And these are really cool stories to talk about and I love telling them to our enterprise clients But the reality is sometimes they're kind of inspirational. They're not necessarily Practical for the kind of mid to large enterprise are really only practical for the largest at times So inspirational, but how do you actually translate that into? Businesses that don't have teams of developers Before we talk about that. I want to talk a little bit about why open stack So we hear a couple of common themes. I like visual aids by the way if you can't tell Common themes that we typically hear and we talk about them here at the summit we hear agility over and over again Agility directly translates into an ability to execute now perform your peers and then you give it industry This is a real common theme and in kind of business management So if you have a more agile infrastructure if you believe that technology becomes more important to running a business If it's more agile then your business is more agile and therefore you're going to be more successful Next theme flexibility If if you have an open architecture and you're based on open source software You have the ability to adjust and become flexible to changing business environments and technologies You're not you know stuck in kind of a predefined box. That's one of the things that I'm really the most excited about with open stack Another really common one is vendor lock-in And this is huge for us right now in the last 12 months We've had lots of customers coming to us and saying hey, you know We've used vendor XYZ for year after year after year and they keep kind of extracting their money out of us Or our money out of out of us and we're kind of done with it We're done with being stuck with these vendors just because that's the way it's always been done And so open stack gives you a way to get out of vendor-supported IT and bring the control back to yourself And then focus also is really important. So most companies again aren't necessarily Technology companies they might be doing other things but rely heavily on technology Well, if you're a health care provider and you're spending all your time focusing on building data centers and Running clouds and making all that work the nuts and bolts of the infrastructure You're probably not focusing on the health care applications that are actually really important to you So this is this is a big one and I'll tell you when we have conversations with clients It never starts with us. They never put their hand up and say hey I'd really like to focus on my business more It's only after you have the conversations you get past the technology and all the other things that this comes up But that's really important and then of course savings So a lot of people I've heard the phrase, you know open stack is free VMware and that's not the case Right. We're not trying to replace other technologies that that are on the market. We're trying to do something differently here But if we ignore the fact that cost savings is really important to all companies Then we're not, you know, we're not going to deliver an effective message. So it matters. It really does So to kind of package that up if you think about the business drivers And this is really the context of the conversation as it relates to open stack in the enterprise It has to be because there's a specific business need or an identified driver. So cost Agility equals greater ability to execute and then technology and you'll note that I put technology last So I'm an engineer. I like technology But if we make the whole conversation about making technology do cool things We're going to lose the business people, right? It's important to focus on what that translates to in terms of the business It's can't be about the science experiment that we all want to do so The next step in this and this is critical if we talk about how we're going to do something before we've stated Why and before we've built consensus, we're going to lose the constituents that we're trying to serve in the first place So you'll hear me refer to this this theme several times But defining the why before the how is super important when you're talking to a business about adopting new technologies like open stack So then how do we articulate this into the business? So when we're talking to business executives and managers about why we want to go do this cool new thing with open stack We've got to talk about total cost of ownership and return on investment, right? Technology is an enabler of revenue within a business. It used to be viewed as a cost center And there are still businesses that view technology as a cost center But now increasingly we're seeing companies using technology as a way to enable revenue So for every dollar that's invested whether that's capex or op-ex or people's time, which is often the biggest cost It has to deliver a return to the business So when you think about the the money that's invested into open stack or any technology initiative It's got a there's got to have be a tangible benefit and then opportunity cost so getting back to the agility Factor opportunity cost is basically the time that it takes to go take advantage of a new opportunity if you've got inherently inflexible rigid infrastructure You're gonna miss opportunities that you might otherwise capture if you're quick and nimble and then people So and this is this is gonna have a real big impact in terms of how we choose to implement open stack within the enterprise But people are expensive a lot of IT budgets. You see people as the number one expense in the business So people translate to time and train therefore translates to money So if you're able to save time and be more efficient, you're gonna deliver value to the business So as we build a business case within our enterprise about why we're gonna go take advantage of this cool open stack Stuff we have to think in terms of the the underlying business drivers and the reasons that we're looking at it in the first place So next psychology matters and this is this is also really important So we've defined kind of why we want to go do this thing. How do we build consensus? So People typically respond to things more effectively and throw more support behind them When they feel like that idea was their own or that they had in a personal investment in coming to that conclusion So if you tell somebody hey, this is what we're gonna go do there might be You know defensiveness to that right they might not immediately jump on board with you But if they feel like they've been part of the decision-making and they've seen the reasons why we might go do something And they've bought into that idea then they then they might go from being defensive to your most ardent supporter So if you're able to make the idea the rest of the the constituents within your organization If you're able to make it their own They're gonna buy into it more and you're gonna achieve consensus And I'll tell you that achieving consensus with the enterprise is half the battle if you can get there then you can then you Can do almost anything on the technology side So success criteria super important If you haven't good going back to the kind of the business drivers around ROI and TCO and the benefit that this is Deliver to the business if you haven't clearly stated here are the metrics by which we're gonna judge how successful we are You're not really gonna get anywhere, right? So you need to think about metrics that are relevant to your business for example in the in the health care example if they're if you have a specific amount of time that it takes to go and retrieve files and deliver patient data to doctors and hospitals and you can Measurably demonstrably decrease that time by utilizing open source technologies and having an open-stat cloud Then those are the metrics that you need to use and set out in advance as hey if we achieve this We've been successful So then we talk about you know, how are we actually gonna do this one thing? That's really important before you go and start putting a proposal out to the business is figuring out what your team skill sets are So if you don't know what you can do How do you know how to build it so identifying team skill sets? That's my favorite slide you guys like it All right, so now Let's let's say we've kind of gone through all these steps and now we've actually got buy-in Now it's time to do a proof of concept within our company. So how do we go about that? so Famous words one does not simply do open stack. It's actually quite quite complex and there's lots of different ways to do it We're gonna we're gonna talk about kind of the pros and cons of all the major ones so first fundamental question that you have to answer is do we build it or do we buy it and I'll say this there are lots of different ways to do each of those right It's not like you can just go into a store and buy the open stack cloud And it's not like you can go and just buy a kit and put it together like a set of Legos, right? There's lots of different ways to do this and there's no one right way so we're gonna kind of talk through the major categories and some of the benefits and and downsides of each and For sure one size does not fit all so thinking about building and buying what am I actually talking about? in a build model generally the themes are you're taking a bunch of stuff and Going back to the skill sets you have people that are capable of putting all the pieces together and building a cloud for your business that meets the objectives that you set out in a buy model you're going to a partner or a service provider or a Appliance manufacturer and consuming open stack. So the question is do you want to go and build open stack or do you want to consume it? And I would say that that the answer to that question has a lot to do with what your business actually is So if you're in the IT infrastructure business, if you're a hosting company, for example chances Are you probably want to go and build it right? But if you're like the vast majority of companies You're probably doing something totally different and therefore building it might not make sense for you It could still but probably not so the question you have to I got goofy if the question you have to answer is are you fundamentally a technology infrastructure company if you're not I would say consider Consider buying and most importantly is is infrastructure core to the business or is it a distraction, right? Okay, so build variant number one building from trunk. You'll also hear this called vanilla, right? So this is going on the open stack website and going through the tutorial and building it from hand if anybody was in my presentation yesterday I kind of took went through some of the steps that it takes to do this and the long story short is it's really hard It takes a lot of work There's no automation involved in building it straight from the open stack tutorial, right? You're literally building each service relationship by hand And it's it's not fun You really can't get a lot of support in that model either because it's not a vendor vendor supported configuration You can't go and call up, you know, you know the the open stock open stack repair shop and say hey come come fix this for me It's not really an option It's inherently a snowflake because you built it yourself you built it unique to your specific requirements So it doesn't fit within a common reference architecture most likely But there are some benefits right you know exactly how it works and you're not tied to a vendor So going back to the whole vendor lock-in thing, you know, nobody's no you're not beholden to anyone But that means that it comes with there is no vendor support So you have to think about is that something do we want somebody that we can call? Are we okay with paying for somebody that we can that we can call? You can also customize it almost as much as you want Again going back to our three monkeys if you've got the skill sets to do that in your company And then lastly, you know upgrades are really tough in this model It's still something that's pretty painful a lot of the distributions have solved or nearly solved this problem But if you're building it yourself from trunk code upgrades are difficult Okay, so build variant number two using a distribution So this is the red hat and canonical and marantus see so others that I've forgotten and So first thing, you know, you typically are limited somewhat in terms of the vendor selections, right? And each vendor has kind of a different approach to this and I'm not going to go into all the specifics But typically a distribution comes with a core set of services Maybe some ancillary services and that's kind of it if you want to go and add on additional services into that cloud You're kind of on your own going back to building it by hand So it's not quite as customizable And it does you it does tie you to that vendor and therefore it costs money The good news is it's way easier to install in any case from any vendor It's going to be much easier and save you a lot of time Upgrades are easier like I said most of the distributions have figured out how to automate Upgrades and both in terms of the systems the hosts as well as the open stack distribution And therefore the day-to-day operations are easier And then lastly obviously you got someone to call when something goes wrong and things do go wrong You've got somebody hopefully that's friendly on the other end of phone that you can ask for help So if you're building you're building more than just a cloud And this is something that is often forgotten when you build kind of the the TCO and ROI model for what this looks like within your company A lot of times this gets glossed over because you're not just building servers and virtualization You have to build a whole practice around it, right? It takes process and operational excellence to support it and deliver a service that the business can actually rely on it takes people It's not just standing up a cloud and saying here guys go have fun Alright, so now we'll switch to the buy methods and I call this consuming so again This is fundamentally different than building you're turning to a vendor and saying okay go and serve my needs And yes, you know in a distribution model that we just talked about you're still buying something from a vendor But it's coming supported, but you're still putting that together yourself This is literally you want horizon and you want to go and start consuming resources So where do you start right? If you go down to the marketplace? and this was from two some months ago, but If you go down to the marketplace, there's 300 companies that all say that their thing is the best way to do it So how do you navigate that? how do you find a partner or service writer that actually fits for your business and It seems like it should be a fairly straightforward journey to navigate the ecosystem You've got your cloud where you're going and here you are and it's a straight line. So let's go The reality is it's typically more like this and you're gonna go chasing that cloud and a vendor that can help you get there And when you think you've found it out comes the fire-breathing dragon And we have seen this lots and lots of times with our customers have come to us and said We tried X and it totally failed and we spent tons of money help so Three ways to buy and these are the three kind of fundamentals. There's lots of variants of these The first is appliance second is kind of sass sash appliance was a relatively new category And the third is a hosted or managed service. So we'll talk about these On appliance basically is a box that you buy it gets shipped in a piece of cardboard You unpack it throw it in your rack turn it on and boom you've got cloud There are some companies that are doing really cool things in this space And it makes it Super easy almost plug-and-play simple to implement on it's fully integrated with the hardware So you're not worrying about, you know Compiling in new drivers and some of the goofy stuff that we have to do when we build it ourselves Downsides it's typically limited to the hardware configuration that that vendor has identified as their reference architectures Which means if you if you're deploying one of the hyper converged appliance vendors Inherently you're either going to waste some disk space or some memory or some CPU capacity as you scale out Chances are their preset ratios probably not going to be exactly yours It also means that you're a hundred percent reliant on that vendor for support So relatively new category in the past kind of 24 months or so. I call it this ass slash Appliance model. It's a little bit of a hybrid. So there's some companies now that are basically allowing you to bootstrap a box Into a compute and storage node and then the controller services run off in the cloud Do you over use the word but basically somewhere else? So that service provider has the portal that service provider has all the control services sitting in their data center Somewhere else and you just have that compute and storage node It's an interesting model. It means that that other company is totally responsible for the hard part Which is setting up all the control services so convenient But it does mean that you're a hundred percent reliant on that vendor a staying around And be physically if you lose connectivity those control services are potentially broken Might not be impacting to the workload on the cloud, but it certainly is impacting in your ability to provision Like I said, it's a relatively new category and there's a couple of players in the space that are doing Interesting things here. So I'm interested to see how this plays out I will note that it still means that you have to take on the kind of operational response responsibility for Providing support to your internal users and then the last one Is the hosted or managed service? So interesting thing about this and this this I could spend another day talking about on its own Because there are tons of choices. So there are a plethora of companies that will let you consume private custom cloud In their data center and deliver it as a fully turnkey service and you get horizon and go spin stuff up And it is the purest consumption model It's the closest to the likes of an Amazon or Azure and that you know You're consuming cloud and you're having no responsibility for operating it whatsoever The downsides because there are so many choices of providers It's hard to find one that actually fits. So I've heard from our customers They've said hey, we really like your company because you guys are super flexible and and you'll let us you know Choose how we want it and and you know, you'll really customize the cloud And then I've heard other customers say we don't want to work with you because you're super flexible And you'll let us customize it So the point is you need to find a provider that is going to align with your desire to have something It's either really custom or fairly rigid and there is a an argument to be made for both And then obviously it means that you're tied to that provider, right? So you better hope that they're a good partner You better hope that they're gonna have your back and operate with the same level of excellence that you would as within your own company So Kind of building and buying here this here's kind of the five choices. I would say the broad categories Again building from trunk or distribution and buying as an appliance kind of the hybrid sass appliance model or buying a hosted managed service so again visual aids All right, so next up you've decided how you're gonna do it Whether it's building or buying now you need to make it easy for people to use So at the end of the day if you're building an open-stack cloud within your enterprise You're doing that to be a service provider to your users and consumers The easier it is to consume the more likely you are to drive adoption within the enterprise so Second part when you build it as a proof of concept build it with production in mind This is not what you want to do If you build it as something that's inherently Unreliable or come with risks Then chances are people probably aren't gonna put important workload on it And if they're not putting important workload on it Then that means you're not gonna have a successful proof of concept Or if you build it this way and they don't know and something goes wrong And it goes down and that workload is impacted people are gonna say see I told you that open-stack thing isn't reliable When it could have just been something like this. I saw some people nodding some heads. I know that that was What my first one looked like so? And then keeping it simple so if you spend any time going around to all the sessions here at the summit you'll hear about endless bray a barrage of Different projects that you can implement within your cloud So my recommendation is to really focus on the core services compute and storage You know if there's a couple of things that you need that are really specific to your business You need databases of service. That's fine, but keep the set limited I know personally when I'm going and doing this for fun I want to implement everything because it's fun and I get all kinds of things to play with But that's really counterproductive in a business environment So I would suggest you set a cadence for conducting surveys of your users and finding out what they're actually looking for Do it on a regular basis so that your users know that there's a consistent process that you follow for taking in user feedback and then considering new features to implement in in You know on a quarterly or or semi-annual basis The reason for this is the more things that you implement within that cloud the more services You have to support the more complexity the more time-consuming it it becomes and worst It leads to choice or decision paralysis and this happens a lot in the enterprise Don't let it happen to you if you become paralyzed the whole thing grinds to a halt Okay, so now we've got a drive adoption right we've built this proof of concept We built it the right way. We decided how we were gonna either build or buy. We're up and running We've got our core services. We've given accounts to all our users. So now we've got to get them hooked And this is gonna lead into kind of business process right like let's assume that we made it easy And we've and everybody can go in and access it Maybe you've done some training to show how to consume it if your business process doesn't catch up To this new way of consuming you're not going to see adoption. So it'll tell you a little story We had a customer three or four years ago that They had a really big private cloud environment built on VM where there's as many years ago And at some point they realized that this company was spending a million dollars a month on Amazon But it wasn't a budget-line item. It was all of their IT users putting down their credit card and going and spinning up resources So they said aha, we're gonna go build our private cloud And give all of our users access to it so they can consume stuff and we're gonna save tons of money and so they did that and They went from 42 days to 38 days in terms of implementation of new systems. Why? Because they didn't adapt their business processes What they did was they had the same requisition form that they used to requisition a bare metal server in the data center And they applied that to virtual machines in their private cloud and guess what Amazon spending kept going up So adapting the business process into a way that's nimble and flexible to keep up with the improvements that you're making this technology Is super important if you want to drive adoption Secondly test drives work, right? There's a reason you go to the car dealership and they gave you the keys and they say drive around and you only get to Go two blocks, but that's okay It really does work when you give your users access and you say here's here's this cool horizon thing You can go spin up whatever you need It helps get them hooked when they see how easy it is compared to what are probably the previous ways of doing things that involve Paperwork and email and everything else so let your users into the system encourage them to play with it and get comfortable with it Okay, so yay success. We've got users on our platform It's the cloud everybody's happy. They're using it now. What do we have to do? First thing we've got to justify its existence now. We've actually got some applications running in this cloud We've got it. We've got a justified existence because it's going to grow adoption is going to increase and oh look We got to buy more hardware to support it. Well, somebody's going to say Tell me why right? So you have to track how people are using resources Two particular things that I like are cloud kitty and Talogen open book both really good technologies to do this a lot of companies will use cloud as the infrastructure as a service for Business units or departments or subsidiaries and so you want to track on a business unit basis But also track and do charge back and show back against specific initiatives that it users might have That helps you justify the existence of this technology on a go-forward basis And then secondly We got to keep it healthy, right? So there's some stuff we have to monitor now first We got to monitor all the open-stack services that are running in the platform So keystone and nova neutron stuff all that good stuff. We got to make sure that it's running This is important to build an operational monitoring system with with good rigor Performance is important. So if if all of a sudden it gets full and performance goes down You're gonna have unhappy users and again, they're gonna do that see I told you so thing Let's go back to the old way So monitoring performance is important And utilization for the same reason, but you got a plan for growth too, right? So one thing that opensack doesn't really do out of the box very well is tell you how much of the kind of physical Stuff you built is actually being used on a consistent basis. So you've got to augment the capabilities So that you can see as that utilization is growing You know when you're gonna run out of run out of capacity and can start adding So I know everybody likes to take pictures of slides. Here's the photo slide this summarizes kind of all this stuff so feel free to take a picture of that and I'll open up for questions Sure, so the question was what's an example of where agile technology cap can help you capture an opportunity So we had a we had a customer Large global conglomerate Manufacturing conglomerate and they Had this opportunity to go and buy a subsidiary from one of their competitors that would strengthen their market position and actually let them become a the dominant player in their particular vertical and They had a really short window of time to do it, right? They didn't have the infrastructure They had kind of rigid process and so they were able to basically say hey We've got this really flexible open-sac architecture. We can add nodes in we don't have to re-architect anything We don't have to do forklift upgrades of big sand equipment and they were able to extract the it Assets of that subsidiary You know within like a 90-day window, which normally in that kind of case would would be a six or nine month process And they had to do it within that window of time Otherwise, they wouldn't have been able to make the acquisition and to do with a whole bunch of kind of environmental and regulatory stuff But that's that's a that's a real example And I know companies like Netflix are all often looking at new markets where they can start streaming so when they announced Year and a half ago or so that streaming would be available everywhere the ability to quickly adapt and deploy reference architecture That was easily repeatable and scalable played a big part in that So the question is if you eliminate vendor lock-in do you get locked into the to your employees? Yeah, no, that's that's that's a really good point actually so You know getting back to the kind of the inspirational success stories, right? You know Walmart has a team. I don't know how many it is now But hun in the hundreds of developers in Walmart labs that are supporting this right so so for sure there is there is You become dependent on the skill sets that you have in house And that's actually speaks to the build versus buy right if you're building it all yourself Then you have to have the people to do that and you got to keep them, right? It's not a build it and then forget it walk away so if if you want to be not locked into People maybe the service provider partner Avenue is the way to go any other questions All right, so Contact information is here if you want to copy of this just send me a quick email. I'm happy to send it to you And if you enjoyed this and found it useful, I'd love some feedback on the on the app Thanks everyone