 All right, thank you all for coming. This should be fun. It is really an honor to be here. My talk is titled, Getting Out of Furskir, Renault-Nissan-Mitsubishi's Journey with Peorel Cloud Foundry. Quick word about myself. I'm Lakshman Diwakar. Everyone calls me LD, working as a platform architect at the Alliance. Up here on stage with me is Didi Esan. Yes, hello, hello everybody. I'm Didi Burkhalter. I'm working as what we call platform architect at Pivotal and working closely with the Renault-Nissan team for a while now. So happy to be there on stage, having the story described for you. Cool, thank you. A bit of context before we move into our journey with the Cloud Foundry. Renault-Nissan-Mitsubishi is a Franco-Japanese strategic partnership between the automobile manufacturer Renault from France and Nissan-Mitsubishi from Japan. We are the world's largest automotive group and a global leader when it comes to electric vehicles. Last year, one out of nine vehicles sold worldwide, where by the Alliance. Under the Alliance, I work for the connected vehicles department. A connected car is basically a car that is equipped with the internet access. Under the department, we actually focus on the following categories. We provide emergency calls, provide better routes and an enjoyable journey, discover the new ways to travel, enhance the safety and security of the car. We actually calculate the car insurance based on how you drive. And finally, the remote services where you can use your mobile app to remotely invoke functions in the car. And this is a very high-level overview of the connected cloud, which is powered by the Pivotal Cloud Foundry. As you can see there, the module within the car is connected to the cloud and all the three companies of the Alliance consume this cloud and also its B2B partners and the backend applications of the mobile app and various other interesting applications are deployed on this connected cloud. Here are some of the production applications that are running on the Cloud Foundry. On the left is a Nissan Leaf, which is the best-selling electric car. And on the top right is a mobile app, which makes it easy to remotely start your car or other vehicle functions, like turning on your air condition, checking the battery status. We also have an Alexa skill that allows you to use your voice to remotely invoke functions in your car. At the R&M Alliance, they've been running Pivotal Cloud Foundry for about one and a half years now. People here would have heard about the two-pesa team rule by Jeff Bezos. Any team that is solving a problem should be fed by two pizzas at the lunch. That is about six to eight people in a team. Having said, we are a one and a half-pesa team. My colleagues, my manager Fukuda-san and a lot of you are here in the room, and we're actually split into two regions, Paris and Tokyo. And we still have room for awesome people. We have seven foundations that span across three regions in the world, and we have 100-plus developers that innovate on the platform, and a bunch of applications related to connected services are deployed. But all these one and a half years were not as easy as it looks. There were days where we would walk in and look at each other and say what we were thinking. So this is a compilation of lessons we learned in running Pivotal Cloud Foundry. So this will be useful for people who are looking to start on Cloud Foundry or people who might already be running Cloud Foundry. And today, I present to you our journey with the Cloud Foundry. We know that the Cloud Foundry community is obsessed with this 12-factor app. And DDS-san here in the States came up with this idea that let's explain the journey in 12 steps. And being in the car industry, I thought let's explain these 12 steps as the road trip. Like every journey, we also face the hardships and I've represented these hardships as rocks here so that you don't have to repeat it. And with that, I hand over it to the DDS-san. Okay, thanks, DDS-san. So first step is the discovery phase. So the team started, I would say, two years ago and having no team, having no platform. So the head of the team at this time had to choose a partner that is being able to help this new team to build this platform. So having a partner that has worldwide coverage and having also an expertise and references in the automotive market. So it was still pivotal. And also to bring this market to life, there is some criteria that the solution chosen at this time have to provide. It's a polyglot platform. So polyglot means providing the capacity to run on multiple clouds, so major clouds, so major IS like AWS, GCP or Azure. Having the capacity to provide liberty to developers with multiple type of languages, what we call having the support with build packs. And also with the fact that the CloudFondry is an open source solution and providing multiple layers of abstraction not having this kind of vendor locking constraints. After you have chosen the solution, after you have chosen the partner, you have to do an installation. So there is a small roadblock, but I would say installation is always easy or should be always easy. So we decided to onboard the developer team, so provide the better developer experience and boarding the team on PWS, so the public solution from Pivotal. Then we started to install the solution on the Azure resource group from ICMS, from Bruno Nisan. And we did, of course, a lot of manual installation. We were using the Cloud CLI and we were also using, for example, templates but it appears that this kind of installation and update and upgrade of the platform was very time consuming. So it took at least, for example, two to three days to have a complete installation. So this was not sustainable for the team. So we decided to go to some very automated solution to be able to deploy the same solution across multiple geos. And for having less snowflakes and having better efficiency from the operation point of view. And LDSAN will come back on this automation, I mean capacities and practices, good practices. Yeah, perfect. I hand over to Mr. Adisan. Thank you, thank you, LDSAN. And the next on is practice agile. We are a single team but split geographically into two different time zones. Agile and the virtual tools are the things that unites us. So most of agile ceremonies were adopted from the Pivotal dojo. As Dom Andrews here in the room said that it's not the technology problem. That's a solved problem. So the problem is the process of developing a product. And that's completely true. Dojo is an onboarding program where Pivotal engineers pair with you to help install and educate the platform. And that's where we learned the art of pair programming. And we try to pair as often as possible so that which increases the team velocity and reduce the break and breaks the knowledge silos. One of the important parts of the product development is the feedback. User interviews were helpful to actually understand the pain points of developers, the feedbacks and the suggestions. And we later used those feedbacks to prioritize our backlogs. Everyone in the team is always excited about one event which is retrospective. This is really a fun event and it helps to keep the team more transparent. And we are really excited to have our second dojo right after the summit. So the next one is start small. If you're a small team like us, you might not have the experience and the resources to manage both the application service and the data service, like the Redis, RabbitMQ and the other services. So it is very difficult to start and juggle all the problems at the once. It is better to start small and slowly expand. Earlier in the talk, I was telling you that we were running Pivotal Cloud Foundry and the great thing about Pivotal is that they have great data services that integrate with the platform. And we hope at one point of time in the future, we'll build our own service and integrate that to the platform, the open. Even before we had our stable platform, we actually introduced Pivotal web services to the developers. The connected service department is a brand new under the Alliance and once that we have decided to use Cloud Foundry, we actually introduced Pivotal web service to the developers. While the developers get accustomed to the Cloud Foundry environment, we were working on and building our own foundation. This was a pretty good move as we took our own one to two month to bootstrap our own foundation and onboard the developers. And this concept applies same to the new data service. When developers request you a new data service, try to deploy a minimum viable version of that. Allow the developers to play with it and collect weekly or bi-weekly feedbacks and use those feedbacks to prioritize the features and improve it. Trust me, this really saves time both for platform operators and the developers, bridging the gap. This was a hard lesson. So we soon realized that developers were not completely leveraging the platform and the services. And we found that updating the documentation is not solving the problem. So we tried to organize some meetings where some developers showed up, but many didn't because they had different priorities. And we tried to organize something called Lunch and Learn where we offered free lunch to encourage attendance and involvement. And to the surprise, many attendees turned out when compared to the previous meetings. In fact, this was introduced as part of the dojo and from that, we tried to organize at least one Lunch and Learn per month where we actually discuss about the platform updates and do some demos. And earlier in the talk, I told you that we were a small team and developers were expanding rapidly. New teams like integration and testing started to appear and they use Cloud Foundry, but many didn't knew the team behind the platform. So that was the time we decided to brand our own team. This happened at the dojo and everyone came up with interesting names. But finally we settled with Kinja, which means that Camry owned, which is our cloud platform and all the platform engineers had considered us ninjas and that's why we have Kinja. So we started wearing t-shirts like this and changing our logos in the slack. So people started noticing us. So they were asking, what is this Kinja? What is this new swag? So we definitely got some traction there. And moving on to the communication. Communication and enterprise is terrible, isn't it? So slack is the main mode of communication, which is very quick and efficient to answer the questions. So we had our own slack channels where developers posed the questions and we tried to answer as fast as possible. Moving on to the next one, automate the platform. This is my favorite topic. When it comes to the platform, we need to completely remove all the manual tasks and make it 100% automated. The sequence starts at the pivotal network. Any updates or patches comes to the pivotal network, which triggers the whole update. Initially, the update is applied to the Sandbox Foundation, which is in the Europe. And our automated smoke test kicks in and which tests the complete platform. And if the smoke test passes, it is then applied to the staging foundations, which is in different regions. And then, only if the smoking test, a smoke test of the staging passes, it is actually applied to the production foundations. So you can see that the updates are applied to the production foundation only after two layers of testing. So this makes sure that the updates does not break the foundation. And this is the success scenario and what happens when it fails. So it fails. So there is something wrong in the pipeline and have you been drinking? Hard, no. No, we don't drink at Japan. So there comes the platform operator. I wish I'm that cool like the guy over there, but that's not me. And this is me. And I go fix the pipeline and the cycle continues. And this whole automation is powered by concourse. We make sure that the patches are applied to all our foundations within a day or two. So this is the automated platform where we make sure that the patches reach all the foundations. And we are 100% sure that any technical depth is available there. And moving on to the next one, eliminating the toil. This is becoming a buzzword in the Asari world. According to the Google Asari book, toil is some work that you do more than three to four times are the work that takes hours and hours of your day. In the cloud foundry, I think we have some toil, like adding and removing a user, managing the orgs and the spaces. You'd be really working on a special feature in the platform and you'll be bugged by the developers asking you to add them to a specific space and a specific org. That was really frustrating. And we came across this tool called CF management, which automates this toil with the help of concourse and a git repository. And this not only automates the toil, but we also have a single source of truth about the orgs, spaces, and the developers underneath them. Moving on to the next one, which is hard and insecure. Every enterprise has a big security team, even we had it. So before you launch an application, you have to pass the security test. So did we. And the security team analyzed the platform, did some penetration testing, and created a bunch of tickets related to the security policies of the platform. Going through the tickets and sending messages back and forth was not efficient and this was actually delaying the release date. So we realized that this setup was not working anymore and we tried to create a virtual platform team with a security expert where the security expert passed with the platform engineers to actually increase and enforce the security to the platform. And this virtual platform team setup was way better than the previous setup. And one good takeaway is that, try to involve the security team as early as possible so that you can enforce all the security policies right from the start. And the next one is testing. We know that the Cloud Foundry comes with a default smoke test. We make sure that we run the smoke test after every updates. Even though the smoke test was successful, we were getting compliance from the developers that they were not able to connect to a particular service or the application could not restart. So when we looked into the issue, we actually found that the developers were trying to connect to the service in a different way that the smoke test were not covering. For example, they were trying to connect to a Redis application with HTTPS but the smoke test was covering only the HTTP one. So we soon realized that and we looked into the application architecture and tried to come up with our own smoke test. And we make sure that we run the smoke test after every update. And writing the smoke test also helped us to understand the application architecture and give feedback to the developers regarding the 12-factor app and other different policies. And the next job was we were given the task to come up with the SLIs and SLOs for the platform. We know that the Cloud Foundry is pretty robust when it is deployed in the high availability mode but we really need to test it before we come up with a value for the SLIs and SLOs. And we devised a Chaos Monkey script which randomly destroys a VM and this Chaos Monkey was really helpful to understand the networking bottlenecks that we had and some of the VM performance issues which we later rectified it. So I highly recommend you to actually do a Chaos Monkey test if you want to ensure the reliability of the platform. And the next one is monitoring and alerting. This was a hard listen too. So the developers use PCF metrics which is a dashboard that contains all the app-level metrics like the request errors, the 4XX errors and the 5Xs. They also have Zipkins which we're telling them the latency between the microservices which were very helpful for them to improve the architecture. And the platform operators us, we use the PCF Health Watch which is an opinionated dashboard containing all the key performance indicators of a platform. And these contain metrics like the Canary app and the CF push and about the Bosch jobs. Since the whole department was actually using the Slack we both use Slack for alerting. So earlier I told you that we had seven foundations and there were about 100 KPIs for each foundation and we started setting up the alerts for all the foundations. And we soon realized that most of the alerts were actually solved by the Bosch self-healing capability so we were paged by all the alerts and we soon lost the interest in actually looking at each alerts and solving that. And then we found out that we need to monitor only very critical alerts like the Canary app whether you can actually CF push and whether the apps manager or ops manager is up. So that's why I've quoted that less is more. And then moving on to the final one which is extend and scale. So this is a geographical representation of our present regions. So right now we are in Japan, France and also in the US. In the near future and in the future we are planning to expand to different other countries like Russia, India, China. In order to scale rapidly we need more awesome people so we are hiring. If you're interested please feel free to talk with me after they talk or my colleagues who is actually in the room. You can also DM me in the Twitter. With that, thank you so much. Thank you.