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?  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.  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.  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.


If I was to say, hello, thank you for joining me, I'm at Slaveway today, most people will think, well that's interesting, I wonder what we're going to see in today's video, where's he going to take us? But some people would be screaming at their computer saying, no, it's not Slaveway, it's Sloughit, and those people would be absolutely right, so let's start this video again. Hello, thank you for joining me, I'm at Sloughit today, it's spelt Slaveway but it's pronounced Sloughit. I'm at the railway station on the Trans-Pennine route, that's looking towards Manchester, that way it's looking towards Leeds. It's one of those staggered stations and it's one that's been closed and reopened, it closed in 1968 but it reopened in 1982. What we're going to do in today's video, we're going to go and have a look at the Huddersfield Narrow Canal because about three miles that way is Standedge Tunnel, it's the longest canal tunnel in the UK. I'm going to go down into the town centre, walk along the moors, we'll go and find the tunnel and then we'll come back to here along the canal. Let's go and explore. I'm down in Sloughit town centre and this is the Huddersfield Narrow Canal, I'm looking at it here, it looks very much canal-like but have a look in front of us. That's why it's called the Huddersfield Narrow Canal because it is very, very narrow. It's a bit like the canal equivalent of an arrow gauge railway and that's a parking route. There's a lock just there, so what I'm going to do is I'm going to follow the canal this way. Now the canal has been closed and reopened, I'll get on to that more when we're further up the valley. I'll talk about how the canal was built, how it closed and then it was eventually reopened. The bridge up there is the modern bridge because it was eventually reopened in 2001 all the way through and that bridge there was only built in 2000. So it kind of blended in and just existed the town without the canal. In fact I think there was a bit of a controversy here because they had to fill a load of cherry trees to reopen the canal but that's what happens when you close things that you later wish you hadn't closed. So this bridge here, bridge 44 which we can't walk through but that is, if you have a look on the stone, it says 2000. So what I'm going to do now, I'm just coming up to this bridge here which is over a roundabout. So to go under that I'll have to get in the boat which I'm probably not going to do today. Town centre, I'm going to head up that way to get up onto the hills where we get some views down and then we'll come back along the canal. So the canal goes that way towards Standedstunnel. So here we are, I've come above Sloughy, it's pretty windy so I'm shouting. I really hope you can hear me but basically the town of Sloughy is down there. You might just be able to see a train. I was up there where it's really windy and you can hardly hear me. We've come to this little hamlet here and here is the old school. It's a shame really because it's abandoned and derelict but you never know. I'd like to think someone would buy it and convert it into a house. What we're going to do now, we're going to go down a lane or a track called High Insane and we should get a better view of the valley which Huddersfield narrow canal goes up and so does the railway. And then we'll take you back down to Sloughy. This is Hollins Lane now, a typical country lane. Give you an idea of this little hamlet. So I'm just slightly further down Hollins Lane again.  It's windy. The railway runs a little mad and so does the Huddersfield narrow canal. You can see the hill looming ahead, that's what Standedstunnel goes under and that's what we're going to go and have a look at. There's three tunnels or three railway tunnels should I say and one canal tunnel. So when we go up there, the village up there is Marston, we'll be able to see what we can see of them. Just walking past an old farm. One thing I found. If you're out this way and you need to use the toilet, I wouldn't suggest you use this one. It's quite funny that an old toilet's the most. I'm not about to use it but there's a flower pot in there. So yeah, just a bit of an unexpected find. Of course, over there's the valley. You can just see the railway. The train went along. Now you can see it go across. I'm going to continue following this path up towards Marston. Slightly unplanned part of the video. I'm in some abandoned cottages there on the path. There was no fence I was walking. Come upstairs at least stone steps. I'm not going far away from here because as you can see, it's holding the floor. So it's interesting to feature these. Probably these would have been this old farm cottage here. A bit of view across there where the farmer would have lived. This is a stone floor. Come into here. Look at this. It's like an old auger. That's quite exciting. Then go through to here. See the fireplace in the ring. This is a shame really. They're so in the middle of nowhere. How would you get to them? If you come outside, that's the path just down there. I think below. That cottage isn't in quite such good condition. You can see the stairs. Looks like they divided this into two at some point and bricked across. They're still windy out there. Let's go down here back onto the footpath. A few little outbuildings. I reckon they must have kept the animals in these little rooms here. Very small inside. Maybe they didn't. Maybe they're coal storages. Coal storage or something. What's in here? There's another. I don't know perhaps this is where they kept the animals. Looks like a barn. Anyway, I am going to continue down the footpath towards Marston. The wind is still quite strong. This is the B6107. I've come up across the B6107. The village of Marston is down there. I'm going to walk around Marston more. You can see where the reservoir is. This is National Trust Land now. Always nice to go to another National Trust property. I'm going to continue on in this direction. Then we'll make our way down to the village of Marston. I'm now above the town of Marston. You can see the town down there. Stand edge tunnel is that way a little bit. I'm heading this way. There is a reservoir down here. My plan is to follow this path along the edge of the hill. Then I should be able to go down into the town. That way into Marston. We'll have a look around there and then we'll walk up to stand edge tunnel. Right now I'm going to enjoy the view of the countryside and the mills. Here I am. I've come down into Marston now. That's the parish church. I did see the reservoir. I didn't go up to it. It was incredibly windy. I wasn't able to record any footage. I took a couple of pictures. You can see into the reservoir. This bridge takes us over the river Colm. The river Colm is the valley which we've been walking up the side of. The canal and the railway follow back down towards Sloughett. I'm going to go up to station road to the railway station. That's where we'll find the Huddersfield narrow canal. Here I am. I'm at Marston station. This is a funny railway station. You can see there's one platform here. The main platforms are there. The majority of trains passing through here pass through on those platforms. It's a good loop but some passenger trains call here. If you want to catch a train you probably won't ever use this platform. There might be one or two a day to do. If you're a track passenger this is a fairly rare track. The funny thing was I just walked in here and a lady followed me in thinking that I was just catching a train. Then she looked at the dot matrix indicator up there and saw there were no trains due so she left again. She'd have to walk all the way up over the bridge and onto the main part of station. This is the loop platform at Marston. Talking of canals and railways and exciting things we pretty much are back at the Huddersfield narrow canal. You'll almost miss it if you look across there. You can see a pub called the Railway Marston. You might be able to see the Tower of the Paris Church. Well, the canal, believe it or not, is here. Just here, down there. That's the Huddersfield narrow canal. There's something railway to look at up here. If we just walk up here there's a National Trust building which is the old railway good shed. One thing is we'll go and have a look at that and see what there is there because the National Trust as we have already seen in today's walk own quite a lot of the land and look after quite a lot of the land here. There we are. That's the Goods Loop platform. Here is the old railway good shed. I don't know if we can see up here but anything to do with old railways is interesting. When we go up to the standard tunnel I'll show you more, tell you more about what there is. This is basically the office for the area we were having a look at. I'm not entirely sure if we can go in or not but you can see it's an old railway good shed. It looks like it's purely just an office but it's nice that National Trust preserved this piece of old railway good shed. There you go. That's the Marston More good shed building. I'm going to head that way now up to the standard tunnel. I've just come down onto the canal round to the back of that railway good shed. It is just over there. As we head this way towards the end of the walk a few things I want to say about the canal. One is it's called the Hudsville narrow canal. So it's a bit like a narrow gauge railway in canal form. At this point it's fairly usual width of a canal. Two boats could easily pass but it's when we get through the bridges and stuff you can see what I mean by a narrow canal. The funny thing is I say it's like a narrow gauge railway in canal form. The widest boat you can have along here is Seven Foot which ironically is the width of Brunel's broad gauge and then this did join the Hudsville broad canal. So as we come into here we're just right next to the station. You know what I meant to go. When we look down. I was up there. I don't know. So we're coming down here in this narrow narrow bit on a narrow canal. The other thing they've talked about we'll have a look when we get up. There were three tunnels. I'll talk more about tunnels when we get near there or three railway tunnels should I say. One canal tunnel. They talked about four-tracking in an electronic trans-pennyte route and if they did they could have reused those tunnels. Well, where places like Greenfield on the other side of the tunnel I'm not quite sure how they would have fitted four tracks unless they were going to reopen the Mikkelhurst loop which was a loop line which effectively went off this line on the other side of the pennyte or the other side of the tunnel went the other side of the valley. That's probably a video for another day but I just wanted to show you here a lock that's Mars and Station a narrow narrow and deep lock on the Huddersfield narrow canal. I'm going to head that way now up to the Huddersfield tunnel. So here we are walking beside the Huddersfield narrow canal that's the Standedge Tunnel Visitor Centre we're not far from the tunnel now if you have a look here this is the railway line it says canals and rivers trust welcome to Standedge Tunnel if you have a look up there you can just see well should just be able to see the railway tunnel onto the aqueduct which actually carries water well of course it would as an aqueduct what looks like a bridge is carrying water down over the railway line it's from one of the reservoirs to the canal so the canal tunnel opened in 1811 with a help from Thomas Telford but it closed in 1944 but then the Huddersfield narrow canal was restored in 2001 you can here take a pleasure trip into the tunnel to the railway tunnel there's three of them the first one opened in 1848 then the second one single track was also opened in 1871 so two single track tunnels and then finally in 1894 the tunnel we had today was open now if we go along here you can see there's a water side cafe and that's probably where you can get on a boat to go through Standedge Tunnel there's the tunnel so I'm just going to walk well I don't know how far I can actually go on this side I can't go right up to the tunnel I'm going to go as close as I can to show you Standedge Tunnel so this tunnel is on this side I think the railway tunnel actually crosses the canal tunnel underground twice so this tunnel here is the longest, the deepest and highest canal tunnel in the UK of course it's also flat the canal builders did not have the luxury of being able to vary gradients like a railway tunnel would do there's 74 locks on the canal and then this section is flat however I say the railway tunnel had the luxury of not necessarily needing to vary the gradients the railway actually chose to also have a dead level tunnel the reason being it's downhill this way towards Huddersfield the other side is downhill towards Manchester steam locals need water so you either stop for water we take water on the move for a water trough that needs to be level so the one place they had on this whole route where they could have water troughs was inside the tunnel so the tunnel is actually level so both tunnels all tunnels are level we've just got up here and we should see the railway tunnel again so I hope you enjoyed this video I've now got a three and a half mile walk back to sour it along the Huddersfield narrow canal it's been quite exciting I've really enjoyed it from near Standesh Tunnel the railway tunnel and the business center goodbye