 Hello everybody. Welcome to our session. We're going to talk about the right approach to find your OpenStack distribution. So it's basically mostly about which questions do I have to ask, where do I have to look for to get the best possible result back. Short introduction. My name is Alex Stelberg. My OpenStack journey started back with Essex back then. And since then I've been working in various roles from end user through architect pre-sales. And since a couple of months I work in the open telecom cloud team and systems as a cloud architect. Yeah. And my name is Sven Michels. I'm the announcer CEO of Sector, which is my own company, but I'm currently working with Strato, which is a German hosting company, currently part of the largest one in Germany doing cloud architecture and other stuff regarding OpenStack. I also joined the OpenStack train around Essex together with Alex. Funny at this time, we were working also at Deutsche Telekom in one of the first OpenStack projects at Deutsche Telecom. So yeah, we tried to ramp up the last years and what we saw, what people should ask and what they don't ask and what they should care about. Okay. So what's the question we're talking about here? It's just what is the OpenStack solution that best fits my requirement? And we will try to give it a short look under various aspects. So we will look at budget. We will look at time and we will look at feature. And as you might guess, these are not easily to bring to the optimal point. The answer to this, unfortunately, it's not that easy because there are way too many options. So do I run a public or a private cloud? Do I go hybrid? Can I buy from a distributor or maybe I roll my own distribution? Do everything on my own? Can I use third party components or will I stick with the reference implementation that comes from upstream? Am I okay to incorporate closed source components or is it a fully open source approach that I want to go? Is it a green field? Is it a brown field where I have to integrate into existing systems? Stack depth means how much do I want to implement? Is it plain, yes, or do I even want to implement some container stuff on top, some past stuff on top? And last but not least, it's also about money. So maybe I want to offer my solution at a competitive pricing. And maybe that doesn't go together with buying fully certified, fully vendor certified stuff because I can't make my price point. And so we really, really have way too many options to simply say, well, let's just take that one that will work. Yeah, so what you need to do is to ask the right questions and the right questions, that's easy to say because in the end, you probably know what the right questions are, but at the beginning, it's hard to define what are the right questions. So you can try to figure out what would be the right questions to ask. So you need to take a look at what is the focus of your project? Why do you want OpenStack? Because many people just roll out OpenStack and see what happens. The same goes for your requirements. So if you want to go with a private cloud, you will have different requirements for your cloud setup. Then if you go, for example, for your for a public cloud or a hybrid cloud comes to security and stuff like that, which is sometimes, yeah, messing her up with all your setups because they tell you what you're not allowed to do. And then it comes to a point where you say, okay, if I implement all those security requirements, it's basically useless anymore. So whatever I get, I can't use or my customers can't use. Same goes for timeline. So if you want to have your OpenStack running within the next three months, that makes a huge difference, besides if you take like a year for rolling out your own OpenStack. And so it does for money. If you can spend a lot of money on it because you need people to do all this stuff. It's another approach as if you just go for like, we are a small team, we don't have that much money, but we have plenty of time on our hands. So we can try to work it out by ourselves. That's also important to keep in mind. And last but not least, whatever you do, try to keep it in a realistic way. So if you come to the point that you look, I would go public within three months, spending like 10,000 euros, that's probably not gonna work. Same goes for you expect a hybrid cloud, which is large and it supports internal and external projects, but you only have one to two people to operate it. That's probably also not gonna work. So try to stick to other people, what they told you about, even on the conferences, for example, they will give you a brief interview about what they did and how many people they involved, how many time they had, and take that into account when you start your planning. Because this is key to success in this time. Because if you just like, yeah, do too much for in a too short frame, it will fail. Yeah, and another very important thing, I think we come back to that later, is remember that if you're working with other companies, vendors, suppliers, even communities to achieve your solution, then you need to give both sides a bit of preparation time. So it makes no sense to define requirements, define test cases internally and hand them over to some vendors that you are doing a POC with on day first when they arrive in your office. That makes no sense. They need, they also need preparation time. The more they get, the better they can prepare and the better fit you might get back from them. So share your requirements, share your test cases as early as possible to allow for the best preparation from everybody that you're working with. Yeah, and last but not least, you need to stick to your requirements. So if you send the vendors some requirements and you change them like every two weeks, this is, yeah, it's really bad for the project for everyone. It also, it's also bad if you change your requirements based on customers. Like you have a customer today, which requires more IOPS than the other one, then you stick to that one. Next day, you get a bigger customer and he requires like large VMs with a lot of RAM. So you try to fit that one in and so on and so forth. So if you change too much in this phase of finding your solution, you will end up in like, we want everything and this is also probably not going to work. Yeah, we all know that from IT projects. If you start working with moving targets, it gets really, really nasty. Yep. Again, it's about requirements because we think that this is really the crucial part and the most important parts. Get your requirements really done first of all. The better your requirements are, the better your search can be, the better the results will be. So I've seen projects that started with workshops where customers said, well, we just want to build a cloud and see how it's going and business will come, no worries. And in the end, these are really the projects that don't go very well because nobody knows what to expect. Nobody knows what to prepare, what to deliver. And every time you deliver something, the customer comes, hey, that's great. Can we get even more? Can we get it better, faster, cheaper? And that's really something that kills your whole project. So without proper requirements, you're really lost in all of the options that you have seen in the beginning. And there's no clear target, there's no clear path to the target, and that really makes things very tough. And you need to prioritize your targets, categorize them, you need to define. These are my essential points that need to be fulfilled from the very beginning. I need this for my first release, so define your minimal viable product. And you may have important targets where you say, hey, I need this, but probably I don't need it from the first day. It's okay if it comes with a later release in six weeks, three months, six months, whatever. And then there's of course a lot of nice to have things that are not really necessary for your product, but that you see maybe we can use that in a later release, but it's not essential to have them. So that's important that you have your requirements really well set, well categorized. And if you have done this, you should be prepared to sacrifice some of them. Because we all know from IT projects, if you look at three dimensions, which are cost, time, and quality, or sometimes people say cost, quality, scope, that's basically the same. Usually we are cost constrained, which means there is a certain line that you just cannot cross because that will kill your budget. And if you look at that circular line, if you set for any point on that line, you will get a certain amount of quality within a certain amount of time and you will still be in budget. And if you then tune one of them, so you say, okay, I need more quality or I need more features, whatever, you need to be aware of that. This will take more time if you cannot go for more budget and the other way around. So that's really something where you might be in the need to sacrifice some of your requirements or to recategorize them from, okay, maybe it's not that essential, maybe I can live with it for the second release. Or you simply notice that it doesn't work like you expect it to be. So, sometimes you pick up like an open stack project, which looks good at the beginning. But the further you progress, you notice that it's not gonna work the way you thought it will be, and so it will probably not helpful. So skip that one as soon as possible. Yeah, right. Yeah, so the first filtering you can do is get everything with, which is at the, let's say, nice to have part for a project like that. Also, whatever doesn't meet your requirements anymore or at any time, just forget about it. Don't think about it at this stage. Because if you do it like that, you will end up in like, oh, we want open stack and we want it with all of those sub-projects because it looks so cool and it's like, yeah, it is the way it is. Like, everyone uses everything, but it's not the case. So just forget about all the stuff you don't need because that will just distract you from your way. So just nail it down to the small things you need. At first, maybe second stage, and focus on them. Try to bring them on the street because that's the way you can start moving. If you don't move, you will not get anything back from it. Yeah, and that's the point then when you really start to talk with possible vendors or communities or whatever. Or people. Or people in general, yeah. And from our experience, there's just one thing that doesn't get you any further, that doesn't make sense, and that is don't do checkbox RFIs. If you have ever worked for a vendor, you may know those. There's a project coming in and at some point in time you are mailed an Excel sheet with 180 questions and checkmarks where you can just say, okay, my solution fulfills that need, my solution doesn't fulfill that need. Problem with that is no is not an option for salespeople in this kind of RFI. So nobody wants to say, okay, I can't do that, I can't do that, I can't do that, I can't do that. Because everybody knows if you take a few noses in there, maybe even in the essential part of it, then you're just out of the business. So you usually end up saying, yes, and then there comes a large but. This will be in our next release. We have this on our roadmap. We are the greatest vendor of all and do everything to make our customers happy, blah, blah, blah, blah, blah, blah, blah, blah, blah. I don't want to say this, this is a bad thing to do. And the only thing is, it doesn't bring you any further. So that doesn't help you find your solution because every vendor will just try to be seen in the best possible light there. And nobody likes talking about things that they cannot do. And just one small notice, the same goes for keep your requirements in mind. Because they may try to change your requirements the way they can support it. But if you have thought about your requirements first in a very well way, there are reasons why you require it that way. So keep that in mind and don't let it change easily by, yeah, maybe you don't need it like that because we have something that is similar to that. And then you're like, okay, maybe we can try it but check first what they really offer you. Because if it's not what your requirements are, then you probably will end up in a solution that also doesn't work well for you. Yeah, good point. So the much better way to approach this is just to workshops. So invite two vendors, three vendors, people from other communities with their projects where you're interested in. Invite them to do workshops maybe half a day, maybe one day. And again, share your requirements with them ahead of the day coming in because it makes no sense to have a workshop and then you tell them at day first, okay? This is what we want to see and nobody's prepared and you will just get crap out of it. So share your requirements and work from them. So it is all about your requirements and you want to see your requirements fulfilled in these workshops. So don't let them do generic presentations. Maybe a short run as an introduction or for having an overview. But then really work on your requirements. And again, that requires you to share them ahead of the workshop. Because both sites need preparations, we've seen the slide before. And maybe don't rely too much on roadmaps because roadmaps are constantly changing. And in every roadmap you will find somewhere printed in six point size, 10% light gray on white. This is just a roadmap and it might change in the future. So there's no promise that this will really be there. Instead, let them demonstrate, especially your essential requirements because this is what you want to see when you start with a product. Let them demonstrate that they can do it, that it works, that it works the way you want it. And if you have time, then maybe even do that for your important ones where you say, okay, we want to see this in our next release or maybe show us what you have now. And maybe it gets better in your next release. But again, don't rely too much on roadmaps. And the workshops are also nice because you can see the product working. So you can see what they do with it, how they demonstrate it. You can start to get a feeling for the product you just get presented. Instead of just doing some slideshows and stuff like that. So maybe there are problems while they do some presentations. And problems are okay because they happen. But take a look how they solve it. If there's something which doesn't work, what do they do? Do they feel comfortable with that and fix it just right away? Or is it like, damn, we never have seen that before. We're not sure what happens now and we're probably the wrong people to solve it right now. Then it's probably the wrong people they send to the workshop for you. So this is also a small note you can keep in mind to get a workshop in a, let's say, very useful way. Just not wasting people's time because usually you invite more than one people to a workshop like that. Yeah, and after these workshops, it's probably most likely the right time to start with a proof of concept where you concentrate even more on the things that you want to see. So the workshops more align your architecture and check if everything is okay, but it's not yet a full-featured proof of concept where you really have your test cases defined. So the first thing is you shouldn't do proof of concept with too many options in mind because that doesn't make sense. So try to get down to maybe two or three in these workshops and then do proof of concepts with them. Because they require time. They require usually at least one week or even two weeks of running time and of course you need preparation time because you need to define your test cases and you cannot define your test cases on Friday afternoon when you start a POC on Monday because you need to share them. It's more or less the same as with your requirements that the earlier your vendor or your community are working with knows your test cases, the better they can prepare and the better the results will be. So define them early in the process, share them. And one personal note from projects that I have done, make sure that your architecture and your infrastructure is set up the way it is required. So it's usually a very good idea to do two or three days before the start of a POC a short call with a supplier and just check, okay, do we have everything that you need so you can start from day one? Because if they come in on Monday and need until Wednesday afternoon to fix infrastructure issues that are not set up the way they are required, that's just a waste of time. It's a waste of money and nobody likes doing this. So the whole team is probably in a pretty bad mood. Yeah, and you can also use those proof of concepts to, yeah, let's say make the environment look like it could look like later on a little bit. So if you're like some customers we had in the past, quite strict about what they have as infrastructure, what they allow you to do on the infrastructure, so they have separate labs for that. And it's a good test for how people work under situations which are not like beautiful, like you can access data center whole time, you can switch cables and stuff. Because this is also in production normally not happening like that. You don't just call someone like, oh, can you just insert another CD to the server or can you switch cables like that? This is not what you would like in a daily base. You would like to focus on the whole software stack and so. And if you keep it like that in a way, you would do it later on. It will also show you how can they work with situations like that, how can they work in an environment like you will provide later on anyway. So that's also a good thing to keep in mind just to keep it as realistic as possible and on your side, not on their side. Because if they just show up with a bunch of machines, we had that with a POC, they just delivered a complete rack, which is nice, but it will not be the rack we are buying anyway. So this is only half-worthful in this case. Yeah, I think we have this point in one of our upcoming slides where we are going from proof of concept to pilot or production, whatever you call it. But of course, it's the same here. So your proof of concept architecture should be as similar to your real production architecture as possible. Maybe not as big as, but similar. Yeah, that's okay. But after your POCs, what you have to do, you have to sit together with your team and just do an evaluation and hopefully come to a final decision. So that should be based on test case coverage. So of course, it's the most important thing that the solution you select covers as many test cases as possible, ideally all of them. But you should also take into consideration the time needed and the amount of work that was needed to get these things done. Maybe two suppliers both fulfill all your test cases. But with one of them, it just worked out of the box. And the other one had to do some really hard work with over hours and all that stuff for two weeks until it was running. So that's the point where it's not only relevant that the test cases are covered. It's just also the feeling that you have. How does the vendor handle issues that pop up during a POC? And there will be issues popping up during a POC. That's pretty normal, the interesting thing is how to handle them. Is that done in a professional and efficient way? Or is it just everyone going into a headless chicken mode? Yeah, we had situations where we found bugs in a POC. And one vendor was more like, yeah, this is just a POC. So we will fix them someday. And the other vendor was like, oh, we have the same bug. Let me call engineering. And two hours later, we got a fix for that, for our POC, which was later put into the product. And so everyone participated from that. So this is also a way how vendors can work like and what's probably important for you. Because if they care for you in the POC phase, which is, I think, a good thing to do, they probably will care about you later on anyway. Yeah, and then we come to the next step. And that's what you've already mentioned before. If you have your decision, move it to production or move it to pilot installation or to whatever you call it. But always keep your POC in mind, because if the architect just differ too much, then what you are going to run is not what you have tested and not what you have just went the whole process with through. So that might be raising other issues that you haven't seen in the POC. Here it is again, the more your POC architecture is similar to the upcoming production, the better your results will be. And if you change it too much, you will also, yeah, it's just like doing another POC in the end. Because you do the POCs to prove stuff is working like you expect it to be. And this is the reason why you usually do POCs like that. It's a proof of concept, so it proves your concept. If you change your concept later on, what did you prove? The old one, not the one you are actually implementing it. And I've seen it a couple of times as people try to change it because they said, it's just a POC, we keep it quite small, just let's say three machines. And three machines is like nothing for an open stack deployment. It's not near in production environment, it's just like you can play around with it for like your own stuff, but it's not what a POC should look like. And that again brings us back to the very beginning where we said, get your requirements done first. If they are really good from the very beginning, then your solution will not change too much and the production will most probably cover what you have set in your requirements. And if your requirements are not good or are too fluffy, then you will, at this point, you will really be in trouble. Yep. Yeah, so if everything went good so far, you should now be able to have a solution that fits your needs. So you can start bringing it to production or extending it to a next level because you say, okay, the POC went very well. Maybe some management decided, oh, the POC was that good. Let's extend it, let's make the environment even bigger. Maybe another data center or something like that. And start working with OpenStack because if you just keep it the way, like, are we doing testing and testing and testing, you won't get any real, let's say, production experience with that. And that's also a thing that comes back to the, let's see what happens. So when you have an OpenStack running and you don't know what to do with it, you probably wasted a lot of time. So again, try to do it in a way where you can use it from day one. So if it's ready, run stuff on it. It may get you into trouble again because there are probably some smaller issues you haven't seen yet. But this is now the point where you can start putting a real workload on it. And real workload is always a little bit different from all the stuff you tested before because there are people involved. They do stuff you never have done before or you wouldn't do at all because you know it better, but they don't. So keep it working as soon as possible. That dashboard is a pretty old one, by the way. I think it's Essex, but it's okay. So that's more or less the end of our overview. I think we have a couple of minutes left. So if you have questions, please use the microphones that make sure that we have everything on the record. Yep. No questions? That's awesome. Oh, do you have people moving? So I was wondering, you gave some suggestions on how to find the right open stack. But I think it's mainly focused on the deployment and installation. In your experience, what should I look out for if my concern is more the operations? Like how much work is it going to be to keep it running, to manage it, to upgrade it? Put it in your requirements. Or put it in your requirements. If you have operational issues, let them show in a workshop or in a proof of concept how to upgrade that stuff, how to run that stuff. It's basically, if you make it part of the requirements and the full solution, then it is part of the whole finding process. And then you can take it into consideration. Good example is upgrading. Upgrading was a long time, very painful on open stack. So it basically didn't work quite well. Some vendors tried to fix that. Some found some own solutions which were more or less OK. But currently we are at a stage where open stack is more or less upgradeable at a certain level. And this is also what a vendor should be able to handle. So if you, for example, in your requirements, stick to some external connectors to some already existing hardware, like load balancers and stuff, you would like to see how they handle and upgrade with all your infrastructure in place. And just tell them to install the latest version in the second stage and an old version at first and then see the progress of upgrading. You can also ask for, let's say, experience with upgrading open stacks for other people. Because this is what I personally like a lot about the summits. You usually will find a lot of people running open stack in some way, and they also get experience. We had a couple of talks in the last years where people running large open stack deployments with just two people. I'm not sure how they do it. But if they tell they can do it, maybe they will share some experience with you. And take that also. You would like to see maybe many of the vendors or suppliers of open stack have testimonies from other customers. And then just ask for it to see how happy they are with their solutions, which is probably not a good thing if it's just from the PR department. But if you reach out to the people, because usually it's not hard to find the real users behind it, you will get some information which could be useful for you or for your project and for the POC phase. Basically, the whole finding process is pretty open. So whatever you define into your requirements can be part of or should be part of the solution that you get on the end. If you want a highly secure solution, bring your security team to the table when you define your requirements. Let them show all that stuff. If you need very easy customization of the desktop, maybe bring some UI designer to the table. If you need integration into billing systems, get your back end people into the team that defines the requirements, and that makes the final decision. So it's very, very open. Whatever you put into it, you get out in the end. And the better your requirements are. It's an excellent example because if you don't have operational stuff in your requirements, then you set up a solution, you build it, you give it to your operations team and they say, oh, what's that? How should we operate it? How can we upgrade it? How can we handle patches, updates, upgrades? So they need to be in the process from the beginning. In the end, it's your requirement that needs to be there from very early on. And if you don't have any operations for that at this stage, it's also good to look for people at this stage. Like maybe some of them can give you recommendations, not only from vendors, but maybe independent ones, just to get at a very early stage enough people on board to bring a project like that to life. More questions? Seems not. Right, so then there's one more slide. Yep. By the way, both of our companies are hiring, so it's all there in the code. Yeah. Thank you very much.