 All right. How's everybody doing today on the OpenStack Summit Boston? Good? Good. Before we start, I wanted to get a show of hands in the room. Who works for a small or a medium-sized organization that's interested in pursuing OpenStack for production workloads inside of your respective organization? Awesome. So hopefully we can fill in some of that stuff for you today in this presentation. The title of it is Free My Organization to Cloud Native Infrastructure. But before we go there, just a little bit about us. Hello, everyone. My name is Steve Black. I work for East Carolina University, and I am a systems analyst slash programmer. What I really specialize in is virtualization. So whether that be traditional virtualization or public or private cloud virtualization, I've had about seven years experience in IT with the last year and a half really focusing on public and private cloud. I have a really heavy background in VMware, Linux, and OpenStack. At work, I am known as go to lunch Steve because I never leave. Some people get there before me and leave before I do. So it's kind of interesting that I really have dedicated the last few years to really pursuing open source technology in OpenStack. Great. Hey, guys. David Kane. I work for Red Hat. I'm a senior solutions architect in the Global Partners and Alliances Organization. So I work with Red Hat's key OEM and service provider partners on building solutions, specifically cloud solutions. I've spent about the past 14 years working in IT with a cloud infrastructure focus. So a lot of what I say I've taken from the School of Hard Knocks, I would say. A little fun fact about me. I really love vintage machinery. I like to restore old cars, which we'll talk about that in the presentation some more. Old hand tools, anything older than 40 years, just like the quality and everything associated with that. And if you'd like to follow me on Twitter, my handle is up there. So quickly, the agenda that I want to run through today with everyone for this session, I want to introduce East Carolina University. Talk a little bit about the school, its mission statement, how many students it has, as well as its business and technology challenges. Steve will take you through that. And we'll lead up to kind of a decision-making process that their organization went through to actually say, yes, we're going to adopt OpenStack in our respective environment. I'll take you through what are solutions specifically for OpenStack and why you should care and what these are, a little bit of a definition. And then Steve and myself will take you jointly through proof points and results since the deployment of OpenStack at East Carolina University. Some advice for you, this track is evaluating OpenStack. So we do have some advice for you in your respective journeys, those that raise their hand, as to how to begin this journey to cloud-native infrastructure, as well as a little taste as to some of the next steps in ECU's deployment, what some of the things that they're looking at next. All right, everyone. So I want to give you a little bit of background on East Carolina University. We are the third or fourth-largest four-year university in North Carolina. We have around 30,000 students and around 5,800 faculty and staff. Specifically, the department I work for is called Information Technology and Computing Services. And what we do is we provide a lot of the public-facing services that the university offers, as well as not only hosting those, but we also do a lot of development on those platforms as well. The slide needs to be updated a little bit. That says 150 employees. It's really around 200 now. And my team has about five people on it. So let me talk a little bit about the business challenges of why we went and pursued OpenStack. Specifically, we have cost and budget. Most problems in the industry are time and money, right? So the way that the university works is we have certain budgets that we really can't go over. And a lot of our budgets reflect around fixed assets, right? So we own and host most of our stuff. And that leads us to time, right? So as an organization, we have time constraints on certain projects and things. So a lot of our time was spent automating and orchestrating a lot of things we do with OpenStack, including other technologies. And we are also a siloed organization. Anybody in here in a siloed organization? All right, you guys know my pain, right? So one of our biggest concerns was customer service, right? Being in a siloed organization, we have challenges of interacting with a bunch of people to provide a very complex set of services, right? So we provide services to like 12 different colleges and we have bunches of platforms, right? So we're not just like a single vendor shop. We have everything you can think of. So when our customers demand something, we either have to be specialized in it and it might take us a little bit longer to get some of those processes started. And another big part is because we do provide those services to so many people and we have budgets for every little thing. So as ITCS, part of the organization, we may have a budget, but if we provide services to say a college within the university or another department within the university, they have budgets to deal with as well, right? So it's really difficult to manage your fixed asset resources along with providing service to those customers. Also as a university, we have to worry about data privacy and compliance. So we do have HIPAA data, PCI compliance, we have to worry about and student data as well. So we don't like to interact student data with like production data and stuff like that. So we really have to be aware in our environment how to separate these things and manage them efficiently. So when we were starting our journey, we were looking at a few different platforms, one of them being public cloud. And I think we got a quote for some of our window service to go in to a public cloud and we were looking at around $50,000 a month. That is really expensive, especially when you have a budget, right? And that wasn't like all of our main infrastructure, either that was just kind of a little subset. And that can be very difficult for our organization because those budgets happen in a fiscal year. So if we had a higher demand for resources, we wouldn't be able to meet that, right? If our customer just wanted like 20 more of something, well, we quoted you on this, we can't expand that good in a public cloud because we just don't have the budget, right? So we looked at externally managed hosted services. And what that really means is a service may be a platform. So one of our biggest platforms is our ERP, our enterprise resource planning platform. It's called Banner. If you've ever been to a university, you've probably seen Banner before. And what that does is that does everything from student registration to paying for books, paying for classes, looking up tax forms, transcripts. I mean, this thing hosts a bunch of resources, right? So there's a bunch of services that make up the service. And if we were to host this on say like a public provider, we've had this for over 10 years now. And we've done a lot of customizations and programming and development behind the scenes to add new features to it. We were afraid that my mic might not work. So we were afraid that a lot of these features that we had wouldn't be compatible or supported if we went with a vendor provided solution, right? So we're always kind of hesitant to go to an externally hosted solution because we can't actually control that, right? Then we had the option to stick with traditional virtualization technologies. We use a wide variety, KVM, Rev, RevM, VMware. I mean, we have a lot of technologies that we use, right? And so as a price point to manage these technologies, it was getting really slow, right? So if you go and manage one thing at a time, it's kind of slow. But if you can improve resources for a bigger set of customers, then it'd make things a little bit smoother in the future, especially when you roll over hardware or make upgrades, right? And something else that we wanted to pursue was microservices and containerization. And a lot of our platforms, 10 plus years old, we can't really containerize everything overnight, right? So you want to host on an environment which really empowers you to be able to do your containerization or microservices. And also, when we were looking at solutions, we thought, wow, Private Cloud really seems like a solution that would be really good for us. Because it's scalable and flexible. So when we were looking at Private Clouds, we looked at a bunch of different vendors. I mean, there's a lot of them out there, right? We're a really big red hat shop. We're very familiar with a lot of the software and the open source projects. So when we were looking for a solution, we really had a focus in mind to, hey, can we really find hardware and software that fit together really well and incorporate all these things into our future services? So before we talk a little bit about what ECU eventually went with, I want to talk a little bit more about how customers view OpenStack solutions. So that was in the agenda slide, what are these and why should you care? And I made an XY graph right here with risk on the X-axis and return on investment in the Y-axis here. And I'm a car guy. So do it yourself or type thing. I mentioned I like vintage machinery. I have a 51 year old car that I've been restoring over the past four or five years and I have an intake manifold from one manufacturer, an engine from a different manufacturer, suspension system from yet another. So I've essentially put together something myself and I support it. One can make a similar parallel in building or starting an OpenStack journey right there. Certainly a lot of major players that have adequate staffing and resources to have a do it yourself attitude where you put all of these individual parts and components together. Yes, you can build something, but maybe there's a better way for organizations that don't have the staffing or the resources or the ability to pay for consulting agreements for stuff like that. So I want to introduce reference architectures, moving a little bit more to the right on the scale there of lower risk and more of a return on investment. And that's kind of an overloaded term right there. So when you say reference architectures back to the car analogy right there, I'll make the analogy that a reference architecture is a playbook. It has components built into it from vendors, a hardware and software vendors, but it does not accurately reflect maybe step-by-step directions or actual validation of that software stack on that hardware stack with a joint roadmap between those entities and writing that reference architecture. So one of the things that I want to introduce as a follow-on to that, maybe a reference architecture plus plus, is a flexible solution. So a flexible solution encompassing everything that I just described, but very much more prescriptive guidance, automation that comprises that and purpose built configurations that have been known to work, known to scale and include companies with deep partnerships and deep engineering relationships and collaboration over a multifaceted stage. Now going back to what I said about do-it-yourself, like I said, I'm a car guy. I love to customize things. I'm not saying that you can't customize your deployments, but what we found and humbling myself working with great engineering teams in companies like this or even customer deployments, I found that customization up to the enthmost scale is kind of an effect of a penalization in scale. And one of the things that I would say, specifically for a flexible solution or your specific journey, is started a known boundary. Take the customizations that are unique and inherent to your individual organizations, but start at a boundary where you know everything works and you can get up and start it and you can actually be productive with that. Hold on, give me a slide. So I want to add to that a little bit for all the people who raised your hands. Who of you actually went out and built your own open stack and it worked perfectly and you were able to scale and it just works beautifully? Yeah, that's what I thought, right? So when we were looking for this flexible solution, we said, look, we don't have a lot of time and money to spend into researching and developing this solution to be able to be flexible. So one of our concerns was, how do you actually have a solution that you know will scale properly, right? So with our solution that we purchased, I've seen other customers actually be able to scale that, so I kind of trusted that. Also, you have to put a lot of trust into people who are providing those services to set you up with a flexible solution, right? So if you buy a car, you buy it to travel, right? And Dave was talking about he likes to build cars and change out all the parts and things. Well, me as a customer, what am I gonna do to it? Well, I'm gonna change out the tires, I'm gonna add spinners on the side, I'm gonna change out my seats, right? I'm gonna add features on top of this flexible solution and I need that to be supported, right? For compatibility. So when we were looking for the solution, not only did we buy it because it was proven to scale and work, but because we wanted to add to it and that was a very good price point for us. So as to the solution that ECU deployed at their site, I'm introducing right now the Dell EMC Ready Bundle for Red Hat OpenStack platform, and this is technology comprising of Red Hat, Red Hat OpenStack platform, Red Hat stuff storage, as well as systems and servers from Dell EMC, specifically the PowerEdge R630 and the PowerEdge R730 XD, those are available as well as the FX2 modular blade-based architecture today, and that includes the Open Networking Dell EMC switches and the core architecture is a 10-node starter kit deployment with 10 gigabit networking, everything highly available, starting at a half-rack of systems. The team itself, I'll introduce a slide here in a minute, but really the ideal use cases for this are infrastructure as a service, containers as a service, scale out, software-defined storage, but tests and development workloads, but also production workloads. So really this is an ideal starter case to really the technology stack to start an open-stack journey, and what does that look like from a logical architecture perspective? So I mentioned everything in the infrastructure layer at the bottom of this picture here, but the software layer on top of that, deployed by Red Hat OpenStack platform director, that's Red Hat's management and orchestration tool to do that, that deploys Red Hat Enterprise Linux, arguably the most successful, longest Linux distribution for the enterprise there, 17 years in counting, as well as Red Hat stuff storage for the block storage, arguably one of the most popular storage solutions for open-stack. But I mentioned before the reference architecture, this is where a solution like this is different. We also have a cloud orchestration layer on top of that. The team jointly, Dell EMC and Red Hat, prescribed and validated deployment guides to have Red Hat OpenShift container platform, that's our containers as a service project there, comprised in the reference architectures, as well as Red Hat CloudForms. So these guys validate very, very well our joint engineering work that we do together. Been doing this for about three and a half years right now, and we include things on the side, I have certified extensions, I mentioned these, having validation of Red Hat CloudForms and OpenShift on there, as well as professional services engagements involved with this. So for those organizations that may not have the staffing or the capacity to deploy this, Dell EMC and Red Hat go on to the customer site and actually work with the customer, get them up to speed with getting this deployed, rather quickly, I heard a statistic at the keynote at Red Hat Summit where Steve was on stage saying that they took their deployment from three weeks down to three. So that's also a portion of both the professional services and this automated deployment tooling, which Dell EMC and Red Hat have announced as Jetpack. So this is tooling that accompanies the reference architecture that really helps stand up and deploy things in a validated and repeated manner very, very quickly, and then they're turned over to the customer after the engagement there. So I can stand up here and spouse on stage all day about the benefits of this, but really what you guys care about, Steve, how did this help your organization? So Dave is showcasing all the benefits of a flexible solution and specifically that solution. When ECU went to look at this solution, like I said before, we weren't looking at just implementing OpenStack, right? We were wanting to improve performance, time to providing services for customers as well. So what we were looking at is integrating a lot of tools additional to this. So when we looked and we communicated with Red Hat, what all tools can we integrate with the solution, right? So we're looking at Ansible, Puppet, we're looking at Red Hat Satellite Server, and we really wanted to integrate everything and maybe even have a single pane of glass in the future for self-service, right? So this solution has really let itself for us to be able to pursue that. So I wanna talk a little bit about our current standings. At the beginning of that project I mentioned earlier, we had around 10 services spread across 20 traditional VMs that we wanted to migrate over. So since then we have added additional 10 services to that. A lot of that time savings was spent making cloud images or like virtual appliances, you may hear them called. So we're able to deploy those really fast. Now we're at about 100 instances. So we have two data centers, two separate clouds. So 50 instances per site, right? And we also have OpenShift on OpenStack now and that happened about two or three weeks ago. So we're just starting out with that and starting to containerize some of our services. So comparatively to the initial deployment of the Dell solution, we met at about 70% capacity, right? So our first three months of using the platform we hit about 30% and we were starting to develop more and more and our customer demands got really high and we started to need to scale out, right? But I talked about earlier we had those budgets, right? So we were able to purchase some RAM and some more storage and we were able to grow, but now we need to add more compute nodes, right? So at our current capacity we are at 50% capacity. When I get back in a few days they plan on me adding some more compute nodes. So I gotta do that when I get home. But what are the real results of having used the technology, right? So I talked early about our capital expenses. We were able to reduce our capital expenses by 10 fold. That goes for hardware, software licensing and some of the other costs associated with that. And also we have operational expenses which were a lot of time and management, right? And we were able to reduce those by about eight fold. That's pretty impressive. If you go to your boss and say, hey, I can turn $5 million into a $500,000 expense. Who wants to do that, right? That's like guaranteed job right there. Also, along with that, notice that we've adopted a lot more automation and orchestration, right? And that's really helped our time. So I wanted to provide a few little statistics on that. So if you look at the graph on the right we had time to build VMs. So this is kind of a comparison on the way we were traditionally doing things and the way that we're doing things now. So you can see our biggest bar over there is server assessment. So when ECU provides a service to a customer we have to make sure we meet all those compliances and that we know exactly what the customer wants and then we have to get certain things from some of our silos like storage or network or firewall requests to be able to do these things, right? And then the actual build time was around four days. And that's kind of slow. Now that we've been able to incorporate all these things and kind of streamline some of those procedures we've been able to hand off a VM in about half a business day. So what that really means for me and my team is I can launch an instance in about 10 minutes and be production ready. So what I mean by that is actually working in production. So 10, 15 minutes to launch something in production that's pretty impressive. However, we can improve that even more by doing self-service, right? So we're starting to allow some of our internal customers to do that and that has gone fairly well so far. I talked earlier about having to get stakeholders on board, right? And the best way to do that is to give them a button. People love buttons. Click, click, click more, more, right? So our customer service has gone way up. Our customers love that we're able to do all these things a lot quicker as well as resource management. And what I mean by that is I was really referring to management of the infrastructure, right? So if you're doing infrastructure as a service compared to traditional technologies, your resource management becomes easy because you just set up quotas for your tenants, right? And that makes it really easy. So when you go into projects, you know, hey, I have this much resources left. I can easily gauge how much my customers are gonna need. And if they ask for more, I just change some numbers, right? And it happens. And then I just have to request things later on. So having stated that we've adopted new technology and that we've had somewhat of success, I would say, I have a few words of wisdom that I would like to impart. The first part is the easiest way to adopt new technology is convince management that they're gonna save a lot of money. I talked about the 10-fold. If you can bring that to your boss and say, hey, look, this guy did it, we can do it too, that's a pretty good argument. So if you get management on board, change generally starts with one person having an idea, right? But one person can't change everything. So you really need to onboard people in the organization. So that could be stakeholders, your own teammates, saying, hey guys, let's try this. And then go to the other silos. If you're in a silo like I am, go to the other teams and say, hey look, let's come together, let's collaborate, and let's see what we can make happen. So that becomes a little bit easier. So some other advice from an operational perspective. Yes, you have all of this awesome new cloud capabilities right here, but having a way to monitor that so you can accurately reflect how much capacity you're using, at Red Hat I'm apt to recommend totally open source things right there. So fluently for log management or for the actual systems itself, actually I'm forgetting the name of it, but have a demon on your system itself so you can monitor how much CPU it's using, how much memory, how much disk space, how much latency right there, and have those metrics captured in a portal like in a graphite Grafana type instance. So when it comes time to ask your boss for more capacity right there, you've got empirical data and you understand and you have a viewpoint into your entire cloud right there. And also charge back, depending on the organization there, some folks have internal charge back capabilities right there. Have that nailed down, even before you do your cloud deployment there because every organization is different how they charge back to get money for resources that they deploy for their customers right there. So just take that into account from an operational perspective. Also your key stakeholders, your customers, your clients that use that infrastructure itself. We talk about digital transformation in such an overused term, but really digital transformation of the technology stack itself. There's also a human element involved in that. Your organizations have to transform as well and start thinking about different ways to either write your applications or service your IT like what we're talking about right now. Push these folks inside of your organization. Show them the realms of possibilities that emerge whenever you have agile development practices, certainly containerization that's an extremely hot topic here. But the fact of the matter is a lot of organizations have so much traditional code written for them. It takes time. And so break things down in a stepwise process and don't try to boil the ocean, at least at the onset there, as well as having specific roadmaps for whenever you do implement a solution like this in your respective organization. As Steve mentioned, you onboard these specific folks. But what we've found that's really helpful is having workshops or having training and enablement sessions. So not only show up at your co-worker's desk, look at all the cool stuff that I can do with this technology, but onboard them, create a participative community inside of your organization, onboard them, and get them enabled. So it's not just you as the stakeholder. You've got an army of people with you to help you make this transition a little bit easier. So what about at the future at ECU, Steve? What are you looking at next? So we have a lot of plans with OpenStack and in general. Specifically with OpenStack, we're looking at upgrading the load balancer as a service V2. Or at Five Integration, I talked about earlier we wanted to incorporate self-service. And having that integration will make it a lot easier for our internal customers. Also with OpenShift, we may look at Manila with CFFS or having Gluster run in OpenShift. That's also in tech preview. So we don't want to go too far into the bleeding edge, but we want to look into it right, because there are some challenges you may face. But knowing that the community will update in about six months, some of your challenges may be solved. So always look to the future. We also are looking into Ironic, deploying instances to bare metal. So that would be very useful for us if we wanted to launch a database on OpenStack. That would be very useful, because databases do not run very well in VMs, especially if you have large databases or clustered databases. Also, we are in the pursuit of CloudForms as our single pane of glass. That's ManageIQ in the upstream for self-service. If we can adopt this and get it running great internally, we would like to maybe possibly extend that out to a few more customers. Specifically, in general, we are looking at providing services maybe to a wider range of customers, possibly students, faculty, and staff with some other options available. And we are also looking at hybrid cloud bursting for our DR strategies as well. Coming from a traditional standpoint, we do a lot of backups and a lot of DR as well for everything we offer. As part of cloud bursting, not only does that apply to private cloud, but also to public cloud as well. So we have a true hybrid approach. We're not going to just stop using other technologies. We want to use all the technologies together. And as part of that, as part of DR, we also are looking into hosting things at another data center as well to really spread our footprint and be more highly available. So we have a lot of things going on at the college right now. Those are just a few of them. But I thought I'd give you guys a little insight onto what we plan on doing in the future. As some closing statements, some of the most important things that I wanted to recommend were to buy in to your organizational stakeholders before you go and deploy this and say, OK, it's here. Now use it. You really have to convince people that what you're going to try to do is going to benefit them. So I talked about onboarding. And one of the best ways to do that is choosing a good solution for you. So for us, private cloud was a very good solution, even though we use a lot more than that. But flexible solutions are a very good option, especially if you are budget constrained. And need to have something right away that you don't have time to put a lot of effort into. So as I mentioned for digital transformation, OpenStack is pretty much the de facto infrastructure as a service nowadays to build private clouds. Consider using a flexible solution, like I mentioned, to help accelerate your cloud journey there. The motions of doing it yourself while attractive, not all organizations are massive retailers or massive telcos that can really embark on putting all these pieces and parts together. So choose something from a known baseline. And yes, customization is great. These are great platforms that services a kickstart to helping you start your cloud journey and transformation. Yep. So I'd just like to close and say that investing in cloud native infrastructure has allowed us to show very great gains. We've saved a lot of money, made our customers happy, and we plan to do more so in the future. Specifically, we were in a reactive state where we had to meet demands all the time, just reacting to demands. But now we're able to proactively look at other technologies and look towards the future. And really, if you can start your organization to look towards the future instead of just reacting to your customers, it'll be really helpful and it will help you grow. So a few resources that I wanted to post out here. The first URL, the title of this track is Evaluating OpenStack. This URL is a portal that Red Hat, Dell EMC, and Intel share that can give you a POC in your respective environments there. You just have to fill out a form, look at some resources that are on there, and someone will contact you if you're interested. If you don't like salespeople, if you just want to see the reference architecture, what we talked about here, to make up your own mind and do your own self-research for now, the URL is the second one there. And it's about a 30-page document there, very, very descriptive and prescriptive. And the rest of the documents associated with this solution are up there in the same website there that you could look at, too, the extensions and everything else that I mentioned there. So with that, we have a good amount of time for question and answers. If you will, step up to the microphone so that this is being recorded. So before you went with the solution that included some custom packaging and support from Red Hat, did you have a chance to experiment with any of this on your own, like different? And I say I'm comparing, let's say, because Ubuntu has a version of OpenStack. So does Red Hat. Then you have CentOS, which I guess it would be the same flavor, except you'd be providing your own support. Yeah, so it's really easy to go out and test OpenStack and these other open source technologies because they are open source. So if I didn't want to go with Red Hat or Dell, I could potentially go out there and deploy any form of OpenStack or even an upstream project. So the answer is yes. We did look at other technologies as well. And the reason was because we mainly had a site license for a lot of licensing. It was really accessible to us. But I can go out there and deploy Ubuntu OpenStack on my laptop in about five minutes, right? So we did have the opportunity to test other things. And we did. But since we had kind of already paid for it, that's what we decided to go with. You mentioned planning for self-service with Cloud Forms. Wondering if you could talk a little bit more about what sort of services you might offer to students versus faculty and staff. What sort of services or apps or environments might be suitable to offer self-service? So that's a dream right now, right? So that's a very challenging approach. So I'll answer that in two parts. We're looking at self-service for internal production use. And that's going to be our main use case to different environments well, right? Not just OpenStack, Public and Private Cloud, just pretty much any technology. But also, because we have OpenShift integrating containers, you can request a container or infrastructure if you really want it. We want to provide what the customers want, right? We don't want to just say, here it is, use it. So Cloud Forms is a good gateway to tying in a lot of those features. And separately, to answer the question about students, faculty, and staff, really they have demands for a lot of things, right? And we're just starting to assess what they may want. So we're looking into a lot of different options. And I can't really answer that fully right now, because we don't really know. That would be a very possible solution. He said labs for classrooms. Yes, that would be possible. How did your backup solution change between before going to OpenStack and now with how did you talk about that process? Yeah, so specifically our backup process, we had snapshotting capabilities in a traditional virtualization environment, as well as backing up bare metal servers as well. And so a lot of the services that we migrated over did become virtualized, right? And so I talked earlier about having cloud images or virtual appliances, right? So one of our backup strategies is if it's a virtual appliance and you've automated it, do you really need to fully backup everything? Well, yes, we have multiple copies, different places, right? So we have two data centers. Of course, we have a DR backup strategy as well, so we have it stored there as well. And if we wanna do snapshots, we can do that within OpenStack. Or if we want to do a more traditional customer wants a more traditional backup strategy, we can also backup those VMs fully as well. How did you manage the adaptation phase of this? Were there any resistance by system administrators, faculty, were there any... A second part to the question is self-service. Once you implement self-service, what type of adaptation phase are you gonna use for that as well too? Right, so I'll answer the second part first because of the question in previous. So to adapt to self-service model, we're really looking at hosting internally first. So that'll be kind of more of our POC type of environment where we onboard some of our main customers and let them use it and see if they like it. As far as the second portion, I can't really answer that for faculty and students. That's kind of above my pay grade. However, I would like to say that the adoption of OpenStack and getting customers to use those, we had a very specific project that we were looking on implementing, right? So we needed to find the solution for a specific project. And what we were able to do is we did it piece by piece. So we might have had two or three customers at the beginning and said, hey, if we sit here, hold your hand through the process, try to help you streamline it and make these cloud images is what I've been doing and really help them automate their deployment because if they can't containerize what they want, and really what most customers want to do is containerize things. So it's easy for them so they don't have to deploy instances or VMs. But in cases they can't, if you are able to help them do that, that helps the process. And as far as resistance from administrators or anything like that, no, because everyone should be leaning to the future, right? You should always be striving to find better solutions or improving performance. So if you get resistance, it might be more of a conflict of what solution you want to use. So that would be up to that specific person and you can't force people to do what they don't want to do, right? So you have to really cater to the people who do want to try something new or will easily adopt things. Any other questions? Okay, well I'll be sticking around afterwards right outside if you have any specific questions you want to ask. Thank you. Thanks folks.