>> So, hi, my name is Daniel Terry, I work as Lead Designer at SEB. So, today we will go through why we are why we are Mirantis' customer, why we choose Docker Enterprise, and mainly what challenges we were facing before we chose to work with Docker, and where we are today, and our keys to success. >> Hi, my name is Johan, I'm a senior developer and a Tech Lead at SEB. I was in the beginning with Docker for like, four years ago. And as Daniel was saying here, we are going to present to you our journey with Docker and the answers. >> Yeah, who are we? We are SEB group. So we are a classic, financial large institutions. So, classic and traditional banking services. In Sweden, we are quite a big bank, one of the largest. And we are on a journey of transforming the bank so it has to be online 24-seven. People can do their banking business every day, whenever they want, nothing should stop them to be online. So this is putting a lot of pressure on us on infrastructure to be able to give them that service. (drum fill) >> So our timeline here. Is look, we started out with how to facilitate the container technology it has to be. 2016. And, in 2018, we had the first Docker running in SEB in a standalone mode. You need that. We didn't have any swarm, or given up this cluster since a while. For 2019, we have our first Docker-prise enterprise cluster at SEB. And today, 2020, we have the latest and greatest version of Docker installed. We are running around approximately two and a fifth at 450 specs. Around a thousand services and around 1500 containers. So, developer challenges. As for me as a developer, previous to Docker was really, really hard to get things in production. Times. It took big things and ordering services and infrastructures was a pain in the... yeah, you know what I mean? So for me, it was all about processes. We use natural processes and meaning that I wasn't able to, to see maintaining my system in production. I was handing that over to our operations teams and operation teams in that time, they didn't know how the application works. They didn't know how to troubleshoot it and see, well, what's going wrong. They were experts on the infrastructure and the platforms, but not on our applications. We were working in silos, meaning that I as a developer, only did developing things. The operations side did their things, and the security side did their things. But we didn't work as a team. I mean, today we have a completely different way of working. We will not see shapes. I mean, we have persons that were really good in maybe MQ technologies, or in some programming language and so on, but we didn't have the knowledge in the team techs to solve things, as we should have. Long lead times. I mean, everything we were trying to do had to follow the processes as we had. I mean that we should fill in some forms, send it away, hopefully someone was getting, getting back to us and saying, yeah guys, we can help you out with these services or this infrastructure, but it takes a really long time to do that. I mean, ordering infrastructure is when you're not an expert on that really hard to do. And often the orders we made or placed were wrong. When we have forms to fill in, it wasn't possible for us to do things automatically. Meaning that we didn't have the code, or the infrastructure as code. Meaning that if we didn't get the right persons into the meetings the first time, we didn't have the possibility to do it the right way, meaning that we had to redo and redo, and hopefully sometimes we got the right. We didn't have consistent set ups between the environments. When we order, as for example, a test environment, we could maybe order it with some minor resources, less CPU, so less memory, less disc or whatever. Or actually less performance on the hardware, but then we moved up to production. We realized that we have different hardware, different discs, different memories, and that could actually cause some serious problems in applications, access-wise. I mean, everyone likes to have exercise, especially if you are the maintainer of the system. That was really, really hard to get. I mean, every system has their own services, their own service, and therefore they need to apply for access to those other services. But today there's a complete difference since we only have one class to produce. Since we don't have infrastructure as a code back then, there were really lots of human errors. I mean, everyone was doing things manually. When you're coming from the Windows perspective, everything is a UI. You tend to prefer that way of working, meaning that if you used to click something in between the environments, the environments will not look the same. Life cycles. I mean, just imagine. When we have the server installed, it's like a pet. You have everything configured all from certificates to port openings, cartels, install patches, you name it. And then imagine that Windows are terminating a version and you need to reinstall that. Everything needs to be redone from the beginning. So there was a really long time taking to, to do the LCM activities, General lack of support of Microservice architecture was really also, a thing that are driving us forward with the containers technology, since we can't scale our applications in the same way as for containers. We, for example, couldn't have two applications or two processes using the same TCP port. For example, if you'd like to scale a web server, you can't do that on the same hardware. You need to have two different servers. And just imagine replacing all the excesses, replacing all the orders again for more hardware, and then manually a setting up there. The low balancer in front is a really huge task to do. And necessarily if you don't have the knowledge how the infrastructure is where you're working, then it's also really hard for you as a developer to do things right. Traditionalist. I mean, the services for us are like pets. They were really, really hard to set up. It'd take maybe a week or so. And if something was wrong with them, we will try to fix them as a pet. I mean, we couldn't just kill them and throw them away. It will actually destroy the application as this, our, like a unit box where all our things are installed. >> So, coming in from the infrastructure part of this, we've also seen challenges. For my team, we're coming from a Windows environment. So doing like a DevOps journey, which we want to do, makes it harder due to our nature in our environments. We are not used to, maybe use API, so we are not used to giving open APIs to our developers to do changes on the servers. Since we are a bank, we don't allow users to log into the servers, which means we have to do things for them all the time. This was very time consuming. And a lot of the challenges we actually still are seeing is the existing infrastructure. You can't just put that container platform on it, and thinking you're sold and everything. One of the biggest issues for us is, has been to getting servers. Windows servers usually takes like 15 minutes, Linux servers can takes up to two week in a bad day. So we really lack like, infrastructure as code. If we want a low balancer, that is also an order form. If we want the firewall opening, that's an order form. Hopefully they will not deny it. So it will go faster. So it's a lot of old processes that we need to go through. So what we wanted to do is that we want to move all of these things to the developers, so they can do it. They can own up their problems, but with our old infrastructure, that wasn't possible. We are a heavily ITIL-based organization, meaning that everything went from a cab. Still does in some way, we have one major service window every month where we take everything down. There is a lot of people involved in everything. So it's quite hard to know what will be done during the maintenance window. We lack supporting tools, or we lacked supporting tools, like log-in, good log-in tools. We have a bunch of CI/CD tools, but the maturity level of the infrastructure team wasn't that good. Again, order form and processes. If we want to, like, procure, do our procurement on a new like, storage system, or a backup system, we talk about here. So to do it is, for us, with containers, it would solve a lot of problems, because we cause we would then move the problems, not maybe move the problems to the developer, but we would make it able for them to own their own problems. So everything that we have talked about up till now boils down to business drivers. So the management's gave- gave us some policies to, or what they, how they want to change the company, so we can be this agile and fast moving bank. So one of the biggest drivers are cloud readiness, where Containers comes in perfectly. So we can build it on premises, and then we can move it to the cloud when we are ready but we can't, but we also need an exit strategy to move it back on premises if we need, due to hard regulations. Maybe you can throw it in the air. >> Absolutely. I definitely can. You're absolutely right. We need to develop things in a certain way. So we can move from infrastructure to infrastructure depending, or regardless of the vendor. Meaning that if we are able to run it on-prem, we should be able to run it in cloud or vice versa. We should also be able to move between clouds, and not be forced into one cloud provider. So that's really important for us at SEB. Short time to market is also a thing here. I mean, we are working with the huge customers. I can't name them, but they're really huge. And they need to have us being moving forward. I mean, able to really fast switch from one technology, maybe to another, we are here for them. And it's really important to us to be really fast for us to get new things out in production. All right, maybe. Nothing else? >> I don't, don't really. From the upside, we are in a huge staff DevOps transition. So, or a forced DevOps transition, which means we need to start looking at new infrastructure solutions, maybe deploy our infrastructure parts inside of containers to be able to use it the same way in the cloud. That's what we do prior, do here on premises, we have private clouds which are built on techno- technology, container technology today. So this fits quite good to have the Docker platform being one part of that one. >> Yeah. And this is solid, we are also working really, really actively on open source platforms and open source drivers. We can see that we have a huge amount of vendors in SEB, really huge ones, but we can also see that we can, facilitate open source platforms, and open source technology as well. So container technology will bring that for us. I mean, instead of having a SaaS platform and SaaS services, we can actually instantiate our own with containers and stuff. >> Also we are, since we are quite heavily regulated, the process of going through to you as like a SaaS service can take up to two years for us to go through, and then maybe the SaaS service, is it, is it what we want to use anymore? So, also we want to develop the things in our own premises and maybe, and scale it to the cloud if we need. And also we want to be an attractive employer, where maybe it's not that, the coolest thing for a young student to work in mainframe, we have a mainframe it's, it's not going anywhere, but it's hard to get people, and we want to be an attractive employer, and everyone is talking Kubernetics and containers or, and clouds. So we need to transition into those technologies. >> Yeah, we need to be open minded and necessarily facilitate the new technologies. So we can actually attract new employees. So it's really important to us to have an open mind. Our experience with Docker Containers. I mean, as I said before, scalability is a really important thing for us today. When we are using a more microservice architecture, we need to be able to Skype. We need to be scaling horizontally instead of vertically. So for that, containers are perfect storage. As we said before, we have a huge problem with environments being differently set up, since it was often manually done. Today, as we have a infrastructure as a code, it's really, really nice to have the same things exactly configured, the same in all environments. And we also have the same tooling, meaning that if I can run it on my machine, it's the same tooling I will be using to run it for test purposes or in production. That's a huge benefit for us as a developer. Time to market. I mean, today, we don't have to order service, we are using the service approach here. So we have a container cluster that are actually just sitting there waiting for our services to be hosted. So no more forms, no more calls, no more meetings before we can set up anything. We also own our problems. I mean, before, as I said, we have the processes, meaning that we ship our applications to any server. And then the operation sites take over. That's not the case now. We are actually using this as we should in DevOps. Meaning the other teams are actually responsible for all their errors as well. Even if it's on the infrastructure part, it's completely different if it's a platform's problem, because then it's the platform's team, and we can use different windows. We can try stuff out, we have an open mind. And that says that I can download and try any container image I would like on my developer machine. It's not maybe, okay to run it in production without having the security people look at it. But normally it's really, really much faster instead of waiting maybe six months, we can maybe wait one week or so. And of course less to none LCM activities. I mean, as I said before, it will take months, maybe, to do an LCM activity on multiple servers. Today, our LCM activities more or less are just switching to a new version of the image from Docker hub. That's all we have to do. So that's actually maintained during the processes we have in CI/CD pipelines. >> And the last one. So our keys to success: you should get demanded from the managers and management that everything should be a container. All the new development has to go through a container before you start ordering servers. Everything shall go through a CI/CD pipeline. We don't actually, here at SEB. Our developers build their own CI/CD pipeline. We just provide a platform for them to use it against, and the CI/CD to systems, but they build everything for themselves. Cause they know how their application works, how it should be deployed, with what tools. We just provide them with a tool set. Build a Cross Team. So you should incorporate all the processes that you need, but you should focus on the developer part, because you are building a platform for the developers, not for operations or security. >> And then maybe >> A lot of... >> you'll be able to take flight >> Yeah. Luck has nothing to do with it? Yes, it has. Of course, luck has something to do with it, even if you're really passionate, even if you're really good at some things. I mean, we got some really nice help from Dr. Inc. We were really... Came in with the technology in the right time for us to be, and we had really engaged people with these projects and that's a really luck for us to have. >> Yeah. And also we... I want to thank our colleagues, because we have another container team who started before us. And they have actually run into a lot of organizational problems, which they have sold, so we could piggyback on that, on those solutions. Also, start small and scale it. This is where Docker swarm comes, fits perfectly. So we have actually, we started with swarm. We are moving into Kubernetics in this platform. We will not force-move anything. The developers just should show us, what their- fits their needs. Thank you! >> Thank you very much.

