 Shriram, Subramanian, is coming up next. Yes, you can take over. Yeah, there's another question that I've written is that why VMware is getting into open stack? So I actually did a competitive search, why, what is the, because there's a lot of questions why VMware is getting into open stack. Because VMware is so much property right, like Microsoft. Why they're getting into open stack? Everybody loves open stack. I want to welcome Shriram Subramanian, also known as the Cloud Dawn. So look for him on Twitter, he also has a dynamite blog out there. And I'm going to turn it over to you, Shriram. Thanks, Zana. Thank you so much. Welcome everybody. Good afternoon. So I'm going to, I'm going to talk a little bit about what kind of workloads we can run on open stack clouds. Kenneth, we talked a little bit about the design principles, how does your workload decide what architecture do you want and he dealt in great details about if you want to have VMware in open stack or what is VMware more suitable for. I'm going to talk in a different perspective. I'm going to not deal with infrastructure. I'm going to kind of highlight what kind of workloads that people have had success with, have had failure with running these workloads. I tried to give enough details. These details have been obtained from the open stack published user stories. Few things are confidential, few things are NDA. Wherever I'm able to mention the name of the client, I was able to approve the information. But if you need more details, if something I can talk offline, please feel free to ping me. Okay, cool. So this is kind of the adoption curve that we are seeing particularly around how enterprises are adopting open stack, right? This follows with the generic public cloud adoption. Thanks to Swarly here, I adopted this for open stack. When small players are early adopters of increasingly adopting open stack, enterprise was like waiting, okay, it's not even a real thing. I don't have to use this one. It is not going to satisfy me. Suddenly they realize, oh my God, I need to take this on and I need to go with this and you see a rapid adoption these days with. So that's what is happening with open stack world. This is for the infrastructure, though. However, when it comes to workload, right, like, what do I run with the workload? We see a different pattern here. Hey, I know everything. It's all cool. I can take my SAP workload, pre-run open stack. Oh no, that's not going to happen. Okay, maybe I can fix the infrastructure. I can fix this. I can port the application. I'm going to try now. Then I go down. I see some issues. Okay, maybe this application is not really suitable. I can't really port. Maybe I can give one more try. It goes up and down like that. Really, people realize maybe there are a few things that I can do. There are a few things I cannot do. I can run a few applications. I should not run a few applications, right? So we are kind of at a phase where we have reasonable idea about what is good, what is not good, or what is a good application to run on open stack, right? So, again, going back to the perspective here, it is not like you have a new shiny thing called open stack and you have the infrastructure and then try moving all your applications into the open stack cloud. That's not the right way to approach this one, and people have been releasing that that's not the right approach. You kind of need to take the reverse approach, right? You might have a different application. Is the open stack cloud suitable for you? So this will say what kind of applications are, what are some applications that we have had success with, and if you have those applications, then open stack is a good choice for you. If it is not, then maybe you should reconsider. So why does the choice of workload matter, right? As I said, like, if you have an Oracle app or Cobalt app that you have been running for 30 years, can we just put that in? Yeah, sure, it's going to work fine, right? Oh, it's not syncing up. That's okay. So it's kind of trying to fit. I had a nice graphic here, but it was my mistake. It didn't get synced up, so. You know you're editing your slides right before you're talking. I know, I know. So, yeah, so I'll try one more time. Do you have the draw box folder or do you have the draw box? Apologize. I have everything here. Which one? Sorry, guys. Can I switch the screen, please? Okay. So it's kind of trying to fit a square into a round hole. If you have a wrong workload, what's going to happen is you start with an, if you have a wrong infrastructure, I mean, if you have a wrong infrastructure for your workload, for instance, if you have a highly available application that needs to be always on, OpenStrike infrastructure is not going to help you with it. So you're going to end up with unmet SLAs, which is going to show up as a degraded application performance, which is in fact, it's going to result in loss of revenue for you. Finally, you might end up finding your ID, which we don't want. But then comes like, do we have any applications which are more suitable? If so, what are they? Let's try finding out. So before we find out what are more suitable applications, I want to take you through like some use cases that we've been having since early adopters, right? Let's walk through some of the applications here. And one thing that I want to stay away is the famous pit versus kettle analogy here. I'm trying to finish this presentation with other analogy. Let me see if I can do that. Obviously, like a lot of dev tests were the first use cases. People try to play with, can they have their developer environment on OpenStrike Cloud? I'm not even talking about POC here. I'm talking about your developer environment or test environment at OpenStrike Cloud. So that's been like a favorite use case. And people have had success with it. People are still having it. Some of the early adopters, some of the early tries were like around e-commerce applications. PayPal was one of them. Mercado Library was one of them. They had their shopping cart or they had their storage back in on that one. And CERN, you would have seen a fantastic presentation of Tim this morning and you've been following from 2011. A lot of high performance applications, compute intensive applications, people have been trying on OpenStrike Cloud. And then also along this time, time frame, people went wanting to play with just Swift, right? Compute was stable. Nova was stable. And then we had a mess of quantum. And then people were still figuring out about how do we go with quantum or Nova network. But Swift was stable relatively early on. So Swift is a very common use case there. Just uses a back end either for backup or archival or just like storing large objects. So that's kind of the first wave I've seen. I've seen like for the first two or three years of OpenStrike. Then more e-commerce applications came along. People tried having compute with storage, not just the compute but with a little bit of storage that needed, right? That's when like Cisco's, for instance, Cisco's, the WebEx application is a good example. Then more backup and recovery. And then a lot of analytics, right? So when you say analytics, like you need, you have a lot of storage back end, but a lot of compute need for processing the data. So those were like second wave applications. At this point, I'm talking about like 20, 30 and early 20, 30 and 20, 40 time frame. We saw some more production workloads moving into OpenStrike. We have had use cases, demos are on the OpenStrike summits. Some of them POCs, some of them production. But we've seen some increased adoption at that point there. Around this time frame, people also tried, okay, I need to have OpenStrike, but I'm not really sure. I don't care about the workload. I'm just going to try porting. I've had an app running for 30 years. Maybe I can move that. No, you can't do that. You can't do that. So we will see why we can't do that a little bit. Can't a little bit talk before about that. But you know, people had failure in this one. Then people start talking about, okay, net new applications, kind of a unicorn here, and this is a French unicorn. So you see Eiffel Tower on him or her. So what are these applications, right? These are elastic, nearly stateless, are stateless applications. They are consisting of compostable services, and they are designed for failure. So they don't rely on having a highly available infrastructure. They don't expect VMs or compute to be always on. If something goes, they can kind of heal themselves. So do they even exist? Can we even get too close to them? We'll figure out. But what has been realistic is that at least some of the real production workload that you are seeing across different clients, different customers, is that it's not like one set of infrastructure they have. It's a combination of this infrastructure. Part open stack, part something else. Could be bare metal, could be virtualized, could be VMware, could be something else, right? But what is running on open stack is tends to be this net new applications, elastic, scalable, replaceable. Whatever you don't want to run on, which is not always on your COBOL app, CRM app, whatever app that you have been running doing it, it's not even worth trying to port it. Just let it run. Yes, you will have the problem of having two different infrastructure, two different paints, but you always had that. Just that it doesn't make sense. Maybe it doesn't make sense to have multiple environments, but when you compare it with system admins, ease of life, whether it's not losing your productivity or losing your ROI by the choice of wrong application, wrong infrastructure, that doesn't make sense either. So this at least will give you the application that you have been running, their ROI, their lifecycle, everything, their SLAs, they are being maintained, but it's a little bit difficult for you, but at least this is something that is working. So we talked a little bit about what was happening in the open stack user space. Now we will try to highlight what has been really published or successful use case, right? So we talked a little bit about e-commerce before and more than one summit we have seen this talking about. So PayPal, eBay, their internal private cloud is using open stack and they have had success running their shopping cart applications, whatever you see in your PayPal site, the shopping cart, they have had success in running on open stack cloud. I mentioned about Mercado Libre before, they are the largest e-commerce space in Brazil. They've had success storing, using open stack Swift for their objects, as an object store, storing their images of all their products and they've had success running terabytes of data in their back end. I'm not very sure if they use the compute for that, I mean, run any of their applications, compute applications on open stack back end, but this is what I can confirm. And we have had HPC high performance computing applications, a lot of compute, tons and tons of compute node, again and again, like we said, soon has been like a pet or a postage child for open stack. This is like one of the most recent data, right? Like they have more than 1,300 servers running with more than 13,000 cores. Applications for FISA set, all compute intensive applications used by FISA across the world. That's one great example. The other compute intensive application is from Ergon National Lab. They had the compute for bioinformatics applications. This is an ANL lab, but the applications that they're running were bioinformatics and some genomic processing applications, right? Again, this goes back to compute with little or less storage requirement. Then comes the big data analytics, right? This is, many have had success with small start-ups. You're going to say a little bit more about a large auto manufacturer also using this one. Why is it very helpful is you get a, you need map-reduced job, which is elastic by nature, right? So they are a very good fit for, sorry, the open stack compute is a very good fit for such elastic compute requirements. You need a lot of storage to store your data, and Swift is a very good fit for that one. Again, you might need to run some custom applications to analyze the data, or you might do some reporting, which is, which can be, we can be highly on, but they don't have to be like, they are not like as highly on as like SAP, or CRM, or ERP applications. So big open stack infrastructure fits nicely with such an application requirement. Many, many have had success with this one, which is, which follows the paradigm of elastic compute with lots of storage. Then comes the financial applications. If you look at financial applications, they tend to be compute intensive. They may require, they may or may not require a lot of storage, but we have had success with at least one big financial applications company. They use the internal private cloud for hosting their financial applications. They've had applications, like legacy applications, they're not having, they're not running the legacy applications on this private cloud, but whatever they could port over, whatever they could rewrite for open stack cloud, they've had success running that one, but their final setup would look like having a combination of both ported over and legacy applications. The other important reason for financial providers to choose open stack or internal private cloud data sovereignty, their data remains in their data center, whether it's Swift or mostly Swift, so it's gonna stay in the data center, so that gives them a control over where their data is residing and so it makes a very good use case for open stack. Then comes the healthcare. We saw a couple of them under ANL. We have had at least more than one healthcare service provider using open stack for their competency workloads. These workloads tend to be either informatics or genomic workloads. Again, these are compute intensive workloads. They tend to have some storage needs, but they are mostly compute intensive. Then comes the automation. This is not the cool BMW demo that we saw yesterday and today. I'm gonna talk about one of the top 10 auto manufacturer. They have a published use case under the open stack site, so what they did was they wanted to evaluate open stack cloud for their application need. They were having telematics application running. They need to have in-car applications running, all of them feeding data into the Hadoop backend and they use Hadoop for processing that. Again, they have a reporting infrastructure for getting nice reports out of this. They were comparing VMware versus other infrastructure, sorry, open stack versus other infrastructure. Open stack tended to be cost effective and working in case of their POC. You can go to openstack.org slash use cases and find more information about this use case. Of course, BMW. Then comes the category of telecom applications. Telecom providers have been early adopters, one of the early adopters of open stack. They've used more than one, sorry, more than a handful of telecom adopters, telecom service providers have been using open stack, not just in the US region, APAC, European region too. Their applications tend to be running their services and more importantly, they run internal marketplace for their telecom ISPs. If their ISPs have a specific workload of Swift application, a web application or Java application, these workloads tend to run on marketplace and that marketplace runs on open stack cloud. Another use case that, another successful workload was a mobile application development platform. So if you're developing a mobile application, you probably use an SDK like an Android SDK or Windows Phone SDK if you're one of those minority developers, right? So if you want to host that development platform, at least one service provider had success in hosting that application development platform on open stack infrastructure. The other category that we have had success with is media. Again, media needs to store a lot, the use case here is using, storing a large amount of data. Swift falls nicely into that one. Some media, some animation companies have had success with running their animation compute workloads. So animation workloads, which are compute intensive on open stack cloud. Kind of summarize the workloads that we have seen are either compute intensive or compute intensive with manual storage or large storage. So these are all like some of the workloads that people have had success on open stack, running on open stack. So what does it tell you, and also we also some workloads that people didn't have success with, right? So what does it tell you? So kind of reiterating what Kenneth was making earlier and then use your application, let the application decide what infrastructure that you need. Do not go behind a shiny object in the VMware open stack, right? What do you have, make a decision based on the application that you need to run? These are scalable, elastic, replaceable, compostable applications at least close to that one, then choose open stack. If they are highly on or if they need to be, you have a 0.99 SLA or you need to be always on, then you need to choose VMware or bare metal. Having said that, there are some ISVs that are providing solutions to make your applications highly available. You might see them in the marketplace today. So if you want to have those solutions, yes, maybe then you can consider running highly available or highly SLA applications on open stack cloud. Until then, if you do not have those applications, you may want to consider some other options. The other thing that you want to consider is that it's not just the application, it's just not the cost. What is your paradigm? What is your process? How is your IT operating? The big difference is the agility that open stack cloud is going to give you. If you are used to having your provisioning taking one month or two months, now you are going to get it in less than a day. That's a big change. You might have internal politics, you might have internal conflict, you might have internal problems with your IT doing that one, but you need to resolve that. Look at that. It is a tool to make you work more effectively, but it comes with internal conflicts. It changes the paradigm. So be prepared for that one. Work on that so it is not just infrastructure, it is a combination of infrastructure, your people, your processes. Consider them all together. Cost is just one aspect. Free doesn't make it really free. Free doesn't make it really inexpensive. Your total cost, your TCO could still be higher. So don't make that as a primary criteria. So these are the top three best practices that I would suggest if you want to consider open stack cloud. If you have any more questions, please, you can ask me now or you can find me offline. One final thing is that there are good use cases published on the openstack.overd site. Look at the super user cases. You can reach it to the community. The community is very helpful. I'll do a Google search. Any questions? Thank you.