 So I just want to quickly have you each introduce yourselves, you know, say which company you're from and a little bit about what your company is doing. Just briefly before we get into the questions, maybe some of your own background. So we'll start with Stefan. So my name is Stefan Bauer. So I'm coming from Audi. I'm heading a department that is taking care of, let's say, collecting and processing all the data our cars are producing during the usage of the car. So we're primarily building up a platform which should be able to be very flexible and to handle a lot of data, as I said, we will be able to make good new products for our customers. So personally, I'm with Audi since, I guess, 15 years. So we have a history in software, of course, mainly in embedded software, and now we are spreading out into the backend software as well so that the car is part of the IoT world. Yeah, I'm Hubert Fischer, also from Audi. I'm the senior project manager of the IoT project, collecting vehicle sensor data. I've been in several projects before within the company, and now I'm part of the transition the company goes through from a pure hardware developing company to an IoT company. Hello, my name is Oliver Goldisch from Deutsche Telekom. I'm a manager in the network and service area. We are using DCOS in particular and this MAC stack for creating more value for our customers in terms of selecting access networks. So I can briefly give more updates later, but we're using this MAC stack for that. Yeah, good morning. My name is Christian Wolbs. I'm a product architect or within ASML. So I'm doing this for a project which is a compute and data platform. We are, I think, quite new in this MAC stack. So we started beginning of this year and we are not using all of the letters right now. And so I'm eager to learn and exchange information throughout the next two days. Great. So we'll start again with you. I sort of wanted to ask, as much as you can share about your infrastructure with regard to what technologies are you using, the size of the infrastructure, whatever you're comfortable with sharing, I'm sure many in the audience would be interested to know. For us, the challenge is we are a Dutch equipment manufacturer which are sending out machines to our customers. And these machines are operating and creating a tremendous amount of data. And our compute platform now needs to be able to properly scale and compute and storage, but also needs to be able to properly actually tackle individual failure modes down to cross data center availability. And that's, we have chosen measures for an infrastructure that we can actually operate the compute and the data capabilities. So we are, of that stack, we are using measures and the Kafka part. We are heading out to the Spark computations in the future. And that's what we are chosen for. Oliver, what do we tell us about Georgia Telecom? Yeah, so we had a problem that we started about two years ago. I think everyone knows it. At least we have all of the Wi-Fi password here on our badge. But actually, we try to automate that so that our customers can get into Wi-Fi networks but with a good, very good quality. So if the Wi-Fi is really poor, you don't get there. So what we started to build is a mobile application that collects enormous amount of information about the access networks you're facing as a customer and we want to give recommendations on a mobile application deployed, which X networks you're going to be steered. And this was quite a challenge to go with an old stack infrastructure and since we expect a bigger customer base come there, the distributed way of how this Mac stack is designed gives us quite a lot of opportunities here. Yeah, so we have millions of car out there equipped with onboard communication units for data collecting. So they're listening to the bus systems in the car and sending those data generated out to a back end. So back end is our project to set up. We use all the five letters of this Mac stack to ingest those data, to do real-time analytics of those data coming in, identifying patterns and course reactions back in the car to the customer. And we do use Spark for that specific purpose. The whole infrastructure is currently based on Amazon, but we have the approach to be and to stay cloud agnostic. And for that, DCS helps us a lot to spread the load between different cloud providers to get a perfect exploitation of the cloud resources which are expensive. And we stay independent from any cloud provider so we can switch from one to another in using DCS. Great. If you let me add some more aspects. Yes, we are a global company. What is very, very important to also to have global solutions. And for that, we know there are different countries where maybe we can use Amazon, maybe we are not able to use, maybe in the look to China. There's always a little bit, let's say, legal uncertainty. What you can do is though, what is very, very crucial to be able to independently from the single infrastructure provider. And even to have the possibility to make some hybrid solutions. As part of the Volkswagen Group, we also have a lot of internal capacity for data centers. So in future, I have in mind that we really could use both internal, external data center for this purpose. Great. So I think I heard a little bit from a couple of you using the full smack stack. So that's Spark, Mesos, Acca, Cassandra, and Kafka. So you guys are using all the letters, I think most of the panel here. And then you're using three of them, right? Yeah, okay. So I guess specifically speaking to the smack stack and the collection of technologies, that is, what has that on the application level? You've touched upon that a little bit. But if there's anything you'd like to add, what has that specific data driven pipeline done for you? Well, for us, I guess the most important thing is the fast, the fastness as we want to do our analytics in real time. So we really want to go out and to go into that field of being able to react immediately on situations that are happening in a single call. And with that, we have to be able to know what's happening outside and to be able to get the knowledge that we gathered from the rest of the fleet. To be able to send directly to the single call. So that's crucial for us. Yeah, and next to the whole analytic stuff, it's important for us not to lose any data. You can imagine we have millions of cars sending in seconds, millions of data. So we need some kind of infrastructure which is capable of collecting those data and not losing any of those. Yeah, sure. Just the distributed workloads are quite an advantage of the SMAC stack. And especially if you don't have customers there, you can really scale them on the infrastructure as well. Which is not so bad as well. Yeah, which sort of leads me into my next question. And we'll start over there. It's sort of talking about the application level, but also the infrastructure level, how using containers and DCOS and the SMAC stack has really, has that helped you build out your infrastructure and plan for the future? If you could speak to that a little bit, if you. So what we are looking forward to and what also the last year of that project has shown that we gain actually the capability and the flexibility to scale, to have the high availability, to also dynamically use and reuse the resources that are on the hardware level available for our applications. And what we build within our computer data platform is the foundation for the applications that are built on top of that. So also we are providing a middle layer towards our application developers actually. Sure, and just to add this was not an easy road to get everything in the containers. But yeah, so. Did you do incrementally or did you do like one big switch over? We built it completely new. New one? Because the mind shift is quite hard. Well, telcos maybe sometimes occur to be a little bit old fashioned. So when I started the project, we asked, yeah, where is DVM? So, yeah. Yeah, and then talking about containers, we're looking forward to software defined networking and software defined storage. So that would be a really good, good next step for the whole SMAC stack. So as you're looking, we've got a lot of people in the audience who are planning on moving to the SMAC stack or are just getting started. If you could talk about some of the challenges or successes that you've had in your migration over to a SMAC stack that people can benefit from. I guess when we have in our history, our schools recommend try to start on a green field to really get up from the scratch to be able to get all the advantages you get out of such a SMAC stack. And the second issue is start with some PUCs, of course, on an open source basis, but we really want to be an enterprise level. So for our companies, we have big companies here in the round here. We need professional support. You need professional services. So as soon as possible, change to the enterprise versions. So, yes, it's not advertising here. I didn't tell him to say that. No, as you see, in our mind, when I go to my board and say, okay, you're introducing a new architecture and new software. So where's the support structure? Who could we call when something is going wrong? What about a downtime? What about some issues or bugs, whatever? Because a lot of the board members think open source is something for freaks, something for, yeah, you can do it at your home-based software development, but nothing for enterprise. So to convince them that it's a professional way of working enterprise versions are very helpful. So to quickly go back to green fields, did you have existing infrastructure that you had to move over or were you able really to start with a fresh project? Yes, we were lucky and we were able to start with a fresh project. So with a clean Amazon infrastructure, yeah. To add there, we had the same challenge. We needed to convince our management that we don't go with our operations team, but rather deploy it on Azure, because we're faster in using a public cloud service. And we directly started with the premium enterprise licenses. And it was just easier with the support of the vendor. We iterated very, in very small cycles. This helped us a lot, not to go too far, just one step ahead. And did you have a legacy infrastructure to move over at all or were you starting? Everything new, yeah, that's the easiest way. I'm sure it is, yeah. How about over? So yes, we are two-way actually. So we do have a hardware platform. That we currently ship to our customers, where our software is running on. But we have to grow out of that infrastructure. So we move into our customers' data center with the deployment of our platform. And the second aspect is that we do have to keep the investments that we had already to the compute stack. So we have to first also create new processes together with our customers and close collaboration. And second, we have to make sure that our investments stay still active on the compute level. So the migration that we did from the Java enterprise world into a more fine-grained containerized architecture, it works, it's doable. And this is what we did in the past. Could you give a few more details about, or were there any challenges, specific things that you could give advice about the migration? Two challenges, it's also a new software stack, also within our organization. So you do have to do a lot of convincing people and showing that it really works. It's a different way of doing the development. But yeah, you have to do your homework in order to bring that to the proper audience. It's also like kind of community management. You could say so. And the second aspect is, on the customer side, they also have the same challenges from moving the ownership of that hardware stack from the business people to their own IT department. That's also the things that you need to communicate. You have to be open there. And yeah, it's doable. Yeah. Yeah, it's like we heard in the last talk. It's not just about the technology. Communication is really vital with these projects. Exactly. And subscribe to that. Maybe let me add communication and trust. So I think for us it was very helpful that we really could rely on our software developers and our architect to say, OK, this is the right way we want to move. And don't bother them with too many comparisons, too many POCs, too many, oh please, could you give me some more insight? Why we exactly use this specific product and not those out of the 20 other products? Trust them. And to add as well one challenge that we had there is actually you need to complete a different skill set of people that can work on this Mac stack. So it's quite challenging to find good people that actually do the work. So that's really a hard one. That's the reason why we have an HR booth out there for some of you are interested in. I mean, have you found you've been able to train some people internally already to get them up to speed? Yeah, that's great. And last but not least, we have to mention that it's not purely a technical issue to do this shift. It's mostly a cultural shift necessary in big companies and also a shift of the work mode of the skills that you've already mentioned. So there's lots more than pure technology. Yeah. One thing to add with regard to communication, I think Ben yesterday in the DCS afternoon had one sentence on the slides which talked about communication. And actually, there was one subject that you could change with any kind of, yeah, with any subject, but it all came down to communication as a key. Yeah. That one I really liked. All right. So last question I had for all of you is sort of a future looking one. So we're implementing the smack stack now. It's running well. Where do we see the smack stack in a few years? What is the smack stack 2.0? Does the acronym change? What are you thinking? Maybe. But for us, the important thing for a smack stack 2.0 is to get the stuff I've already mentioned, software defined networking, software defined storage. That would be a good thing. And the tight integration of the products together would also be really a huge advantage for us to avoid down times while migrating to higher versions and things like that. And that's the components inside the smack stack themselves, the integration or the application other? Yeah, the smack stack itself and each application within. And the other thing around is that we have to implement more and more components into that stack regarding AI capabilities. That's one of the crucial factors for us to succeed in the matters of envisioning environment, building map layers with real time events on it to let the car drive on its own in the future. Yeah. Yeah. Smack stack, I guess, will not change. I can still download a lamp. Probably the package is still different things in it, but the label sticks the same. I think that a lot of the majority will be done on the infrastructure level, like new orchestration frameworks appearing. This is more where I see a future something is going to change. Looking into the future, I hope that there will be a smack enterprise version. So if you really build products that are running at your customers, you have to take care about maintainability, monitoring, security aspects, encryption at rest and transit. And if you would like to add all this on your own, then you actually build this smack enterprise. All right. Thank you, everyone. This was great.