 All right, so let's start. Welcome to my presentation. So today we'd like to talk about how we help one of the largest German automotive company to build a scalable cloud-native architecture, so with the help of Cloud Foundry. And of course, what the title says, how it actually saved human lives with this. Let me introduce myself first. So my name is Datron, and I'm a senior data scientist at Pivotal Labs. I'm based in the Berlin office, and my job is actually to help clients making full use of the data. And if you would like to connect to me, so this is my Twitter handler. Let me start my presentation first with some facts that you may or may not know. So did you know that actually 1.2 million people die in road crashes each year, with many people becoming more injured or disabled? And basically, road traffic crashes are actually a leading course for death globally for young people. And this is even before suicide and even HIV. And of course, if you compare it to other means of transportation, for example, like air travel or trains, it is actually the most dangerous one amongst them. So what is the problem actually? Why so many people still die in cars? Well, one of the major part of this problem is actually, as you can see on the slide, so worse road traffic conditions, for example, like class for us. Of course, there are other conditions. For example, after a huge rain, the streets getting wet and something like this. Nevertheless, in all those cases, people still tend to drive very fast. For example, I know myself when I drive in a car, so I was in October first this week and was driving very fast, despite the fact that sometimes the weather was not so good. And basically, one of the reasons is there aren't very good smart warning systems. So from what we've seen, however, most traffic conditions are actually predictable somehow and preventable. So for example, we could use weather data or data from other cars to warn drivers. For example, I took the car from my dad. He has a BMW. And the cool thing is they have this head-up display. I really, really like it. So you could just integrate a system in this and then integrate it into the head-up display. And our goal was therefore actually to help this client to see if it's possible to predict road conditions, basically, in Germany, based on weather data. So, yeah. In this talk, I actually, on the one-hand, want to focus on the technology side that we're used to solve the client's problem. But from this slide, I know it's a very marketing synthesis. But from this slide, apart from the right technology, the process that how to build the software is also a key component during our project. And we actually believe that you actually need both component for a successful project. And therefore, I will also shortly talk about the process and also about the data science involved during this project. So let's first start with their technology part. When we started with this engagement, the client actually came to us and said, hey, I want you to solve our problem, but we don't have the technology foundation for this and possible for low money. And please, I need it in 10 weeks, because I have a board meeting. I need to show it to someone. And I guess some of you probably would know it if you, for example, from a consultancy business. So we were actually faced with a very, I don't know, situation where we had no computing power, no software, so basically nothing we can work on. For some people, that would probably be scary, because like, oh, you don't have anything. But we were like, yes, finally, it's a super situation where we can actually build something on scratch and we can use anything that we want, right? So we can use the right technology for the right problem. And as you already can guess, we were using the cloud. So this cloud thing to build everything. And yeah, so basically this is how our architecture looks like for this project. As you can see, this is the very famous Lamer architecture. What we did here is we were streaming data with Spring XD from cars and also weather data to two layers. So one goes to the batch layer. The other one goes to the read time layer. And everything is, of course, we did everything on AWS. What we did here was we, on the batch layer, we were streaming the data in a structured form. So basically the data wasn't structured. It wasn't a very weird former. We structured this former through Spring XD. Then we stored it on S3. And then from S3, what we did there is we spin up Spark. We spin up an EMR cluster with Spark basically to pre-process the features to reduce the dimension of the data. And then what we did afterwards is we were spinning up a GPU cluster on Amazon and then using a deep learning network to train this model. Afterwards, what we did there, we stored this model on Redis. Redis is, as you know, an Emory cache layer. What we did there, we stored the model there. We used the other stream basically and tapped it onto Redis queue. And then this model was basically doing just prediction with one of the services that we created. So the predictive VPI. And afterwards, we enriched this probability with more data like GPS data from the car. And at the end of the day, what we did for this project is we plotted this on a dashboard. So as I said, we're using Spring XD and the reason why we're using Spring XD is because of the domain-specific language. So it was really, really easy to use this for this engagement. And also one of the main reason is actually the shell script. So as a data scientist, we're not very good at Java or some of the other programming languages. So we are using a lot of Python and shell. And basically in Spring, it was really, really easy to integrate it. And of course, it also had a very easy connection to S3, which helped us pretty a lot to store the data. And of course, you have all the other advantages, right? So it's really easy to scale. And in the future, we probably wouldn't use Spring XD anymore because probably we would use Spring Cloud Dataflow. But at this time, when we started with this project, actually, Spring Cloud Dataflow was still too immature for this kind of use case. So in the batch layer, as I said, we started the data in S3. And then afterwards, we spin up an EMR cluster. Specifically, in this case, we were using PySpark because we love Python in the data science area. And afterwards, what we did there is, as I said, we spin up the GPU cluster. Here, we are using Keras, which is basically a Python abstraction layer on top of Theano and TensorFlow. And then also in the Lex block, you can see that we were using Luigi, which is actually a project by Spotify to create analytical pipelines. So in the real-time layer, as we said, we're using Redis for storing and caching the model. And basically what happened was already described before is the data which we got from Spring XD is queued into Redis. And then we created a couple of microservices. So like the predictive API, which basically constantly just give probably from the queue. And then afterwards, we're just outputting it to the JSON file, enriching the data, and then at the end, creating a dashboard on top of this. And everything basically ran on Cloud Foundry. So Pivotal Cloud Foundry. And the main advantage in this case for us was that we had different blowpacks, especially as a data scientist. As I said, we mainly use Python. But for example, for other words, like the dashboard, basically our sub-engineers from our team basically use JavaScript and Ruby to do this. And so basically the teams could focus on what they're good at. And of course, the other advantage is what you have with Cloud Foundry is, of course, right? So you could easily scale different instances, have load balancing and all the stuff. So yeah. The next important part I want to talk about is actually the data science part, which was also a core of this project. And the main goal was, as I already mentioned again, was to predict road conditions based on weather data. Who have you know what deep learning and machine learning and all the stuff is? Or like, OK. So I mean, I will give you a short introduction into deep learning because I think it's a huge buzzword nowadays. So as I said, our problem is to predict road conditions with weather data. And this can be quite complex, especially if you think about the data that you have, right? The input data because the dimension is huge. It's because of three-dimension data, like you have value in each time step, right? So the time is also important and also the location because we're looking at roads within Germany. And to solve such a problem, actually, deep learning is very good at doing this. And basically, what is deep learning? So deep learning is actually a subclass of machine learning techniques, which actually uses algorithm that mimics the human brain. As I said, it's everywhere now in the press. So everyone is talking about this. I think every startup that you're doing right now or every startup that's just started, that has an AI or machine learning or neural networks in the name, is not going to succeed. And on this slide, what we are actually doing is we're predicting the moods of babies. So it's a multi-class problem. So you have three classes, which is positive, neutral, and negative. And here in this case, the input feature is images of babies. And what it does is, OK, we're inserting it in the input layer. And then basically, the network learns the edges, the contours of the faces, and then also the facial expression. So it comes, binds them together in the hidden layer. And the reason why this is called deep learning is because it has many hidden layers. So if you're just talking about one layer, so if you have one hidden layer, it's just a neural network. But if you're talking about deep learning, it means that you have more than one layer. And specifically for our problem, we have more than two layers, of course, because if you have only two layers, you won't go too deep into layers and learn less of the complexity that you get from it. And also, considering our problem, we don't have a multi-class problem. But everything that we did was kind of a binary class problem. So at the end of the day, in the input layer, for example, you either have wet or not wet or slippery or not slippery as a target variable. Concerning neural networks, actually, there are many types of networks. But generally, we can summarize it into two types of networks. So you have feedforward networks or you could have recurrent neural networks. In this case, a feed neural network is basically as we already saw before. So you're actually inputting data into the input layer, right? And then the input layer goes one direction. So it can only go one direction. And basically, this neural network is very optimal for solving functional mapping problems. So functional mapping problems, actually, you can approximate any function that you like to. And typical architectures that we already, for example, saw before is called a multilayer perceptron or CNNs. I think some of you might have heard of CNNs, right? So convolutional neural networks. For example, Google is, you know, there was a contest from Google that we're using this kind of networks and it really performed quite well. And basically, the feedforward neural network is used in many, many applications. Whereas in the other site, we have the recurrent neural network. So the main difference between a recurrent neural network and a feedforward neural network is that you have a feedback loop included. So for the feedforward neural network, you can only go one direction. For the recurrent neural network, you can actually basically jump between two directions, right? So you can go in the past or in the future. So the network is learning in terms of the whole time series structure. And that's why it's very good to basically model dynamic temporal behaviors. And also for this kind of network, you have many variations. So for example, you have LSTM, so long short-term memory. You have GROs, so it's gated recurrent units. And then you also have B-directional recurrent neural networks. The application concerning application, it's very successful and it's mostly used in handwriting and speech recognition. I think a lot of you have smart apps and there are many applications that basically use a recurrent network to give the smartness for this kind of application. In terms of recurrent neural networks, there are also many ways, actually, to construct the network, right? So for example, you have one to one, one to many, many to one. In this talk, I will not go through deep into all of them. So if you want to know more, you just can Google this blog post here and try entry Kapathy. He's doing his PhD in Stanford. Of course, I will also provide the presentation afterwards, so you can look it up. And in our case, actually the many to one is the most appropriate one. So basically, as you're already aware, we're dealing with weather data, right? So weather data has this time series component. So you have sequences of values over time for each time step. And the output at the end of the day, what we had was either a wet or not wet, a slippery or not slippery. So it was a one to zero decision, right? So it was a binary classification. And basically, this resembles actually a very famous time machine learning problem, which is called the sum problem. So what are key learnings from this project? As I said, we were actually trying to predict road conditions in Germany. And in terms of whether it rained or it snows, you know that in Germany it doesn't rain all the time, right? Or it doesn't snow all the time. So we're not like in London or somewhere else where you have 70% of your time, it's just raining. So one of the problems that we faced, we had actually a very overbalanced problem. So overbalanced problem means that 80% of the time it didn't rain at all. And you only have like 20% of the time it rained. And in terms of this, this is actually a very difficult problem for machine learning model, right? To learn this kind of situation. But of course in this case we use, for example, different evaluation metrics. So for example, instead of accuracy, we're using precision recall, or we use different machine learning techniques actually, to for example, either increase the unbalanced class, right? To make it a balance. And yeah. And also as I said, there are many variants for recall and neural networks like ST, LSTM, or GRUs. And for our case, we actually decided to go with simple RNNs because they gave us a better performance in terms of evaluation and also computational complexity. Moreover, also when we started with this project actually we thought like, oh, the dataset is still quite nice. So we can use CPU. So we thought like, okay, that's still possible. But then after our first one, we were like, shit, that takes hours. So not a good idea. So we did this, okay, let's switch to GPU. And that was a really good decision. So it was 10 times faster with GPUs. A good idea for this. And also on this project, especially in neural networks, you basically waste a lot of time basically just to find the optimal network. So there's actually no, no methodmatic foundation behind us to find the optimal network. It's basically art, right? So you need to experiment a lot. So for example, you need to experiment with the number of APOCs, the activation function that you're going to use, the number of hidden layers and how you actually construct the network. Of course, I mean, in many university projects, we already have like pre-trained networks that you can use. That's what we already did as well. But then also, of course, we need to experiment a lot actually to fit this network to our problem. And also one of the key points was that we actually needed a lot of data actually to train the network. Sometimes we didn't have much enough data so that the network can converge because basically what the neural network does is it's optimizing weights within a global network, right? And then certain looks for their optimal global minimum. And in some cases, it didn't converge at all. So as I said, apart from the right technology, the right process also played a critical point in this project. Yes, I think some, I think everyone of us already attended the keynote talk today with Michael, Andres Nolte and Rob Mead. So he actually pointed out some of the practices that we have. So for example, pair programming. So at PIVLAST, we do a lot of pair programming, which means you have two people pairing, solving one problem. And also we have test room development, which ensures basically that our code is always production ready. In this talk, actually, I will not go through all of them into more detail, but only on API first. So, yeah. So what is actually API first? This is actually an image that I took from Mikro's Brown's new post. So what is hardcore data science in practice? So he published it last week. So it was really good that he did last week for me. Basically what it is is API first is actually thinking to ensure that you think about how to interact between data science parts. So the data science model to the sub engineers. So how do you basically make it production ready? Because I don't know if you see it in your companies. So maybe you might start data science initiatives. You might hire a data science team and start a data science team. But at the end of the day, sometimes it's just going nowhere because they are doing a lot of R and D, right? Because most data scientists don't have a software engineering background. So it's really hard for them. And basically what we are doing or we are trying to do is, okay, let's pair data science with the sub engineer, right? To think very early how you could basically put this into production. And our core is at the end of the day, if you look at the box between the data science part and the engineering part is basically to create an API which offers a very clean contract to the sub engineers and other people, I would say, to interact with the model, right? Yeah, here are actually additional links if you want to know more about API first idea. So this is one of the blog posts that was written by me and my colleague Alicia. It was actually released two months ago. So I was ahead of Mika's blog post that the blog post from Mika was also pretty good. So it's a very good read. I would definitely check it out. And he's talking into other areas more detailed than me because I was giving an example and he was using it more from a very teamish point talking about this. Also from, if you attended today's keynote with Dr. Nolte, he actually also mentioned that at Allianz they had this very old waterfall culture and actually they had to create their own digital garage, right, and send people there instead of having them within the company to make sure that they don't get influenced by the line managers. And this basically was the case for our project as well. So when we actually started with this project actually, so our client told us that when they signed the contract their procurement department and legal team asked, hey guys, are you really reassured you wanna work with them? Because it says the contract, you have to come to the Berlin, you have to go to the office and you have to work with them, right? That was a complete shock for them because usually when you're a big company, right, you're just hiring your suppliers and they say, hey, I pay you this kind of money so you have to solve my problem, come to my place because this is how it is usually, right, and what we did is they came to us and basically at the end of the day they basically built it together with us. So that was a complete new experience for them. Another important point that was also mentioned today at Allianz is usually the release cycle it can take months or even years and what we did actually, we managed it to pull it off within seven weeks. So the release cycle was much shorter and basically at the end of the day they could give feedback and they could actually test it, right? And another important point was basically what also was mentioned today, this monolith waterfall approach which is very still in many German companies and for our projects, of course, what we did is we separated it into different microservices. So, and that was a good decision because the data science team could actually focus on what they're good at because we're not good at Java or creating code or in scholar or something. Some of us might do this, but for this short time of a short amount of time it was really hard, right? And the summer engineers, they're very good at creating dashboards in JavaScript and Ruby and all the other languages they use for this, right? So everyone could focus on what they're doing, right? Instead of like, hey, you have to learn this and within a short of time and it's not even very good code when they're doing that afterwards. And then the best advantage was we could actually develop and also deploy it independently at the end of the day. So, what are key takeaways from this project? So, our takeaway is using the API first, thinking. So, bring your models as fast as possible into production because clients can test it. So, your client could, it's not even what we understand from a consultancy business, right? Because your client could be also an internal client, right? The other departments or something like this. So, release it, get feedback, right? So, we have a very user-centric approach. The user is in the center of our application. You will get very fast return investment from this because you always deploy early. And, of course, for this project, we use Cloud Foundry, which basically enables us to reliably expose the models as an API, which is one of the main advantages when you try to create smart apps, right? And, of course, the main advantages which I already told, whatever I said, is basically teams could focus on what they're good at, right? So, you don't actually force someone to do something else that he doesn't want to, right? So, yeah. So, this was my presentation. Thank you for coming and I'm open to questions. No questions? Pardon? Yeah, so basically, I cannot go too much into detail. But it's card data and weather data. So, the details are confidential. Cool. Thanks for being here. Okay. Thank you.