 Okay, well, welcome everybody. I know it's just after lunch, so hopefully everybody's had a chance to stand up and stretch. But welcome to our presentation on OpenStack Tenant Perspectives. So what we're going to do today is talk about OpenStack Cloud Tenants. And I know there's a variety of definitions of tenants out there, so here in just a moment I'll give you a little bit more description on sort of our more expansive definition over and above, I'll say just the normal OpenStack definition really of a specific set of applications within the OpenStack Cloud. The reason we wanted to do this presentation today is the three of us, myself, Fred, Fred Karris, Georgia Karstensen, and Abhijit Saneel over the last year have worked with a variety of large enterprise cloud deployments. And the three of us in each of those have been involved very much with the tenant side of things and have gotten an appreciation for some of their needs, their characteristic and also wants from the cloud of choice OpenStack. And then finally, because of a lot of this communication that we had with tenants, we heard some very specific needs and frankly in the rush to move out large-scale deployments in the enterprise, frankly that some of these tenant voices haven't been totally heard. So we're going to spend a little time discussing what some of those needs and wants are and hopefully get you an appreciation for their role in the cloud ecosystem and frankly their driving role as far as we're concerned. So first of all about a tenant, tenants of course, if you just looked at the dictionary are really about a person that's renting property, an apartment or whatever and has a landlord but is inside of a rented domain if you will and they're occupying that. Of course in the cloud environment, tenants are really defined as any group of application all within their secure, bounded space within a virtualized environment. And one of the things that I think hopefully this picture illustrates is the tenants do vote and they have a big say in the direction of the OpenStack cloud implementation. Okay, let's go and take a look at the tenant's role in the ecosystem. There's a big potential to kind of consider the end all of the OpenStack of course as the wonderful software that is released and implemented and it is actually a very, very great achievement that the OpenStack community brings out to the forefront in our each revision of the OpenStack software. However, there's several other very, very important elements, one of course being the data center infrastructure, the hardware that the cloud actually operates on. But the third thing and we're talking about it today is the cloud tenants themselves, the workloads, the applications and frankly the actual operating business that we're talking about and between the three of these ecosystems is actually the production cloud. So without that if there is really no cloud that's actually doing anything. So that's a very, very important concept to take away here. And as I mentioned before, our perspective that we're coming from is each of us were involved in the past year in some very large-scale developments and deployments. And working with the tenants, whether it was migrating them, onboarding them, validating their systems on new OpenStack cloud releases, we became intimately familiar with the business, the technical and the operational needs of these cloud tenants and got that appreciation. And that led us to understand that frankly the cloud really is not successful if the tenants aren't successful. So based on that we decided to go forward and do a bit more structured review of the tenants and the tenants' needs, get their voice through a process that led us through interview cycles and so forth with tenants. Essentially we went and we, after understanding what the tenants' perspectives were and deciding to embark on this project, we went and got a sample. Now it wasn't a huge sample but we're talking about 15 tenants going on cloud systems and went through a series of interviews with these tenants and the really amazing thing is they were very, very open to us. So if you ask them, they will come back and talk. We did a series, as I mentioned, of anonymous interviews and keeping their responses of course anonymous. We then synthesized the data and what we're going to present today is I'll say a tip of the iceberg but half a dozen or so specific, you know, top of the list needs that these tenants are currently experiencing and asking for from their cloud provider. And one last thing I'll mention here before I turn it over to my colleagues is all of these tenants were and are on open stack clouds. Some of them were on clouds going back to Grizzly but some on Ice House as well. So they're moving forward in sort of the current cloud releases and they represented or representation, representative, sorry, of a number of industries, freight and logistics, healthcare, mobile security, online survey systems for webinars and then a variety of enterprise apps and middleware. And once again these tenants were some serving internal enterprise needs but a good number of them were actually helping outside of the cloud or outside of the enterprise type of services direct to end customers. So with that let me turn it over to Georgia. Thank you Fred. Well when we start thinking about perspectives from the tenants we hear all kinds of different words. Some of them come from the IT side from the open stack side but when you look at what the tenants are saying, most of them are just, no, most of them are just talking about things from the business side. They're looking at things like migration, elasticity. They want to be able to run their business. They want scalability. They want to be on demand. They want dynamic. They want governance. They want all the things that really don't have to do with technology. They want all the things that helps them run their business in a better fashion. I'm sure if I ask everyone here there's going to be a thousand other words but we picked one of the top ones. Some of the topics and we had very many topics that we went through and we picked the top six or seven and one of the main ones that we heard that were across all the tenants is operations. Of course when you're looking at operations back in the traditional IT stack, it went all the way down from hardware up to the OS and finally to the application. Now when you're looking at the new ways of working, even though the tenants are responsible for their upper echelon as you see on the slide, that upper echelon which is the application is as complex as some of the whole IT stack in the traditional sense. So they're not really seeing that kind of support. They had their new business. They have a constraint on budget and resources. That's why some of them are moving to the clouds and now they have to support the complexity of the old IT technology in this new fashion. So what's the problem? Someone moved their cheese. Things changed. Their way of working. They needed to have a support model now that actually fits in with what they're doing. They wanted to be able to have someone that one stop shop as they did in traditional sense to be able to have that analysis, that support. And if they don't have that support, well then they need some money to be able to build their own, to be able to self fund and be self-sufficient. So what the asks, they want to be able to have an end-to-end model just as they were used to. They want to be able to fit in that model, to be comfortable, to be able to know exactly what's going on. They want to be able to have that SME. Who do they call? Do they need to call multiple people? They don't want to be siloed. They want to be able to have that ability to get the answers that they need without feeling like it's fragmented. And most importantly, if they can't do that, then they need their operations manuals. They need the training. They need to be able to develop their own self-sufficiency. One of the other topics that we've heard about was the ability to share volumes. They wanted to be able to share volumes to be able to have an active passive relationship. One of the examples that was given is that if they're looking at freight and logistics where they're starting to move information from one area of the world to the other, they would like to be able to have from the option of those clouds wherever they may be to share that database. So the problem is that there is no easy way to share volumes. When it comes to Cinder and Nova, there's an interdependency between those two. Now, I can only speak from the Ericsson perspective. This has been going on for the past few years. And right now, it is starting to come into the way. But really, the best practices have made it, there are no best practices that are making it simple across the core teams and the core projects to get together. And therefore, you really need an advocate, an advocate that's strong to be able to bring over these projects to actually identify the value. So they ask of OpenStack, let's have these interdependencies. Let's start establishing these design teams that are across projects that are beneficial. Because of course, when you're looking at it for the future requirements, we're trying to move the intelligence up higher into the application. When we're looking at future algorithms to be able to define instead of attaching the volume to have the volume self-attached. And now we're looking at having to be able to handshake between the core teams. When right now from the Ericsson side, there is a design summit going on where we're going to bring once again the ability to have the Cinder requirements and the Nova requirements together so that we can actually move this forward. Help. There's a lot of it out there. A lot. But even for myself, when I was looking, when we started hearing the fact of having volumes attached, when I went on to the OpenStack documentation, it was not very clear if it was supported or not. Was it fully supported? Was it not supported? I reached out to a couple of colleagues. We weren't really sure. And then finally, I have to hunt it down through Ericsson. So there is not only the abundance of information, but it's not really synthesized in a way that the tenants, whom are not always technical, who are looking to run a business and have this revenue stream, may know how to use it. So what's the problem? Even though the OpenStack community is one of the better communities when it comes to open source for documentation, there is a lack when it comes to the tenants. They want to be able to have user stories. They want to be able to see how can I best use this functionality that's out there to support my business, to support my revenue stream. And whenever they're looking at having specific tenant side information, because of course they're using it, they don't have the budget. They don't have the budget. They don't have the resources to be able to start building that out. So they ask, things are moving at such a fast pace. Maybe we can have better documentation. Maybe that documentation has to come from the tier one providers that are moving even quicker, that have a larger gamut of items that they're using. So therefore, the user stories can start getting established. The use cases start getting used. Maybe the best features, or what is deemed as the best features, can start coming to the forefront to enable the tenants to be able to use it. And of course, the reason why is that instead of focusing always on the documentation from the technology, from the development up, maybe we should start looking at it somewhere along the middle line so that the tenants can also use it to their benefit. And at that, I pass it to Abhijit. Thank you. There you go. Hi, everyone. My name is Abhijit. I'll talk about the next case that we heard from the tenants, and throughout our survey process, when we talked to tenants more than 15 or so that friend mentioned, we heard one resounding fact that everybody wanted the elasticity and agility that cloud provided for them. And they didn't want to be constrained physically within the cloud or externally to the cloud. And most of these tenants that we talked to, some of them really large, running a lot of VMs, they were specifically focused on the scalability that cloud provided for them. For example, they would have a few VMs running through weekdays, and then due to traffic, they would have hundreds of VMs suddenly spawn over weekends. So in order for them to take advantage of this, they wanted the cloud system, the platforms that they were running on, also to give them that kind of agility. And a curious thing that they mentioned here was that the VMs did not show consistent performance, even while being spawned on the same environment. And this could be because of the varying hardware platforms across even just one data center. And the current OpenStack features were not usually available to them. And this is, as we'll see later, usually because they are dependent on private proprietary releases of OpenStack. Now, many of these tenants, when we talk about going to cloud, it's really different from just adopting Linux over Windows, over a period of time in a company due to policy or so. Because a tenant, no matter how much they would want to be on a cloud instantly, there would always be elements that are non-cloud, that are external network connections, probably, that go outside of the cloud. So they might be operating, perhaps, in like an 80-20 model, maybe, a 90-10 model. And this leads to the fact that cloudification, so to speak, of tenants is constantly evolving, and it has to evolve. And usually, when cloud is put into place at enterprises, this is something everybody is aware of, but it's not really taken into consideration for operations purposes. And when we say that our applications are now on the cloud, we just assume that everything is on the cloud, and everything would work on the same model. And tenants said that we wanted to actually have a good model for taking care of ourselves, even during a migration process, or an upgrade process. They didn't want to have any downtime. Now, we saw from the presentation yesterday that Fred gave about migration that migration usually causes a lot of hurt. Because any activity like that causes tenants to be down for a while, their production environments are affected, things like that. And all of these concerns are not really of tenants, because as far as the tenants, the users of the cloud is concerned, they just want to be on the cloud and turning their production environments. And they don't want to be dragged into the operations, loops, and development cycles of the cloud that happens in the background. Then we heard from tenants about the need for them to have a front door to the cloud. Now, when a new tenant needs to come into the cloud, they would often have to just send an email to somebody who maintains an Excel sheet about which tenants are where and what site and what are their requirements. Then people get into a call together to assess the demands and things like that. And this is usually the structure that happens in any enterprise that begins to put their applications onto the cloud, adopt cloud platforms across their operations, et cetera. But given the fact that this has to grow organically, still when an enterprise grows, sometimes this fact that tenants need to manage themselves via a unified platform usually gets left behind. And tenants are usually dragged into all the IT bureaucracy that happens in the background. Like for example, when in the same example of a migration, we heard from tenants that they migrated to a new site, but then their networks are not working anymore. And then they had to raise a ticket for it and wait for somebody to actually take a responsibility on that ticket. And then it's the end of the day and it's a weekend and then their production environments are down and there is nobody responsible for these things. So like we saw earlier, how Georgia mentioned, operations also need to evolve with the fact with cloud tenancy. And what this actually enables us is to put into place a workflow. Now even after a migration or an upgrade process, what happens is tenants usually come back with problems like, oh, I named my VMs wrong and therefore I have to now go back to somebody else with an Excel sheet. So this unified workflow and policy control enabling tenants to manage themselves as for more VMs or less. And self manage themselves, tell the organization who are the owners of the tenants and so forth is really important. And this is important in two ways. Not just for the tenants, but also for the organization because we actually try to reach out to tenants who cease to exist in an organization two years ago. They had development virtual machines running at some point and then eventually they moved on but nobody in the organization knew because they weren't really paying for it and therefore it just happened to be redundant. So this would not just affect the tenants but would highly impact the efficiency of maintaining a cloud as well. Now following from that, we have to consider the fact that inevitably tenants would be on a multi-cloud scenario. Tenants could have development VMs at one site and production VMs eventually maturing at other sites. And this fact is often not really viewed seriously because the abstraction is like how Fred tried to, earlier tried to define a tenant. Many tenants could be part of a bigger project and this could be part of something else in some other organization. And no matter what the abstraction level of how things are grouped like users could form a tenant, tenants could form a project. Now this could lead to one big project actually managing several tenants across the nation or even the world. And how are they going to manage all this? Now even when we look at implementing OpenStack it's not really feasible for somebody to have administrative rights to all the OpenStack instances across various sites and then go into horizons of each of these places to manage themselves. So what the tenants told us is that they really needed a single pane glass kind of control mechanism where everything else happens in the background and they are shielded from all the integrities of looking at exactly how all the multiple sites are integrated together in the background. And their architects wanted to look at their workflows and ensure their fails of mechanisms of working nicely. And also when tenants move from one place to the other this could be because of a migration activity or an upgrade process or one site just was down and they wanted to maintain their production. So if they moved they said they had to now reconfigure their entire networking end to end at the other site. And this again is leading to the earlier problem we talked about in operations. You know it's a ticket that was raised and waiting for somebody to take responsibility for. So the ask is basically to have a unified mechanism for any abstraction level to look at multiple sites across the world all of the technical details that they would need to have their production or development VMs up and continue with their operations despite what happens back in the cloud. Now this is very evident when we use a public cloud like Amazon or something like that. But in an enterprise private cloud the way it has to be implemented surely should be different from how it is in a public cloud. But at least the operations easiness should be similar. So with this I hand it back to Fred. So thank you. So that's rather interesting isn't it? I mean basically there's two viewpoints. There's a bottoms up type viewpoint and then there's a top down. And so what we're hearing from the tenants is really a top down how do I manage how do I control my application? Now I wanna spend just a minute talking a little bit about the future and where are tenant sort of requirements, needs, asks may be coming in the future and why. So here's an interesting factoid. If you look at just the five year span from last year 2015 to 2020 based on the most recently available research we're looking at at least a 10 fold increase in the size certainly based on on dollar spend of the enterprise cloud. So and then if you actually even extrapolated another five years out to 2026 it's a 36% year on your cumulative annual growth rate. So the point is the enterprises are now at that threshold and I think you've heard this throughout the conference of really marching forward with a significant advancement in the size of the enterprise clouds. What's driving this? It's not small and medium business type support and applications, tenants that are going these are big industrialized systems that are coming into the enterprise private cloud. They're very, very, very sophisticated systems and our projection is this is going to lead to even significantly more requests, wants, requirements from the tenant community. I've listed here just a few that we've heard hints of in working with the tenants. I think we already mentioned here about the database volume sharing, but there's for instance the logistics company that we interviewed literally would have the need to connect to their home base volumes and databases even when the cloud was connected somewhere offshore with the VMs and that cloud back to the sort of home database and sort of the continental US cloud. We see also a rising need for what we call threshold and predictive scalability. So I mean it's interesting some of the applications that we talked with the tenants literally could have just one or two or three users on them and then literally within a few minutes scale up to 20,000 users on their systems. This was actually the case with this webinar survey tenant that we spoke with and frankly what they would like to have is some sort of a native open stack service that would allow them to use tool sets to start understanding, hey, when I start seeing my traffic go to these type of levels, give me information so I can start spawning my additional VMs and things like that. And then finally, at least in the enterprise clouds that we've been dealing with, there still is not a perfected mechanism for in place upgrades of versions without having downtime. The tenant's demand is as many nines as possible of availability and it is a big operational disruption when they have to basically shut down one of their availability sites and move to another one. So be prepared, we're looking in the very near future for a lot more tenant requirements, a lot more features that they can consume and I suspect this is going to even further accelerate as they start realizing the full kind of functionality and features of the cloud, which they actually like very much. So our call to action here is let's take care of these open stack tenants. They're not just technical applications, yes they are that, but these are operating businesses and at the end of the day, very important, they are the ones ultimately that pay the bills. And the three of us advocate strongly that the voice of the tenant needs to become a real mantra within the open stack community and have a mechanism to be heard and then acted upon by the community. I was really gratified this morning to hear the focus of the keynote address was so much around various sort of applications sort of oriented discussions. We need to keep that up. And then finally I'll leave you with this that we've come to realize that unless the tenants are successful, the cloud is not successful and it's really going to be the key to expansion of the open stack clouds as we see this future expansion, I think really driven in the enterprise. So with that I thank you all for being an attentive audience and the three of us, this is a passion of ours, would welcome you to come and contact us. We're actually looking to do a continued dialogue with the tenants that we're heavily involved with and more to drive these new sort of tenant requirements into the open stack sort of community and be acted upon. And with that I'd like to ask if there's any questions, please feel free to ask and use the microphone if you can. Thank you. Hi everybody. So you mentioned having a mechanism by which the tenants can have a dialogue with the cloud operators. So this is in particular like one of our biggest challenges, right? So we've got a cloud, I'm very proud of it. I happen to think computers are cool. So it's fun for me to interact with it but it's finding that bridge between the tenants who are always gonna have more faster, better, whiz bang features from AWS and so on to convince even the more business minded of them that this is a good idea financially and so on. It's hard for me to, do you have any recommendations for convincing these folks who again, pay the bills, they're doing that cool stuff. The cloud doesn't do anything without the software running in it. So do you have any recommendations? What is that bridge? Cause that's kind of my present challenge. So here's, this is all I can suggest on that bridge is I think structured, some sort of structured dialogue or mechanism. Now we undertook sort of this project simply because we had been doing it in the conduct of each of our jobs. Like I said, it was in terms of really working with tenants on either onboarding or migration type activities. And I was absolutely amazed in the several enterprises. There's several different enterprise clouds we were dealing with. These guys were so thrilled, these are real people to actually have somebody call them up and talk to them. And it wasn't like I had to pull information out. It was, it came as like opening the floodgates. So I would say what I think it would be a good mechanism whether it's within any individual enterprise as you're embarking on your cloud projects or in the community itself. But let's just start with any enterprise is make sure that you've got a conduit, a forum, maybe a stakeholder community in your tenants that is actively solicited and part of the sort of the dialogue as you roll your cloud out. It really comes down to, I'll say structured and a very structured kind of dialogue type of methodology. And I'm gonna be talking with you, I'm pretty sure. Okay, and also you have to be careful with the feedback mechanism. The structure needs to be there because as we heard from some of the tenants, the ones that manage the tenants, how do we stop the flood of information, right? If you're already doing 100 things and then you're getting another 200 more, how do you filter to realize which ones are the best across the tenant group? So those are one of the things. You have to be careful. And I will say one last thing is, I mean it's a typical thing right in software development or technical endeavors to have a users group. So that might be another sort of way once again to bring the information in. And just to add to that, some of the traditional practices of addressing, like for example, ticketing, et cetera, might not always be the best ways of working for a cloud platform is something that we heard directly from tenants that we talked to. As an example, like I mentioned about, if something is not working suddenly after an upgrade or a migration and then raising a ticket for it, waiting for somebody to take responsibility, et cetera, might not be the best way forward for an evolving cloud platform. So this was a feedback that we heard. And so that also adds to that, thank you. Cool, thank, sorry, go ahead. I'm so glad that I attended this because I'm the PTL for the OpenStack UX project and one of the things that we're driving across project is a common set of roles that we can agree on or personas. And I'd love to sit down and talk to you about the tenants, because we do have a tenant persona, but we need to understand a little bit better and I'd really like to get your feedback on that. One of the things that we are doing in fact with our personas is we're creating a matrix. So it depends, the persona is highly, it's a contextual thing, the persona changes based on the type of company. Right. So I'll talk to you guys a little bit afterwards. Please come up when we finish here, we'd love to meet you and talk a bit more. I think the other question that I had too is I think you touched on it. How much of a problem is quotas for you with your various tenant projects? Managing quota. Let me, so that's a rather, so in the enterprise private cloud I was involved with, I'll be honest with you, it was a big problem because I don't think the enterprise that I'm specifically been dealing with has come up with a good method of doing that. I think they tend to oversubscribe and I don't think they have a good charge back for that oversubscription because if they did, I don't think the tenants would ask for so much. Is what I found and so I actually think despite the fact that ultimately a virtual environment is supposed to ultimately make the utilization better, I actually think that they're way oversubscribed but that was my experience. General Abhijit, you've been on the same project. Yes, I would agree with the same thing. Thank you. Okay, yeah, what these guys are going on. Yeah, kind of on a similar note and I apologize, I walked in a little late so if you've already touched on this but just in terms of managing quotas and tenants across multiple sites, like you touched on the challenges for that, how are you guys addressing those difficulties and is there some kind of solution that you guys have chosen to kind of automate some of those manual procedures and approving tenant quotas and going about that? So I think the first step is to reduce the number of middlemen in this. Now when we are talking about multiple sites, like especially from the perspective of OpenStack, we are also talking about who has the rights to view what, et cetera. There would be somebody who is an admin at various sites and so forth. So consolidating all of that is the first step and then every enterprise is wired differently and when we are talking about a multi-site tenancy in enterprise private clouds across various organizations, the business policies and how the technology came to be adopted first and evolved impacts the way that the tenants are located and how they are managed and we saw this at the project that we three together work in and the fact is when somebody has to look at a consolidated view of, for example, a big project who has multiple tenants across multiple sites, when they have to do some adjustments or when they have to go through an activity of just assessing the evolution of where they would go take how they would manage and direct their traffic or so. Then it's a matter of calling together a lot of people who has information into a lot of different things and then talking all together. So a unified system which is able to view all of these together would eventually be the ultimate answer for something like this because there are too many middlemen now and too many Excel sheets with too many people. And I'll add one other thing to that. So the three of us are from Ericsson so we're in the telecom space and in the telecom space there's always the concept of sort of almost a system-wide view, the communication system bridge and so forth but as we get to these complex cloud systems that now have multiple networked clouds together so I might have a very complex tenant that's got an active setup in two geographically dispersed clouds and a passive, the geo-redundant setup in a third cloud to actually be able to see that as a system is something I'm not aware that's out there and frankly I think it needs to be developed and what I think is gonna have to be developed is some sort of a platform, maybe it'll be through the OpenStack community, maybe from somebody else but I hope it's through the OpenStack community and then it's gonna have to be custom configured to whatever the rules, policies and so forth of the particular enterprise. It'll be a configuration play every time a specific enterprise implements a complex multi-site cloud network system. Yes. Yeah, I was a little surprised that security group administration wasn't mentioned. From our users we get a lot, I mean they're not used to administering firewall rules. The horizon GUI is very elementary and so we get a lot of any, any, right? That's what customers do, is there been a lot of feedback on that from the customer base as well? Yeah, why don't you? Yes there was, they were looking at it from different levels, they were saying about how because of the security groups that they weren't getting enough isolation to be able to do the things that they needed in the cloud how it was carrying over to other areas so they did mention it but as we were pressed for time we kind of picked the top six but it was really one of their top concerns after these ones. Yeah and let me, because I'm glad you bought that up so we could mention and build on what Georgia just said. So there was two of the tenants that we talked to specifically said look, we know that the cloud security we take confidence in the fact that you sort of secured the cloud itself but we've got this complex system and frankly we used to just be an application owner and everything else was taken care of and now some sort of our internal firewalls, security policies and rules and how you actually engineer that into their increasingly complex tenant environments they expressed a serious need that they don't feel they have the training and expertise to actually do it so I don't know if it's a training and documentation issue it's partly that and probably partly a bit of a lack of potential tools that we could provide the tenants as well so I don't know if that fits your experience but that was our message. Well yeah I mean we get that, I mean like we just see a lot of tenants just open up everything right which is bad and so like some of the stuff we're thinking about is templates for applications to say okay for this application create security group templates you just apply them and we provide them as part of the infrastructure. That's a great point because actually that is almost exactly what one tenant that we interviewed specifically said if you just tell me how to do it and then test it I'll do it but we don't even know how to do it. Yeah. Yep we get a lot of it as well. Great, thanks. Thank you. Are there any? One more question. Quick follow up, I'm just curious like how large are the organizations that you've been working with? I'm just curious if. Tier one. These are all tier one type enterprises so what we would call us Fortune 500. So very large. Yeah right. Any others? Well thank you again for attending and let's heed and hear the voice of the tenant and going forward and open stack. Thank you very much for attending.