 All right, hello, thanks for coming. So I appreciate people who made it here to kind of the very tail end of the conference. My name's Brad Schick. I work for a company out of Seattle called SkyTap. And what I'm going to be talking about today is the evolution of complex enterprise applications to the cloud, specifically to the public cloud. So most of this conference has been about OpenStack on-premise. What I'm going to talk about is migration of enterprise apps to the public cloud. And this is based on both the experience that we've gained working at SkyTap, where we have enterprise customers who are going through transformations like this, and then some of my own personal background being in this industry for a while. So a high level of what I'm going to go through first are a variety of paths to the public cloud. So how are enterprises, enterprise teams, thinking about moving their applications to the cloud? And in particular, I'm going to focus on two techniques to do that. One is called hybrid applications. I'll get into details about what I mean about that. The second is doing development and tests in the cloud. And then kind of towards the tail end of this, I'm going to talk about why we think at SkyTap OpenStack is important and will be an important part of this transition. So let's start by looking at the current state of cloud adoption in the enterprise. To be fair, this quote is a little bit old, but it highlights the fact that many enterprises actually have hit barriers in their approach to starting to get, or their path to starting to adopt the cloud. This is from the 451 research group. And it goes on to say not only 83% of the enterprises that were surveyed have some sort of barrier, but that 70% of the actual activity for cloud adoption was private cloud adoption. And while there's nothing wrong with that, private cloud adoption is inherently different than public cloud. There are different benefits from each of the two. And different roadblocks. Often on-premise virtualization ends up looking a lot like virtualization with a portal in front of it, which is useful, but it's different. So why are so many enterprises constrained or hitting barriers with public cloud adoption? There's a lot of reasons, but one of the key problems is the way that people think about how to adopt the cloud. How are they going to start integrating the cloud into their applications, taking advantage of it? So the first thing I'd like to do is go through five common paths or common approaches that people are using or following to think about cloud adoption. So the first path to cloud adoption for these enterprise applications are forklift upgrades. I think that that graphic there is pretty descriptive of how this usually goes. Guy doing a face plan onto the concrete there. It might sometimes work. It's applicable for simple applications. But for anything that's more complex that's been around for a number of years that people have traditionally deployed on-premise or in a co-location facility, a forklift upgrade is pretty difficult. I personally have seen this exceed very infrequently. So I'm going to label that as it's not often possible. It's possible for simple applications, not for most applications in the enterprise. The next approach that people follow for cloud adoption are greenfield applications. And these are applications that are built from inception to run in the cloud. So they're designed to understand the primitives of the cloud. They're designed to work in the cloud from the get-go. And when is this applicable in an enterprise or a big business? Sometimes people are creating a web front end or a mobile front end to a traditional app. Occasionally you get to rewrite something from scratch. And then sometimes there are new business lines or new opportunities where new applications are created. And so while these things do occur in the wild, and I put Netflix there as an example because they're sort of the poster child for born in the cloud, most businesses that have been around for a number of years don't see a lot of opportunities like this. And in fact, it's certainly not what's running the core of their businesses, new applications. So I'm going to label that one often not applicable. Apply sometimes, but not for the bulk of their investments. So the next approach to cloud adoption that you see discussed quite a bit is hybrid infrastructure. And this is sometimes called hybrid clouds. I think VMware did a great job of pointing this term. And what it usually focuses on is the connection of on-premise resources or on-premise data centers with cloud resources. And it focuses on the physical connectivity of your on-premise resources with cloud. You might use this for doing things like backup or data archival. And while this can be useful, it is a useful technique. It doesn't really solve any of the hard problems about how do I take my application and make it take advantage of the features that are in the cloud. Just connecting the wires together effectively doesn't solve any of the hard problems. So I'm going to call this one not sufficient for most enterprise applications. All right, so the next approach for how enterprises are starting to take advantage of the public cloud is moving part of their SDLC. So this means just leave production alone. Don't touch your production deployment of your application, but use the cloud as a tool to help you improve your software development lifecycle. And the best candidates here are development and testing workloads. So this could be anything from doing unit testing and continuous integration in the cloud to all the way to full stack functional user acceptance testing in the cloud. One of the things you might think is that doing a full stack test in the cloud might be just as difficult as doing a forklift upgrade, but one of the things that's appearing in this space are purpose built solutions that help enterprises do development and test of traditional apps in the cloud. So the company I work for, SkyTap, happens to be in that business. We're not the only ones. Revello is essentially in this business too. So this is the first one that I'm not going to gray out and say that it's not super useful, because this actually is an approach, a valid approach for a lot of businesses to start leveraging the cloud. It helps them speed up their development and testing processes, which means they can ship features faster and ship innovation faster. It's removing bottlenecks from their software development lifecycle, even though they're not really moving their applications, they're moving part of their workloads. This is what I'm going to argue is the most potent answer. So when you're thinking about an enterprise application and how you can start improving it, the important thing is to consider the application itself, not the infrastructure, not how it communicates, but how is the application itself functioning. And so in this graphic, I'm showing that a hybrid application is really just a traditional app with one of its components or its services either rewritten or optimized or changed to start taking advantage of the cloud. So this is what I'm calling a hybrid application. It's an existing app that's really been optimized. And I believe that we're already seeing that this is the way that most businesses are going to start taking advantage of the cloud. So I'm going to get into a few more details about what this is and what we mean by this. Before I do that, I want to go through a few reasons why I think this is a pretty likely outcome in our industry. So the first is I made this point zero because if you don't believe this, there's no reason for the cloud at all. And the point here is that the cloud really can improve the efficiency, the agility, and the scalability of enterprise applications. I'm not going to spend a lot of time on this because I think most people in this conference probably already buy off on this. But the short version is that this comes from well known qualities in the cloud, like metered usage, and capacity on demand, and improved global reach, as well as ready-made capabilities and services that you can just buy in the cloud instead of having to build yourself. So the next point is that businesses want to leverage their existing investments. And people often forget about this. It's entirely obvious, but it's important. And it applies to physical product lines, like I have here, as much as it does to technology. So businesses don't want to throw away what they have. They might have a 15-year-old enterprise client server application running. Very few people are interested or think it's a good idea to basically throw all that investment away and start over. And there's a lot of good reasons for that because applications codify a lot of the experience that you gained over the years. If you throw something away and start over, all of that knowledge that's built into effectively hard-coded into the application goes with it, and you have to start over. OK, so the next point I'd like to make is that we've really seen this before. The cloud is not the first revolution in computing. It's not the first seed change that everyone's talking about that's going to change the way people build software. If you look back at historic changes in computing, you find that our new technology almost always augments rather than replaces the old technology. And I've got a couple examples up there of changes that have occurred over time. And I'm going to go through a few of these really quickly, partially just because I think it's entertaining to look back at past changes. So the first example I want to look at is the transition from mainframes to workstations and client server architectures. So my own personal first job out of school was working for Ameritech. Actually, I worked for a consulting company that was doing work for Ameritech. And we were building a graphical front end to their billing system which ran on a mainframe. And the way that this project worked was we were building a graphical client application that was running on Windows for Work Groups, which was making RPC calls to a Unix server that was doing screen scraping of CICS running on a mainframe. And it sounds a bit goofy now, I think, but back in the time, this was a pretty hot project, particularly for the consulting firm that I worked for. But the key to all that, though, is that this was an era in the early 90s where mainframes were said to be dead. And there I was working on a very large, well-funded, expensive project whose whole goal was to extend the value of the mainframes that this company had purchased years ago. It wasn't to get rid of them or replace them. So the other thing I want to highlight here is that do some Google searching for client server architectures. And I particularly like this graphic. So this is what you find. I really like the beige server tower. In the 90s, that was a server. It was a beige tower. I also really enjoyed the hub at the center of our sophisticated client server network there. Don't see a lot of hubs around anymore. Anyway, it's surprising how dated client server looks these days. So I wouldn't want to start a new mainframe business myself, but 30 years after the introduction of client server, it's still big business. If you look at the world's top banks, retailers, 71% of the Fortune 500, they still use mainframes. This is recent data. This is not old information. And I think it was announced last year, six months ago, that the mainframe business is still IBM's most profitable business line. One more point on this, because I think it's funny. I took a few liberties with this quote, but this was from an IBM white paper about mainframes. And they basically said that all browsers and the internet are as a new graphical user interface for mainframes. And if you're making an airline reservation or talking to a bank or a retailer, this is actually often true still. So the next sort of sea change in the computing industry that I want to go through is SOA. So SOA, I'm sure most of you are familiar with it. It's a design principle that helps you build scalable applications by offering up design patterns for the creation coordination and scaling of these apps. And it's all about having independent, loosely coupled services. SOA has taken a lot of flack over the years, but pretty much everyone agrees that the core tenets of SOA are useful and worthwhile. But when this came out, did enterprises go out and rewrite all their applications to comply with SOA and be SOA applications? They really didn't. So what they did, in my opinion, is that they cherry picked the best ideas from SOA and they opportunistically deployed it and created what I'm calling SSOA applications, which stands for sort of service-oriented architectures. Thanks for the laugh. I appreciate that. And so I wanted to trademark that and try to collect royalties on the name, SSOA. Unfortunately, it didn't work out. And another term has caught on for this recently that everyone's talking about. Anybody know the term? Someone's got to know. Microservices, right? Everyone's talking about microservices. And microservices are really the latest recasting of SOA with some of the goop stripped out that no one cared about anyway. So it's another trend. But it's what's old is new again. OK, so the last point that I'd like to make about Enterprise Cloud Adoption is that production software often needs to be designed to work in the cloud. This is the exact reason why forklift upgrades to the cloud are difficult. This comes from the fact that the performance, availability, durability, atomicity, characteristics of the cloud are often different than what you're going to find on-premise. You have to think about things like the cap theorem and eventual consistency in the cloud where you can often, through specific purchasing and designs, ignore those problems on-premise. A lot of times, I think people ignore them to their own peril, but you can avoid those problems with money a lot of times. In the cloud, that's not an option. So again, that's why forklift upgrades to the cloud aren't very likely. OK, so I've gone through four reasons why I think that Enterprise Cloud Adoption is going to happen, and also why I think that's going to be gradual. So let's change gears a little bit. And I'm going to play the role of the VP of Engineering for this fabulous looking application here. And based on its complexity, I'm going to say I work for the Health and Human Services Organization, and this is probably the Obamacare website. I'm sure there's 500 million lines of code. I don't remember 500 million lines of code for a website. I'm sure that's got 500 million lines of code in it somewhere. So anyway, what I need to do is I want to turn this into a hybrid application. So I'm going to look around for both challenges and opportunities to start integrating the cloud. So let's look at a few specific things. First, I have a mainframe. Part of my application, way too expensive for me to rewrite. I can't just throw it away. It's an important part of my stack. So this is something I'm going to have to consider. The next thing I'd like to deal with or think about is my data warehouse. So I'm using this for business intelligence. And there's a couple problems I'm having with it. The primary one is that it's not scaling well, and it doesn't have a scale out solution. It's a scale up solution. And I'm paying way too much money to my vendor to make this happen. So it's becoming a bottleneck in my system, and I'm not getting the intelligence that I want out of it right now. So I have another service over here that holds sensitive medical records. And although I could potentially move this to the cloud, it has compliance requirements. Let's say HIPAA or something. And moving that out to the cloud is going to be a pretty significant barrier for me. So I also want to take a look at my web tier here. And my web tier was written in Java, and it's already designed to be a scale out application. But the load on this thing is bursty. So I sometimes am over capacity, and sometimes I'm under capacity, and I'd really like to be able to get capacity on demand for this. So the very last thing I'll look at is my development lab that's off here on the side. And the problems I'm having with my development lab are that during the day, there's a ton of contention on this environment. And at night, it's drastically underutilized. It's often polluted by last week's old data or bad builds, and it's become a bottleneck in my software development life cycle. So the rest of my application is fine. It's paid for. It's essentially a sunk cost. I don't really want to mess with it. I'm happy where it is, and I don't really want to move it anywhere. So given all those challenges and the opportunities in this application, and those four points I raised earlier, what are my options? What can I do about this application if I want to start taking advantage of the cloud? So option number one, just punt, ignore it. I would say that a lot of businesses are doing this today. My personal feeling is this is not a sustainable position, that eventually ignoring the benefits that you can get out of the cloud, taking advantages of the cost savings or the features or the scalability of the cloud is going to end up helping your competitors. So the other option is private clouds. And I kind of put that in air quotes because private clouds often do amount to not much more than virtualization with a portal in front of them. That's not always true. I was actually having a pretty in-depth conversation with someone from SurveyMonkey, and he was telling me about how they're going through a really extensive debate about whether they should build a private cloud or use the public cloud. And we ended up both agreeing that the decision factor for them should be whether they're going to treat their private cloud as a key differentiator for their business. Are they going to put their top notch people on it and make this something that their business is dependent on, or are they going to treat their private cloud like a side project for the ops team that's just a cost for them? It's like the accounting department. It's necessary, but no one in that department's going to become a rock star in the business. And this is what most businesses are dealing with, is do they really want to invest the expertise and time to turn their own infrastructure into a real cloud? And I would say, even if you are putting the investment in, often a private cloud doesn't end up being, it's missing some of the characteristics of a public cloud like scalability, right? You can't easily get capacity on demand if you're buying the resources yourself. And I think probably the biggest challenge with doing a private cloud is that you lose the opportunity to make parts of your application stack and parts of your infrastructure someone else's problem. So you can't essentially outsource it or offshore it and make someone else deal with it. You have to maintain ownership of the entire application that you're building and everything that it's running on. So it's viable, but there are some challenges. So the last option is really what I'm here to talk about, and I mentioned, I described this earlier, hybrid applications. And this is an attempt at a more complete description. Really what a hybrid application is, is that it's an application that's running across multiple different providers. So often that's going to be on-premise resources like your own data center and a cloud provider. The key here is that the focus is on the application itself and how the application can take advantage of cloud resources rather than how to hook the infrastructure up. And so I'm going to go back to this just because maybe hybrid was a bad choice for hybrid applications because everyone uses the term hybrid for everything. But I'm going to try to clarify one more time, this isn't a hybrid cloud. And the reason I say it's not a hybrid cloud is that people usually mean hooking up infrastructure when they talk about hybrid clouds. And the key with the hybrid app is that you don't need to do this. It doesn't preclude this, but you don't have to have any special connectivity between your data center and a cloud provider's data center. OK, so let's return to my role as the developer of this great application and talk about some of those components that I want to be able to start taking advantage of the cloud with. So I'll start by looking at my data warehouse. So if you recall, this wasn't scaling like I wanted it to, and I was paying a lot of money to a third party vendor to keep this thing going. So what I'm going to do with that piece is I'm actually just going to rewrite it. I'm going to start from scratch, and I'm going to build it on top of Spark running on top of Rackspace. Rackspace has their cloud big data platform that can give you Spark as a service. So I can really consume this as a service. So I don't want to imply here that this is free or easy. I might have to start over here. But the key is that it was an easy part of my application to move, and I'm going to get significant benefits by doing this work. So I've picked something kind of opportunistically that I get a lot of bang for the buck from putting in that work. One of the reasons this was easy to move is that it's pretty self-contained, and it wasn't latency sensitive to the rest of my system. It's doing sort of batch processing work. So let's look at my web tier next. If you recall, that was already written to be a scale out application, but I wasn't able to get resources that I need for the thing, both scaling up and then giving resources back when I want to scale it down. So I'm going to move that out to cloud servers by Rackspace as well, and I'm kind of keeping with one vendor here on purpose. And again, I could build an auto-scaling feature on my own, but why bother? This is something that's already out there, already available that you can consume as a service. In this case, my Java application was already designed to take advantage of being able to scale horizontally. So it's not a huge transition in this case for me to move my Java app out and start taking advantage of auto-scaling. It's available in most cloud providers. So one tricky thing here for this application when I was thinking about how to optimize it is that the web tier does have a very latency sensitive connection with its database. So that's not a good place to split these things. I don't want to move one far from the other. So what I decided to do in this case was to move both the database and the web tier together so that they could remain close. And then communication with the rest of my gnarly application here is over a message bus. So that makes a really good spot to split my application because message buses tend to be more tolerant to hiccups and are less latency sensitive. I'm going to get into some of those details about what makes a good candidate for moving or migration in a bit. OK, so the next thing is my development and test lab. And although this is not a sponsored talk, I still felt compelled to throw in a plug for my company's SkyTap here. So what SkyTap is providing me in this case is the ability to basically get environments on demand for my developers and testers. So I'm taking my dev lab and I'm basically removing it from on-premise, hosting it with a provider, and being able to basically get resources for all my devs, all my testers, whenever they need them. Equally important, when they don't need them, I can turn them off and throw them away. And there are several products that are specifically designed to do this to help with this really dynamic workloads that are layers, essentially, on top of raw IAS that are tailored for development and testing uses. A benefit that I've got here is that all of these services fall under the OpenStack API, where they have OpenStack-compatible APIs. I should say, in SkyTap's case, this is something that's coming fairly soon. We don't have a full OpenStack API, but we're working on it. This helps me with the portability of my workloads. It means that I don't have to train my teams to understand a lot of different platforms. So one of the keys to the work that I just did here is that I don't have to deal with the complex parts of my stack that I didn't want to bother with. I didn't have to touch the mainframe. I just left it where it was. I didn't have to deal with the system that was holding medical records that was going to be difficult to uplift because of compliance requirements. I just didn't touch them. So most of my application is, in fact, unchanged. And I'd say, through the magic of PowerPoint, I've created a hybrid application here. So easy in PowerPoint. So this is the cheat sheet version of this presentation. Have you heard the saying, how do you eat an elephant? Yeah, a lot of people got it, one bite at a time. So it's the same strategy with complex enterprise apps. How do you start taking advantage of the cloud? You do it one bite at a time. And you be opportunistic. You start off with the easiest things. And you just leave everything else where it is for the most part. So let's say you want to do this. And you're interested in starting to take advantage of a cloud provider in your application. How do you go about finding candidates for migration? How do you find things within your stack or application that are good candidates to move? So the first one is services or components that aren't meeting scaling needs. This is pretty obvious. If you're having to go buy a bunch of infrastructure and do things on your own, those are great candidates to start moving out to the cloud. Also things that you're going to get quick payback through reduced costs. So if you have very spiky workloads, things that are consuming a lot of resources during the day and not a lot at night, you might be able to save yourself a bunch of money by moving it off your own infrastructure. And I talked about the next example, which was capabilities that you don't even have. So if you want to do auto scaling or something like that, you're going to be faced with the choice of building yourself. It's kind of a build-buy question here. Sometimes it's more efficient to buy. So services that benefit from reduced latency to end users are another great candidate because you often don't want to have to build your own facilities and data centers around the globe. If you can go to a provider who has more facilities that's closer to your end users, that's an easy win. And then finally, I'm going to go over the last one here, which are non-production workloads like development and testing. Those are often good candidates for migration out to the cloud. And part of the reason for that is that they tend to have fewer barriers to entry. You have fewer people that are going to be calling security into question or compliance into question when it's not part of your production stack. OK, so let's say that you've found something that you want to move out to the cloud, a component or a service that's part of your application. What are some of the qualities that it would have that would indicate that that's going to be a good thing to move or at least easier to move? The first point up there is really that there's no point to swimming upstream. You should find something, and particularly in big businesses, number one is an important point. Find something that meets your corporate security and compliance requirements. If the first thing you have to do is fight a huge political battle about how you can take advantage of the cloud, it may not end up being worth it. I suppose an obvious point, but it's still very contentious in many businesses that we see out there. The next one are services that are self-contained and loosely coupled. So this means basically that they're just easier to separate from your application. If it's self-contained and it's dependencies on other parts of the system are minimal, easier to dry around. And the next is that services that aren't latency sensitive. Usually creating a hybrid application means that the things are going to go greater distances and you're going to have increased latency. So you have to be tolerant of that. The next are item potent protocols. And most of you are probably familiar with this. This really means protocols that are safe for retrying. If you are splitting something across a greater distance or chance of hiccups or disruptions and the communication between those pieces goes way up. And so to the extent that your protocols and your communication between your components can tolerate that without causing weird side effects or failures, you're going to do a whole heck of a lot better. And really anything that's already designed to be scale out and felt tolerant is going to be a lot easier to move to the cloud. Because the semantics of services like that are often better matched the semantics of what you're going to find in infrastructure in the cloud. OK, so it's really never quite as easy as I'm making it all sound. There's definitely going to be challenges here. And we see these challenges all the time. And I'm just going to quickly go through some of them. So the way that you do authentication and federation, sorry, authentication and authorization on-premise and in the cloud are often different. So you might have to come up with some techniques to federate that. Deployment strategies, how do you get your bits out there? How do you get new infrastructure in place? How do you create networks? You might be talking to your ops team on-premise and you're going to have to call an API in the cloud. Consider those factors. Monitoring and learning is pretty much the same. They're the same in that it's different, which I clarified it. And then data placements, often a concern as well. If you're splitting things, you're probably going to have to deal with things like data replication or caching. The data needs to be close to the place that's being used often. And when you're moving things apart, you're often going to have to think about that relationship and where the data should live and if it needs to be replicated or moved around. Sometimes you're going to face the need for a new IPC mechanism. I talked about idempotent protocols already. If you don't have idempotent protocols, if you look at the way your services communicate and you find that this is intolerant to hiccups, you're probably going to have to make some changes. The most common, I would say, problem child in that space is an RPC call. If you look at most code that's out there, it's calling an RPC call just like it's a local function. And no one expects that to fail. And that was probably a mistake from the get-go because it can fail. But on premise, it fails a lot less than it's going to fail if it's somewhere remote in a data center miles or hundreds of miles from you. And then I have one more point. And this is, I think, particularly relevant at a conference about OpenStack is that the choices that you make when you're picking a cloud provider are likely going to be with you for a long time. So it's something that you need to consider carefully about who you're going to use and how you're going to integrate them to your application. And so that's my little picture of a walled garden there. And you may want to pick a single vendor. You may want to pick a solution that only one vendor provides and only you can only get from one source. But if you do, you should do that knowingly. So you should make this decision consciously and say that I'm OK that I'm building my future around a platform or a solution that comes from one vendor. And I'm going to be tied to them for a long time. So what are the choices out there? Amazon is, by far, the leader in this space. I think Microsoft's a distant second. And OpenStack, particularly for the public cloud, is behind, but I think catching up. And what we see in our business, we're talking to Fortune 500 enterprises all the time, is that the interest is actually going in that same order. Almost everyone is thinking about Amazon. They have concerns. Some people are thinking about Azure. And OpenStack is kind of what we see is becoming a point of interest. Most of the adoption that we've seen of OpenStack has been on premise. But based on this conference and my experience, what we believe at SkyTap is that OpenStack is going to grow and become an important player here. So I will also add that there's a whole bunch of alternatives that are, I would say, up-and-comers. We've seen a ton of Docker and Kubernetes at this conference. Google Compute Engine and even VMware, I would say, are up-and-comers or dark-heart horses. The interesting thing I think is putting VMware here because it's obviously huge and well-established and it's in all enterprises. The reason I call it an up-and-comer here, though, is that developers aren't using VMware as an API. We don't see anyone in our experience building applications that are tied directly to VMware. So a bank's billing system is not tied to VMware in any way. VMware is generally a tool that's used by the operational team to give resources out to other parts of the business. They're trying and they're working on things that are designed for developers. But in my opinion, they're kind of behind today all these other components. One of the interesting things I think out of this conference is Docker and Kubernetes. We actually met with a Gartner analyst who said that there's today equal interest in Docker and Kubernetes from businesses as there is OpenStack. And I've been to a lot of presentations here that talk about how people talk how Docker and Kubernetes fit together like peanut butter and jelly. And I actually think that's a good argument that they're pretty complementary with each other. OK, so why does OpenStack matter? Some of these slides came from a conference that wasn't just about OpenStack. So I probably won't belabor these points since I think most people know. I'll highlight a few things in here. The first one, I'll relay a brief story because I think it was interesting. We met with an analyst at Gartner talking about our company and our strategy with OpenStack. And she was actually very disparaging of OpenStack and didn't think that it was going to really matter. And her main reason for saying that it didn't matter was that OpenStack isn't unified. And you're going to have all these different vendors creating their own flavors of OpenStack and that this idea of reduced lock-in is bogus. And my answer to her was, I mean, sure, you're going to have a bunch of varieties. But what's more complicated? Moving from vendor A's version of OpenStack to vendor B's version of OpenStack are moving from AWS to Azure. I mean, those things are completely different beasts with completely different APIs and completely different semantics. Sure, everyone's going to want to have their own value added version of OpenStack out there. But the core, the Defcore API and the core semantics are going to be similar. And so it definitely gives you more choices and it definitely makes your binding to a specific vendor a little bit less severe. So let's see, anything else up there I want to highlight. For a lot of our customers, which tend to be more like sporting equipment companies and insurance and occasionally banks, they're not super interested in the ability to fork something and take it private. But they are interested in the third point, which is the ability to look inside. So we've pointed this out to them repeatedly, which is it's a lot easier for you to understand and deal with a system that you can look inside and see the source. Your developers can actually gain knowledge by looking at it rather than having to call the support team of a closed system. OK, so this is pretty much the end. And so what I'd like to summarize is by saying that I think enterprise applications definitely will evolve to the public cloud. And the key takeaway, I think, from this presentation that I'd like you to take away is that enterprises should be thinking about how their applications should evolve to the cloud. How do I make my app consume capabilities and resources from the cloud rather than how do I make my infrastructure communicate with and connect to the cloud? We see that flipped fairly often. And I think it's a huge mistake. So then the last point is that you should choose your dependencies carefully because they're going to be with you potentially for a very long time. And then I put up that up there because I'm talking about evolution and I thought that was funny. So that's it. That's all I have. Thanks for coming. And I think if anyone had a question, I think we've got three minutes and 30 seconds left. That must have mean it was a great presentation. All right. Hi. Just a quick comment. I want to take on that, I guess, is that we often say that people in processes are more important than technology when you're moving to cloud. So that, I think, goes with some of the arguments you made. In your experience, have you seen that? Like how people handle people in processes while they're moving to cloud? Yeah. 100% agree with you that people in processes can be as much of a barrier or sometimes more. The struggle I have there is that there's no silver bullet answer. How do you get a business or an enterprise ready to go and accepting of these things? What we've seen is that there's two potential problems. One is sometimes there's a lack of knowledge. So people don't understand or know what they can get out of a cloud provider. That one's fairly easy to deal with. You show examples. You showcase studies. You demonstrate what other people have done in the cloud and provide them kind of the ammunition or the info or the data to get motivated about it. That's the easy one to deal with. The harder one to deal with is people that feel sort of threatened by it and they are attached to the way that they've done things a long time and they're not interested in changing or they feel it's a threat to them. I think we're going to run into people like that. It's inevitable. It kind of always comes with change, but that sort of obstacle always ends up going away if the benefits that you get out of doing it justify the ends or justify the transition. Eventually the steam engine replaced the shuffle because it was a lot better. We're definitely, SkyTap is not in the business of trying to overcome those barriers. We tend to leave that to our customers. We focus on presenting them the data and say, hey, your return on investment's going to be great. You're going to save this much money. Here's all the reasons why it's compelling and let them figure out the personnel problems. So you mean you want a name of a customer that's actually doing this? Or? It's kind of what I was trying to do with all this stuff back here is a Java app that's deployed on-premise that's a scale-out Java app. It's already running across, say, end servers. That is something that's going to be generally really easy because it's already a scale-out multi-instance service. Taking that and deploying it to the cloud probably doesn't require a rewrite. That'll probably work unchanged in the cloud. And then you can start taking advantage of things like capacity on demand or scaling down on demand. I'd say that's the classic easy example is a service that's already designed to scale out. Most web tiers are like that. Most back-end batch processing systems are like that. The thing that's not good, the counter example, is the single instance, people talk about pets versus cattle. The single instance, I know the name of this machine is Fred and it can never die. That's usually not a good candidate. Thanks.