 I'm gonna ask each one of you. So the challenge that you had, whether it was getting into the technology, it was a culture change, walk us through just for a minute or so, two minutes. How do you start that change? Because we've heard about, I've got to get executive buy-in, but some of this is there is no white paper written, there is no best practice. Talk a little bit about how you went through that challenge of saying like, how are we gonna take on managing the kitchen, if you will? Well, we have an ecosystem for almost four years, and we started very early to put that onto containerized or to Docker containers. But what we felt about that was that we, it's strictly on AWS and we have, it's not that scaling as we like to have that. And we are looking for a different solution for that, and how to make that better. And then we'll look at several solutions, of course, in the market. But in the end, we came to the conclusion that with Kubernetes or in the platform OpenShift, of course, it was much easier to get into that stage where we can have, I heard that today a lot of times to have that dev ops approach. What was very important for us to have the developers in the responsibility of their own applications. And that was what we are lacking for the current solution and what we have to want to have for the new solution. And that's what we can do actually with OpenShift and at its best. And that was for us, the main reason to go that way. Okay, great. Yeah, jump in. I think that the technology such as OpenShift enable the possibility to make real dev ops. But the change is in a role. And if, in a role of each department of a company, have to work, sorry. It's okay. A mentality, a mentality change for use of this technology that permit this transformation. But transformation is in mind, not in technology. Technology actually is mature for creating easy tasks, easy pipelines, easy ICD deployment. But the business must invest on this type of approach. Yeah, yeah. I'm gonna ask Ken and Sphere, sort of a variation on that. So Ken, you're dealing with Black Friday transactions, which for some parents buying gifts feels like a life or death thing. If you don't get the right thing, Sphere, you're actually dealing with life and death stuff. How do you convince your team, your management that some new technology is the right way to go when you know that's the risk that you're kind of balancing it against? Walk us through a little bit of that thought process of how do we make this work? So for us, we actually had a little bit of a perfect storm. To make business decisions cost is usually the driver. And to build highly reliable systems is extremely expensive. And one of the things that I was faced with as the chief architect was to reduce the cost per transaction. Because as we scaled the solution and more and more tenants were coming on board, the cost of the transaction was impacting us. And so to get the same, what we call non-functional requirements, the same availability model with containers was actually a lot easier to do than with traditional infrastructure. And we have a geo-distributed platform. So we have data centers throughout the world and being able to run multiple OpenShift clusters and be able to scale up multiple container instances and be able to kill any one of them at any point in time and not have it even phase the system was pretty compelling. And then to show that we could do all of that and lay this infrastructure out at an order of magnitude less cost was the business justification that we needed to be able to pull the trigger on it. That coupled with the company driving towards an agile model and DevOps coming into being all of those things kind of blended together to create a perfect storm. But it was really unique in that this wasn't an initiative that was driven by operations. It was an initiative driven by architecture to try to reduce the cost of running the service. And so we kind of dragged operations along. But once they started working with the platform they haven't looked back, they're very happy. Yeah, and is that done in a combination of a bunch of spreadsheets to talk to the fans house but also a bunch of demonstrations and POCs? Yeah, when we initially proposed it we have this thing at ACI called the Technical Review Board and you can bring any innovation idea to it and get funding, it's kind of like that TV show where you present your idea and you try to get money for it. I'm not sure if people are familiar with it, but and so it was originally pitched as a POC. We got some small funding to go off and do the POC because some people were concerned that it wouldn't scale because the other platform was written in C++ on Solaris and everyone thought that that's the highest performing environment in the world. And how could we build microservices on Java and have it perform as well? And so we did the POC and showed that through the scalability of the platform we could easily surpass what the capability was of the original platform. Yeah, that's fair. Yeah, we mainly just told management that a technology stack from Red Hat could solve the GDPR problems. Then we were home safe. So somebody told you there's just no way to kill a Linux machine and you took that as a challenge? That's part of the truth. But what we actually did was telling them that actually GDPR is a huge load in business processes documenting a lot of stuff. And since we're working in three different SBUs, we need sort of bridging those in a new digital era if you want. And they could see that we need to change from the legacy systems that we're running. We have three different case handling systems and I think the newest one is actually mainly built by Indians before they got structured. The first automation that had was an Indian guy sitting in India and pushing a button and then it was automated. That's not compliance. And it seems like the business could see this demand for new technology and stuff. So we made a couple of PUCs, invited the right people, some of the developers, and they got a Red Hat and saw some new toolbox and they won immediately. So it was more the culture chains that would be the issue. We saw that immediately. And the first problem was actually our general management because they were used to just going into the IT department, demanding whatever needs they had, but suddenly the process is changing. Now they need to document a lot of stuff, especially according to GDPR, before we can actually start the development. I think that was probably the biggest driver to make the change and actually to establish this bi-model setup. Second chance, anybody got a question? Oh, gentlemen in the back. Joe, you got it? I'll get it. We'll run around. What you got? Hi. So my question is for those that are doing micro-services development or cloud-native development, which kind of goes hand-in-hand with the container platforms, how did you guys train and enable your app teams to make sure that they're doing it the right way as opposed to just developing, let's say, the old-style big monolithic apps and just dumping it on OpenShift? I could start saying that we started out hiring a team from Red Hat and they are still onboarded, half of them. We are hiring in developers and making sort of training on the job how to do it. We have a complete dev-op team from Red Hat helping us out, getting the right culture, the right perspectives. They have been helping us with architecture, everything, since we only knew about Microsoft service. So that's how we did it. Maybe I can add something here. We're at Forvec. We are a company of playing people, playing maybe children, maybe playing children. And if you get a new toy, then the developers are allowed to play with that. And at the moment we are at that stadium so that they can play around with a test cluster. But of course we have to also be GDPR compliant and we have a lot of quality assurance. And we are currently building a framework for OpenShift to have a central point of checking compliance, checking security and so on. And that will be in future, will be introduced. And then of course the children cannot play anymore in that way. So they have some direction where they can go and some direction where they can't go. And that's the way we are currently doing that. Yeah. We spun the environment up by doing some initial training. It was almost like a grassroots organization at ACI. We started by presenting to the Technical Leadership Council the concept of microservices and how to build them. Then we created small development teams that started working and building microservices. And then we actually expanded them into the Docker realm after they were already working with microservices. So we didn't start out of the gate just building on Docker. We started out of the gate trying to build microservices that was stateless in nature. And then it evolved so that each team picked up one Docker expert and it would just kind of picked up steam from there. The unfortunate thing in all honesty is that when you self-learn like that, you pick up bad habits. And when knowledge is not available, you try to figure out ways to work around the knowledge gaps and then you apply things into the environment that are not necessarily best practices. And so now we're in a little bit of a backpedal and we're trying to fix some of our earlier sins where we made compensations for lack of knowledge and we're revising things now so it'll be an even better environment. Okay. I say to you to our experience on the deploy and create a microservice application. Last year we chose the platform and we integrated in our ecosystem. And later we choose one of big application, internal application, all the application with more and more features with a big year to deploy on different application server. And with application team and work together we try to integrate the first pillar of microservice 12-factor and begin together to separate and extract functionality from main application. We create a duality with all the application in applications server layer and in a new application written with some principle of microservice. And we manage duality and we develop main feature such as landing page or payment service. And with a month of developer together we can move the customer from the old legacy application to a new application and new infrastructure benefits of modern CICD deployment pipeline with a good server with hard Jenkins integrated in our change management application. But I think that the microservice way is a very training of a job work. Today in our company we have a main table composed by operator team but many architect and many application team who debate the best way to realize the right pattern for internal application for give to other fabric application this pattern for make an internal library to program in easy way a new application written in with microservice way. But this is a training of a job that is not an agile approach I think. You know gentlemen for time I think we're going to wrap it up with that. We appreciate the input folks I appreciate the question just for the lack for the set of time we're going to bring up some of the PMs so we can kind of do and ask me anything and then we can get to kind of stretching and getting out having a beer having a drink talking with some people. So gentlemen thank you very much for the time tonight.