>>from around the globe. It's >>the Cube with digital coverage of Dev >>Ops Virtual Forum Brought to You by Broadcom. Welcome to Broadcom, Step Ups, Virtual Forum I and Lisa Martin and I'm joined by another Martin very socially. Distance from me all the way. Coming from Birmingham, England, is Glynn Martin, head of Q. A transformation at BT Glenn. It's great to have you on the program. >>Thank you, Lisa. I'm looking forward, Toa. >>As we said before, we went live to Martin's for the price of one in one segment. So this is gonna be an interesting segment, Guesses. What we're gonna do is Glen's gonna give us a really kind of deep inside out view of Dev ops. From an evolution perspective, Soglo's Let's start transformation is at the heart of what you dio. It's obviously been a very transformative year. How have the events of this year affected the transformation that you are so responsible for driving? >>Yeah. Thank you, Leigh. So I mean, yeah, it has been a difficult year Bond, although working for BT, which is ah, global telecommunications company. Relatively resilient, I suppose, as an industry through covert, it obviously still has been affected and has got its challenges on bond. If anything is actually caused us to accelerate of our transformation journey, you know, we had to do some great things during this time around. You know, in the UK for our emergency and health workers give them unlimited data and for vulnerable people to support them and that spent that we've had to deliver changes quickly. Um, but what? We want to be able to do it, deliver those kind of changes quickly, but sustainably for everything that we do, not just because there's an emergency eso we were already on the kind of journey to by John, but ever so ever more important now that we are what we're able to do, those that kind of work, do it more quickly on. But it works because the implications of it not working is could be terrible in terms of, you know, we've been supporting testing centers, new hospitals to treat covert patients, so we need to get it right and therefore the coverage of what we do, the quality of what we do and how quickly we do. It really has taken on a new scowling what was already a very competitive market within the telco industry within the UK. Um, you know, what I would say is that you know, we are under pressure to deliver more value, but we have small cost challenges. We have to obviously deal with the fact that you know, Cove in 19 has hit most industries kind of revenues and profits. So we've got this kind of paradox between having less cost, but they're having to deliver more value quicker on bond, you know, to higher quality. So, yeah, certainly the finances is on our minds. And that's why we need flexible models, cost models that allow us to kind of do growth. But we get that growth by showing that we're delivering value, especially in, you know, these times when there are financial challenges on companies. >>So one of the things that I want to ask you about again looking at, develops from the inside out on the evolution that you've seen you talked about the speed of things really accelerating in this last nine months or so. When we think Dev ops, we think speed. But one of the things I love to get your perspective on we've talked about in a number of the segments that we've done for this event is cultural change. What are some of the things that scene there as as needing to get, as you said, get things right but done so quickly to support essential businesses, essential workers? How have you seen that cultural shift? >>Yeah, I think you know, before, you know, test test team saw themselves of this part of the software delivery cycle. Andi, actually, now, really, our customers were expecting their quality and to deliver for our customers what they want. Quality has to be ingrained throughout the life cycle. Obviously that you know, there's lots of buzzwords like shift left. How do you do? Shift left testing. But for me, that's really instilling quality and given capabilities shared capabilities throughout the life cycle. That Dr you know, Dr Automation drive improvements. I always say that you know, you're only as good as your lowest common denominator on one thing that we're finding on our Dev Ops Journey Waas that we were you know, we would be trying thio do certain things quicker and had automated build automated tests. But if we were taking weeks to create test scripts or we were taking weeks to manly craft data, and even then when we had taken so long to do it that the coverage was quite poor and that led to lots of defects later in the lifecycle or even in in our production environment, we just couldn't afford to do that. And actually, you know, focusing on continuous testing over the last 9 to 12 months has really given us the ability Thio delivered quickly across the the whole life cycle and therefore actually go from doing a kind of semi agile kind of thing where we did you use the stories we did a few of the kind of, you know, as our ceremonies. But we weren't really deploying any quicker into production because, you know, our stakeholders were scared that we didn't have the same control that we had when we had more water for releases. And, you know, when way didn't think ourselves. So we've done a lot of work on every aspect, especially from a testing point of view, every aspect of every activity, rather than just looking at automated test, you know, whether it is actually creating the test in the first place, Whether it's doing security testing earlier in the light and performance testing. Learn the life cycle, etcetera. So, yeah, it Z It's been a riel key thing that for for C T for us to drive, develops, >>talk to me a little bit about your team. What are some of the shifts in terms of expectations that you're experiencing and how your team interacts with the internal folks from pipeline through life cycle? >>Yeah, we've done a lot of work on this, you know, there's a thing. I think people were pretty quiet. Customer experience. Gap. It reminds me of a cart, a Gilbert cartoon where, you know, we start with the requirements here on Do you know, we almost like a Chinese whisper effects and what we deliver eyes completely, completely different. So we think the testing team or the the delivery team, you know, you know, you think they've done a great job. This is what it said in the acceptance criteria, but then our customers the same Well, actually, that's not working. This isn't working, you know, on there's this kind of gap Way had a great launched this year of actual Requirement Society, one of the board common tools Onda that for the first time in in since I remember actually working within B. T, I had customers saying to may, Wow, you know, we want more of this. We want more projects, um, to have a actual requirements design on it because it allowed us to actually work with the business collaboratively. I mean, we talk about collaboration, but how do you actually, you know, do that have something that both the business on technical people can understand? And we've actually been working with the business using at our requirement. Designer Thio, you know, really look about what the requirements are. Tease out requirements to the hadn't even thought off and making sure that we've got high levels of test coverage. And so what we actually deliver at the end of it, not only have you been able Thio generate test more quickly, but we've got much higher test coverage and also can more smartly, you're using the kind of AI within the tour and with some of the other kind of pipeline tools actually deliver to choose the right tests on the bar, still actually doing a risk based testing approach. So that's been a great launched this year, but just the start of many kind of things that we're >>doing. But what I hear in that Glenn is a lot of positives that have come out of a very challenging situation. Uh, talk to me about it and I like that perspective. This is a very challenging time for everybody in the world, but it sounds like from a collaboration, perspective is you're right. We talk about that a lot critical with Dev Ops. But those challenges there you guys were able to overcome those pretty quickly. What other challenges did you face and figure out quickly enough to be able to pit it so fast? >>I mean, you talked about culture. I mean, you know, Bt is like most come countries companies. So, um, is very siloed. You know, we're still trying to work to become closer as a company. So I think there's a lot of challenges around. How do you integrate with other tools? How do you integrate with you know, the various different technologies and bt we have 58 different whitey stacks? That's not systems that stacks all of those stacks of can have, you know, hundreds of systems on we're trying to. We're gonna drive at the moment a simplified program where we're trying Thio, you know, reduce that number 2 14 stacks. And even then they'll be complexity behind the scenes that that we will be challenged. Maurin Mawr As we go forward, how do you actually hired that to our users on as an I T organization? How do we make ourselves Lena so that even when we you know, we've still got some of that legacy and we'll never fully get rid of it on that's the kind of trade off that we have to make. How do we actually deal with that and and hide that for my users a say and and and drive those programs so we can actually accelerate change. So we take, you know, reduce that kind of waste, and that kind of legacy costs out of our business. You know, the other thing is, well, beating. And I'm sure you know telecoms probably no difference to insurance or finance we've got You know, when you take the number of products that we do and then you combine them, the permutations are tens and hundreds of thousands of products. So we as a business to trying to simplify. We are trying Thio do that in a natural way and haven't trying to do agile in the proper way, you know, and really actually work it paste really deliver value. So I think what we're looking Maura, Maura, at the moment is actually, um is more value focus? Before we used to deliver changes, sometimes into production, someone had a great idea or it was a great idea nine months ago or 12 months ago. But actually, then we end up deploying it. And then we look at the the the users, you know, the usage of that product of that application or whatever it is on. It's not being used for six months, so we're getting much we haven't got, you know, because of the last 12 months, we certainly haven't got room for that kind of waste and you know, the for not really understanding the value of changes that we we are doing. So I think that's the most important thing at the moment is really taken that waste out. You know, there's lots of focus on things like flow management. What bits of the our process are actually taking too long, and we've We've started on that journey, but we've got a hell of a long way to go, you know, But that that involves looking every aspect off the kind of software delivery cycle. >>What are some? Because that that going from, what, 58 i t stocks down to 14 or whatever it's going to be go simplifying is sounds magical. Took everybody. It's a big challenge. What are some of the core technology capabilities that you see really as kind of essential for enabling that with this new way that you're working? >>Yeah. I mean, I think we've started on a continuous testing journey, and I think that's just the start. I mean, that's really, as I say, looking at every aspect off, you know, from a Q, a point of view. It's every aspect of what we dio. But it's also looking at, you know, we're starting to branch into more like a AI ops and, you know, really, the full life cycle on. But, you know, that's just a stepping stone onto, you know, I think oughta Nomics is the way forward, right? You know all of this kind of stuff that happens um, you know, monitoring, you know, monitoring systems, what's happening in production had to be feed that back. How do you get to a point where actually we think about a change on then suddenly it's in production safely. Or if it's not going to safety, it's automatically backing out. So, you know, it's a very, very long journey. But if we want Thio, you know, in a world where the pace is ever increasing the demands of the team and you know, with the pressures on at the moment where with we're being asked to do things, you know more efficiently Ondas leaving as possible. We need to be, you know, thinking about every part of the process. And how do we put the kind of stepping stones in players to lead us to a more automated kind of, you know, their future? >>Do you feel that that plant outcomes are starting to align with what's delivered? Given this massive shift that you're experiencing, >>I think it's starting to, and I think you know, Azzawi. Look at more of a value based approach on. Do you know a Zeiss? A princess was a kind of flight management. I think that's that will become ever evermore important. So I think it's starting to people. Certainly realized that, you know, people teams need to work together. You know, the kind of the cousin between business and ICT, especially as we go Teoh Mawr kind of sad space solutions, low cold solutions. You know there's not such a gap anymore. Actually, some of our business partners expects to be much more tech savvy. Eso I think you know, this is what we have to kind of appreciate. What is I ts role? How do we give the capabilities become more for centers of excellence rather than actually doing Mount amount of work And for May and from a testing point of view, you know, amount, amount of testing, actually, how do we automate that? How do we actually generate that instead of created? I think that's the kind of challenge going forward. >>What are some? As we look forward, what are some of the things that you would like to see implemented or deployed in the next say, 6 to 12 months as we hopefully round a corner with this pandemic? >>Yeah, I think you know, certainly for for where we are as a company from a Q A perspective. We are. Yeah, there's certain bits that we do Well, you know, we've started creating continuous delivery. A day evokes pipelines. Um, there's still manual aspects of that. So, you know, certainly for May I I've challenged my team with saying, How do we do an automated journey? So if I, you know, I put a requirement injera or value whoever it is, that's why. Then click a button on bond, you know, with either zero touch of one touch, then put that into production and have confidence that that has been done safely on that it works. And what happens if it doesn't work? So you know, that's that's the next in the next few months, that's what our concentration is about. But it's also about decision making, you know, how do we actually understand those value judgements? And I think there's lots of the things Dev ops, ai ops, kind of always that aspects of business operations. I think it's about having the information in one place to make those kind of decisions. How does it all tied together, as I say, even still with kind of Dev ops, we've still got elements within my company where we've got lots of different organizations doing some doing similar kind of things but the walking of working in silos Still. So I think, having a eye ops Aziz becomes more and more to the fore as we go to the cloud. And that's what we need to. You know, we're still very early on in our cloud journey, you know. So we need to make sure the technologies work with Cloud as well as you kind of legacy systems. But it's about bringing that all together and having a full visible pipeline. Everybody can see and make decisions against >>you said the word confidence, which jumped out at me right away. Because absolutely, you've gotta have be able to have confidence in what your team is delivering and how it's impacting the business and those customers. Last question for you is how would you advise your peers in a similar situation to leverage technology automation, for example, dev ops to be able to gain the confidence that they're making the right decisions for their business? >>Yeah, I mean, I think the the approach that we've taken actually is not started with technology we've actually taken human centered design a za core principle of what we dio within the i t part of BT. So by using humans tend to design. That means we talked to our customers. We understand their pain points, we map out their current processes on. But when we mapped out, those processes also understand their aspirations as well, you know, Where do they want to be in six months? You know, Do they want to be more agile and you know, or do they want Teoh? Is this apart their business that they want thio run better? We have to Then look at why that's not running well and then see what solutions are out there. We've been lucky that, you know, with our partnership with Broadcom within the P l. A. A lot of the tortures and the P l. A have directly answered some of the businesses problems. But I think by having those conversations and actually engaging with the business, um, you know, especially if the business hold the purse strings, which is you know, in some companies, including as they do there is that kind of, you know, almost by understanding their their pain points and then saying This is how we can solve your problem We've tended to be much more successful than trying Thio impose something and say We're here to technology that they don't quite understand doesn't really understand how it could have resonate with their problems. So I think that's the heart of it is really about, you know, getting looking at the data, looking at the processes, looking at where the kind of waste is on. Then actually then looking at the right solutions. And as I say, continuous testing is a massive for us. We've also got a good relationship with capitals looking at visual ai on. Actually, there's a common theme through that, and I mean, AI is becoming more and more prevalent, and I know yeah, sometimes what is A I and people have kind of the semantics of it. Is it true, ai or not? But yes, certainly, you know, AI and machine learning is becoming more and more prevalent in the way that we work, and it's allowing us to be much more effective, the quicker and what we do on being more accurate. You know, whether it's finding defects, running the right tests or, you know, being able to anticipate problems before they're happening in a production environment. >>Welcome. Thank you so much for giving us this sort of insight. Outlook at Dev Ops, sharing the successes that you're having taking those challenges, converting them toe opportunities and forgiving folks who might be in your shoes or maybe slightly behind advice. I'm sure they appreciate it. We appreciate your time. >>It's been an absolute pleasure, Really. Thank you for inviting me of Extremely enjoyed it. So thank you ever so much. >>Excellent. Me too. I've learned a lot for Glynn Martin and Lisa Martin. You're watching the Cube?