 Let's see if the mic is on. Is the mic on? Ah, there you go. And you guys here? Oh, there we go. Like an echo. Hey, so I'm Bill Giard. I'm a Princeton Engineering at Intel. Over the last few years, I've been leading our overall IT app software development. So the perspective you'll hear today really is from a customer or consumer of cloud technologies and really what is our approach is to really engage our app software development team. In Intel IT, we have almost 3,000 or so applications and 1,500 app software developers. And so the journey we'll talk about today really is how we've engaged that development team, tried to move them off of their old way of doing software development and embrace and take advantage of cloud technologies and other efforts. And with me is Brandon Bowling. Hello. I've been working with Bill for quite a few years. So we're excited to share our journey and our experiences in this effort. OK, so from a context, I think really at a high level, you've deployed a cloud architecture. You find that adoption may not be quite what we expected from an IT organization. How do we engage the developer? Really so the conversation today that we want to have is approaches to engaging the app development teams. What are some of the architecture considerations, some of the enabling capabilities? And so it kind of ranges a broad set of topics, and we can leave some time at the end around questions and answers. But fundamentally, our goal is to accelerate adoption of the cloud architecture that we're investing quite heavily in. So before we kind of get into what does it mean to do cloud architecture, the harsh reality, at least in the discussions that we've had, is cloud in and of it by itself isn't a compelling enough driver for most enterprise applications to adopt. They're pursuing multiple efforts. And when combined with embracing improved user experience, security threats, what's going on for analytics, those are all things that all of a sudden become more compelling and address it. It's not a single effort that one application that's a global consumer, you have to address multiple ones. It used to be in IT organizations that if you had more functionality, lower cost, that that would be the selection you did. And what we found over the last few years is that user experience drives more purchasing decisions from our end, our users within their organization. That's quite pervasive. We'll spend more for solutions that work better, even if they may have less functionality. The cloud is real and disruptive. It's really a play for time to market for most developers. From a user, it's pervasive connectivity. So it provides quite an opportunity. Security threats are increasing, and there's really just a lot of things that are going out from a developer's perspective, a business perspective, to understand, hey, how do we adopt and respond to the plethora of things that we're being asked to do? And the developers are taking lots of demands, from management, from the end users. And so we have to now address the demands of the end user who wants to work on any device anywhere, anytime. And then we have to adopt new methodologies and best practices to drive agility and time to market. And in addition, we have now the enterprise has embraced open source. At Intel, that was a long time coming. And while it's exciting, you can't do it blindly either. You have to spend a lot of time to make sure that you embrace open source in a way that protects Intel and our employees. And then finally, social is everywhere. And we have to address that demand as well. You mentioned open source, and it's changed quite a bit. It used to be that most organizations would look at open source around, hey, who's my one vendor to go hold me accountable? But it's really pervasive in almost everything that's happening in solutions. And I think what's exciting for developers, for us, is really the pace in which new capabilities get deployed, the things of advantages that we can deploy from app development perspective, whether it's new libraries, new frameworks, et cetera. So if you put it all together, we've come up with a strategy that tries to integrate different approaches for our app software development teams. Fundamentally, at a high level, move the back end to the cloud. Enable the front end to work securely and with a good experience across any device or platform. The bring-on device phenomenon is really shaping our thoughts around, hey, how do we enable our users almost immediately? It used to be that we would gain speed and efficiencies by standardizing on one platform. And now it's, in fact, slows us down. We have to go refactor that. So embracing some of those open standards and get those solutions moving really is a key point. So back end cloud, a front end multi-platform connected to services. So what does this mean for a program execution? So we went back and forth, and most organizations like to say, hey, go follow a direction and set direction, follow mandates. And the short answer is we try to set goals. We try to say, here's the experiences that our users are expecting. They expect their personal information, their customer information, their design information to be secure. They want it to be intuitive and easy to use. They don't want to go through large sets of training classes. And so we've got some efforts to try to measure usability through some usability studies and some pretty good science behind some usability statuses. Platform work on any platform. Support different device feature sets and new user action models, while fundamentally landing in the cloud. So cloud becomes an enabler for that. And the developer implications are also pretty important for those. So in security, we're uplifting and training our software developments. We want them to follow OWAS security, vulnerability, practices, integrated code scanning, all of the things that are becoming more important from a software development perspective. Design practices around minimal user clicks and interactions. How do you support capabilities for people that may interact with the solution differently? Fundamentally remove any and all OWAS and browser dependencies that you can. Let them run standard on any framework. And then the list goes on. So part of our approach really is to say, here's the measurements of success to enable your solutions to work on any platform. And then flow into how do we enable them, which is an important element. So we want to set goals, not mandates. And then say, hey, if you can achieve them with other areas, how do we help them achieve those goals? And so we'll probably get into next, really, what are the tools and capabilities that we're enabling our own internal development teams to meet these new goals and requirements from an end user perspective, from a technology and industry expectation for our users. And so with that. Right. And just to reiterate that, we didn't achieve this through mandates. And it was end user focused first. Which is an important culture distinction. I think if you mandate to a development team, even if it's the right thing to do, nine times out of 10, we've seen the developers get really creative and try to move around it. So we try to avoid those mandates because it has the opposite effect. Right. So to help enable our developers to do the right thing, we arm them with templates, reusable code assets. We can bundle some of those key functionality into app generators. And then we have supporting websites, where, again, they can get help when needed. They can get metrics on their assets. We can showcase some of the common reusable code assets that we have. And a place where they can go get their questions answered. To really drive all of this home, we developed a website called IT Developer Zone, which the goal of ITDZ was to provide that one stop shop for developers. If you're a developer and need help doing X, you could go to that website and find out how to do X. And we developed that website using all the best practices, using these new processes and methodologies and deploying to the cloud. And then we leveraged that code base as our showcase app to developers that want to see a reference implementation of all of our best practices. Can you talk about at least some of the technologies? I know we went back and forth around, do we use a rich app framework? Do we use standard HTML frameworks? And where do we end up with that showcase in our own learning? So there is no right or wrong answer when you pick frameworks. Depending on your needs, you may pick different frameworks. But for us, from a UI, a web development framework, we've been using Angular for a couple of years. It's worked well for us. No, it's not perfect. But it's important that we picked one framework and then provided style guides. And again, these reusable code assets that we don't mandate developers to use, because we don't like to carry around a big stick. What we'd like to do is have those carrots. And just like the open source community, if you provide tools that developers want and it adds the least friction to get a job done, they're going to use it. And that's what we found. So we've kind of focused on Angular from a UI perspective. And then on the back end, we use Node.js. But if we're doing API development and we want to leverage those same JavaScript skills that we have had to uplift our developers, a lot of them weren't JavaScript experts. So since we invested that time and energy to get them trained up in JavaScript, why not use JavaScript to write our services? So we use currently Sales.js as our framework of choice. Again, it's not mandated that they use that. It's not saying that we won't switch to something else later, but it works for us now. And it's been evolving with the community. I mean, initially, we didn't have a good graphing component. They've added some JavaScript graphing libraries. I think the observation for me is we've made a lot more progress in engaging that development team by enabling them with tools and frameworks versus saying thou shalt use a certain methodology. So I think enabling both through training, best practices, kind of drinking your own champagne as you use those frameworks with the IT developer zone is a good approach for sure. So we talk about enabling the developers. And we also want to make sure our own internal flow hits certain goals. And so we set goals from our own cloud implementations with respect to app development. Certainly, the first and foremost for both the development team and our users is time to market. We've got to increase our pace of delivery for applications. It's almost notorious in most IT shops that I talk to with my peers really is we need to move faster. And so pace and agility, and we'll talk about moving from weeks, days, to hours, minutes, that was important at all levels. Efficiencies and cost, as any cost organization is super concerned about costs and efficiencies, we'll share with you some data around how we've improved our cost and our time to market. And security is super important, and we'll talk about security a bit. So those are really the three key pillars that our IT business organization is pursuing in addition to what our developers and our business stakeholders want to do. So enabling both the business and the developers, I think, is an important element. And so we do that through self-service. Self-service is super important, both from a cloud app platform, database hosting, and compute. It's interesting, a lot of the times that we talk about, even though the developer and the engineer may be in IT and they may work together, they really don't want to talk to each other. I don't know if you want to. I mean, developers, they just want to get their job done. And they would like to get things deployed and have things just work and have things work in development just like it does in tests and preview. And in the past, that hasn't been the smooth transition. And working with the system engineers hasn't always been fun. So having the self-service is extremely important. And bridging them so they're on the same page, both from a cost efficiencies perspective. So self-service, both for development and engineer, I think, is super critical. And enabling self-service at every level. And so really, what does that mean for our platform implementation? So we follow our own guidance much like we have. I mean, we're using Cloud Foundry. We're using some other capabilities and components to enable app developer services. We did find that it's not sufficient just to put it out there and let them adopt it. Hey, we've got it available. Why aren't people using it? And so there's more work that we had to do to just bring that home. UI interfaces, we mentioned the training and the developer. It's running on a stack. And the picture you see up on the self-server portal really bridges some additional things. We made it even more easy to use from our development teams. And it happens to run on the same app framework that we were proposing. Enabling analytics, message queuing. We've done some additional work to auto logging service and analytics for usage so that we can understand if solutions are being adopted. Integration with single sign-on experience is something we'll talk about in a minute. It was a super big issue for us, our users, from an expectation. But really, we do fundamentally understand that enabling self-service wrap development is important. Right. And it's not good enough just to have a command line interface. While many developers love to use that, when you have over 1,000 developers, you're going to have all types. And so providing multiple ways to interact with the cloud to get their apps deployed is key to the success of cloud. And conversely, we would say if you had only a UI interface, that would meet some of your more aggressive DevOps continuous integration teams. And so both of those are important. And I think the transformation, at least we've seen, we've got developers with 1,500 app software developers in our own organization. They're in different stages. Some of them are doing large-scale ERP implementations. They've been using a certain technology. Some are doing web apps for a long time, but they're really tightly coupled web apps. And so those are app capabilities that moving them over to some of these new modern frameworks is a journey. And so you've got to understand where you're having those conversations. They're super sharp in their field, but not necessarily using the modern technologies. Maybe a complete Microsoft shop using Visual Studio. Some using Eclipse and other frameworks and approaching them and engaging them where they're at, giving them multiple options to go pursue. And so speaking of the traditional way of building apps, like most good developers, we've been conceptually layering our application architecture for a long time. I mean, the 15-plus years I've been at Intel, for the most part, we have a UI layer. We have a back-end layer. And then we have our data layer. However, we haven't done such a good job of keeping those separate when we deploy them. It's just too easy when you're dealing with one technology that you can just deploy it as one application, which has been OK. But that's kind of shielded us from some of the issues that we're going to cover in the next few slides. And now we still have our layers, but we're deploying them separately. And yes, we're using the cloud. But if we would have been doing proper three-tier development for the last 10 years, then maybe we wouldn't have been so surprised when we saw some of these issues that we're going to cover. There's a couple of dynamics, at least in the software development ecosystem, that is helping us along. We've been pushing service-oriented architecture, multi-layer design, stateless architectures for a long time. And for the most part, they've done the job. Like I said, it's easy to cheat. Hey, I got to cut corners. I'm going to go put some presentation logic inside of my service. And all of a sudden, you find yourselves in an area that gets you into trouble. The nice thing is both the cloud architectures kind of force some of the stateless transaction a little bit more, which is good. The app frameworks themselves allow you to go and enforce these types of architectures. And so we're getting a lot more adherence. We used to go through the architecture governance and say, are you doing x, y, or z? By promoting some of the frameworks in the right way, we've been able to accelerate a lot of those things that we've been pushing for quite some time. So because we've mentioned that one of the driving forces of some of the changes that we're doing is we need to support multi-platform. So we decided that we were going to, from a UI perspective, when we're developing our web applications, we were going to leverage standards like HTML5, CSS, and JavaScript. And we weren't going to use our proprietary technologies and build solutions that get rendered on the server and then just the HTML push to the browser, which has shielded us from things like cores. If you're a developer, you've more than likely heard about cores. But if a browser is making a request to a service that you don't own that's not on the same domain as the application running, you're going to run into a cores issue if the service that you're calling isn't cores enabled. And when you're dealing with a large enterprise, you have lots of legacy systems that are not cores enabled. Or because you weren't aware of this before, because you were doing everything in .NET. And so those service calls were happening on the server and not through the browser, then you might not have seen this. And this is an easy thing to address, but it was pervasive. I mean, it was stopping developers because they were like, what does this mean? And then when you don't control a service and you can't cores enable the service, which is easy, usually just a configuration setting, if you're dealing with a legacy, then you're going to have to write a wrapper to actually call that service from your service layer instead of through a browser, which, again, isn't hard to do. It's just another thing that you have to deal with. And again, it happened over and over again. And it was a common question that we had to deal with. Yeah, so it's part of the common conversation we have with the developers. Hey, you've been doing app development, you're doing service development for a long time. Why do you have to consider this? And we all know about it, but it's not necessarily in part of their normal practices and training them how to do it consistently and make it easy with the frameworks themselves. And so it was an interesting thing. So we didn't expect cores to be that big of a consideration, because everybody knows about cores in the app software. But if you're not doing it, hey, well, how do I do X, Y, or Z? How do we share those practices? And so it's a consideration for sure. So another issue that was a little bit more challenging was authentication. When you're an employee at Intel and if you're using a Windows system, you're used to going into work, logging in, and never typing your username and password ever again, no matter how many websites you go to internally. That doesn't really happen when you're in the cloud. Yes, we could use Kerberos, but we were unable to do that. And so we're very Windows dependent. So we came up with a custom solution that we call token translation services, basically what it is. We call it ISO integrated single sign-on. And again, it wasn't a necessarily clever design or a difficult design, but it was absolutely something that stopped applications from landing in our cloud infrastructure for quite some time before this was solved. Yeah, especially when you're running and you're busy, hey, we can support LDAP integration. They can do that cloud native. That's not the issue. The issue is that there's almost no application in most enterprises that don't integrate with other legacy apps. And they want that same sign-on experience. And so really the catch for most is, hey, it's not that I couldn't write an own standalone app that can do active directory and authentication into that to give the experience. The problem is I consume three or four or five services, perhaps, from a different system. And they're maybe old, they may be soap-based systems, they may be restful services. We would all like to adopt some of the new authentication OAuth models, but for the most part, at least in our environment and people that we've talked to and our peers and other companies, because we can ask them, how are you addressing these types of frameworks? It's really integration with LLN. That's really a key tenant in enterprise implementations, really understanding what does it mean to integrate with other enterprise systems? And how do we consume employee data, sales data, ERP information, et cetera? And so making sure we got that right, openly it stopped our development team from embracing our cloud architectures for probably 18 months. And it's not that it's a hard problem. They're saying, hey, I've got my old way of doing it. I can give my users a seamless experience. I'm not going to move over to a new architecture where these are issues that they're coming in from a flow. And so something not terribly complex, but unknown. And so you're really thinking about the full experience through the whole framework and how to integrate with those things is important. Just to give you a high level view of, again, it's not a hard solution. What we did was essentially create a service. And then we had a wrapper that is a module that you can write in whatever language that you need to do. And how this works is by a set of HTTP redirects. We do 302 redirects, which keeps the app developer, the UI developer, from having to develop anything specific for this. The service developer, all they do is add a node module if they're doing node development. And that's it. And they get authentication. So there's no special development needed for authentication. And because we use 302 redirects, the end user in the browser isn't bounced around within the app as authentication occurs. It just happens behind the scenes. And it is a little performance hit up front, but it is a session token. So once that service has issued a token, any subsequent calls to that same service API, you will not have to go through this whatever eight steps again. But then if the web UI is calling multiple services, you do take this hit with each of those endpoints. So what happens? The browser says, hey, I need to communicate with the service API. The service API goes, nope, you need a token. So a browser uses that information to go get a token. The ISO service then issues a token based on the user and sends it back to the browser. A browser then re-sends the request to the service API. The ISO module, again, intercepts that, goes off to the ISO service, verifies that it's a valid token, and then finally, the service sends the response back to the UI. So not difficult, but it's something that took us a while to figure out the right solution, given our very specific requirements that our users do not want to type in username and password ever. And our developers want to move fast. We get this experience on our old traditional virtual environments. That's just another thing. So doing that for them, remember, time to market is the most important area meant for that audience. And then another thing, again, it sounds easy, and you've probably dealt with it for many, many years. But Cloud just emphasizes this notion that, hey, when you're doing web UI work, you want to give the user the best experience possible. So you're doing data validation on the browser to do that. But we don't trust the browser. So you have to do that same data validation and data integrity checks at the service layer. And then if you're really concerned, you might also have some of that same stuff at the data layer. So when we're deploying to the Cloud, these extra steps, again, if you're deploying three tier and handling this before, great. But some of our developers were not. So this was another area that was common. So let's talk about some of the results, really. We said, hey, time to market, and it's really super important. We set a goal, really, from weeks, spin up an environment, configure it to less than a day. And that's really still too slow. It's really minutes, and we're achieving that. We'll talk about our number of apps and number of developers. We've got a slide coming up on that. But we do find that the standardization of the stack not only helps us from a time in pre-configuring on the environment, the developers don't want to have to set up and configure a new web head, set up and do their runtime library. So as much standardization we can move up the stack as we can is a key enabler, because that's really the driver. In both database and app platform services. And so we are achieving releases in less than a day. I know you're often asked to go prototype, get something out the door. What's your experience in that? Right. So developers ask, how do you do something? And it's fantastic to be able to use some of our tools, like app generators and templates, to quickly, in a minute, spin up a template, code out what they need to see. And then with a command, deploy that to our cloud infrastructure and have them see it live. So they get a live demo as well as now we can share the code. And so before, that wasn't possible unless you had a server running underneath your desk and you could share it out that way. Or you had link to your own desktop and you go home. And then if you get a broad audience, you can't get it. The other area, and there's a part of it in the white paper that you'll see at the end of the session, there's a link to a white paper. But it's worth mentioning here just because you see the levels of standardization. The security findings that we are experiencing. Legacy code has more vulnerabilities. And so migrating over to these new app frameworks has fundamentally reduced our overall security risk for those new apps. So the apps themselves are patched more frequently. They're running on more hardened technologies versus some of the older ones. But also our time to patch and compliance. Software vulnerabilities, configuration standards, those are areas that drive risk and are currently unique configured virtual servers. And so our information security engineering team is finding that this framework has allowed them to integrate and patch the servers, make sure that you've got standard configurations without unique security configuration checkers. And so it also has another benefit to helping improving the way we manage and operate and help secure the environment. And so these levels of standardization and freeing up the ability to misconfigure or have out-of-date software or app vulnerabilities really is one of our strategies that we're deploying to help improve the security of the solutions that we're deploying within our IT environment. So adoption. We talked about mandates. And we've had various mandates for different things from our organization. Interesting kind of experiment here. We have not mandated the cloud at all internally. But yet you're seeing, you know, this one shows almost 700, it's actually over 800 applications deployed in that environment in various stage of design and development. Some of them are small, some of them are larger. And then you see the blue line, which is the number of developers. It's ones that they're picking up and adopting for that time to market flow. And so it's an interesting phenomenon where it says, hey, how do we drive and engage the development teams? You know, our execs typically say, hey, go tell them, will this tell them? And that works for a little while and then you see it taper off. And we're just seeing a steady growth of adoption organically. And now we're seeing such value that they're now contemplating, how do we mandate more? And we say, hey, just, you know, enable, you know, set the goal, set the direction. And you engage a lot with the development teams. I mean, what's your experience with getting them on board? You know, again, it's, you provide the carrots. You make it easy to land their applications. You enable them to develop their applications quickly and they'll use it. And if they don't use it, you know, you'll know. Because we track with metrics on our reusable code assets, we know which ones are used and which ones aren't. So, you know, it's very much like, you know, the open source community, you know, developers will speak loudly. Very loudly. So, you know, the other area, you know, just from a raw savings. I mean, we're pursuing cloud, not only for time to market, we've got other benefits. You know, what's our own, you know, efficiencies and, you know, cost advantage. And for us, you know, the integration with legacy apps and services certainly helps our time to market. But just our raw infrastructure cost management. I mean, we have driven efficiencies in our infrastructure over the years. We've done our own internal benchmarks and we're constantly asking the question, which ones do we pursue externally? Which ones do we pursue internally? Certainly the SaaS areas, you know, in an IT, a buy versus build, we always want to try to buy the software versus build it. And so that seems to be the area that we look at SaaS more often. But in the app development space, you know, the pace in which we can deliver and just the infrastructure costs, you know, we're, you know, almost 2X lower cost than what will cost us to go externally. And then our pass-in framework, in addition to that, because of the app density and the standardization, we even get more savings. So you'll see, you know, kind of the numbers there. There's a, you know, more information on that. But, you know, we are accountable as an IT organization to really make sure we're driving the right strategies and getting results in time, security, cost efficiencies, and then get adoption. So it's been a, you know, really a good story for us internally and setting those goals. And so we continue to track it and measure it, and now we're adopting, how do we bring in some more container strategies to enable some of the unique configurations? But these are all areas that, you know, we continue to look at and say, how can we do better, right? And our management sees these goals and then they set higher ones, which is always, you know, the way it works, I think. So, you know, from just a high level, you know, our cloud deployments, you know, really engaged by, you know, enabling the development teams, engaged the development teams, helped them achieve those business goals of, you know, improved user experience, multiple device, you know, support, you know, lower cost, how do we do embedded analytics? How do you respond to those things that, you know, all of the businesses are responding to? And approach it really from, we're gonna help solve a holistic problem, and cloud is one of the methods that you can do that. You know, integrate both app and infrastructure strategies, you know, private cloud has accelerated our own adoption and use, and we do things in multiple areas, but, you know, we brought that essentially almost exclusively internally from a development perspective, unless we're doing SaaS externally, those teams, it's the first choice without having to, you know, go catch the sprawl and drive self-service at all levels. You'll see the link there, you know, really to a more detailed explanation of some of the approaches in flow. So if you want more of those, you can look there. But it really is, you know, in my experience, the biggest shift, and we've gone from, you know, mainframe to client to PC to server, but you're seeing, you know, at least in my observation, the big push for security, it's forcing us to look at old legacy applications that we didn't have before, the new expectations for user usability and user experience, to bring your own device phenomenon, that everybody's bringing their own, you know, device into it and the pace of browser updates, and OS updates is, you know, no longer three years, it's, you know, one year for an operating system and six months for a browser, and then there's a bunch of them, not just one. It really is the biggest change, right? You know, cloud architectures, front-end architectures, new expectations for development, it's changing, you know, fundamentally the approaches we have. And so, you know, what would you add from your perspective as a pace of change, as a... I would, you know, just say that absolutely cloud has changed how developers, you know, can be efficient. And again, as was said several times, that you don't do it through mandate, you do it through providing those carrots, because the developers don't wanna be told what to do, they want to just do what they think is the best way to do it, and that has been working for us. With that, I think we have time for questions. Hi, my name is Aniket, I work at Vox. So it was very encouraging and almost expected to see that as you lower the barriers to adoption through reusable code and frameworks, that you will have organic adoption for new development. Can you share your experience, not just for development of new applications, but your adoption of cloud by your legacy applications? Sure, it's a good... What are you seeing in terms of organizations seeing the benefit of the cloud, you know, your business units and then transitioning their workloads onto the cloud? Yeah, it's a good question. So the, I think it was on the speaker, but fundamentally, a lot of these really are organic adoption around native cloud. So what does that mean from, you know, perhaps legacy implementations? And so a lot of the strategies that we have when we change any architectures, some of them are, you know, deployments, a cloud architecture deployment around, you know, migrating and supporting some of the legacy app. But a lot of the new frameworks, and even when we've gone from, you know, VB and PowerBuilder and .NET and Java, you know, what we find in a bigger application is they move sections of apps, right? They'll move, you know, service enabled, they'll do some abstracted, they'll do some new capabilities to support mobile devices. And so in our own implementation, it's really been staged module deployments that help do a hybrid cloud, right? So the hybrid cloud between, you know, what is cloud native versus legacy, and that's been the typical migration path. There's some teams that have gone a big bang approach. Most teams don't do that. They say, hey, I need to do X, Y, Z, and they do that on the new architectures. And then there's different strategies that would be a broader topic from this one to say, hey, how do we just pick up and replace? And so, you know, do you move the database or just move the app server? So we see the app servers kind of move first, and the databases tend to move after that, right? Right, yeah. Good question. How about containers? You'd not touch upon that at all, but do you see a lot of movement within the organization? Yeah, I think we do see a lot of interest in containers. Containers have, you know, we're using Cloud Foundry for this implementation, but we start to get, you know, limitations in some of the implementations we have those framework. It meets a lot of our use cases, so there's a lot of adoption on that. And we're looking at containers for some of the unique configurations, right? How do you do the standard templates? The things that we're thinking about from a usability perspective with containers is developers still don't want to provision out and configure their container, right? Even though you could do it with command line and never touch it. And so we're looking at, hey, how do we integrate the best of containers, right? Which gives you uniqueness with the best of traditional past frameworks and deploying, you know, preconfigured sets of containers that do standard functions and then giving them the ability to, you know, modify and update those. And so containers will absolutely be in our strategy. They're emerging already in some areas, but this got us started and now they're wetting their app, but I had to say I needed to do more. And so that's kind of really where we're headed. I would see the same type of growth we've seen with just Cloud in general in the last 12 months to be the same for containers in the next 12. Provided you put the layer on top, right? You can't say, hey, you can do it, you know, the system engineer function. Without ever talking to the engineer, they don't want to do that function, right? So they want to be able to spin it up. And then if they have to, they want to be able to do it themselves if they want to do some unique stuff, so, yeah. Good question, okay? Implicit in this presentation might be the answer to this question, but did you see a lot of shadow IT prior to this? We still have shadow IT, let's just be... And it's one of the things that we say, hey, you know, and mandating shadow IT with people who have budgets themselves. So for, you know, shadow IT for those, it's a term that, hey, IT development app development outside of the traditional IT funding body. And so we still see that. We see a lot less, or we see more of those shadow IT that's existed for a long time coming in because of a time and price. We do find because of the cost-private points, you know, our upcharge, we don't do a, you know, charge-back model because it's cheaper than what we could do externally as a company. And so we start to give them the tools, set them the expectations. And so they're driving to that and they're coming to us probably way more than they've ever done before. Right. Is that it from a time perspective? Okay, thank you. Appreciate it.