 I'm Nathan Watimena, I'm Nathan Watimena, I'm the product owner for the Join Cloud Foundry team. And just like a lot of people today, we're here to tell you about our journey on implementing Cloud Foundry. So a little bit about myself. I've been working at KLM and OPS for about 10 years. And for the past year, I've been involved with the team that implements Cloud Foundry within Air France KLM. And with me is Fabien Lebrer, so I'm working in Air France. I am a Dev guy, so not OPS, sorry. And I'm working the stuff to Air Engineering. And for Nathan, I was a Dev representative, so I represent all Dev, Air France and KLM. And I'm working in Air France since 1999. And so we have built a solution together at France KLM. We're at the Air France KLM. What do we do? We fly planes, right? That's our main business. But now we're in a world that is so fast changing and moving. And we're not competing, but also working together with other businesses that implement technology in the current world, which is moving too fast for us. So we have to change our world, change our game, and we have to move to digitalization. So here, I stole this from a business presentation with Air France KLM, by the way. So this just shows that all the move, all the world around Air France KLM is different. We have to compete with other businesses for the same market share. So Air France KLM has decided to focus more on digitalization and software. Also to reduce the technical depth that we might have if we don't move along with the rest of the world. So let me go back a few years back before I was the product owner of this team. So compared to the previous presentation, so we started with a Cloud Foundry open source. I think it's about three years ago. We started to do investigation on that. But we were really, really struggling with the team, with the skill level. We had a lot of team members changing. It was not a good understanding of the technology itself. It was difficult. So there was also a change in skill levels every time. We had really hard time to get it production ready, to get the organization around us, to trust us to get it into production. There was no alignment at all with business apps. Only use for prototyping only. It was really hard. And so the management, they saw the need in moving, always changing world. They saw the need that we really need to do something. So we really need to get it moving. And we decided to go for the pivotal solution, which are the rock stars in this business, actually, at this moment. So why pivotal? It's not a pivotal pitch, of course, but I just want to mention that why pivotal. They had a lot of experience. They're the main contributors to the open source program, of course. And they had a lot of experience in implementing Cloud Foundry, their pivotal Cloud Foundry, into enterprises. A lot of experience. Also, they came with the pivotal Cloud Foundry product. Comes with a lot of toolings and automation to make your life easier. So looking at the skill set, which in the team, so the things that we need, we really could use the things that the pivotal Cloud Foundry brought into our lives, into our organization. And they can also deliver the production support whenever there is a big problem or a problem might come up. They are willing to support us all the way. But what I really want to mention is about all these innovative stuff in pivotal Cloud Foundry itself. It's great. It's awesome. All the tooling is great. It makes our life easier. Opsman, PAS, whatever. It's really great. But what I appreciate the most is the involvement of the team itself. So involvement of, I have Erwin here helping my team in all aspects, not only technical aspects, but also for me as a product owner in my product management roles and tasks. And his involvement, or the involvement of pivotal itself, not only Erwin, their involvement within the organization is really what makes it a real good partner for us to work with. So our platform journey started with, of course, the dojo. Everybody knows about the dojo. Yeah, their concept of I do it, and then you do it, or we do it together, and then you do it. It's focused on enablement. But to be honest, their lean disciplines and everything as the core principles of enablement and the way of working, to be honest, it was very hard for us. Very hard. We're not used in pairing. We're not used to do, I don't know, to do real agile methodologies. We did agile methodologies. We did our stand-ups. We tried to implement scrum, so we did our stuff. But those dojo period, we stretched it into eight weeks instead of six. It was really hard for us. For me, personally, I got really stressed. But they tried to learn something, something more than just installing things, installing PCF. They tried to teach us discipline. They tried the real core principles that focused on enablement and not just push next, next, next, and then it's done. And it's always in customer-centric position from a customer-centric solution. It's always to deliver value to your customer. But we're not used to that. We're not used to have to talk to first, to every user and get their opinions and whatever before we implement something. So it's something that we need to learn. And the things, the core principles of build and measure and learn, we really had to get used to that instead of just, oh, we're engineers, so we know what to build and we just move forward. So something that we need to learn also. And from day one, their focus was to automate it. Please, automate it. And our deliverable was not really big compared to the previous presentation of 26 foundations, but we only had to have seven foundations. But they started at the beginning, yeah, but if we installed it manually, I'm done in one day. If I have to build a pipeline, I have to learn concourse, it's such a pain for us. The learning curve is too high, but no. They really teach us, no, focus on automating it. So we started with concourse, building a pipeline. Not me personally, but my team is here. So they started doing that. So we really needed to learn a lot. But because it really helped us, because after the first pipeline, just creating the first install, it is easy to push it to the next foundation or the next environment. And after that, you can build upon the pipeline to do other things and just install. I don't know. We're now, I think, at the point that we do the small patches automated. So we did it anyway. So thank you for teaching us that. And thank you for the team that implements that. And I'm really proud of my team that were able to do that. You might wonder why I say Seven Wonders platform. I will come back to that later. But Seven Wonders is basically a board game. It's a strategic board game compared to Age of Empires. I know if the old guys are there that used to play those games. But basically, you have to gather resources and gather all the things before you can create a society, basically, and run from there. So this is what we have done as part of our journey. Get all the small things, gather people, gather resources, order servers, and whatever to get where we are right now. But to be in Air France KLM, it means it's that we're not able to work independently as an island, basically. And we had to integrate with a lot of the current systems within Air France KLM. So things like monitoring, tools for troubleshooting, metrics, logging, authentication methods. So we tried to do that. It's really difficult because in an organization, SF France and KLM, all the things, this is managed by different departments. So again, we had to start talking with them. So we just contact them and start to get all those things going. Again, a real pain for us. Really heavy. But again, we managed to integrate with a lot of the existing systems and tools, like we managed to get introscope working, to get the metrics from applications. We are able to send the logging to an aggregated log system within Air France KLM, which is managed by a different team. And we had to have the access to the platform itself, to PAS, and PAS basically had to go to an authentication method, which is within Air France KLM. So now we have integrated with that. And all the users, first, we moved from creating local users. Now we use Ping Federer to connect to the platform. So you get authenticated on the platform directly. Here's a small picture of Seven Wonders, the board game. So we started really from zero, from nothing, basically with the open source Cloud Foundry. But this journey of Pivotal Cloud Foundry, we started with nothing. But with support of the product manager and everything within Air France KLM, all the different departments also, we started to get this project going. We get physical servers across three data centers. And after the six weeks of Dojo, we have installed seven foundations across three data centers, which is basically also after the Dojo period, which ended in the end of March, beginning of April, we were operational and we were live. It's an on-prem solution on Feesphere. It's a production-grade dual-site design, according to the reference architecture of Pivotal, with three availability zones design. So for HA purposes. And we try to implement as much as possible the reference architecture. So we are feature-proof also. For monitoring and alerting, we had to integrate with the current solution at Air France KLM. So we could try to combine some stuff, which is already within PCF, Pivotal Cloud Foundry. And this is an example how we integrated with the alerting mechanism used by Air France KLM, which is Cintrion. So we implemented HealthWatch as platform monitoring. And talking with the teams of the monitoring team, we came to a system that can send the metrics from HealthWatch to Prometheus. And from there on, they created a bridge to Cintrion. And now we have also alerting mechanism for our platform. But this is just one of the integration examples that we did. But as I already mentioned, who are we doing it for? My main client is the developer themselves. So where to the developer? Thanks, Natan. Maybe just before to continue, a small question. Who is in a room, is not a developer? Please raise your hand. Not much? Sure. Okay. Have you already asked to a developer what is his dream? What does he want? Have you done his job already? No never? Okay. Because in fact, for developers, all is simple. We are in the business world. So in English, it's more the clear beer. I think you know the series. Yes. Yes. Because for you, sometimes the developer, yes, is dreaming. He's dreaming a lot. In fact, what he wants the developer is simple. He wants to code. Code, but code with the language he wants. Coding, but the database he wants. The middleware he wants. And he wants to be able to deploy automatically his application without any problem. Of course. I have a new language. I want to use it because it's fun. Yes. Do you know Kotlin? Go. Yeah. Very fine languages. But of course, infrastructure is not for me. Piper work, not true. If I need to plan ahead, disk server, router, IP range, no, I don't want to touch. No, no, no. Install VM. Operating system? No, no. And of course for me, we have delivered a nice platform. And of course, it's back up. Well, if you ask me the question, I want to know why. But the more important, yes, I have designed my application. And of course, if something fails in life, please don't call me. Yeah. Okay. So, is still a dream, of course. And maybe we try to say, okay, this dream we wanted is possible to implement it. So, we have started to collect requirements. We have done some interview survey to the developers, to the application operation. And at the end, we have qualified more 100 requirements. Of course, if I push all requirements, I say to Nata, hey, please, tomorrow I have this platform. It was a little bit difficult for him. So, we define a subset. Only 34 requirements. So, to start, we have called these requirements MVP, minimum value product, to have a real value for the developer. Most of them concern the core feature. Yes, we need to have something to install. It's a little bit difficult. But the good value for us is a service broker. So, we have just put in the bucket two. Yes, two. After that, you say, okay, now we have the platform. So, we want to enrich it. So, we have started to define a new subset, 20. And most of them, as based on the extended service catalog, and we want to add 10 more. Yes. I know it's hard for you, but... Let's talk after the... So, today we are here. And of course, the goal is continue to enrich the platform and to have a big service catalog. If I come back to the first MVP. So, in France, we have services already provided by our operation. And we have full focus only on two. So, when I want to deploy my NASA application, okay, I have a nice cell services. I click and instant... Directly, I have my ProGray SQL... Oh, sorry. Oops, sorry. I have my... On the fly, I have my ProGray SQL databases. But of course, my application is so simple. I need other services. And for that, unfortunately, I need to release the legacy way. So, mail, issue, things like that. Just to be straight, for example, I wanted Mongo. So, we raise the question to operation. Hey, I wanted databases for my application. And, okay, they say, okay, for them, you will have in four weeks. But I wanted another one for acceptance, no? Yes or no? Or is enough? Or is not enough? And they say, no problem, one week more. But I want the life, too. Yes, no problem, one week more. Okay, so six weeks to have for life. So, of course, as a developer, what I want? I want to have my old services in cell service mode. So, of course, I click and I am very happy. Oops, sorry. But with now, we want hybrid services. So, we want to provide something. We want to get services the benefit of the cloud. So, there is a nice feature in the cloud. So, of course, if I can just click in Cloud Foundry and get it, yes, very fun. I like the web services, self-services. And, of course, so, if you are more technical, you know that, it's based on Open Service Booker API. So, okay, now we have a lot of services. So, it's great. But now, what we need to do? Train the people. So, to train the people, at the beginning, when you started, we said, okay, we need to define a training one day and explain to the developer how to use the platform. Yes, of course. But when we discover the platform, we say, hey, in fact, we have just to say CF push and it's down. Oh, too simple. So, we say, okay, we are going to do some cookbooks, some good line, and maybe we'll be enough to start. Yes, right. But if I want to use a really benefit of the platform, it's not enough. For example, if I want to use microservices, if I want to use Spring Boot with all the features inside, yes, we need to do more. And for that, instead of traditional training, we say, okay, we are going to do AFKL developer events and push information by the other communities. And for that, thanks to Pivotal, because they have a nice evangelist, as I say, for example, Jakob, sorry. And a very good guy about microservices. And when he went to your company and explained, developers are very, very, very, I don't know why, but very happy. So, of course, as said by Natan, we have three data centers. So, he has done only one, but he has done one in Valbon, another one in Toulouse, and another one in Amsterdam. So, free time. So, it's a big investment for us and for Pivotal. So, thank you very much. And one in Paris also is going to be organized. No, it's there. So, a little bit complex. But for the communication, it's very good. And the investment would get very benefits. So, okay, we have 20 people, but now we have existing application, I think is your case too. And we want to do the clarification. This term, I think, not exist. But we have more 100,000 applications today. And when you go to some conference, what they say, hey, you need to be collaborative, you need to follow the twelve factor. Everybody knows the twelve factor here? Yes? It's a bit complex when you do me a question. You need to follow that. If you're not aware about this, I propose to you to follow one other session done by Cassie West at the Sprague one, two years ago. And it's very fine because they say, okay, there is pattern, anti-pattern, so 30 minutes. And I think we learned very well the twelve factor. I propose to focus on the process part. What is the anti-pattern of the process? No? Anti-pattern is the NFS. No, NFS, network storage, of course. But just keep in mind one thing. All your applications are not Facebook or Twitter. Yeah? So, to explain a little bit more. So, we have a nice application. It's stateless, so no problem. Free application, free instances. Nice. I need to have storage. So, for that, of course, object storage. And by the way, I've created a very nice application. My customer can be worldwide. I can have one billion of users. Perfect. But one thing to pick in mind. We are doing migration. If we are doing that, yes, it's nice. But your migration cost increases a lot. Maybe in this case, why not to stay on NFS? Yes. Of course, you are not going to reach the worldwide. But on B2E application, your company, your staff maybe is enough. And by this way, you reduce the cost of the migration. Agree? So, Pivotal understands that. And for that, they say, okay, there is a 12 factor line in hand. But in another hand, we are going to create a new service broker, the volume services. And by this way, what? Just check in the marketplace. It's existing. Create the services very easily. And, in fact, just to bind my application. So, okay, it's not 12 factor. But for immigration, it can be enough. Just maybe one message more is keep in mind, in fact, there is 12 factor. But to use platform 3 for our only mandatory. Thank you. Nathan. Right. For you. So, our journey. We're still on that journey, by the way. We're not as far as I'm concerned. We're not there yet. But that's basically the next slide. The challenges that we have right now, the challenges for the team, the challenges for the organization itself, is one of the biggest challenges that we come across during this one year journey, is that I think from, we are one organization starting 2004. And we're now in 2018. But do you think that all processes are aligned? Are we using the same tooling? No, not at all. So, we've been, yeah, you do the math 14 years later. So, it's, some of the things look similar. But a lot of things are so different. The teams are different. The mentality is different. Organization, Air France KLM. But not even Air France KLM. Within KLM itself. The way how department works. Supporting departments that we are depending on. They use different processes. The one department wants you to use JIRA to get requests. Want to use mail or even forms in Word. I'm not kidding. But at least with this product, Pivotal Cloud Foundry, we know that I want to use the analogy of a fast car that we are driving right now. On a bit of a dirt road. At least we have already bought the car. Right? It's working fine and it can go fast. Very fast. That gives us the time to concentrate on everything else around it. So, concentrate on the road. So, we can try to concentrate on the organizational restrictions that we have right now. So, that's more all related to the DevOps implementation. The technical restrictions which is now as an example that there are no service brokers to use backend services or we're not allowed to use the APIs that is currently running. But also we'll focus on the processes. The processes within a big organization such as Air France KLM. But in mind, while doing that, we have to try to not be in Ireland again. Just to really focus only on our thing. No, this is really what we want. And please give us or just please work with us. And really focus on that. We have to be careful to operate like that again. But this also gives us the means. Implementing this gives us the means to standardize a lot of things. Processes like self-services. Provisioning of your environment. So, not only within Cloud Foundry. But also to implement service brokers in the future. And to drive self-services and DevOps. Are we there yet? Not at all. Far from it. But we keep on moving. So, I found this thing on the Internet which says about present continuous. It means you're here, but you're not there. You're not where you want to be. You have to keep moving. You have to go forward. So, currently, my team are focusing on three things. So, we want to bring more features to our clients. So, we are focusing on the service catalog. But no, it's also an answer. If you want me to have PCF set coffee, then I might not implement that feature for you. So, but also concentrate on the platform itself. So, enhance the platform. We want to work on automating a lot more stuff. Backup restore, working on disaster recovery procedures. So, and also on operations, other operations tasks such as guiding team, guiding development teams on the platform to use the platform better to make use of the platform correctly. So, the title of this presentation was sky is the limit, but it was. It's not anymore. It's just where you put your bar. If you want to reach the sky, I can go to the Eiffel Tower. I'm already in the sky, but it's not there. We're not there yet. So, just like in the keynote this morning, we talk about the space. So, that's where we want to go in space. So, what's next? We keep onboarding dev teams. So, currently, you have a lot of teams more than over 50, 50 apps, 50 apps on non-production. And we want to really guide them into production-ready status. But also implementing PCF, we want to drive DevOps. We want to drive other departments, operations departments. We have multiple layers of operations departments, but also development. We want to drive them into DevOps. It means that because this platform already gives you directly the capability of to do your own self-service, you provision your own environment. It means that you also have to learn, you have to teach them to be responsible for their apps, for their environment. And developers don't want to do that. They want to constrain on the apps. Still. So, this implementing PCF, we want to enable the transformation by implementing this technology. So, the future, it's just open. Hybrid cloud, maybe, in the future. But it's nothing blocking us from that. Right? The standardizing components, like the open service broker APIs. Yeah, why not? Let's do that. So, Sky was the limit. Not anymore. But we also want to celebrate. So, I want to ask my team to come up here to take a picture. We will take a picture together. So, as a last moment, please come up to my PM, AJ, my architect.