 All right, why don't we get started? Guys, thank you for joining us this morning. Today, I'm going to talk to you a little bit about ways that you can build consensus for an enterprise cloud strategy. This is based on my own experiences, and I'll talk a little bit about those in a minute. Why are we talking about this? We're already at a cloud conference. It seems to be, if you're here, at least you've thought about cloud in your enterprise. But that may not be the case for everybody in your organization. Cloud isn't the obvious solution for everybody, and it may not be the only solution to problems which you're facing. So we're going to talk a little bit about ways that we can, one, determine if cloud is the right strategy for us, and two, ways to implement that in the enterprise. So cloud is as much about implementation clouds as much about a cultural change as a technological change. Today's talk is going to focus more on the cultural side of things and less on the technological side. Before we start, let me tell you a little bit about myself. My name is Justin Moore, and I'm the Director of Cloud Operations for American Express Enterprise Growth Group. So Enterprise Growth Technologies is responsible for the applications and infrastructure, which support the company's expansion beyond the traditional card and travel markets. So not the traditional side of American Express. We do new product development, including the serve card, the target red card, the blue bird card with Walmart, also foreign exchange services and expansion to international markets. So as you can imagine, we're a pretty fast-paced environment. We move quickly. We're an agile development shop. There's a really high rate of change, and a lot of times, they're short timelines. So for us, that means we had to come up with a better way of doing things. And I'm going to talk to you a little bit about how we've done that and what the cultural shift has been inside of Enterprise Growth. So on the agenda, we're going to focus more on how, as I mentioned, the how of our cloud strategy, less on the what. We do want to come back, and we've got a more complete story for you, and we've got things in production. But we want to make sure that we're adding value. All right. So how do you implement a cloud strategy? The first thing is to start with a problem statement. What problem are we trying to solve with cloud? Is this a problem that could be solved in other ways? Are we trying to improve our developer experience? Are we trying to reduce our time to market? Are we trying to reduce our costs? These are all good use cases for cloud, but the cloud's not the only solution for those use cases. So start first with what's the problem we're trying to solve before we just jump in and say, let's build a cloud. Is there an easy way to solve the problem? Can we just build a faster horse? If you're trying to solve the problem of faster provisioning, is cloud the only way to get to where you want to be? Is there an incremental improvement or a set of incremental improvements that we can implement to existing processes that will meet the need in a cost-effective way? There might be. So we don't have to necessarily go with a cloud approach. But you might decide that we have to fundamentally alter the way that we're thinking. So cloud can be a powerful tool, but it requires a lot of effort to implement. If you're here, you probably know that. It's not the case that you can stand something up in a matter of hours or days and have a cloud up and running and you've transformed your environment. There's a lot of work that has to go into it from a technological and cultural standpoint, from a process perspective, and also just from the underlying technologies, getting people up to speed with a different way of doing things. These new technologies have a broad impact on the way things are done, the way we provision infrastructure and services in the environment, and also in the way that we deploy code and manage processes for things like audit and compliance. OK, so you've gone through the problem statement and you've decided that cloud is something that can really help solve a problem for you. What type of cloud are you going to build? There are a couple of options. You can go totally public, something like Amazon or Azure or Google. You could go private. OpenSAC is a great example of that. You may go with a hybrid approach. You might have something that spans both. There are going to be some drivers for this, legal and regulatory. If you're a big public company or in the finance spaces, we are, you may decide that the public cloud isn't the right place for your applications. On the other hand, you may decide that it's a great place for your applications. Cost and time, you may not have unlimited budget. I'm sure that you don't, I don't. You don't have unlimited resourcing and staffing to implement a cloud strategy. You may also not have the right expertise. So you might not have a team in place that can implement an on-prem cloud. So that may push you towards a public cloud offering. All right, if we've decided where our cloud lives, whether that be on-prem or public, what are we looking to deploy? This goes back to your problem statement. We're just talking about how do I provision servers faster. We may be talking about infrastructure as a service. If we are more interested in the developer experience and abstracting away some of that infrastructure provisioning, we might be talking about Paz. So we really have to think about what the high-level vision of our ideal cloud looks like for the organization. It doesn't have to be complete at this point. So all we're trying to do is just get an idea of what we want to build, how we'll solve our problem. You don't have to have all the answers, but it's a starting place. It's something that you can take back to the team and talk through. It's also the basis of future conversations. So it can't be just a really vague idea, hey, I want a Paz cloud that's going to be on-prem. We're going to go forward with that. You should put some thought into how some of those processes should work. So once you've got that idea, let's talk to our direct leadership. So that's your manager, your director, your VP. Talk to them a little bit about the problem that you're trying to solve. Why you think cloud is the appropriate solution. Demonstrate that you've thought through some of those questions, the regulatory compliance concerns and the cost. Like I said, public or private, you really just have to put some thought into it. The reason you start with your leader, they're going to ask you some great questions. They'll talk to you about some of the challenges you may run into. But more importantly, if you get on the same page with your leader, they'll be able to give you support as you move through the process. So later conversations with executive leadership, having your leader on board and having his leader on board is a big benefit. Okay, so if your boss is on board, we're ready to implement or start investigating a cloud strategy. We've got to think more critically about what we're actually building, nuts and bolts. So pull together a cross-functional team. And this needs to be pretty broad across the enterprise, across the users in your environment. Because their job is to define the MVP. So we want to come together and talk about what's the first iteration of our cloud, what's the minimal viable product that we're going to launch with. This group doesn't need to be a group of senior leaders and in fact it makes sense that it's not a group of senior leaders. It would be better to have people that are closer to the problem, practitioners, people that deal with the struggles of implementing infrastructure and deploying services on a day-to-day basis. They best understand some of the real-world use cases. Want to keep the team small. We want to get away from or try to avoid analysis paralysis. Large teams, everybody gets a say. I'm sure you're all aware of this. You've got a hundred people involved. There's just too many cooks in the kitchen and we're just not able to get things done. So we want to keep it small. We still want to have a diverse group of people. But keep the group as small as makes sense for you. Some of the questions we've got to talk through. How will the process work? What other information are we missing? Like I said, we have sort of a high-level understanding at this point of what we mean by cloud and what we're talking about deploying. But we don't have all the answers yet. And the group's main goal is to think sort of more broadly about the types of issues that we'll have to solve and that we're hoping to implement with the cloud. You're gonna need to meet often at first. For us, we did an off-site, a several-day off-site with this group and we just talked through our past experiences, our current challenges, a lot of whiteboarding. And we came up with an early draft of the cloud. At first, you're gonna be meeting very frequently, a couple of times a week. There's lots of decisions to be made. As you dig in more, you'll find more information. This group is going to be the sort of steering committee for those future decisions. But as we get further in the process, you'll be able to meet less frequently, weekly or bi-weekly, monthly. It just depends on what cadence makes sense for you. Okay, so our cross-functional teams met and we've got an idea of what we want to build. So the next step for us is to put together a demo. And this demo doesn't have to be anything robust, right? For us, it was all in one install of Packstack. And the goal was really just to take this out and show it to our leadership. And just say, hey look, here are the problems that we're trying to solve. We put together a small POC and here is sort of an idea of how we want to solve it. A working demo is really important at this phase. Like I said, it's not something that you're going to push into production, but it is something that you can show. Seeing as believing, right? So as your leadership sees that you've put some thought into this and sees how things can work, it's going to sort of form the basis of future conversations. So you want to talk about the problems that you want to solve, how you're going to solve them. The demo shouldn't just be here's Horizon, here's how I launch an instance. You need to relate it back to real-world problems. How long does it take to provision infrastructure today? If that's one of the problems you're trying to solve, demonstrate how long it takes in the cloud. You want to propose high-level timelines with milestones. So your leadership is going to be very interested in knowing how long is this going to take? How are we going to track our progress? What's the cost going to be? How much resourcing am I going to need? And how am I going to prioritize this against other initiatives? So most importantly, solicit feedback. This is a really good place for you to get some information from people that have a broader view of the organization and some of the challenges that you may not be aware of, timing-wise, project-wise, funding-wise. So listen to their feedback. Don't just say, I've got an idea in my head of cloud and this is what we're going to build and either you're on board or you're not. This is an iterative process. So take that feedback into account and build it into your next iteration. You want to make sure that you're clear with what you're asking for. What do you need to move forward? Do I need additional resources? Do I need people? Do I need money? I don't have enough servers to launch the cloud. Is this something that leadership can help with? So get those the asks ahead of time. So know what you're going to ask for. It sets the groundwork for some of the resourcing you'll need later. And this group is going to be a team that you can use to help make the case of senior leadership. So it's about building broad base of consensus up front. Our approach isn't to start with the CIO and have a mandate, our approach is, let's build a broad base of consensus and take the whole organization along with us. Okay, so leadership is a bottom. They say, let's say, go ahead and start down this path. You really need to get the support of the rest of the organization. So we want to take this on a road show. And we're going to start small. We want to meet with groups individually, current stakeholders, people that provision infrastructure today, application owners. You want to talk to the business where it makes sense. And the goal is just to talk through some of the challenges that they have, explain your viewpoint, explain the problems you're trying to solve with cloud and then explain how they fit into the process. So why are we building this? What are we building? How do you fit into the process? It's really important that people feel engaged in the process, that you're not just coming and moving their cheese. If people aren't engaged in the process, they'll find a reason for it to be unsuccessful. Again, you want to solicit feedback here too, right? These are your SMEs, these are people that are already experts in your environment. Maybe they're network admins or storage admins. They know how things have been done and why. They may be able to give you good feedback as to what types of challenges you'll run into with the approach. One of the big messages we tried to send is this wasn't about a reduction in force. Even though cloud automates a lot of what people have done traditionally, our view is that it takes some of those time and we can use those resources more effectively in the future. Want to try and focus on problems that they have. Engineers, at least my engineers, don't love tickets, right? They work from a ticket queue. So we went to all the engineering teams and said, look, wouldn't it be great if you didn't have to sit in a ticket queue all day and just provision infrastructure from tickets? All right, good communication. That's key to the whole process. So there should be a continuous feedback loop between you, your leadership, your stakeholders. As you're building, get feedback. You don't want to get to the end of your build process. You've got the cloud up and running and it completely misses the mark. You want to have something that's useful for your end users and your stakeholders and something that makes sense for the organization. You want to keep in constant contact with the stakeholders and involve SMEs. So for a couple of reasons, like I said earlier, these are people that are already experts in your environment. I like to pick on the networking team because it was a big challenge for us. How do we get, how do we do networking in the cloud? You know, if we're including the SMEs, they've got some stake in the game. They can say, this is why we've done things this way and maybe your approach doesn't take that into account. If they're in the process early, they'll be much more beneficial to your initiative. You want to incorporate that feedback into your design. As I mentioned, it can't be a build at once and hopefully it was the right thing to build. All right, so we've got a cloud that we've been building and we've gotten something that we think resembles an MVP. We want to start lining up beta testers. So these are internal users that will have a use case for the cloud. Maybe they're your application owners. And you want to find people that are going to be engaged. So a program that's mandated from the CIO tends to have a low level of engagement, right? Big Boss comes in and says, we're going to have cloud. You're going to be on cloud, whether you like it or not. People don't really like being told what to do, right? If you can engage people early and say, listen, this is something that we think is going to help everybody. We need your help to get there. You're going to involve people in that process. So by asking for volunteers to join the program, you're going to be finding people that are motivated to move to cloud. So people that are enthusiastic supporters. When you're picking up that pilot team, you want people that are going to be enthusiastic, but they also have to have a good network internally and a good reputation. So these people are going to be your best salesman. If I go and I'm an infrastructure guy and I'm trying to sell the app dev, I don't have as much credibility as somebody that's a technical director who delivers applications, right? So if I can get somebody from the application team to be enthusiastic about the cloud and be a big proponent of it, it's going to have more credibility with the rest of the team. So these pilot users are part of what we call a high touch beta. And we mean in high touch, just give them the white glove treatment. So we want to learn from actual use cases. So we're going to test this out on real customers, right? Our end users, in this case, application developers, figure out what works for them. We want it to be high touch and give them the white glove treatment so that they feel like they can be enthusiastic supporters for us. If the cloud goes terribly for them, these people that have great networks and have a lot of credibility all of a sudden have a reason not to back your cloud initiative. So we want to make sure that they have a really good experience. We want to just define success criteria up front. What does it mean for us to be successful in our POC? When will we be finished with the beta? Kick off a scheduling meeting initially to just talk through how the cloud works and do a hands-on training. So up front, remember, we're still learning from them. We want to update our documentation. But we also want to make sure they're really comfortable with the cloud. And we're going to have to meet early and often. As I said, these are high touch beta users. They're going to have a lot of questions. We may not have all the answers. Let's keep a continuous line of communication open. This could be a couple times a week. It could be even informally. So, hey, I've got a problem. Make sure the cloud team is available to answer questions over email or chat or phone. We want to build on existing documentation. So this documentation is what we're going to provide to future users. In the future, we don't want every user, every new onboarded tenant to be really high touch because that's expensive for us to manage. What we'd instead like to have is a good base of documentation that we can use to onboard customers more quickly in the future, but something that's been tested and used by other teams in the environment. So the general roll out. We've had a successful pilot. Our pilot teams are engaged, they're enthusiastic. We've solved all the problems that they've encountered. We've gotten good documentation and we're ready to roll out to a broader audience. So we want to leverage some of those learnings from the pilot teams. And this might be new user stories to develop new features. This might be updates to documentation, but we definitely want to make sure that we have learned something from the beta and that we build that into the next iteration. And again, with our onboarding process, we want to start with training for the new users. The worst thing that you can do is hand somebody a manual of 50 pages and say, here's how you do the cloud. Start out with an hour long session and talk them through how the cloud works and show them hands on how it's going to work for them. And again, be available. You want to be there to answer questions for the team. Don't just fire and forget. We are not a public cloud provider. We have internal users. We work with these people every day. Be good business partners to them. Make sure that they're comfortable with the solution. Probably most importantly is track the adoption and display this around the office. So I've found that people are very competitive. And if you show that one scrum team has fully adopted the cloud for their application and you put that out in front of people, other scrum teams are going to say, hey, listen, I don't want to be the last guy in the cloud. I'm going to start prioritizing some of my user stories in my backlog to get on to the cloud. So by pushing this out in front of people, they can see where they are in the process. OK, so we've talked mostly today about how we're doing things. What are some of the challenges that you might run into? And some of these we've run into. Funding. So it's very rare when you start a cloud initiative that you just happen to line up perfectly with the budget cycle. And your CIO and your finance people say, here's $5 million to build a cloud. Usually what happens is over a period of time, you come to a realization that you need the cloud. And it's probably off cycle. It might not line up well with your hardware refresh cycle. So you've got a sort of an issue that you run into. How do I get funding for servers? How do I get funding for resources? How do I get funding to run this project? So by keeping in contact with your leadership, you have the opportunity to get additional funding potentially, also by talking to the functional managers. Those functional managers that we're solving a problem for, they may have some hardware budgets that they can help with. If this is you can demonstrate something that's going to benefit them directly, they may be willing to help out. They may also be willing to help out with the resourcing. Maybe I can dedicate half of an FTE to help with the cloud on a weekly basis or something like that. Partial buy-in, this is something that was interesting to me. And it's something that we ran into. Very early on, we got pretty broad acceptance of the cloud. Everybody, in theory, said cloud is great, and we really want to have cloud. It's going to solve a lot of our problems. When we went to some of the functional teams, and again, I'll pick on networking, we went to the functional teams and said, OK, here's what the cloud means for you. I'm going to implement SDN. All of a sudden, it becomes more real for those teams, right? And they say, OK, well, listen, I appreciate what you're trying to do. I've got a good handle on my component. I think there are other areas that you'd be better spent by focusing on, which was interesting to me, because the cloud only works if we've got all the components together. So you've got to talk through what are the challenges they're facing and how we're going to solve their challenges in the broader picture, and how all of those components tie together. It won't work if only certain components are on the cloud or certain teams have joined the cloud. We've got to take a holistic approach. Prioritization, I'm sure you're all aware of this. You have business initiatives you've got to deliver on. The business is most interested in getting functionality out to the customer, as they should be. So the teams are already busy. Do they even have time to help you? You may not even have a staff. It might not be the case that you got 10 FTEs to work on the cloud. So if I'm asking a functional manager for help with the cloud, does he even have the resources to help me? He might not. So this is, again, going back to talking to your leadership, keeping them up to speed, getting there by and early. They can help with prioritization. As I mentioned when we started, I wanted to reserve some time here at the end for Q&A. Most of this is just around the how. It wasn't a technical discussion. But hopefully you all have some questions for your own organization or questions about what we've done at American Express. So if you've got questions, please, they ask me to ask you to use the microphone. Or if you don't want to use the microphone, I'll repeat them. It would be better if you could use the microphone. How many people were on your project team initially? Initially, it was just myself. So we had to make a case internally for how we would build this out. We were able to pull from other groups. We got four FTEs to work on the project. I was fortunate enough to cherry pick these from the rest of the organization. So we got some really high-end talent. But we didn't start out with a budget to hire a whole team of engineers. Were the four FTEs cross-functional people? Yeah, they're more DevOps. So we didn't just pick a Linux guy and a network guy. We tried to pick people that had a background and a number of different technologies. And were the four FTEs the number of people that you had when you had the MVP? Yeah, we still only have four. Wow. Yeah. Now, we're not fully in production, right? So we're, as I mentioned, our story is still evolving. But we expect we'll be able to keep the team small. So one of the benefits of Cloud for us is the number of people that we needed to manage the infrastructure in the past. Those resources can work on other projects. And our Cloud team will be fairly small for the foreseeable future. And last microphone-hogging question, the period of time? The period of time, end-to-ends, has been about 12 months. That's been a pretty quick turn around so far. Thank you. So my question's around infrastructure and or maybe better said, environment and reuse. And how much do you green field and how much do you try to integrate with the way you do your current network connectivity, your current security model, your current system administration? Do you try to kind of fit that or do you say, you know what, we're just going to go over here and invent it? We'll have one plug-in. And if you want to use it, you go over there. Yeah, so it sounded maybe like there were two questions. How much of the existing infrastructure do we use? And then do we standardize? Well, maybe to kind of wrap those together is what trade-offs, you know, like, do you try to fit it in? Do you try to find a way to shoehorn it? Or do you say it's better to go green field? Yeah, that's a really great question and something we've struggled with constantly. Initially, we said, let's just layer cloud on top of what we have and it'll magically make things better. That was a really, really bad approach. So what we did instead, at every step of the way, right, at first we said cloud on our existing virtualization platform, cloud on our existing storage platform, and servers. At every step of the way, we found it just was not workable. So we've just taken the approach of it's a totally new environment. We're building it off in parallel and we'll be migrating applications over as we can. OK. Yeah, great. Thanks. So when you said you're migrating applications over, are you asking your application teams to actually re-architect their applications to be a cloud aware? So are they willing to take their investment and do they re-architect their applications or just as it is migrations? Yeah, that's a great question. So there's not a whole lot of re-architecting that we have to do. We're an NTR web application primarily already. We already put our instances behind load balancers. So we already expect that nodes will fail. For us, the re-architecting was really around tooling. So we used a desired state configuration which had some requirements inside of the .NET version that we're using. So it really wasn't a huge, or hasn't been so far, a huge lift in terms of re-architecting the application, but maybe just validating that newer technologies still work with the existing code base. So if you're doing access migrations, what kind of tools are used to convert from the existing platform to the open stack platform? Because the IPvases are different. Data formats are different. Yeah, so we don't actually do a conversion. We don't take the existing VMs and migrate. We won't talk too much about it today. We do want to talk more in the future about how we've built our Pazlairs. We've built our own. But maybe just from a high level, we're not going to do a conversion. We're going to take those applications and employ them new to cloud infrastructure. So I'm trying to think, what is the compelling driver for the application team to come here to this platform if they are not going to get any capabilities from the platform perspective for their applications? Yeah, so for us, what we sold to them is platform as a service. So we built our own Paz, and now they have complete control of the infrastructure. So when they deploy their code, they have push button integration with CI-CD. They also have push button integration for push to production. So they don't have a big orchestration between IT operations, project management, and delivery, and software delivery. They own their application, and they have the ability to do everything they need to do to support the application. Thank you. Did you have to write a business case for this? We did, although it was a little less formal. So what we did was we did a cost-benefit analysis. So we said, here's the amount of time that we're spending today supporting the infrastructure. And we've got pretty good metrics around that. We tracked through tickets, how long people spend on particular items, and we said, if we didn't have to support this, here's how much we would save. And even beyond that, there are some soft costs that we can gain by decoupling big bang releases and going to more of a componentized model that make the business a little bit more agile. Did you consider developer productivity in that? It was number one. Yeah. Although we called it developer enablements, I thought the keynote was very interesting. I also don't believe my developers are unproductive, but we want to enable them to do their jobs better. OK. And do you have any metrics that you've been tracking in terms of cloud adoption? We will. So as I mentioned, our story is not complete yet, but we have a dashboard that we've put together that tracks, basically, we have scrum teams. How many scrum teams have adopted and what phase of adoption they are. And have you done a survey of any of the cloud users to get informal feedback from them? Yeah. And it's actually more formalized. So we meet frequently with our pilot users, and they're giving us really great feedback about not just documentation, but things they would like to see built into the platform and workflows they'd like to see. That's a really good talk. Are you going to say no to puppies? I was curious what your puppy strategy is. And did you involve, two questions, I guess, and did you involve the early to get stakeholders and buy-in, the security side of the house? Yeah. As you can imagine, American Express were very security conscious. They've been involved at every step of the way and validating the way that we're laying things out. Compliance as well. We want to make sure that we're both secure and compliant. Your other question around pets versus cattle, we are bought in very heavily to the cattle idea. There are going to be some piece of infrastructure, which are pets. We hope that that's as close to zero as possible. We're sort of in a unique position because we focus on product that we've developed in our environment. So fewer off-the-shelf applications, which we may not have control over. You mentioned that you had problems trying to adapt existing technologies like storage into the open stack. Was the issue that you were trying to be co-resident with existing workloads? Or was it just the technology and an array was the wrong fit for your thing, but you had total control of the array? It's actually both, right, and really good points on both. One is sharing is difficult. Open stack likes to own everything that you give a control of. But two, when we started out, we said, look, it's not enough to just automate existing processes. We don't want to just automate a process that takes two weeks. We want to rethink the process and say, what's the right way of doing things in this environment? And that was more of the driver for it. Be one thing to automate every little step that a storage admin does. But if an app owner really only cares about data persistence, there may be a better way to solve it. So you've gone down the direction of having a greenfield deployment, as opposed to trying to mold it around what you're currently doing. Do you have a set out plan on how you're gonna deprecate the legacy environment to avoid having, basically, supporting two long-term environments? Yeah, great question. So I'm actually responsible for both environments. So it's very near and dear to my heart that we do have a migration strategy. So first and foremost, we're working with the scrum teams to get adoption onto the cloud. As we get all of the scrum teams migrated over, we're gonna look at those applications which maybe are commercial off the shelf that we may not have the ability to modify. Hopefully, we can migrate those as well. And are you looking at using internal chargeback cost as a motivator or, I mean, what's your motivator? Are you just getting technology buy-in or are you using a whip as well? That's right. Yeah, a carrot and a stick. So the carrot is you get all these benefits of the Paz layer that we're gonna give you. The stick, it's sort of a soft stick. We're gonna show back. So we're gonna say here's how much your infrastructure costs. We've done a lot of work around a cost model internally. So we try to build everything we can into it, maybe the cost of cables and patch panels and things like that goes into the cost of a virtual machine. And if I can just be, I have one more question. Can you talk a little bit about some of the issues you may have had integrating with the existing enterprise legacy heavyweight authorization authentication problems? Because I imagine you're not totally green-fielding that. And I imagine I would think that AMEX would have quite mature role control already. Yeah, to a degree we are though. Part of this as well was developing a set of tooling which allows us to manage our infrastructure in a more lights out capacity. In our environment, sort of a bad word to say you're gonna SSH or RDP into a box and do something to it. We want you to use the enterprise tooling. That's our back and that's integrated with existing AD. But we didn't necessarily have to integrate the underlying VMs with things like AD in all cases. In some cases they are, but in some cases we're gonna say, look, you just don't have the ability to log in. Thank you. So did you go through a vendor selection process for a new hardware? Or do you work with existing vendors? And what did you use for your OpenStack deployment? Yeah, we did go through a vendor selection. We've got a couple of large name vendors. We also went with some smaller name vendors. The idea was we wanted to drive down costs because we're bought into the cattle model. We really view infrastructure as a commodity. So if we're talking about a commodity, then I'm really talking about my vendors competing with me solely on cost. It took some convincing on our part to get them to understand that we don't care if a box fails and that's okay. They wanted high end raid guards and things like that. Not position to share exactly which vendors we leverage. In a future talk, we will talk through some of those things I imagine. But we did focus mostly on cost and we knew that we were giving up reliability at an individual component level to some degree. We solved that in other ways though. So you mentioned your network team a couple of times. How do they feel about these new products coming in? You know what's funny? I pick on them because traditionally they're sort of the stodgy old guys, right? That maybe push back a lot. They've been really ardent supporters of what we're trying to do and have really bought into a lot of the things. And they've come to me with, hey, wouldn't it be cool if we could do this? So they're adding things to our backlog as well. Is there one more question? Yeah, so you said that you don't care if things fail. So that requires a new way of architecting applications. How ready was your development team to undertake that new age cloud native design and how they're doing that? Yeah, so one of the benefits we have, the division I'm a part of, we're about six or seven years old. So we don't have all of the legacy applications that haven't been thought through Web 2.0. Today, our existing applications already route around failure by having a load balancer out front. So individual nodes can fail and we don't have a major outage. So there wasn't a huge lift for us. I don't have, like I mentioned, we don't have a huge legacy backlog of applications that are 10 years old that we had to support. So things like concepts like stateless applications and things like that are baked in already. They are stateless as much as possible. Where we need to have shared session state, it should be in something that's a clustered Redis, things like that. Can I just trigger the totally unrelated question? How about disaster recovery? Is this production or is this pre-production development stuff? Right now we're in a pilot. It will be production. So we do plan on running our production workload off of this. We view disaster recovery a little bit differently. We follow sort of the availability zone and region model that Amazon has. So we don't recover VMs in DR. We run those VMs all the time in a second region. So then it's a matter of routing traffic. All right, any other questions? Well, thank you for your time today. I appreciate it. Hopefully this was a good use of your time.