 confidence we won't lose everybody to sleep. So I'm going to start. My name's Steve Wally. I'm a distinguished technology at Hewlett Packard. As of next week I'll be a distinguished technology at Hewlett Packard Enterprise. And I've been in the industry for about 35 years now. I've had the privilege of being both on the vendor side as well as on the customer side. I've worked in large IT organizations for a large part of my career. And my co-presenter. I'm Leong. I work for Intel as a cloud architect. So I've been working in the industry for about 15 years with a mixed background in software application developments, infrastructure development as well as operations. And before Intel I work for Liberty Mutual IT. So it's one of the insurance companies in the US, a very big company in the US. And I also work for a couple of companies including Motorola and also let the engineering team of a few start up company. And back in 2013 I obtained my PhD in multi-cloud orchestrations. So we're talking about turning pets into cattle today. And I wanted to make sure though we do a quick base set on what we're not going to be talking about. So this is not a talk about how you're going to deploy those applications in any kind of continuous integration, continuous deployment situation or how to automate those things. This is not a talk about puppet or shelf or salt or ansible. Those are all good things. Those are all excellent practices. But those are also cultural practices between engineers and operations folks. And what we want to do is this is a talk about application architecture. And I'm sure everybody's familiar with the idea of pets and cattle. Pets are things with names. These are your traditional three tier architected applications. They are highly managed. They're long running. I mean we used to measure things in uptime, right? That was the important thing that we all cared about. A lot of people like to talk about this as your legacy. And that's one way to think about it. But it's actually these are your business critical applications. And then you contrast that with the cattle world. These are suddenly things that you can scale out. They're highly resilient. If you lose a machine or you lose a piece of the application, there's enough redundancy built in that things just keep on working. Now a lot of people are already doing the exploration into how they would build cloud native applications and how this is going to work forward. But that's the way you think about the applications that you are building forward. How you're addressing your backlog. And what Leon and I want to talk about is how do you actually think about moving some of your pets and these highly managed workloads, these business critical applications into a new cloud enabled world on OpenStack. Now one of the things that you'll come across before we get too far, we will be publishing the slides as well as the fact that the OpenStack organization will be publishing all of the slides. We'll also turn around and we'll each publish those slides through our own slide share and such. So you'll have access to any URLs that are mentioned here. The URL at the bottom there though is an exceptionally good document at allowing you how to think about some of these issues. And one of the things it presents is this idea of cloud application maturity levels. The problem in this space though is it's always presented to people as if these are absolutes. You know you're at level zero or you're at level two. And the thing that you need to think about when you start trying to understand how you're going to move your application workloads and how you're going to kind of forklift your business critical applications into an OpenStack cloud world is you can actually be at multiple different levels of maturity in each application. So we're all probably, you know, if you're a Fortune 500 company you are already a VMware customer. You know we all understand virtualization and kind of level zero. Most of us have been living there for a long time. When you start looking at level two, sorry level one and level two, that's some of the work that Leong's going to demonstrate in a minute. It's how do you think about taking that three-tier application and begin to tear it apart in interesting ways without having to refactor it all. When you finally start stepping up from kind of that level two to level three, we start talking about, you know, that's where you get into Netflix country. You know, everybody aspires to be Netflix. So it's we're going to take this kind of to the next step and Leong's going to be working with WordPress because that's a three-tier application that everybody understands and works as a really good model to tease out the questions about how you have to think about re-architecting things. So, okay, I believe most of us has come to be into the process of migration from physical environment into virtualization environment. So when we move our application from physical to virtualization environment, our applications architecture actually doesn't change too much. So traditionally, we used to have web clusters and application clusters and the DB clusters, but when we move into the virtualization environment, it turns to moving the same model into the virtualization world. So what we gain from this model, from P to V, is basically we maximize the resource utilizations on the machine level and we probably can do some of the on-demand configuration by launch, you can launch your application in an on-demand way. So that's where we go from physical to virtualization P to V. But when we come into virtualization to cloud, we start wondering, I mean, can we do the same thing in what we have done in the P to V model? Can we do using the same approach without changing or without re-architecting our application and move them into the cloud? That's what we call paths to cattle. So what are the things that we need to be done? I mean, do we have to do re-architectures or can we just do port the whole VM over? So one thing I want to, before we dive deep dive into more of the architecture design, I want to show you this diagram. And this is one of the diagram that we borrowed from the, recently we published a booklet called OpenStack from business perspective. So the documents, I mean, is a collaboration work between HPE and other companies in the foundation, in the community. And you can actually download the PDF file from OpenStack.org slash enterprise. It's freely downloadable, so you can access the documents. And basically what I'm trying to tell you here is that we need to understand, first, we need to understand the differences between virtualization and cloud. As you can see from the diagram here, on the right-hand side, okay, on your left-hand side, okay, in the virtualization world, our applications tend to rely on the infrastructure to achieve higher resiliency. So relies on the hardware solutions, the application, everything on hardware layers. And our application tends to be a skilled up-moder. When we come into the cloud-based environment, or cloud-native environment, our application is designed in a distributed fashion. So the application itself, a cloud-native application, is responsible for their own resiliency mechanism. And it's kind of like independent, independent from the underlying infrastructure. If you're building a cloud-native applications, your application can run on private cloud or public cloud without too much changes. And the cloud-native application is more API-driven and is scaling horizontally. So there's one of the key differences in between virtualization and cloud. And another thing I want to show you is about the architecture design between Conventional App and Cloud Aware App. So when we design our application in the past, the application tends to be monolithic, centralized state, and very highly coupled. And most of the requires tends to be synchronous. But when we come into a cloud-building cloud-aware application, we are thinking about building, using distributed architectures, or using microservices. And requires tends to be asynchronous. And the app itself is designed for failure. It can handle all kind of failure situations. And basically, we're using common or share nothing architectures. And there's this concept about eventually consistent. So these are the design considerations when coming to the differences between Conventional Application and Cloud Aware Applications. So just now Steve also mentioned about these documents. So in these documents, it's published by Open Data Centers Alliance with a few companies, including Intel, HP, World Disney, and other companies I can't remember the name. So basically, in this document, talk about our evolution of application architecture from physical to cloud, sorry, physical to virtualization to cloud, and also identify some of the key principles when we want to build cloud applications, cloud-native applications. So some of the key principles are highlighted here. So a cloud native application has to be resilient to failure, and generally it is composable. So you can build your application in different components. And it has to be elastically scalable. It can be scaled out and scaled in. And it needs to be location independent. So you are independent from the underlying infrastructure. Because if you don't build your cloud native application in this way, it will hinder your ability to transition from either private cloud to the public cloud in a hybrid bursting model. So if you're interested to build cloud native application, I would recommend you to read this document. It's very, very useful documents. You also identify some of the strategy that you can apply when moving into the cloud. So once you understand the differences between virtualization and cloud, so what kind of strategy can we use to migrate our application to cloud? So when you look at that application, I think very important is you need to understand your architecture. You yourself have as architect or developers, you have to understand how your application is going to work. You need to understand where is your data. So most of the time, what I would recommend, or most people what they're doing today, and I would recommend is keep your database and what you have today. Don't migrate your database if you're not familiar with cloud today, especially for those company new to the cloud. And you can start looking at other components such as web tier or media ware or messaging. Start moving the web tier or media ware tier into the cloud, and it's more like moving bits by bits. Don't do everything in one shot, okay? Because database data is a key, right? You can't lose the data. So once you get yourself familiar with how the cloud is going to operate in your environments, then you start planning for the migration for the database. So most of the time people are moving the web tier and the app tier to the cloud when they first start their journey into the cloud, into the open stack. So another thing I want to bring out is the shift of focus. So we want to design a high reliable system. So reliability generally is being measured in terms of meantime between failure, meantime to repair, and availability. So traditionally when we build a high reliable system, we tend to buy very expensive hardware to increase the meantime between failure. I showed this slide before in the Vancouver summit. So we use a lot of hardware-based redundancy solutions to achieve high availability. But when coming into the cloud, we kind of like think on a different strategy. We can focus more on the meantime to repair, to reduce, I mean, maximize our automations in the cloud to reduce the meantime to repair, use a lot of different open stack features or cloud features to achieve software-based redundancy to achieve high availability. So it's kind of like shifting of focus. So we are moving away from mid-increasing meantime between failure to reducing the MTTR. So it's a shift of focus between on how can we design a high reliability systems. So demo, okay. Next one I'm going to show is a quick demo. So in this demo, as Steve mentioned earlier, I'm going to use WordPress as an example. I believe most people understand what is WordPress. And today a lot of company corporate, they also use WordPress for their corporate website. So generally, I mean WordPress, well, you can argue that is basically a two tier applications, right? So basically the PHP everything and database, you can split the database. But so in this demo, what I'm going to show you is I'm moving the web tier into the OpenStack Cloud by keeping the DB intact in your existing environment. So, okay, so what you see on this screen here is a video basically, okay. So this is the database service. So this is where the WordPress database is being hosted. So that's the internal IP addresses for the database. So I'm just in this screen basically just showing you that there's a database XZ. And of course, don't use root. So this database will be used by the web server, which I'll show you later. So there's a show databases. And you can see there's a WordPress database here. And the next screen that you see is the VM in the OpenStack Cloud that actually will connect to this particular database. So conventionally, when you're designed, when you when you deploy a WordPress application in your existing virtualization environment, you do the same thing. So WordPress, you have to configure your WordPress config file, WP-config.php. You basically configure the parameters to point your WordPress application to the database clusters, right. So I can see here, that's the DB name, username and very secure password demo123. And connecting the database host that you see just now. Okay. So this is what we do in the virtualization environment, right. Nothing change, nothing special. So we can do the same thing in the OpenStack Cloud. And what you see on the user front end, so this is our private IP address for the web servers. And what you see from the user front end basically is nothing different. So basically the website is a very simple website. So there's two web servers hosted in the cloud and there's no differences. So we can do the same thing when you want to migrate your WordPress website into the OpenStack Cloud, keep in the web, migrate the web into the OpenStack Cloud but keep your database intact in your existing environment. So this is one approach that we can use. But using this approach, we basically follow all the P2V approach. We don't re-architect anything, right. But in this approach, we doesn't gain the best benefit of cloud. Okay. So the next demo that I want to show you is a different way of doing things. What I mean is you can view your application as a different component. So an example is, for example, if you're building an e-commerce website, you probably have a building component, your login component, you have a product catalog. So you probably can start moving, consider moving your product catalog only into the cloud. Of course, this kind of model, this kind of approach will require some of re-architecture or redesign of the application to split your product catalog and move that into the cloud. And again, I'm going to use the WordPress as examples. So in this WordPress examples, what I'm trying to show you is, when you hosted a corporate website, right, so usually you have a content owner, they'll update the contents, right. And the website visitors basically just read the contents and they visit the website and they read the contents and they don't do any updates to the website. So you basically split that, split them into two different view. One is for the website viewer and one is for your content owner. So you can still keep your WordPress content owner those WordPress servers on your local virtualizing environment and for the visitor content, the public content, we can, in the WordPress, you can actually use some plug-in to convert those into the static content and in this demo I'm going to publish those content into the OpenStack object storage, Swift content, the Swift object storage. So the demo basically is very, very quick demo. Basically, I have wrote a script and read the same WordPress content management system just now and for every static file, convert them into the static file, static image and push them all the way down to the OpenStack cloud. So what I did here behind the scene basically is reading all the WordPress file, static files and using the OpenStack API to push the content into the Rackspace public cloud. So what you see here basically is reading the file and pushing them into the public cloud using to the API, everything automated. So this is one approach that we can do especially for new adopters when moving into the cloud. As you can see here, this is the previous web service, nothing special. So when I push the content into the cloud, this is on the Rackspace object storage. So everything looks the same. So the Rackspace you can use object storage to host all the static content but for the content update, you can still keep in your WordPress service as a single visualization and do the update and then push the static content into the OpenStack cloud environments. So this is one approach that we can use. So another advantage of using this approach is like using a push model, especially coming to a hybrid model. If you deploy your web server for example, if you deploy a web server in the public cloud and if you want to keep your database in private cloud, more often you are not in a security concern because you don't want to expose your database to the public cloud, right? So one way we can do is using this kind of approach by pushing the content into the cloud rather than pulling from the internet. So a lot of times when you design your application, your security is always the first concern, right? So this is one approach that we can use. So when you want to move your application to the cloud, there's always different strategies that you can consider. So don't just restrict yourself to the old way of doing things. So think about a new way and thinking of the box. So think about the new ways of doing things. There's a different multiple approach that we can use. So these are two very simple examples that we can use. I hope you understand what I'm trying to say. So with that, I'll pass the time to Steve talk about some of the 12-factor apps. Right. So what we've been looking at so far are things that you could do with an application architecture that don't require you to reach into the internals and start tearing it apart and refactoring the app and things like that. Now, there's been a lot of popular discussion for the last couple of years, a company called Huroku that does a lot of excellent work lifting applications into the cloud and providing cloud services for them, publish this idea of the 12-factor app. Now, I'm not going to walk you through all the 12 factors right now or anything. Depending how old you are as a Unix person, a lot of this you look at and you go, well, yes. But putting it all together, it actually helped a lot of people think about how these things can be addressed. Continuing with the idea of WordPress, there was a company that went out and took WordPress and actually turned it into a 12-factor app, almost. If you go and look for a 12-factor WordPress, they have a wonderful, wonderful long blog post that takes you through each of the factors and all of the decisions they had to make. And when you look through it, some things were absolutely obvious and absolutely easy. And those were often the things that we should all be doing with our applications anyway. The idea that everything is under version control, well, you can kind of check the box on that one, it was very easy to make sure that worked. When you start looking at things like the dependencies, the architecture of the application of WordPress itself already allows you to encapsulate all of that in the composer.json file. But when you start stepping into some of the other things, that's where they started running into problems. They had to think their way very carefully through how they handled configuration, because the 12-factor app, and the 12-factor apps are kind of that step towards doing microservices. Well, how do you get things into the environment? They had to be very careful. Some of that stuff belonged in configuration rightly, and some of it, you needed to get bootstrapped into the environment properly. They ended up replacing Apache with nginx, because when you start getting into how do you deal with things like sessions, if you're going to go into a stateless world, how do you handle things at the concurrency level of port binding, they just needed to literally rip and replace the HTTP daemon itself. So when you start thinking about that next step up for how do I get my traditional three-tier app into an open-stack cloud- enabled world, that's when decisions will start to possibly get a little more expensive. You will have to think about some of the factors. But many of these things are things that you can actually, are just good practices. And these are things that you'll handle culturally rather than technologically. It's almost think of it as a different bucket of money in IT, because you're going to have to train people differently. So that was part of the learning that they went through. I would encourage you to go and read the blog post, because there's lots of depth and detail there that, again, will hopefully provoke interesting questions for you as you look at your own three-tier applications. That's not the only way to think about it, though. Again, Leong's demo showed you how to bring a lot of your app into an open-stack enabled world. And it was dealing with a lot of things that really were infrastructure as a service types of things. Things that, you know, are the core services of open-stack. But there's other things that open-stack as it evolves has been providing. So you could start to look at things like, can you use Trove as a way to handle your database? Now, my last experience a few years ago in on the IT side of the world. I worked for a company that was, we had a lot of static content. We could do things with Swift. That would have been an absolutely excellent way to do things. But our database world had evolved to become so central to the way multiple different applications were feeding off the same collection of tables in the same database. And again, over history, it had been, well, normalized. And then parts of it had been denormalized. And that evolution of what had happened to the database was going to make that evolution to a cloud-based architecture in open-stack extraordinarily difficult. That was a set of choices that one company had made. Your choices may have been different, but I would encourage you to think carefully when you start brushing up against the database. But you may have an opportunity that a class of your applications and your application portfolio, you can lift very easily using Trove. Looking at things like if your application is conducive to being refactored a little bit and you can start to move yourself into that kind of 12-factor app space and things become a little more stateless, you can start thinking about how you might do containers for that application. Now, again, it doesn't require you to do everything absolutely. You may not need to move the entire application into a containerized world using Docker. You may be able to tear it apart and refactor pieces of it and start to move it. So you've got lots of choices here. I think what Leong and I want to do is make sure you're thinking, you're not approaching your application portfolio with this mindset that I'm going to have to forklift entire applications one at a time and all of the work that that might be. There's lots of advantage you can get moving into a cloud world and all the cost savings you're going to get that way and the kind of time to deployment and the automation that you'll be able to apply just by doing these things one at a time. I'm going to hand this back to you again. No, I just tried to wrap up what I was trying to say. So I believe that every technology must create value to business. When today if you want to migrate your applications to the cloud, think about what kind of value or what kind of pain point you're trying to solve from the business perspective. You don't just want to migrate out of no reason. So think about why you want to do that, what is a goal and what kind of value that you want to create to the business. So always the same thing I mentioned in the previous summary, every technology must create value to the business. If the technology doesn't create, doesn't add value to the business, it's useless. So with that I think, oh sorry. I would like to point out that was not me. I am normally the one that is death on hardware in any kind of a presentation. Go to the, actually let's go to the call to action first and then we'll handle questions. Okay. So Leong and I are part of an open-stack working group. The enterprise working group has been wrestling with issues for better part of a year and a half to two years. There's a number of sub groups in it. One of them is the cattle and pets subgroup. And we meet regularly. That's the mailing list for it and the weekly logistics. I would encourage you to join us. Can I have a quick show of hands, how many people actually work in enterprise IT here? Excellent. That is absolutely excellent. What we've suffered from for this past year is too many vendors. Yes, I am one and Leong was one of our few. Used to be. Used to be one of our few true customers from IT. And we're trying to wrestle with questions like what are the problems preventing enterprises from moving to open-stack? And it's a collection of vendor product manager engineers going, well, this is what I think they'd have to do. We would really encourage you to please come and participate with us. We would like to use this as an opportunity to deeply understand the things that we can be carrying back through the product working group and building blueprints that cross projects and such so that we can genuinely begin to evolve open-stack into ways that will help people in the enterprise space be able to more easily migrate their applications. Yeah, one of the main reasons for this working group basically you want to understand what is a barrier on moving your applications or conventional applications, the patch model into the cloud. If you have any problems and issues, and come join us in the working group and we will try to help work as a community to derive a solution that can help you to migrate moving into the cloud. So this is our email address. If you guys want to contact us, you can... I am always happy to take email. And before we go to Q&A and if you're joining the Intel Passport program, do ask, go for Chris. It's over here. You can get a stamp. And with that, we're going to go Q&A. Are there any questions? Please. Do you want to use a mic? Do we have a mic? Yeah, we have a mic. Thank you for that. It's pretty interesting. But what's the point if you don't actually move the database? Sorry? What's actually the benefits if you don't move the database? I mean moving the... moving and I understand that you can sometimes transfer your data. But if we're not dealing with data in OpenStack and we're not dealing with transactional data, are we actually really addressing the enterprise? That's a very interesting question because most of the people come to me and say that can we keep the database first without migrating because database is the key, right? Database is very critical to applications, especially for new adopters to the cloud when you're not so familiar with the cloud operation model, the cloud native way. If you start moving a database without understanding how it works, it's a very high risk to use, right? Of course, I'll be happy to help you to move your database to the cloud-based environment. As I say, we plan for the migration. We don't migrate everything at one shot. It's very high risk. From virtualization to cloud, to a lot of enterprise IT is a big challenge. So don't do everything at one shot because that's a high risk. It's basically a risk assessment. Of course, definitely, you can do database migration. I have no objection and I'm happy to help you on that. But for most companies, they are very concerned of losing the data. So that's why a lot of companies approach even eBay or PayPal. They're also keeping the database layer as the same environment and push the web here and app here to the cloud first. And slowly, once you get familiar, we start moving the database into the cloud, either use Trove or using the same building of multiple VM SQL clusters in the cloud VM and learn how to adapt the database. The question speaks exactly to the big problem because so certainly, you can get the scale of benefit at your web tier and even the application tier and that is a huge benefit and a huge step forward depending on the nature of the database. And I believe me, like I said, for my most recent experience on the IT side, I realized how fraught that can be depending on the architecture that has evolved over time and how much diligence and rigor may or may not have been applied. But in some of the simpler situations, you could even use OpenStack today to simply get high availability for your database. So you're scaling it differently now, but you're replicating the database because you can replicate the VMs while you're doing more of a scale out kind of thing on the application tier and the web tier. So again, it's that teasing the layers apart and applying different strategies to each of the layers that is extraordinarily database dependent. I appreciate that, that I'm not suggesting that that was easy or would work for everybody's data environment. If you're really interested in moving database to the cloud, I would encourage you to look into the Trove, the Trove service in OpenStack. That is the database as a service. A lot of companies still doing POC and try to understand how it works before they move on. Sorry. Exactly. Yes, database support would be critical. The difference between if you've got a strongly web-based application and it was all MySQL-based, you're probably in fairly good shape. If you were extraordinarily dependent on a complex Oracle or SQL server database, you're going to need to make different choices. Today, the open source Trove, they only support a few open source database. If you're working on other database such as Microsoft SQL or Oracle kind of things, then you probably have to approach the vendor-specific solutions for Trove. So that depends on what kind of things you use. I certainly know that from HP's perspective, we've been working with Tesora and they are out in the marketplace here. And they've done lots and lots of plug-in work for different databases. Again, I appreciate that we're kind of hand-waving here because of the complexity of the database, but that will probably be where you discover most of the evil things that have evolved in your data environment over the last decade. And that's part of the challenge here. You will have some vendors that you may well have encountered some of my own colleagues that will tell you, well, you just have to rewrite everything into a cloud-native way. And I realize that so many of the applications we're talking about are business-critical applications that you may have done the minimal port from a traditional Unix environment to a Linux environment 12 years ago kind of thing that these are applications that have been long-running, long-established. The data environments that move with them are equally complex. And complex not just because the application was complex, but you've made different choices over time. So depending on the diligence all the way through the history of that application can really affect your ability to port it. Other questions? If not, I'd like to thank you all very much for your time today and your attention. Thank you.