(upbeat soft intro music) >> Hey everyone. Welcome back to theCube's live coverage from Los Angeles of KubeCon and CloudNativeCon 2021. Lisa Martin with Dave Nicholson, Dave and I are pleased to welcome our next guest remotely. Steven Huels joins us, the senior director of Cloud Services at Red Hat. Steven, welcome to the program. >> Steven: Thanks, Lisa. Good to be here with you and Dave. >> Talk to me about where you're seeing traction from an AI/ML perspective? Like where are you seeing that traction? What are you seeing? Like it. >> It's a great starter question here, right? Like AI/ML is really being employed everywhere, right? Regardless of industry. So financial services, telco, governments, manufacturing, retail. Everyone at this point is finding a use for AI/ML. They're looking for ways to better take advantage of the data that they've been collecting for these years. It really, it wasn't all that long ago when we were talking to customers about Kubernetes and containers, you know, AI/ML really wasn't a core topic where they were looking to use a Kubernetes platform to address those types of workloads. But in the last couple of years, that's really skyrocketed. We're seeing a lot of interest from existing customers that are using Red Hat open shift, which is a Kubernetes based platform to take those AI/ML workloads and take them from what they've been doing for additionally, for experimentation, and really get them into production and start getting value out of them at the end of it. >> Is there a common theme, you mentioned a number of different verticals, telco, healthcare, financial services. Is there a common theme, that you're seeing among these organizations across verticals? >> ^There is. I mean, everyone has their own approach, like the type of technique that they're going to get the most value out of. But the common theme is really that everyone seems to have a really good handle on experimentation. They have a lot of very brig data scientists, model developers that are able to take their data and out of it, but where they're all looking to get, get our help or looking for help, is to put those models into production. So ML ops, right. So how do I take what's been built on, on somebody's machine and put that into production in a repeatable way. And then once it's in production, how do I monitor it? What am I looking for as triggers to indicate that I need to retrain and how do I iterate on this sequentially and rapidly applying what would really be traditional dev ops software development, life cycle methodologies to ML and AI models. >> So Steve, we're joining you from KubeCon live at the moment. What's, what's the connection with Kubernetes and how does Kubernetes enable machine learning artificial intelligence? How does it enable it and what are some of the special considerations to in mind? >> So the immediate connection for Red Hat, is Red Hat's open shift is basically an enterprise grade Kubernetics. And so the connection there is, is really how we're working with customers and how customers in general are looking to take advantage of all the benefits that you can get from the Kubernetes platform that they've been applying to their traditional software development over the years, right? The, the agility, the ability to scale up on demand, the ability to have shared resources, to make specialized hardware available to the individual communities. And they want to start applying those foundational elements to their AI/Ml practices. A lot of data science work traditionally was done with high powered monolithic machines and systems. They weren't necessarily shared across development communities. So connecting something that was built by a data scientist, to something that then a software developer was going to put into production was challenging. There wasn't a lot of repeatability in there. There wasn't a lot of scalability, there wasn't a lot of auditability and these are all things that we know we need when talking about analytics and AI/ML. There's a lot of scrutiny put on the auditability of what you put into production, something that's making decisions that impact on whether or not somebody gets a loan or whether or not somebody is granted access to systems or decisions that are made. And so that the connection there is really around taking advantage of what has proven itself in kubernetes to be a very effective development model and applying that to AI/ML and getting the benefits in being able to put these things into production. >> Dave: So, so Red Hat has been involved in enterprises for a long time. Are you seeing most of this from a Kubernetes perspective, being net new application environments or are these extensions of what we would call legacy or traditional environments. >> They tend to be net new, I guess, you know, it's, it's sort of, it's transitioned a little bit over time. When we first started talking to customers, there was desire to try to do all of this in a single Kubernetes cluster, right? How can I take the same environment that had been doing our, our software development, beef it up a little bit and have it applied to our data science environment. And over time, like Kubernetes advanced rights. So now you can actually add labels to different nodes and target workloads based on specialized machinery and hardware accelerators. And so that has shifted now toward coming up with specialized data science environments, but still connecting the clusters in that's something that's being built on that data science environment is essentially being deployed then through, through a model pipeline, into a software artifact that then makes its way into an application that that goes live. And, and really, I think that that's sensible, right? Because we're constantly seeing a lot of evolution in, in the types of accelerators, the types of frameworks, the types of libraries that are being made available to data scientists. And so you want the ability to extend your data science cluster to take advantage of those things and to give data scientists access to that those specialized environments. So they can try things out, determine if there's a better way to, to do what they're doing. And then when they find out there is, be able to rapidly roll that into your production environment. >> You mentioned the word acceleration, and that's one of the words that we talk about when we talk about 2020, and even 2021, the acceleration in digital transformation that was necessary really a year and a half ago, for companies to survive. And now to be able to pivot and thrive. What are you seeing in terms of customers appetites for, for adopting AI/ML based solutions? Has it accelerated as the pandemic has accelerated digital transformation. >> It's definitely accelerated. And I think, you know, the pandemic probably put more of a focus for businesses on where can they start to drive more value? How can they start to do more with less? And when you look at systems that are used for customer interactions, whether they're deflecting customer cases or providing next best action type recommendations, AI/ML fits the bill there perfectly. So when they were looking to optimize, Hey, where do we put our spend? What can help us accelerate and grow? Even in this virtual world we're living in, AI/ML really floated to the top there, that's definitely a theme that we've seen. >> Lisa: Is there a customer example that you think that you could mention that really articulates the value over that? >> You know, I think a lot of it, you know, we've published one specifically around HCA health care, and this had started actually before the pandemic, but I think especially, it's applicable because of the nature of what a pandemic is, where HCA was using AI/ML to essentially accelerate diagnosis of sepsis, right. They were using it for, for disease diagnoses. That same type of, of diagnosis was being applied to looking at COVID cases as well. And so there was one that we did in Canada with, it's called 'how's your flattening', which was basically being able to track and do some predictions around COVID cases in the Canadian provinces. And so that one's particularly, I guess, kind of close to home, given the nature of the pandemic, but even within Red Hat, we started applying a lot more attention to how we could help with customer support cases, right. Knowing that if folks were going to be out with any type of illness. We needed to be able to be able to handle that case, you know, workload without negatively impacting work-life balance for, for other associates. So we looked at how can we apply AI/ML to help, you know, maintain and increase the quality of customer service we were providing. >> it's a great use case. Did you have a keynote or a session, here at KubeCon CloudNative? >> I did. I did. And it really focused specifically on that whole ML ops and model ops pipeline. It was called involving Kubernetes and bracing model ops. It was for a Kubernetes AI day. I believe it aired on Wednesday of this week. Tuesday, maybe. It all kind of condenses in the virtual world. >> Doesn't it? It does. >> So one of the questions that Lisa and I have for folks where we sit here, I don't know, was it year seven or so of the Dawn of Kubernetes, if I have that, right. Where do you think we are, in this, in this wave of adoption, coming from a Red Hat perspective, you have insight into, what's been going on in enterprises for the last 20 plus years. Where are we in this wave? >> That's a great question. Every time, like you, it's sort of that cresting wave sort of, of analogy, right? That when you get to top one wave, you notice the next wave it's even bigger. I think we've certainly gotten to the point where, where organizations have accepted that Kubernetes can, is applicable across all the workloads that they're looking to put in production. Now, the focus has shifted on optimizing those workloads, right? So what are the things that we need to run in our in-house data centers? What are things that we need, or can benefit from using commodity hardware from one of the hyperscalers, how do we connect those environments and more effectively target workloads? So if I look at where things are going to the future, right now, we see a lot of things being targeted based on cluster, right? We say, Hey, we have a data science cluster. It has characteristics because of X, Y, and Z. And we put all of our data science workloads into that cluster. In the future, I think we want to see more workload specific, type of categorization of workloads so that we're able to match available hardware with workloads rather than targeting a workload at a specific cluster. So a developer or data scientist can say, Hey, my particular algorithm here needs access to GPU acceleration and the following frameworks. And then it, the Kubernetes scheduler is able to determine of the available environments. What's the capacity, what are the available resources and match it up accordingly. So we get into a more dynamic environment where the developers and those that are actually building on top of these platforms actually have to know less and less about the clusters they're running on. It just have to know what types of resources they need access to. >> Lisa: So sort of democratizing that. Steve, thank you for joining Dave and me on the program tonight, talking about the traction that you're seeing with AI/ML, Kubernetes as an enabler, we appreciate your time. >> Thank you. >> Thanks Steve. >> For Dave Nicholson. I'm Lisa Martin. You're watching theCube live from Los Angeles KubeCon and CloudNativeCon 21. We'll be right back with our next guest. (subtle music playing) >> Lisa: I have been in the software and technology industry for over 12 years now. So I've had the opportunity as a marketer to really understand and interact with customers across the entire buyer's journey. Hi, I'm Lisa Martin and I'm a host of theCube. Being a host on the cube has been a dream of mine for the last few years. I had the opportunity to meet Jeff and Dave and John at EMC World a few years ago and got the courage up to say, Hey, I'm really interested in this. I love talking with customers...

>> 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.