 Welcome, everyone. Thanks for coming. This session is about transforming from traditional IT to the cloud, transforming into a cloud-native organization. And the idea is that there's a lot of conversation about what is cloud-native, but it's sort of hard to put your finger on what does it actually mean, how does one actually get to that ideal or that place within an organization. And the way that we would like to organize this is that we have a panel of people whom I'll introduce very shortly. But the one thing I want to take care of first is I want to know more about what do we have in the audience? Who are the people that are here? And so if you could just do a quick raise of hands. How many are here from a, how should we categorize this? A to be transformed. A to be transformed organization. And how many are here from the standpoint of I'm a developer and I need to transform an application? And how many are coming at it from a business perspective as in we are looking? So it's a good mix. What else am I missing? Who else would be here? Who's here because they're in the wrong room? Could we ask a couple more questions about this? For the people that are looking to transform workloads into cloud, into more cloud native, what are the biggest obstacles that you're encountering right now? What are the class of applications that you're looking to transform? Security. Good example. Another? Is it just security related? I'm sorry? ERPs. So shared database driven applications. Like SAP, SAP. Any of, I'm sorry? Web apps. Web apps. That's much easier. Okay. So the two main things that we'd like to cover and I'm going to first introduce everyone. So all the way over on the left is Ulf. Ulf is the, he's in charge of the operations for the HP public cloud which runs on OpenStack. And so his perspective will be from a very operational perspective and how do you get this thing running and how do you keep one running? In the middle we have Matthias who is a chief cloud technologist who works with the Helium product. He's based in Europe here and spends a lot of time with customers with this very question. And then we have Michael Aday who is our, help me, director of cloud events. So I manage technical partnerships and evangelism for HP Helium. So the two things that we really want to try to get everybody to walk away with is here are the things that people are actually looking at here, what customers and partners are looking at in the transformation. As what I mean by that is these are specific applications and workloads that they're looking at. The second thing that we'd really like everyone to take away is that we have broken it into categories of how one actually migrates the application, whether it be to the cloud or whether it be into a cloud native environment. So the format is interrupt at any time, talk as much as you want. It means that we have to talk less. I have some slides that I have created for this that I'll basically give in certain chunks and then I'm going to ask specific questions to the panel. But again, just if there's any question at any time, please feel free to involve yourself and interrupt as you need. So what does it mean to go cloud native? On a very simple level, becoming cloud native means that you're burning the ships. You can't go back. Cloud native from this perspective means that your data resides in the cloud itself and the services of the application, they also reside in the cloud. It's basically an encompassing place. But what this means is that you have burned the ships. There is no going back. You're not going to get back on the ship and go home. Once you move to this place, this is where you're going to be. So I'm going to turn this to the panel and I'm going to basically ask the question, what does cloud native mean to the customers that you speak with? What does cloud native mean to operate from the public cloud? And from the developer perspective, what does that mean to be in a cloud native environment? This is already in a traditional environment and just trying to deploy it in the cloud. But they recognize that they also need to have the right thought leaders, the right developers, the right organizational structure, the right tools to develop and deploy and test and then monitor what's happening in that public cloud environment whereas the application was in their own infrastructure before. So it's those that make those choices well, those that think about all these different dimensions, those are the ones that I see being successful. From a business point of view, I talk more as a cloud chief technologist with C-levels, CIOs, CFOs who not worry about the technical details, but they perceive cloud native as a threat very often as a challenge because they see this. And also I'm detecting the interfaces because a lot of interfaces have grown over the past five years and those who have grown them have left the company. So sometimes it's a very tough thing to move such a beast into the cloud. However, you could consider to move things under the umbrella of a cloud of a hybrid cloud to propagate all the nice business attributes. As I said, CFOs, they don't know where there's up on the keyboard only because there's a pringing on top of it. They know how to place it. Therefore, they don't care about these things, but they care about the nice advantages of the cloud that they can burst into things, which means that they do not have to pay for any kind of slack space. They can have real-time reporting. They have a build-up feature to look into things. They are no longer the pathologist who knows everything but six weeks too late. These are also advantages where you can think about what does your SAP system do, what are the requirements from a technology point, and then let's find the best, if possible, hybrid or a possible cloud native solution. But it depends significantly on what you have done with that SAP system over the past ten years and I know what that means. I'm a certified sub-consultant by law. So I actually have a slight additional question. How many of you guys are familiar with the argument around pets and cattle? All right. How many of you are looking to move pets into cloud native applications? Make pets into cattle. So the bad news is that it's rare that your pet is ever going to become a cattle. And there's a fundamental reason for this, right? At the design level, at the architecture level of the application, cattle are engineered so that they tolerate failure in the system. And pets, on the other hand, are not. And so pets tolerate different types of failure. Let me put it that way. They tolerate failure through other mechanisms. So I actually believe that as much as Jerry said, the goal for every application is not necessarily to get it to become cloud native. The goal is to implement on top of a cloud platform. And within that platform, there are various levels, various technologies, various strategies that you can use to segment, to contain, to provide high availability and resiliency. And those technologies are implemented differently for, I don't like the term pets and cattle, I like to call them highly managed workloads or lightly managed. Cattle run without regard for failure at core parts of the cloud system because they're architected to have no single point of failure. Pets, on the other hand, frequently do have no single point of failure that have additional specialized capabilities thrown at them to prevent them from going down. So it's not like you're going to have a machine to put your pet in the machine. You punch some numbers and then open the door and out pops cattle. But there are various strategies that you can employ to, for example, contain, to compartmentalize that workload and then to virtualize that workload on top of the cloud resource pool. And there are, in some cases, you can actually segment the workload. So there was a question about web workloads, moving web workloads onto the cloud. Well, web is one of the easiest ones to move because it's a stateless interface. And so if you moved your interface into a cattle metaphor and you had your back end system, the back end of your web service, right, that is implemented as a pet and is managed as a highly managed workload, then you can, through compartmentalization containment, you can actually manage that as a more native cloud workload. But a truly, truly cloud-native workload is happening at architecture. They don't happen by migration. They happen by re-architecting. I think those are common. Well, I was going to say, I was saying that we were looking to move the web apps. That's the first thing. Sure. We would like to move a lot of things above. We would like to move some pets. We would like to start with web apps to see how it works. And that's what a lot of, I mean, in the customer set that I engage with, most customers, when they're looking at OpenStack, they're looking at it as a way to manage web workloads initially because those are the ones that, quite frankly, OpenStack was initially conceived to manage. The issue is that then after they get a good experience with that, many customers have fantastic experiences with that, then the next thing is, well, I want to use this for more stuff. I want to use this for more highly managed workloads. And that's when you have to be strategic about how you're containing different types of functionality that are dependent on specialized hardware or specialized infrastructure or a specialized software component, like for example Oracle or some very highly managed database or if you can migrate other selected portions of it, basically contain the highly managed workload, contain the lightly managed workload in different operating contexts. That's a very good segue into the next compete. We have one more question. Absolutely. One of the biggest issues with OpenStack is that OpenStack is actually end up in the traditional enterprise. And in traditional enterprise, as you said, it's all about architecting and I think we have specifically five more sub-artifications which means you don't have access to the architecture. Brian changed the architecture. Brian, that means I would be interested in actually getting a different definition of the cloud native which goes beyond just the retroblows which are easy to change, because otherwise you never get the benefit of it. You never get the end of the cloud, right? I can't visualize how old they are, because 30% of all of them are cloud. So I mean, you know, the W guy, the kind of old guy talk before about live migration, that's a pet talk, right? Yeah. And they don't say cloud, but they should also love live migration. Exactly. So I would be interested, I mean, you said before you kind of move it back, but obviously the idea is that you have the job ability and portability and you have the issues across policy. Yes, yeah. So I'm going to start around, you said, you know, animation. Yeah. It means private cloud is as good as cloud model as public cloud. Exactly. And I think that term cloud native meaning it's all in the public cloud. Well, so... And I wouldn't talk about being cloud native as in a public cloud. It could be private. There's no question. It's just about, it's a cloud. Not necessarily this, that on-prem, off-prem. That would have very little to do with being cloud native to me because when you look at some of the customers and some of what people are doing, take Netflix, for example, they have pieces of their delivery that are completely cloud native. And it's crazy how cloud native work, but they also have components in their workloads that have nothing to do with the cloud. And they have both private and... They use both private and public clouds, but they use their own private cloud that doesn't even talk to the public cloud, which is generally Amazon in their case. So you made a number of points that I think were worth calling out as additional high-value points, right? First one is that I believe that if you try to make everything into one thing or another thing, you're going to fail, right? Especially in the case of legacy enterprise workloads. They're architected for a reason. They're architected to be a specific design. They were done with best-of-breed technology at the time that they were architected to. Many. There's always exceptions to this. But from my perspective, I always start with a do-no-harm kind of approach, right? And if these workloads are truly critical for a business, and they can be offered in a different delivery model, and offering those in a different delivery model with a different set of technologies adds value to the company, then transforming them into more cloud native may make sense. Otherwise, there are these other strategies that I talked about. Containment, segmentation, virtualization. We're going to talk a little bit more about which workloads and specifically how you can move and why you could not move some of them. But I want to move forward just here. As we know, not all green players, although they know that could be argued, I guess, not all players are necessarily great coaches. In the same way, not all workloads are meant to go to the cloud. So what I'm showing up there is these are the top 10 workloads that we see deployed in the cloud today. And if you look at these 10, the thing that got interesting, that was the most interesting for me from the data, is that the top five of them are all born in the cloud. And the bottom five are enabled or bolted on or integrated into the cloud. And this starts pointing to the question of which workloads do exist, which workloads should be in the cloud. So the question that I am going to pose to the panel on this particular thing is, these are very high-level categories and not even necessarily an application or a workload itself. But in your experience from the different perspectives that you have, what do you see as being the top workloads that should or should not be moved to the cloud and what are the impacts and challenges of those, either from a technical standpoint or an operational standpoint? I think I want to start in here. One of the reasons why transformations fail are because they are technology driven. Because you want to move things that are in the cloud or you want to move it because it fits so nicely with the cloud. Your biggest problem is the business who has to agree with this transformation. And they follow a principle that translates my German background as saying they want to get washed but do not want to get wet. So German phrase is The point is that the business needs a reason to accept any kind of change and it must have an advantage for them. If you come and say, I want to move because there is open stack in the old days it was, from server 2000 to 2003 or from Linux, whatever reason, release, that is not a business reason and then it's from the objective. So when I classify my candidates for transformation, I look at two parameters. The one is what's the technology fit? So you have things that are inheritance, old stuff and you have things that is absolutely new. You have even a cloud version or cloud native version of that application and I look at the business impact. The things that have a heavy business impact you will never ever get an acceptance by the business to transform that first because they will not say that I put the critical items of my business as guinea pig for you to find out how to run that cloudy thing. They are accepting that you use things that are easy to remove, things are easy or if you have a cloud native version these things are moved because they have a low business impact and they have a low technology impact and they also have a low security impact and data privacy impact. Then the business is willing to say yes we can't stand the way of the evolution of technology. That is your playground and then you can attack those things that have a low business impact but hinder the business because they are old. That's quite a volume and with that volume you can make first of all the money to pay for this whole exercise and you have the single chance to build up the experience and also the belief and the trust of the business that you can do because first of all they don't think that you can do because you've shown in the past that you've failed. I don't want to say that you can't do but unfortunately failure remembers spending our brain in six days and therefore once you have achieved that then you can address the business critical items. Therefore the ERP system that is running the main core business of your environment or your enterprise will never show up on the first line and honestly I wouldn't touch it. I would first see that all the process it's come through and this is also a very important thing we have to deal with human beings. We talk about availability. We invest millions and companies are extremely willing to invest millions in hardware resilience. Four high speed data connectivities between four data centers across the universe the geostationary satellite bed-up system they want to spend that money but that covers only a fifth of all the failures. Half of the failures are human error of the programmer but we invest not in that we invest in hardware because it's so easy to understand and we save the money in having the operations done by arm trained offshore personnel and development is done by people who can't read our language. Amazing that we put 80% of the availability into a flaky hands and invest in best tons in something that's just hardware. So this is also something we have to think about. When I hear about security if you look at the last security breaches and the biggest one that is currently in the press Mr. Snowden, which I personally am very happy that he did it but there was no technology breach this guy just took the data and moved it out. So when we look about transformation it's first of all you have to have transformation crew you have to have a good transformation concept and we have to have a business oriented classification not a technology classification. Yeah I think that I think I would take a slightly different take on that and I mean I understand the validity of your argument around addressing business needs first and I think I would double click on that. So there are a variety of business needs that are not satisfied with legacy technology and so the way that you're able to address for example having a global deployment of your application that satisfies multiple different audiences that's hosted out of different countries is through a cloud model. And so the fundamental way to address the business need is to use new technologies and for those types of situations I think that you can make a case and many companies do make this case that implementing a solution on top of those technologies is critical to their business and therefore they invest in the technology. I do think that your point about I have a legacy application and it's so critical to my business that I can't move it is a valid one and that's what I was trying to get at with the do no harm kind of comment. Those technologies will migrate over time to use new technologies. For example SAP is part of OpenStack now I don't know if you need that. They've joined OpenStack and they're looking at how they use Ironic to deploy SAP solutions in cloud but with a cloud resourcing model and cloud management model these types of solutions will naturally gravitate for technology that offers them an advantage. And so I do think that there are fundamental business drivers that can be addressed in a cloud that are not addressed in legacy technology and that's where that critical intersection is where cloud becomes a focus for deployment. That's where they can satisfy me that is not met with existing technology. Let me answer this in a different part of the spectrum. So what I see as the operator of a public cloud is what works and what doesn't work and what I don't see is the upstream decision making process of my customers. I only know about them once they show up in my store but those that are successful and that have reasonably large deployments large means north of 200 VMs north of 5000 VMs those that operated that scale are successful are always the ones that came to me before they made the deployment decision and asked how does your thing work what are your fault domains what services should I be using what single points of failure do you have so that's the option answer. I'll give you an example there's a company that I'm doing quite a lot of work with right now that is they have their own version of a legacy workload and some people might consider it to be pretty advanced but it's a very very high compute very very compute intensive workload that was traditionally deployed on bare metal linux and so I'm not talking about just a few nodes I'm talking about thousands of nodes so they have the solution they use it every day they generate tons of money out of it it is the heart of their business and they're not waiting to try to to try to migrate it they are literally taking a containment approach and they're using mesos along with a container technology to deploy this as a bare metal workload in the context of the cloud obviously there are problems around this right the parallelization of the technology is a problem but having that cloud resource model and having that cloud deployment model using in conjunction with a container technology and using it with a scheduling technology they're using two they're using mesos as a scheduler and they're also using a thing called HD Condor which is a high volume scheduler and so these technologies their approach is very innovative and they'll realize instantly business benefit in doing this but it is a very very legacy cloud work they're tolerating failure at the node level saying well if I have a problem with this I'm going to throw out all the results and it's a very now produced kind of a center to be I'm going to throw everything out in that node and I'm going to reschedule that particularly now I'll just slide that question so I'm interested why you're classifying number 6 without the patients under the line and then maybe the second question is the one that is on top of the DevOps maybe I'm reading this wrong I can see it more as a way to deliver workloads which is not a problem really yet so it's a nuance there's there's microservices focused architectures there's SOA focused architectures there's a legacy 3 tier web application focused architectures and some of these are more suitable to cloud employment than others some of them are the less dependent on highly managed back in infrastructure than others are and so I actually think that web applications should both be on top of the line and below the line language dependencies underlying infrastructure dependencies dependencies on you may have a web focused application that has some really specific networking dependencies you may have web focused applications that have real specific security dependencies and whenever and it kind of depends on when they were architected and what the approach was and what the underlying implementation was but certainly I mean there are web workloads that it's so drop-dead obvious that they're cloud native that they should be on the top of the line at the number one level what that is really speaking to is when you is the test environment what does that test environment look like in a CI CD or in a DevOps piece the reason that web apps when I read through and creating and looking at the data in my research the reason that web apps actually falls down there is because a lot of times what you see and it's true of everything in the bottom of this the ROI of re-architecting a particular legacy application doesn't make sense to take it into a cloud native space as opposed to as what Michael is talking about is sort of let's just contain it let's draw the line around it and basically say okay the investment that we're going to do into this particular web application is very minimal we need to get it to the cloud into a cloud native space when we can however it might be so optimized within a VM in a traditional workload that moving it to the cloud might result in a very small a very insignificant amount of return on that investment in which case leave it it's doing just fine, it's not going down and the comment was made earlier we don't do this because we can we do it because it's the right thing to do and I think that that's what you're seeing at the station there and the ERP is another one that's very it's more of a classic when we talk about very complex systems that are highly optimized in the VM environment let's just leave them they're fine there and at the next opportunity let's talk about what it means to move it to either into that hybrid environment or a cloud native space whatever that might be to the organization Any questions? What is the purpose of existing applications that are largely traditional and avoid the scale up application that I'm working with and try to understand the cloud model and we know that cloud model comes traditionally from the scale up application so now the statement is something has to move right and the moment the discussion right now is going to the applications has to move so the question is how do we move the application but the question is is this actually the right model or is it actually is it politically actually like maybe even in 5 years time there's still a scale up application because inside the enterprise you don't have to be very very close by so this will not change so does it mean that maybe what will happen is that in the future maybe some of these applications will come potentially right there will be more of an assess which means they don't matter to us anyway and the ones which we do still deploy inside our enterprise a large percentage of them will still be scale up which means not the application but the cloud has to move I mean look at the cloud just applying service orientation to the structure right and if you look at the service concept then you can make everything into service if you say for scale up like migration and you know create VM that's right you could you might that's right I think there's a lot of consistency in this concept here right but the point of culture management I mean we all have these issues right the point is I'm an enterprise architect so if there's all this renovation and you know products become go ahead and apply and that's the point that you make so of course you don't make this anything right but the point is what's the target set right I'm not talking about the next few years where I'm also finally understanding what the cloud is and I don't think anyone needs things that in 5 or 10 years or pretty much I believe that in 5 or 10 years I need everything that will be running on cloud some kind of cloud cloud one subject as you said so basically that's the point but you don't need to run anything just as an example that's why I'm kind of interested just looking at the devil's real clothes and the devil's clothes this is all enough but anyway I'm not predicting further than 3 years anything first of all because predictions that point into the future are always very tricky second thing is if you go back 5 years the tablet was not existing in the audience everybody hasn't kept it so what do you mean I'm sorry to interrupt and I don't want to stop the conversation but we have to stop the conversation thanks everyone there's clearly a lot of conversation here I'm sorry we didn't get deeper into this but thank you everyone for attending thank you everybody on the panel and I guess we'll now be in the conversation after well then I'll throw out a plug there's a session tomorrow that I'm posting with Intel and with Oracle around pets versus cattle and how we depolarize that conversation and how we get enterprise workloads moved into the cloud if it interests you please come to that session thank you