 But now I can't see the massive crowd in front of me. Welcome, everybody, and thank you very much for coming here on the last session of a very busy week for you. I realize that we're all at standing between you and some quiet time in the sunshine. We're here to discuss enterprise strategies for cloud-aware applications. Ultimately, that's what everything here is all about, is how we move all of our business and all of our workloads into the cloud. My name's Steve Walle. I work in the strategy team in the helium engineering team. And I'd like to each of my panelists to take a moment to introduce themselves. We'll start with Kathy. OK, hi, everyone. I'm Kathy Spence. I'm a principal engineer at Intel. I've been doing a lot of work over the past five years around cloud computing. I'm a huge proponent of platform as a service and cloud-aware application design. Hello, my name is Gerd Prussmann. I'm chief architect at Deutsche Telekom, products and innovation. And I'm since three years with Deutsche Telekom. And I developed with a development team and operations team, the first open-stack production platform. Hi, I'm Leong. I'm principal engineer for Liberty Mutual Insurance Group. My primary role in the company, basically, is to try to educate or evangelize the developers on building cloud-aware applications. So I want to start the panel off with a question or two. And get people going. But please, if you have questions, please step up to the microphone. That's the way we'll get everybody recorded properly because we are alive and being recorded. So first off, I'd like to ask Kathy, can you give us kind of a quick overview of what are the differences between kind of traditional workloads and cloud-aware workloads? What does moving into the cloud mean? OK, could you please advance the slide? That would involve me to know what I'm doing. OK, great. I know this is a little bit of an eye-tart. It may not be easy to see, especially from the back. But what you see on the left is the before picture. This is the traditional application. And what you see on the right is the cloud-aware application. So now what you'll notice is that there's a lot more going on in the cloud picture. So on the left, you see a typical three-tier client server type application with all of its layers. It is bounded by a static perimeter. And it has, typically, a synchronous connection to one client device operating system browser. What you see on the right, the cloud-aware application has been decomposed. So what you see is that it's not all about one client device. It's a whole spectrum of devices, including things you can see in the picture, like cars and trains and things like that. So our notion of client endpoints is changing. And it's an asynchronous connection to the cloud at the back end, which is running in a very dynamic perimeter with components that scale out. And then you'll see there's orchestration and composition engine in there as well. So there's a whole lot more going on in the cloud. And then to the very right, you see that everything is instrumented, because you've got a lot more moving parts. And we want more applications to be written in that cloud-aware model. So as we think about moving forward into this new cloud-aware world, Leon, do you want to take us through some of the benefits of what it is to be in the cloud and to have a cloud-aware app? The benefits? The benefits in some of the architecture that you build. Well, maybe you want to go on to the next slide. Well, as you can see from this slide, actually, there's quite a different cloud-aware characteristics here that you can see. So one of the benefits of moving into a cloud-aware application is it has resilience to failure. So if you're required to build a cloud-aware application, it's designed for failure. So it's easier to maintain in a way. And it's also resilient to latency. So there are some characteristics that you're resilient to latency as well. And it's secure in a way, and location-independent. So especially when you're building cloud-aware applications, so you're trying to make it in a way that it is location-independent. So it doesn't matter where the application is being run on. So you can build applications and running on different kind of platforms or even different providers. So this are some cloud-aware characteristics as well. And if you are not building a cloud-aware application, potentially you are actually preventing your application to move into a hybrid model. So if you try to build a cloud-aware application, and it gives you a lot of benefits and help you to move into the hybrid architectures, so resource efficiencies as well so it can minimize a lot of calls. And a lot of automation can be done through cloud-aware applications as well. Super. So when we were talking earlier, Deutsche Telekom took a slightly different approach to this massive portfolio of applications that you have. And how would you start to think about moving things into the cloud? Do you want to discuss that a little bit, please? Yes, we are offering software as a service model currently, for example. And we are moving traditional applications often to the cloud. What we are seeing is that there are no cattle applications. There are only traditional applications available currently. So we have to consult the ISVs, for example, that offer these applications for us to the end customers and offer them services on the cloud so that they are able to consume the cloud, also with their old-style applications. So on the one hand, we are offering cloud resources like virtual machines and CPUs and all this stuff, and automatic installation or automatic configuration. But on the other hand, we have to support and help the ISV to change his application to consume the cloud more efficiently. So for example, we try to convince him to rewrite parts of his application. For example, if the application uses functions to store data on the local file system, we try to convince him to consume an object storage and to write this part of the application to be able to being failure-resistently against the failure of the storage, for example. We offer a set of services in this area, for example, reference tenants, life tenants, and development tenants, so that the customer, the ISV, has the chance to develop his application on our cloud and test it before it goes to production. Super. Thank you. So this is kind of a new style of computing. Everybody's trying to get their head around what do we do? And Garrett made reference to cattle. Everybody heard the expression pets and cattle before? Show of hands if anybody does not know what that means? Good. So what are some of the challenges that you have when you try and take a traditional application and start moving it into the cloud and turning it into a cloud-aware application? Do you want to start, Kathy? OK, so challenges. So in the enterprise, specifically in the enterprise, and we're here to really talk about enterprise computing and whether it's your private cloud or whether it's your public cloud, the reality is that the enterprise has a lot of legacy applications. So what I've heard is some organizations, what they focus their cloud on is all the new applications, all of the greenfield-type applications. And then you don't have as high a barrier. I think that there are some cases where you might be porting some applications over. And I think that you want to do that when you're at a major design decision at an inflection point in your app where it's a major type of upgrade. Maybe it makes more sense to do some re-architecting of the app at that point. One of the things that we're doing in Intel IT is we have a program called Five Star Apps, where we want all of our applications to run across all of those devices that we saw on the previous slide. So what it says here, cloud backend, multi-platform front-end, we want the apps to run over phones and tablets, as well as PCs, laptops and desktops. So that particular program is generating a whole set of development where there's new development going on to write a bunch of HTML5 front ends for legacy applications that sit in the back end and then connecting those through services. And that is a great target also to put that in the cloud. And personally, I feel like apps are going to run across multiple environments anyhow. I may have one app, and it's got components that are maybe they're legacy components. Maybe they're sitting on physical infrastructure in the back end. Maybe there's a component that's running on infrastructure as a service. Another part's running on platform as a service. And maybe it's consuming a SaaS app all at the same time. We made the same experiences, for example, with legacy services consumed by these applications. We had to replace databases, or we had in one case the situation to onboard an application that used local storage. And local storage in the cloud is not very common use case. And we implemented something in an open stack to deliver this local storage. And I'm happy to hear that this customer now is also happy to use the storage back end from a SEF cluster, for example. So he learned something during this process. And I'm really happy about this. The main problem is that the applications are developed for a limited number of CPUs or servers. So the focus is to deliver the application via a predefined set of servers and CPU resources. And in the cloud, you have this horizontal scaling with an unlimited number of CPU. And you use it when you need it. And that's a very different approach. So for example, if you think about Google and MapReduce or Hadoop, then we have the possibility to compute over a huge data set and deliver the data in subseconds to the user interface. This is never possible with a limited number of servers, for example, in an on-premise installation. And to develop applications for this style of cloud is very different from the traditional approach of software creation. And this must be reflected if you bring this application on the cloud. So you have to deliver either legacy services on the one hand. And on the other hand, the application should be changed in some aspects to make it more resilient against failures. Yeah, I mean, one of the key challenges I can see for enterprise developers is the design mentality. So traditionally, I mean, most of the enterprise developers used to be developing applications targeting for the traditional infrastructure. So things like, I mean, sometimes the developers will put in some sort of static information in the application. Some developers also try to use a static IP pointing to a particular database service. And that's the kind of thing that is not going to happen in the cloud-aware applications. Because if you're going to in the cloud-aware applications, you're not going to put all this kind of static information in. It's not going to scale. So design mentality is quite a big challenge for us to educate our developers and to understand the differences between traditional applications and cloud-aware applications. And sometimes, I mean, we talk about design for failure. And most of the existing developers doesn't build that failure-resistant features into their applications. Because they think that, I mean, they expect the server or the virtualization machines of VM there should be there. But when coming to the cloud-aware application, that is totally a different model. Because in the cloud-aware infrastructure, the cloud-based infrastructure, the VM became disposable. So any time that the VM can go up and down, it can spin off 10 VM right now and then 100 VM later and then scale down to 10 VM again. And this kind of design mentality has to be changed. Because if you don't design that way in the cloud-aware way methods, you're not going to scale your application or infrastructure in a massive scaling mechanism. One of the other challenges from an application standpoint, application feature standpoint, is identity and access management, which has been a big challenge. Because individual apps have used different types of approaches, whether it's a Kerberos or Windows integrated authentication. And developers are used to doing that in the traditional apps. But the problem is if you do that, you're tied to that server. And you can't move that workload around. Or if we wanted to burst that to a public cloud, you couldn't do it. So really introducing OAuth and web services for iDAM is another, that's been another big challenge for us in tying that back to enterprise identity. We were actually lucky enough. I haven't been with HP very long, but I came out of an IT shop. I was running the platform engineering group just as we were starting to experiment with some of these things. And that was, we went through that inflection point. And one of the first things we were lucky enough to do was to be able to break out identity. We were a medium-sized business. It was 1,000 employees, 100 in IT. We were running 1,000 production servers and another 500 backing that. But we were lucky we didn't have that exact problem. Right, right. And I just want to be clear that I'm not talking about Keystone where your developers need to authenticate so that they can use the platform and create infrastructure. I'm talking about the apps that land there need to have a model so that their users can authenticate. That's really what I'm talking about. And that's a good bridge to this is a brand new world. Enterprises tend to have large, well-developed practices and processes for doing things. So how do you handle the cultural change when you start looking at the changes that need to happen in operations and the infrastructure team, the changes that have to happen for developers? Kathy, do you want to start? OK, I don't want to hog things, though. You can pass it off. No, I'm going to answer. I know, OK. So we've been engaging with our developers actively and we're trying to educate them around the characteristics of cloud-aware applications. I think personally that it's not revolutionary. I think it's evolutionary. I think cloud gives you reasons for wanting to really follow all of the good practices. The core of it is small components designed to scale out. And so now this gives you a reason for wanting to do that, because now you can be massively scalable. And so we're creating design patterns for developers so that they can have examples. And the other thing that we've been doing is we've been hosting some internal hackathons with our developers. So basically, we don't care what application it is, but they can bring in an application that they've been working on, or they can create something from scratch, or they can start with one of our example apps. And then as they demonstrate the cloud-aware characteristics, we give them points for that. And we give a prize at the end of the day. And it's a one-day enterprise-oriented hackathons for our IT developers. Deutsche Telecom is not really a software producer, so we are delivering products to our customers. But at least for the internal departments we are working with, we see a development into this direction. So we try to help the other departments that want to onboard applications on our platform. And we try to help them to introduce development models for cloud applications, for example. We onboarded one application that is currently running as a private end customer application on a traditional data center installation. And it was changed from the same development team that developed this application to another business application. And this business application is now hosted on our platform. And it's quite different. So the adoption of cloud development technologies and models already started. That's very interesting for us. I think education, education, education. You always have to educate your developers on moving into cloud. One of the things that we did in the company is we try to educate, to let the developers know what is a cloud-based infrastructure, how does it look like, and what is the differences between cloud-based infrastructures and why you want to build a cloud-aware application. One of the things is, for example, a lot of developers tend to use stateful information. And when you move into cloud, you have to move into stateless. But why do they have to move into that kind of model? So we have to show them that this is a cloud-based infrastructure. If you don't do stateless information, it prevents the infrastructure to scale because you have to tie the sessions to each VMs, which make it difficult for you to scale. So education is very important. So we do a lot of so-called tech talk or trying to educate the developers, show them what is OpenStack and even what is AWS, how are we going to run a VM, how does it look like. And the VM can be disposable. And the IP address is not going to be static. It can be dynamic. It can be changed over time. So education, education, education. Actually, I'd like to build on that a little again from the experience I had prior to HP. We had an enormous amount of technology debt. I was laughing. I heard a talk last week where they were saying, apparently as developers, we've all been doing it inefficiently for decades now. So there was this idea that, OK, so how do we get people? There was a lot of fear in this medium-sized company. How do we get them engaged in this? And so we literally carved out a small team of folks to pick a particular example application that worked very well along with the rest of the main application suite. And we built that. We had to almost do it as a hackathon. It was very quietly done pieces at a time over a couple of months. But then we turned around and used it as a demonstration in front of the executive team. And they were excited enough because we were able to show them simple numbers. And it wasn't wildly deep metrics, but simple numbers of what we'd been able to accomplish in a reasonably short amount of time that was much more flexible when you're talking about that expansion out to things that run on templates and such. They had a very traditional, fixed internet explorer web interface. And now all of a sudden, we were showing them something that ran on tablets and their phone. And once they were excited, the pull through culturally across the rest of the operations and infrastructure team, as well as the development team, it was incredible. All of a sudden, it was like everybody wanted to start to learn these new things and to be a part of the excitement. And that was quite the thing. And when we did that small exercise, we made sure that it was very much a cross-team effort. There was developers involved, but there were also absolutely the infrastructure guys were involved on the back end. So it was very much a collaborative effort. Well, one of the things for the developers, a lot of things are changing for them right now. So development teams are moving to agile methodologies. They're trying to do CI, CD in their environment. There's all of this guidance around responsive application design. And now we're asking them to look at the cloud piece of it as well. So there's a lot of change for them. So I think the real key, along with education, is providing enough tools for, I like to call it, make it easy for them to do the right thing and use the carrot approach as opposed to the stick approach. One thing to add on is one thing that we're trying to do is to create some sort of reference architectures to show the developers. You put out some example applications. So that will help the developers to understand, OK, this is an architecture. How does this look like? And then we provide some sample application. If you want to do this kind of architecture, this is a sample app. You can use it as a sample. And from that sample, maybe it can be a very easy application. My first hello world cloud applications. So that helps the developers to learn and to build a cloud application, cloud aware applications. Now I know we've had a few people come and go since then. If does the audience have any questions? And if so, please step up to the microphone while we're going through that. So one of the things we haven't really talked about, but you hear a lot about in the hallways, the idea of hybrid clouds versus public clouds versus private. Do each of you want to take a couple of minutes to talk about some of the experiences that you've had working, either choosing not to or choosing to work with any of these particular models? If you're building application for hybrid model, especially in a public cloud, I think you have to be concerned about bandwidth and the data transfer between your application to get that cost money. So if you build an application within your own premises, you don't have to spend too much of concern about the data transfer fee within your own premises. It doesn't cost money. But when you come into the public cloud model, if you develop a media streaming applications, the bandwidth is going to cost you a lot. So you have to think about how to minimize the bandwidth transfer between your application if you're building cloud aware application in a public cloud. And also, one of the things that we did before is a media transcoating application. If you look at, for example, if you're using AWS, AWS, they charge you the VM in terms of by hours. If you use a VM, for example, if you run a transcoating task and the transcoating task is finished within 10 minutes, you still have remaining 15 minutes. And if you try to build an application in such a way that you can make use of the remaining 15 minutes, and that will help you to save money because you don't have to spin off additional VM to complete your transcoating task. Because AWS modally, they charge you by hour. If you use 10 minutes and 15 minutes or one hour, the cost is going to be the same. So we have somebody out of the microphone, may I step out to the mics? Okay. Please. My question is regarding ephemeral VMs. So I think everybody seems to get that keep state out of the VMs. But in OpenStack, outside of Swift, we really don't have a good means of HA to keep state. If you guys could elaborate that on that. For us, we're keeping our databases like Oracle and Hadoop outside of that environment. And those are the problem childs, right? Okay, so for Intel IT, so another reason for Cloud Aware apps, right? And we're encouraging folks to deploy multiple instances of their app. So start up two instances of your app, put it behind a local load balancer. You kind of get that for free if you use the platform as a service, right? And then it becomes more about the data. So we encourage that for state type information, you could use a service. We offer, with our platform as a service, we offer like Redis, which is very good for some basic state information. Otherwise, just go ahead and use a database for that. Our database as a service is separate from our cloud environment, where we offer, it's a full HA database, and then we have a self-service interface to that where they can request like, give me my SQL database. We provide back the connection string and the credentials, and then they use that connection string. We do the care and feeding of the database behind the scenes, the backups, the high availability, we take care of all of that. And they just have to worry about their tables and their data. And that's working really well for us right now, and it's a very popular service. We have the state information currently on the databases on the platform, and that is a problem, and we discussed this already. We might shift our databases to the data center from the platform, but until today we haven't done this. I think the key thing is, there are still applications that require state information, but the key thing is you're moving away the way you maintain the state information from the front end layer or the web layers to other components such as using Redis or even to the database. So that will help you to scale your web layers. So I'm not saying that you cannot do state applications, but just you're moving the place where you hold the state information to other components. So to follow up, we're doing the same thing with the philosophy of keeping the databases on the outside and databases as a service outside of OpenStack. The challenge is that using Heat for doing a declarative model for what that infrastructure looks like, we've had to extend Heat to describe the database as a service and provide that as an extension. It just seems like that should be part of OpenStack, even if it is dealing with something outside of OpenStack. So I just want to be clear. Our database as a service is actually deployed on top of OpenStack, but it's separated and it's built in an HA type of a model. So I just wanted to be clear about that. I don't know, does anyone want to comment on the second part of that, about it being built in? So one of the things that's been on our list is to look at Trove, and we haven't really gotten around to that yet. So I'm not familiar enough with that to really comment as to whether or not that provides a lot more capability, but there's also another component in OpenStack, that is also HA databases that's being developed right now too, isn't there? Talking about the HA database, again, if I have to really meet all these requirements, my database also has to be distributed, like our web app. So is that getting a lot of momentum in the industry or not? I mean, for me, as far as I know, we are not getting that much traction at the database layer to have a really distributed database and keep the data in syncing across the globe if you really want to go as a cloud model. That is my first question, is there any best practices that OpenStack Foundation actually providing that, okay, here are the frameworks that you can go with the distributed database for production applications so that they can really adapt to that model? My second is all these talks are within the platform and infrastructure layer only. If that is so compelling, the higher executives who are actually supporting this business applications should also be there and it has to come from them, right? So we are all the ones who are going and marketing that here is the benefit there, company drivers, but I don't see that much of traction happening in that side also. Any thoughts on that? Okay, so I'll answer the first question about distributed databases. And so there's kind of like two models for your application for HA, right? So generally you talk about active passive, right? Where I've got two instances of my application and one of them is the active one and then we'll swap over to the passive one if there's an outage, right? And then there are active, active applications where both instances are active at the same time and this way the users that are local to that app use the local instance of it and then they both interact behind the scenes with local data which then synchronizes behind the scenes, right? And actually we've also experimented a little bit with active, active, active applications where I might have an application in multiple zones maybe even one external to Intel, right? Where it's kind of a similar model and the big challenge with that is all about the data, right? How you do that synchronization and there's a couple of different methodologies to do that synchronization and one of the things, especially if it's more of a global type of application, there's an opportunity to do something that's called eventual consistency, right? Where basically you take that table, right? That everyone is updating and you split those rows across instances of the database and then you synchronize them eventually over time so they're not, so you have some of the local data cached, I'm not really talking about memcached here I'm talking about you have that local data and they get the responsiveness they need but then over time you deal with that. There are other strategies as well for how you deal with that and I think also there are certain databases that lend themselves to that type of a model too so depending on what kind of a database you're looking at and some of the new SQL databases like Cassandra for example, looking at those as well so it really depends on what your app is trying to do. So, other comments? For our offering it's much easier because the applications are not very huge, no very big applications so we offer MySQL, Postgres and MongoDB for example and it depends on the application if it runs in active active mode or active passive mode. So it's not about global distribution of data for example, in general we have all the servers available, highly available in active active mode and that's limited to this platform only. I think there are also different approach to tackle this kind of problem because if you look your applications as different component so we can start moving your web front end the application end to the cloud model whereby keeping your database at the existing models and this is one approach and we are also trying to I mean at the moment we are trying to experiment we have some running some experiment by moving the MySQL instances to the cloud environment so for example we actually use a normal instance hosting the MySQL servers whereby we're keeping the data using all the sender volumes and as Katie mentioned just now we run into active passive mode if let's say the master SQL servers went down and these can be filled over to the slave one whereby you spin off an additional instance to actually retake the sender volume to get back the data. And I just have one more comment too on the data too that I think is really interesting is that as the data gets bigger you have to kind of rethink your strategy too for your application design and has anyone heard of the notion of data affinity? You move the processing to where the data is you don't move the data to where the processing is. So you kind of have to rethink that as well. So, okay, oh what was your second question? Your second question was from the adoption perspective. So it is majority of the times it is infrastructure as a service and platform as a service talking about this open stack, migrating to open stack. So actually we are the ones who are actually going and pushing it upwards. Then they're coming from the higher ups who are actually managing the business or managing those applications. So you see what I'm trying to say, right? So the momentum has to come from them that okay they realize the value of the cloud so I want to port my application to the cloud and those things. I still didn't see that kind of adoption. So the adoption. Yeah, so from an adoption standpoint, right? And I already mentioned, let's make it easy for them to do the right thing because they want to move as quickly as possible to land their apps. And the big value of the cloud for the developers is that they are not hampered. In a traditional application, right? I would have to, not only have to write my app, but I'd have to go buy a server, I'd have to figure out where to land it, I'd have to go through the whole governance process, all of that stuff, that's pretty slow. That can take like six months, right? But then when you use the cloud, you're gonna be able to move a lot faster. And the faster that they can move, that's really the value that they're getting. So, and as I said before, I'm a proponent of the platform as a service because it's not just about the provisioning, right? So if you are a developer at Intel and you want to use infrastructure as a service, a typical application for us is deployed into three virtual machines with a security group. And by de facto, you have now become a server administrator at Intel. And so that means that we hold you to the same standard that we hold all of our server administrators. And you are responsible for the security of those servers and you're responsible for the patching of those servers and you're responsible for if there's an audit of those servers, right? Well, a lot of developers don't really wanna do that, right? But if you use the platform as a service and you connect to the platform and you push your app, the IT hosting team takes care of the servers. There's no server provisioning, right? There is, you know, and I can scale really fast, right? So, you know, so understanding that as well. I think, you know, maybe it won't matter in the future. If you can do it super fast, you know, if you've templatized your application and you can do it super fast and you can rebuild and tear down as opposed to patch, then maybe things will change a little bit more too. But I think we're just, you know, I don't care whether you call it infrastructure or platform as a service. I think OpenStack has components that are more platform as a service than infrastructure as a service. But, you know, maybe that's more of a religious discussion. Sure, and some of what we were looking at is, so infrastructure as a service that can often get spun up as it's a cost saving thing in IT. But when you start looking at platform as a service, that's actually how fast can you deliver apps for business value. So it's both sides of the budget get involved. And it's interesting to play the discussions that way. But the reality is delivery just starts happening faster, especially when the appropriate, everybody keeps talking about DevOps. And when I was on the IT side, it was like, well, that's nice, but we actually have a group of people in infrastructure and operations that really do know their jobs and it's giving them the tools to deliver faster and then giving the application developers the tools to deliver faster. And the automation of that was giving us that speed without necessarily having to tear the entire culture apart and convince them that, well, now everybody's DevOps. So please. I just want to share my experience with helping some, you know, quite a few CIOs and CTOs with their cloud transition is that the hardest part is changing people and processes. Technology is easy. To answer your question here, gentlemen who asked the question earlier, like why it's not coming from the business side of things? Why are the higher ups and the C level execs are not saying that we need to move to cloud? So their goal is operations, right? Their goal is not creation. So we have to separate these two entities, creation versus operations, right? So for operations, they are looking for business continuity. They want less disruption. They don't want their mission critical applications broken when they're sort of trying to move, when techies say we want to move those applications to cloud. So people processes are more important and it will just take time. And from what I have seen in the market is that most of the applications are moving from the periphery of the enterprise. I want to hear your comments on that. So there's a systems of innovation if you will and the systems of records are not moving because of the monolithic amount of data behind those systems. So if you can shed some light on sort of different tiers of systems and which systems sort of make sense to either migrate or rewrite or just do some sort of layer on top of existing applications, that would be great. I mean, I hope I understand the question previously. So we're talking about the values, right? I mean, the values of moving into the cloud or the applications. Well, I mean, in yesterday, yesterday we had a session talking about enterprise enabling business agility for open stack. So we talk about measuring the values. So sometimes we talk about, when we build application, we also talk about, we always mention about, we want to build a reliability system. Okay, so traditionally when we build reliability systems, we tend to use a lot of hardware-based solutions, hardware redundancies or using expenses hardware to increase your mean time between failure. But when you come into the mission critical applications, you sort of, if you want to make this become highly reliable, right? So how can you make a system become highly reliable? So basically, either you try to increase the mean time between failure or reducing mean time to repair. So if you move into cloud-aware applications, which we use a lot of automation stuff, auto-skilling, auto-healing matters, you can reduce your mean time to repair. And that helps you increase the system reliability. Because system reliability is about mean time between failure, mean time to repair and availability. Do you have anything to add to that, Kathy? I think we're out of time. What, are we out of time? You want to get your question in though? Well, if we're out of time, I would. I'd encourage you to come up to the panel. I'd like to thank everybody. Like I said, it's been a long four days. And thank you very much for being here. Thank you so much, everyone.