BMW Logo
Branche: Automotive
Ort Germany

How BMW is adopting containers

Highlights

  • Enables DevOps teams to manage several clusters across several locations in the same way.
  • User interface is the same, regardless of infrastructure platform.
  • Able to manage and maintain hyperconverged infrastructure with lower effort.

Produkte

  • Harvester
  • Support and Services
  • Rancher ›
  • Longhorn Block Storage

At-a-Glance

In May 2022, Greg Muscarella, former general manager of enterprise container management at SUSE, interviewed Andreas Poeschl, head of Edge computing and container runtime at BMW, about how the manufacturer is using Rancher to keep its factories at the forefront of automotive manufacturing.

Watch the interview

"In the past, one of the issues were always maintenance, upgrades, dependencies, and therefore, of course, the move from this old VM based operating system, monolithic style to modern applications, containerized and orchestrated, usually via Kubernetes is the natural evolution from our perspective."

Interview transcript

Hello, and welcome everyone. I've got Andreas Poeschl here with me. He is the head of Edge Computing and Container Runtimes at BMW and we're here to talk about how BMW is adopting containers. So welcome, Andreas.

Thanks Greg.

Hey, I just want to get this kicked off real quick to kind of think about what the high level is at BMW. Would you mind telling us a bit about what the strategic direction is for IT and applications at BMW?

Yeah, of course. As we are currently seeing a big increase of modern requirements of new use cases, we are currently driving a public cloud-first strategy at BMW. We are still in this space of kicking off that move of also existing workloads to public clouds, developing new workloads only on public cloud and therefore leveraging the potential of public cloud services. Besides that, there's also this Edge part. So, to us, public cloud always means public cloud plus Edge where necessary. Because it's all cloud native workload, it has to be cloud native. It's not just classical IT 2.0. It's a completely new concept, new approaches, new ways of operating, of developing, and therefore the big move is to forge public cloud first.

That makes sense. And a lot of people when they move to public cloud, there's sort of a choice that they make. They either want to kind of go deep on one cloud and kind of get commitment there so they can kind of go and use all the services on that side. And some want to be a little bit more multi-cloud oriented. So, they want to stay up... And that's one of the advantages that a Kubernetes or cloud native environment brings is they can kind of move between clouds, not momentarily, but it's a little bit easier to architect across clouds. Does BMW have a strategy on this?

So yes, we also work with two primary public cloud offers and usually it is dependent on the area of the application or the business. So, in all of the different processes, we have got more one primary cloud provider and the other one being secondary. But nevertheless, we would like to be able to switch back and forth as you mentioned, not instances, but more from a strategic perspective. So, it should be possible to have the same services available also with another partner.

So, you're looking for that flexibility should you need it to.

Indeed, indeed. And also, to leverage the services which suit the requirements best because every cloud provider has got its own strengths and weaknesses, and therefore we would like to leverage the services that fits our requirements best in each area of the application or the business.

Totally makes sense. But if I think about BMW, you guys have operations around the world. And so, while you move a lot of your applications in the public cloud, no doubt you have compute needs down in your factories and other locations. So, what do you use there and what are the applications that you're running for things that maybe you can't move to the public cloud?

So currently we of course have this classical setup that we use virtual machines in plant data centers and also in central locations. And what we are now doing is move the core components towards public cloud so we can leverage the PaaS services and the even SaaS services there. On the other hand, we have got some parts of these applications which are directly connected to locations. So, we need a connection to production systems to shop floor. We have got requirements in terms of low latency. We've got high data volume where we don't want or are not able to send the big data volume back and forth to cloud and back. And therefore, we will have this Edge part in plant locations primarily, but we could also think of other smaller locations, and these will be kind of extension of the public cloud into our own infrastructure, into our own locations.

I get that, the latency and the bandwidth constraints. Could you give me like an example like the type of application that you'd run there so we can sort of wrap our heads around it a little bit?

So, in terms of latency, as one example, just imagine you have got some automated logistic devices in the plant where you try to control logistic trains, autonomous logistic elements. And in terms of latency, if you just imagine a fairly slow vehicle, six kilometers per hour, and then a typical latency to public cloud of 50 to 60 milliseconds, the distance this slow vehicle would move within the 60 milliseconds would be 10 centimeters. So that's enough to crash into something if really necessary.

If we go on Edge and are at the one, two, three millisecond range, that's down to five millimeters. So that would be something that really need that low latency, or in terms of communication to some components on the shop floor where it is about synchronous communication. You just cannot do that directly to the cloud.

In terms of high data volume, just imagine lots of cameras, high density, high definition cameras taking pictures and videos of the cars moving along of the paint shop or during the final assembly where we try to find issues, errors, and therefore improve the quality by that visual measurement. And that creates also a high amount of data, and it makes sense to pre-process that on Edge, and then do maybe the final work in a central public cloud environment.

Thanks. That actually helps me understand a lot better. Those are very interesting applications as well and I can see the challenge that you guys face. When I look at these types of applications, like what made cloud native as an architectural choice attractive to you? Why did BMW go in that direction?

In the past, one of the issues were always maintenance, upgrades, dependencies, and therefore, of course, the move from this old VM based operating system, monolithic style to modern applications, containerized and orchestrated, usually via Kubernetes is the natural evolution from our perspective. Because there we can have the best separation of the workload and the underlying infrastructure. We have the opportunity to do really zero downtime maintenance (planned at least), and therefore improve the availability of the system. On the other hand, we reduce the effort to maintain it, to make sure that all the components work together because they are perfectly encapsuled and then we can have the separate release cycles on the different components without interfering.

So, both getting the microservices architecture, so like you said, independent services that can be updated and swapped out individually.

Yeah.

Okay. Makes sense. That all sounds fantastic. And now, you've been working with Rancher for a little while in your factories. What did Rancher bring to your architecture, your environment? Why did you choose Rancher for your factories?

So, we were looking for some management interface where we can really work with all the different plants. We've got different locations, different setups, but nevertheless, we would like to help our internal customers, which are the application groups, the DevOps teams, to manage several clusters in several locations, the same way. In terms of user management, in terms of policies. And what we appreciated with Rancher was the opportunity to work on different infrastructure platforms. We are using Harvester right now, and there we have got the opportunity to use our standard service actually out of the regular purchasing. We use those servers with a lot of discs in there, combine that with Longhorn, to have a storage system and have this hyperconverged infrastructure based on Harvester. And we can manage and maintain that on one hand on a very low level, the Harvester cluster itself, or on high level with Rancher. And that combination is something that gives us the benefit of lower effort.

That's fantastic. I'm glad that we had the tools to fit into your environment, how you want to work and how your business works. So, I'm looking forward to more success on that front. Now, if we took and looked forward a little bit more, what do you see coming next for BMW at the Edge and with containers everywhere?

Good question. Because actually this is a fairly new journey. And currently we are also collecting our experience. We have got a very good footprint on-premises. We started to do a lot of things in cloud with specific workloads, but now as we see this migration and that transformation of this classical workloads into public cloud, into modern architecture, modern concepts, I hope that we will reduce the overall effort a lot because we are able to use higher levels of services coming from Infrastructures as a Service to PaaS and SaaS services and therefore reducing the overall IT effort. On the other hand, improving the service for the business, gaining speed, gaining stability, improving availability. And that's from my perspective, the main reason to go on that journey towards public cloud and Edge, which belongs together as I mentioned.

It seems like you guys have made some awesome first steps on that. And I'm looking forward to seeing how BMW continues to innovate. Thank you so much for sharing your story with us and for taking the time.

Yeah, you're welcome.