 All right, welcome everyone. Thank you very much for attending this session. We're gonna have a very good panel discussion here with some experts from industry-leading companies that are gonna share insights about organizational best practices for cloud adoption. So I'd like to welcome on stage, first of all, Mark Williams, who before joining Redapt was the CTO of Infrastructure at Zynga and led their, basically, their public cloud and their private cloud build-outs. I'd like to introduce Mariano Cunetti, who is the CTO at ENTER, an Italian service provider that's built a three-data center open-stack public cloud. I'd like to introduce Ariel, who before joining ScaleVP as an investor, so he's our money guy, was a director of engineering at Netflix and built the very famous Netflix OSS tooling for that Netflix used to adopt cloud. And then I'd like to introduce Ian, who is the CEO and founder of CloudOps and let's give them a round of applause to welcome them. All right, so just to kick it off, I would like to ask the audience a couple of questions just to get a feel for what the breakdown is. If you're from IT, can you raise your hand right now? And if you consider yourself more of an application developer or non-IT, would you raise your hand? All right, so a little bit less, but mostly IT, awesome. So let's kick it off with a couple of kind of a nectodes, a couple of things to break the ice. So how about we, do you guys have any interesting stories of things that you've seen in CloudAdoption that were really not cloud, some fun stories to tell there? Mark or Ian? CloudAdoption, excuse me, CloudAdoption that hasn't been cloud, a lot of the customers that I'm helping out there, excuse me, I don't know what's wrong with my voice. That's better. A lot of the customers I've kind of helped engage and express their vision for their future of cloud have wanted to stick to so many proprietary technologies that might be on that list of what is considered supported by the orchestration software that they're taking a look at. But inevitably what happens is it becomes so unique and custom and un-upgradable over the long term that it ends up not being a cloud. So what I try to educate such customers on is really the value of having kind of a utilitarian version of cloud that is very simple. Just coming from an operations experience, getting that phone call in the middle of the night when something is broken, the value of keeping things very simple, eliminating potential points of failure is super valuable. So having all that custom complexity stuff is where I think you have a lot of risks in that form of it. Ian, any fun stories of Safi? Yeah, I guess I think what we've seen is, since the topic's barriers of cloud adoption, we're seeing a lot of cloud adoption, but we're seeing a lot of very, we're seeing a lot of cloud adoption sort of echo what Mark's point was that is fundamentally not changing the way people work or changing the processes people are using. So they're adopting the technology, but you don't have the cultural change. DevOps is a great example, sort of an aspirational way of working with cloud, but also on the process side, we see a ton of problems. When we go in with a lot of customers, they'll have very, very strange deployments on Amazon or even internally that are fundamentally explained by how they procure services and how they manage them. So they'll do things like adopt cloud, but you're not allowed to sort of dynamically spin up and destroy instances. They have some really slow, ITIL change management process with lots of approvals that are required. So obviously that's a really big problem. Then on the flip side, sort of in the enterprise data center, we see things like people trying to deploy open stack or Hadoop clusters on blade servers and IBM sands, which is just, I mean, aside from, in many cases, defeating the purpose also leads to all kinds of really awkward operational issues. So yeah, there's a lot of cloud adoption. I don't think there's a lot of barriers to cloud adoption, which is actually leading to the problem of people adopting cloud very poorly. So on the topic of cultural change, go ahead. Let me add just one quick thing which is funny because I just heard this over lunch today when I was sitting down. And this was one company that we're all familiar with that I won't repeat the name of, but this person was telling me about how they went through this cloud adoption, cloud migration phase and it took a couple of years and they're very unhappy with it. They're very unhappy with the results and now they're thinking about alternatives and when I asked about the details, it turned out that basically what they did was they took their existing legacy applications, their existing architecture and forklifted that and just moved it into the cloud and never scaled up, never scaled down, always used those resources and then they were very unhappy because the cloud cost so much more than what they were paying for in-house. And I think that echoes a lot of the cost concerns and that you hear from people migrating to the cloud and in this particular case, it was a public cloud use case, but you hear this for private cloud as well where unless you're also marrying that migration with rethinking about how to re-architect your applications and your processes to be more cloud native then you're not really in the cloud. Yeah, there's a lot of cloud challenges and disillusion when you move to the cloud because of those processes that might have not changed. So on the topic of cultural change, in your opinion, what are the first things to tackle when you're trying to take a big organization that's using the traditional model and moving that to DevOps type? Well, Mariano. In my expertise, as far as I can see in the Italian market but I think it's the same everywhere, the cloud is a source of stress for organization. I think you laugh, so I think you agree. Every organization is stressed by the concept of cloud. You ask for a story before, I have the story of a guy that I call a nervous guy. He came up and showed up and asking for, okay, we run this large hospital and healthcare application and we want to run it on the cloud. We are building a startup, we want to move it to the cloud. Okay, let's see. Let's see how the application is done and let's see how architecture fits your needs. And then we started to dig into the application and we discovered during a meeting with the project manager, the lead developer and the CEO of the company, we discovered that a lot of stuff was done by, it was a Java and Oracle typical application. Was done inside Oracle and nobody knew what happened inside this Oracle with 700 tables inside. A lot of the application was delegated to the database. So we saw the CEO becoming very, very upset and the project manager becoming very, very uncomfortable. And so in the next meeting, he became always more and more nervous because he understood he had to take up the information and the process that was delegated to an external deposit like Oracle and the people working with Oracle and the consultant and he needed to take it back to the company. He understood he had lost the value of the company which was the process and he had to get it back into the company and in order to go to the cloud and to make an application scale, design a good architecture for databases, for front ends, for middleware, he had to understand how it worked really and so he understood the huge amount of work he had to do and he had to learn a new way to work. That work was an organizational change and increased collaboration, that sort of. Yeah, when you bring up the process, you are half the way you have to go. The second half is to reimplement it in a smart way. If you are running a startup, you are five people, one couple of developers and you want to just translate the legacy application to a new cloud-aware application. There's a lot of work to do once. You cannot afford to do it twice or three times or any time. So the guys are still nervous now. So, yeah, go ahead, Mark. I can kind of speak personally for what my transformation was kind of going through this at Zynga. So early on, before we had really done anything with cloud, I had a very stressful job to ensure that all of the infrastructure was up. I felt like that was my domain. It wasn't necessarily a control issue, but it was a confidence issue that I know how to make this work for my customer who I'm allocating infrastructure for. What became clear to me is as the needs of my customer outpaced my ability to really support them in a manner that was going to drive their business requirements, I found that I needed to be more transparent and in fact more collaborative and providing an education to my customer about what it is that are my pain points, right? So one specific example of this was our two biggest games were literally consuming all of the private data center space and server capacity I had. I was in the middle of doing our second data center. This is before we had done really anything in public cloud yet. And one of the CTOs of a game studio and his SVP wanted to come into my data center. And I'm like, I don't have time for that was my initial reaction, right? Like I know what I'm doing, I can just talk you out of this, right? I need to keep focusing on getting your hardware to you and moving you into this next data center. I had a rational epiphany to go ahead and do this. And what I realized is that their reaction to walking through this data center and seeing empty spaces in all the racks was a natural conclusion of well, why can't you just put more servers in there? Like that they don't really have an appreciation for what these challenges are in real infrastructure. And so it was great to educate them so that they really helped me think through, well, how can we do this differently? How can we make this easier for me? And so through that transparency and really collaborating, we were able to kind of take those next steps and accelerate how we did this in successive investments and later investments in how we did cloud. Ariel, were there any changes in relationships between application developers and IT and Netflix? Yeah, yeah, quite a bit. So I think there were really kind of two key things that we did at Netflix as part of the cloud migration that in hindsight made it successful. And I think are really two key ingredients for anyone doing it. And so kind of painting the picture of what it was like before we moved into the cloud, we were very traditional IT organization. We had an IT operations team that was responsible for managing and maintaining the site. And then we had a product team that was building all of the software. And every six weeks it would get on a train and a release train, or not six weeks, two weeks, it would get on a release train and get deployed by IT ops into the production environment. And then whenever someone checked in some bad code or there was a problem with the deployment, the whole train stopped. Everybody got on board, figured out what was wrong and then it got through again. So part of the cloud migration was really rethinking the application architecture and moving from this monolithic large job application into large scale distributed service oriented architecture that was all centered around this notion of microservices and very, very small units of logic that would be able to scale up and scale down on their own and have very relatively limited blast radius for failures. So that was one key of moving to the cloud. It wasn't simply, well, let's replace the infrastructure. It was let's rework the whole application and really take advantage of this new compute platform that we have, which is the cloud. That, by the way, is based on an unreliable set of resources. And even though you might think that you have a reliable set of resources in the data center, they're equally unreliable. So that was another really important design assumption that we had. The second part of that migration was really tearing apart that wall between IT operations and the product team. And in fact, we actually did away with the entire IT operations. I shouldn't say did away with, but we refocused their work on supporting all of the corporate systems and all of the customer facing systems were now moved into the product, the engineering group. And so every single engineer that was building code that was building software to be eventually deployed into the production environment was now responsible for deploying that code into the production environment and was now also responsible for getting that call at three o'clock in the morning on a Sunday night if their piece of code was somehow causing a problem. And so you'd be amazed at how quickly that aligns the incentives for making sure that your code is well tested and that you have kind of all the operational assumptions that you need in order to run your service effectively at the development phase and not found later by an IT operations team that feels like they've been handed this hot potato that they have to maintain. So I think those are really two of the really key factors for making that call migration successful. One was re-architecting the application to be in a cloud native. And the second one was eliminating that gap between IT operations and development and really collapsing that all into a single function. On the topic of that gap, what's the biggest reluctance? Like where did you see the most reluctance and the most difficulty in getting people to change as opposed to getting systems to change? Ian, if you wanna tackle that or Mark? Oh, I was just actually just gonna add, you know, there's certainly with a number of our customers a huge amount of reluctance that I suspect at Zynga Netflix was a little bit easier to resolve because Netflix and Zynga are, you know, both online business models where the profit center, basically the line of business is highly aligned with the technologists in the organization. A lot of the large enterprises even if they've got a significant investment in software development, we're working with one that has 260 applications that they're developing. They in fact do have aspects of the line of business that are completely online businesses but there's a massive battle being waged and it basically comes down to, you know, a CTO who's got a group of developers who are charged with sort of driving the innovation and ultimately contributing to the success of the business and are much more profit centric sort of aligned and then you've got a CIO and a very large IT group who ultimately, like right from the top are organized around managing a, you know, large budgets which are committed to significantly in advance and the CIO is compensated not based upon necessarily supporting sort of increased rates of change and innovation but in fact based upon, you know, cutting 5% off the budget. So there's, I think, so a lot of the larger organizations we're working with, the biggest barrier really starts at the top with how those executives are compensated and how they collaborate. And in this particular case, what's interesting is we're helping them with an OpenStack project right now but it's unfortunately what's happened is sort of the, and we've worked for both sides of the fence which is also rather interesting. Like we've done work for the IT guys, we sort of, you know, did a cloud strategy, did a cloud architecture for them but then they ran into sort of these procurement politics and like, all right, well, how do we take the cloud ops architecture and then make that real with our existing suppliers and our existing budget and just basically ground to a halt. And then we continue to work with the sort of more innovation side of the fence and to date they've really just been adopting Amazon but they basically got to a point where it's just too costly and they want to do a significant chunk of their development on in-house infrastructure and so we've been contracted to go in there and help them with an OpenStack cloud. But this is all happening, I'd characterize it as a bit of a sort of a Skunkworks project. So it doesn't really have the support of the executive level, they're aware of it but they're sort of like, well, let's see what the CTO and the developers are able to do over here with some, you know, on a shoestring budget. So it doesn't really have a, I'd argue the characteristics of constructive cloud adoption. Mark, you have a lovely experience as an integrator for very large organizations. Can I answer your first question? Because at first you stumped me because like, wow at Zynga we really didn't have a reluctance to do things in a more modern way but what I have actually seen being in the system integrator role. Spill it out. That I've seen it not only at the executive alignment level but in fact the first week on the job at Redapt I was participating in a cloud workshop where we're discovering well what is it that your workloads need to do to be cloud enabled and how do we help you do that? And the customer had initiated this plan from one individual in a leadership position but not really socialized it with his team that he was taking a new course to do this cloud natively. And his team was white knuckled on exactly the way they've been doing it. We're gonna stick with our blade servers. We're gonna stick with our, you know, very proprietary networking topologies. We're gonna stick with VLANs. We're gonna, you know, and it was very awkward to be in this meeting educating them and trying to suss out detail about how to build a cloud for this team that did not wanna build a cloud. And I've since seen in some of our customer space there's some acquisition going on where we've built native clouds for them and then an acquiring company will come in and these white knuckled guys are coming in and they're kicking the cloud out. Like because they are so fixated on the traditional historical ways they've been doing it. So in the face of that reluctance what did you guys do? Well in a sense of an acquisition if the acquiring company is leading that we're not really being asked to impact that unfortunately. So what we are hoping and unfortunately the acquiring company has been losing the employees that have paved this new way trying all the while to educate above like this is the value of it. We are a smaller team kind of ratio to infrastructure wise than what the acquiring company is doing for the same effective capacity management and it's not resonating. So we're not in a great position because our relationship has been with the acquiree rather than the acquirer. Yeah. I wanna just make a comment about the previous comment that Ian made which I think is a very good one that centralized IT has been its policies I think have been one of the things that have driven a lot of public cloud adoption to date which is that you started to see this you know what's being termed shadow IT where all of the business users and the technical application developers are taking it on themselves to create the mechanisms that they need in order to innovate quickly and they're being successful at it and they're being rewarded at the business level and they're getting support from their executive teams for it and they're able to out compete their industry competitors. And so what you're seeing now is all of these different shadow IT springing up in different organizations and I think the CIOs are starting to realize that what they need to do is to start enabling that and to start being more of a service provider to the rest of the organization rather than the control and the gatekeepers. And so you know at least from what I've seen from the more innovative IT organizations they're shifting towards thinking about how they can enable their application users and their functional business units to take advantage of some of these new technologies in order to be more agile in order to be more innovative rather than trying to always play the cost argument or the security argument or the control argument. And I think that's a very positive thing for the overall industry. So it seems like the dot coms and the online businesses tend to have it a little bit easier with cloud than more regulated industries. What would be your recommendations if say a large healthcare provider wanted to make a big step or a bank wanted to make a big step into a cloud? What sort of change would need to happen there? So I think most of the web 2.0s, the gaming companies have had the luxury of no legacy, right? So that's why there was really no resistance to adopting a new method. But having worked with a lot of more enterprises and more risk averse companies, trying to boil the ocean with one massive overhaul is not an approach that is ever going to work. Getting whomever is in the company that is starting this skunkworks or hopefully a top down directive to go this direction always encourage them to start small, find your earliest, your best candidate as your internal customer that can be your early adopter and can co-avangilizing, co-develop what those requirements for that cloud are once you've successfully, and then here's another thing I actually really did experience. Once I built a private cloud and having a company that was 85% dependent on a public cloud at the time, nobody wanted to move in. Everybody was warm and fuzzy and they're a little, so how do you get your first customer in there, right? So this ties into the same thing I educate customers on is you need to find that willing participant, that early adopter who can help influence the design of the cloud and adoption of that cloud and then become your evangelist internally to spread the word of how much better it was. And in my case, I was fortunate to have built the right thing because we collaborated on it and it was a richer performance experience. It was a, it wasn't painless to move people but it was certainly kind of, in the end of the day, it was less expensive for them on a cost per unit basis. We were doing charge back so there was that increased the ability to encourage more adoption later. Having the internal adopter who was evangelizing, we had our own evangelist as well and educating. You need to educate as well. And then ultimately having that financial influencer to have a third of the cost per unit available on a private cloud charge back versus less performance and higher price per unit for a public cloud. Yeah. Generally the way we start with a large enterprise and usually pretty carefully because we're a small company is with an inventory of their application. So we'll, the company I was talking about before, they got about 260 applications. Only about 40 of them were cloud suitable. And then we further went and did an analysis on as to whether they're public cloud suitable or private cloud. So I think that's a very important step is that inventory of the workloads and taking a really hard and honest look about how, because there are folks out there, they're application product owners who are maybe a little bit over confident in the abilities of their application. So we typically with a large organization take a very conservative approach and sort of go for those early adopters, those, the lower hang fruit because you got to show those success stories. And then that sort of, those become the sort of business cases and proof points to drive the rest. And those tend to be like mobile development, like mobile applications, like the new wave of applications in the regulated industries that tend to be those early adopters for public and private cloud. Mariano? Yeah, but regarding the large enterprises I've been to, I have two examples for Italian companies. I've met Pirelli, which is a tire company, and Ducati, which is the motorbike company. And it's very strange how you look at large companies from outside. You would think that Ducati is a very red oriented and very passionate company, very innovative. And you would think that the tire company, typical tire company is tiring. And instead we found, I had this meeting with the media marketing manager in Ducati and I had this conversation. It was very informal and he had this poster behind him. I could not stop laughing because the poster was, I love milk and all the time, this thing. And it was unbelievable. And we understood that they approached the cloud very early with Amazon and there were already shrinking the domain of the private and I can say, I can say the valuable information, they were shrinking the domain within SAP inside the company and they were setting up some gateways to take this information out and in just to protect the valuable data to design such an anone around this internally and externally. So they were almost ready and open minded to go to the cloud. On the opposite, we went to Ducati and we discovered that since the main sponsor for Ducati is Telecom Italia, which is the main telecom operator in Italy. They were, they could not buy from any others from them, but Telecom Italia like any other tech companies very far from understand and just to build and to sell the cloud. And so they have this weird situation by which they had to order VMs via Fox and yes, they do. They send a Fox and they get the VM in at least 30 days. That's the Ducati. So you write your API call on the fax machine? Yeah, that's it, that's it. So we've been hearing a lot about when you take these like IT and application developers and you make these blended DevOps type teams, then making sure that accountability is still held somewhere, people are still responsible. And how would you manage blame when you've got these teams that are, go for it. Well, the first thought was, I know Ariel mentioned this earlier, like developers need pager duty. So once there's a mutual understanding of what that pain is, it changes behavior. The other one is, again, this is where I had initial resistance and as a part of my personal evolution into cloud two is I used to track availability, right? And I cared about what I could control. So I had an availability number on network infrastructure and server infrastructure, et cetera. So as we matured in purely mutual kind of collaboration around DevOps and application ops and infrastructure ops, there was a suggestion to essentially have one number for availability for the entire company that counted everything, including services we had nobody in the company had control over. So Zynga being very Facebook dependent, if the Facebook API went down, our games would generally go down. And there was a suggestion to our availability number should count everything. And what finally got me around is recognizing that the value of having that one number helps rally everybody around agreeing that that is what the number, that is the user experience for what we are providing to the world. So it is the most representative. Yes, certainly having that data is critical because if you can't measure it, you can't fix it. And so knowing why each outage mattered or contributed was valuable to help focus that. So did you put a dollar amount next to an every outage? Oh, yes. Definitely. But getting the culture kind of rallied around that. And also aligned very well to organizational MBOs. So quarterly, we would have to set out as a purely infrastructure team, I had to have to commit to a total availability number for all of the games. As uncomfortable as that was, it drove all of the right behavior. Our collaboration with our peer group who did the outage, my team in terms of, hey, network guys, I don't care if you have five nines of network availability, but you need to be transparent with what your hardware is doing so that when the appop guys have a suspected problem and they don't know what it is that they know I can eliminate network or I need to focus on network. So getting that, the true transparency of all the different pieces of this infrastructure. So just doing that one very simple thing is really important. So everybody agreeing on the availability number drove a lot of alignment and collaboration. So I think that was a terrible question. And I'll tell you why, because I think the question is, the way you phrase the question is, well, one flawed and two also indicative of exactly how people within organizations ask that same question. And the reason is that you're looking for where to place blame. You're looking for where to place blame. And I think that's the wrong pursuit when you're trying to improve your availability. I think what you need to start with an assumption of trust, that everybody in the company is doing the right thing for the business. And when you have problems that come up, if your perspective is who is the person or team that needs to get blamed, then the way people are going to approach that investigation is how do I defer responsibility for me to the next guy? And that doesn't help you identify what the actual root causes and the actual reasons are for why you're having problems. Is that okay? At the Chef conference this year, we heard a lot of talk about blameless management. Is that what you were referring to? That's exactly, that's a great way of putting it. Ethnathics, for example, each one of our postmortems was really focused around identifying what the reason, and usually not reason, reasons for things not to go the way that we wanted them to go. And then deciding whether, what the reason for that was, and typically it was because it was just resource investment. We decided to invest into moving very quickly, into investing into innovation and not enough into the tooling that we needed in order to get code safely into production or into the right communication between teams or basically what is it that you can do so that something like this won't happen again next time and if your answer to that is, well, we have to be more careful then that's wrong, right? Because everybody's already being as careful as they can be. And so you're assuming that that's the steady state. So I think the way you approach outages, the way you approach your postmortems is gonna be very telling of the kinds of results that you get. And if you approach it from the perspective of which team is responsible for what and who carries the blame when something goes wrong, then you're gonna create a culture of trying to avoid blame because who wants to be blamed for things. But if you look at it from the perspective of we're all trying to improve our availability and the reason we're not where we want to be is because we might not be investing in the right levels in the right things, then it becomes much more of a collaborative exercise in order to how to raise the bar. On the standpoint of the vendor, we are the last step. Always blame the vendor. Always blame the vendor. But our approach is since we have nobody to put the blame on to. We are, we have this approach. We take the blame on us, but we explain what happened. So at the first time, the customer is happy because it has someone to put the blame on too. But answers are starting to coming up from below and they go all the way back to the exact responsible person. So during this time, you see that people start to consider you reliable, more than blamable, and they still put the blame on you, but they get answers, so they trust you. You build the trust by taking the blame and giving answers. Then in time you get less blame and more trust. Yeah, and do you have any experience? Lots of experience with blame. So a lot of the larger organizations we work with are very siloed and they play this blame game constantly. What we've been, where we've seen success with some of the larger organizations is taking, is sort of encouraging them to create sort of small teams that cross these silos, they're focused on very particular, like, identifiable service delivery and business results and having them as a team responsible for making sure that that result is achieved. It's hard to do because, depending on the culture of the organization, but that's where we're seeing results. And there's actually a bit of a movement in the enterprise world towards, I don't know if anybody's heard of intrapreneurship, but there's sort of a whole sort of, there's a bunch of folks running around sort of trying to bring kind of lean methodology and more sort of DevOps style approach to problems in large enterprise. And we're starting to see some success stories there. And I think GE actually hired, like they had their whole organization go through training around that. So, but I think it's still early days, at least for the large organizations. But where I think the small companies have an advantage in terms of adapting and obviously the ones who are already very sort of, already focused on sort of more next generation business models. I'm going to pause you for just a second. We're going to take questions shortly. So if you can line up behind the microphone, we'll take them there, go, sorry. But with the large companies, I mean they're like aircraft carriers that take a while to change direction. So where we're seeing results is if people can sort of carve out a very particular problem, bring together sort of a community of practice around it that hopefully spans a couple of those silos and then be sort of held responsible for achieving a particular business result instead of being responsible for just, making sure that, I don't know. One part stays available. Storage doesn't crash. So we have a couple minutes left. So if you have any questions, feel free to go up to the microphone. Otherwise I'll just continue on. So for cloud adoption, we've heard some cases where there was endorsements at the very highest levels for cloud adoption and there's in other cases where it's very much of a grassroots effort. What do you think is best for an organization to adopt cloud, whether it is best for it to come from below or from the top? Mark always takes the first question. As long as my voice works. So I've seen the Skunkworks grassroots where it can run into a major obstacle is if there isn't strong alignment at least with the technical leadership of a company. So the CTO or VPs of engineering to ensure that you have a customer who is going to be mandated because you can't control engineering from the operation side. You need to ensure that you have alignment and a mandate to ensure that you have customers at the end of the day. So I don't think it's exclusively either. More often than not, I do see kind of the executive leadership trying to influence this because they're the ones paying attention to the marketplace. But they may not have enough bandwidth within the technical organization to actually start educating themselves about what it is to start down this cloud path. That's where executives are ensuring that they have people who are resourced to be able to investigate these things and not just running around doing heroics to keep the existing production up as key. There's an easy road and a hard road. I think the easy road is when you have the top level executive realize that the key to them having greater business agility is to transform the organization into one that takes advantage of elastic compute resources and elastic platforms. And I've seen this firsthand in Netflix since that's very much kind of how it came down. Reid was himself a really big proponent of moving to the cloud. And that just saved us so much time of having to get buy-in, having to kind of have all of those political discussions around where a resource is gonna come from and what's the right approach. We know that this is a key in order for us to be more agile, in order for us to be more innovative, and the question is how and not if. Now, you can also do it with the Skunk Works way. I think it's harder because you're gonna end up coming up having to overcome a lot of impediments and having that high level sponsor, the CTO or a VP of engineering or someone who can at least give you air cover helps with that, but it's certainly a harder road to go down when you're trying to do this in a small individual level than as a broad organization with all the resources and kind of all of the alignment already behind you. Yeah, and of course it helps if you have grassroots that validates the CIO's vision or CTO's vision. All right, thanks everyone for sitting in on this session. We'll be around for the next couple of minutes. So if you have any questions to take to us privately, please feel free to do so. Otherwise, thank you very much and please let's thank the panelists.