Jonathan Le Lous

Hello everyone. We are really happy to be here at DevOps Enterprise Summit. We are going to talk about industrial digital transformation at Airbus Helicopters. First, we are going to introduce ourselves. Alexandre, please.

Alexandre Barbier

Yes. So, hi everyone. Happy to be there with you. I am Alexandre. I am currently working in the IM department in Airbus Helicopters, and I am acting as a project manager for the containers platform and the end-to-end monitoring solutions.

Jonathan Le Lous

I'm Jonathan Le Lous. I'm CTO at Capgemini CIS Cloud Infrastructure Solutions, and I'm heading the cloud native infrastructure team.

We are going to talk today first about one of the main purposes of our talk and what we bring over: it is about the container revolution. As you know, a lot happens today in this field. We see more and more clients and more and more projects running in containers. Obviously there is a lot of value to run with containers. You can reduce your carbon footprint, you are going to save time and money, you are going to speed your production, and you are going to go faster in production. You could introduce easily what we name digital transformation. I think today it is pretty obvious on the market, and you can see in every company, every organization, what happens around containers.

What we think so far also is that you have many different things around containers. We are talking about containers, but in fact you are going to use containerization in different ways. First, you could do cloud native, purely and simply, and try to deploy your application. You could take containers as a part of the cloud transformation, meaning you would like to go on a move-to-cloud project and you are going to use containers to leverage the opportunity to reduce your cost, go faster, and integrate DevOps. Third, it is an IT modernization approach, where you are going to try really to save time and money and to be able to deliver practically the DevOps change leveraging containers.

What was opening to our clients is really a multi-cloud strategy, where today every cloud provider gives you Kubernetes, for example, a kind of platform; you are going to have containers capabilities on every cloud provider at scale. That is why it is really a great opportunity to do a neutral way of working and doing multi-cloud.

The second part is hybrid cloud. Sometimes you do not really have the choice to start on private and go on public, and you cannot go multi-cloud first. You have to first think about a clear modernization path for your application, and try to do both ends and to do great on both platforms.

First, it is FinOps. Obviously this is going to be a huge, huge point now in the next year: how you are going to reduce carbon footprint and your overall cost leveraging cloud. We see a lot of our clients moving to cloud from VMs to VMs on top of cloud providers like Azure, GCP, or otherwise. Now they have to save money. They have to go on the cloud. You have to go on your application to see how you are going to save money, really try to lean your application, try to reduce the overall footprint of your application. But also you have to think beyond doing only VMs. You have to think about what could you do better on my IT side to really take profit from the cloud.

If you look at it this way, everything is easy: you go straight, the technologies are here and your path is here. But as Alexandre knows very well, you have different steps, or different things today, that slow down our clients on this trajectory. First, technical complexity. I think doing containers or doing that kind of technology is not something you do just like that. You have to think about technical complexity, how you are going to change your mind, what kind of target architecture you are going to have, and how you are going to change your way of processing.

Also you have the second point: if you would like to change the technical complexity, you have to think about how you are going to operate that. This is the main topic for most of our clients: how you are going to do that completely. That is one of the things we are working on with Alex: how you can manage that in production.

Security is a topic. This is not our specialty with Alex, so we are going to let more specialists on this topic. Skills shortage is one of the big points, because if you look at this way, how many people could say on their resume, "I have five years' experience with Kubernetes or containers or technology like that"? Not so many. We know on the DevOps side; I have been working on DevOps for the last eleven years. But how many other people could say that? Even if Alex or myself say we were preaching on the DevOps approach, it is not really the case for most people.

Existing culture is really important, and I think Alex is going to testify about that: how they had to change that, particularly in the Airbus context. And the learning curve: we never did that in one month or two months. We have been working on that for three years now with Alex, and that is why it is a learning curve. You are not going to do that the day after you start. Maybe in the Airbus case, tell us about your project.

Alexandre Barbier

Yeah, sure. So in the same spirit of what you described just before, obviously Airbus Helicopters decided to set up a digital platform. This digital platform is first to support Airbus Helicopters' digitalization journey. This digitalization journey started, as I said, four years ago. At the end, we wanted at least to provide an agile way to design, develop, test, and deploy new services for internal businesses, but also for our customers at Airbus Helicopters. We wanted to ease our onboarding process. This is part of the process that you just described before: we have to adapt our process to be more agile on the onboarding process of our ecosystem of partners and to accelerate our transformation.

For sure, as Airbus Helicopters, we have to take care of the security of the solution. So we thought about a secure and easy way for developers and application owners to use, at the end, the overall services that we are providing. I will describe later on the next slide the services that this digital platform is providing.

As with most big companies, we have technical complexity. One of the aims, one of the objectives of the platform, is also to hide as far as possible the technical complexity of our current information systems, and provide at least some added services to handle this complexity.

We wanted also to take the opportunity through this digital platform to evangelize a DevSecOps culture to all businesses and all development teams, to take care first, for sure, of the quality of the code itself, but also to be secure at the code level and also at runtime. This is clearly part of the overall objective of the platform.

To be able to reach this objective, to be honest, we had to standardize the technical stacks that this platform will provide to the development teams and to the application owners' teams. At the end, this is also a better way for us to be able to easily better manage the obsolescence of the overall technical stacks, because I think that you all know that the main difficulty that we have is to manage this obsolescence regarding the number of technologies that we have to take care of.

At the end, we found a way, with Capgemini support, to easily deploy the solution and to find a way to easily support this platform with a small team. You have to know that we are only four internal people managing this platform with the support of Capgemini. In Capgemini, I think, Jonathan, you should have more or less five or six people. That was part of the challenges on our side.

For sure, as Jonathan said, we have a learning curve. This learning curve started four years ago. We have reached some objectives already, but we have not reached all the objectives that we have to reach currently. So we share with you just quickly on the next slide what is the digital platform, maybe on a more technical aspect.

This digital platform is fully hosted and running on a Red Hat OpenShift cluster. This Red Hat OpenShift cluster is providing at least two main components, two main zones that you can see on the slide. On the left of the slide, you can see the pipeline zone, the way that the developers and the application owners interact with the digital platform itself and with the services.

We are operating at least two main services for the end users, so the developers and the product owners. The first one is, for sure, GitLab, to manage the source code itself of the applications. We are providing also Mattermost, an instant messaging solution, helping us first to interact with the team and on all the projects with the teams, but also we are using Mattermost to send feedback of the pipeline that has been run on the platform to the developers and the project teams.

As soon as the new source code is published on GitLab, you have an automatic pipeline that is launched. You can see it on the left. This is currently based on Jenkins and Jenkins Pipeline, but we are also, in this pipeline, running security checks. We are performing some checks with the artifact repository if we need to, and as soon as the image itself has been built, we are pushing this image in the zone to run, at the end, the application itself. We are providing for the end users the automatic access to start to test the application that has been built on the pipeline.

As I said, we tried to mask and hide the complexity of our information system. This is why we decided first to integrate on the platform the capacity to perform some application performance monitoring. This is the APM zone on the right of the slide. Second, the full integration of the SaaS or enterprise solutions that we are able to provide to the end users, and especially to the developers, to help us to be more agile.

The key benefits of this platform are first, code centralization, to be sure that we always have the code and the last version of the code of the application running on this platform. We have a full integration in our information system. We are secured because we are providing at least some security stuff to be sure that if something is going wrong in terms of security, we are blocking the deployment of the application on the platform itself, and we have integrated the SSO.

This is part of the overall spirit that you just described before, Jonathan. We reduce drastically the time to market to deliver new applications and new services to our customers. We have a collaboration approach and the overall workload of the team is optimized by the way due to the fact that all of the pipeline is fully automated.

Jonathan Le Lous

What we can do, if you look at this way, on every project we are going to have the same approach. Most of the time we complexify too much. As we say, it is technology stuff. You have technology stacks, and today not every company can go purely on public cloud. That was the case of Alex's scenario, for example, because in Airbus you have a really highly regulated part of their activities that cannot be managed outside. Today there is a strategy of Airbus to go on AWS and on private cloud, and depending on the case of your project, or what kind of restrictions you have, you could go on one or the other.

That is really interesting to see, because at the end of the day, when you would like to deploy DevOps and a container-based DevOps platform, or platform as a service based on microservices, you have two scenarios. You could do all on private cloud, and you could do this on public cloud. Depending on how far you would like to go on public cloud, you could use directly the native platforms from your cloud provider and use their DevOps tooling, like Azure DevOps, for example, or GitHub Actions, for example, or you could do your own and use your GitHub CI, for example, if you would like, or another tooling. It is really up to you and up to your organization.

When you say DevOps, because we are at DevOps Enterprise Summit, particularly on containers, we are talking a lot about DevOps on top of Kubernetes, on top of the container orchestration platform. Even if you think you have one container orchestration platform, you are going to have a dev, pre-prod, prod, and so on platform, and you have to manage also the complexity and all the automation of how you integrate those clusters and make this smooth for the developers.

All the magic from DevOps and the complexity of working with Alex is because today we support Alex's platform more on the production side, on the ops side, but let Alex and the teams do whatever they want on the platform because we need to bring innovation. That is the kind of description you have and the process we have to smooth the relationship, integrating SRE, integrating DevOps, and so on.

What is really interesting in the talk is mostly the way we address update and maintenance of your platform in the long term. When you think why the OpenShift choice has been made, it is mostly because when you look at a Kubernetes orchestration platform on the private cloud side, you have to manage plenty of different tuning, plenty of different tasks. Not all platforms have this opportunity. In Capgemini, we have a bunch of benchmarks of the different platforms you have on the market. It could be GKE, it could be OpenShift, it could be Rancher, and depending on the scenario of the client you could have different things. I think on the Airbus side, the choice has been made many years ago, and it was clear on this side. We even had to go from one version to a new version of OpenShift. Maybe this slide is what is Red Hat OpenShift.

Obviously, we are not here with Alex to promote OpenShift or another tooling, but it is interesting. Maybe you could explain, Alex, on this side, why you chose OpenShift and what kind of tools you liked in OpenShift.

Alexandre Barbier

Yeah, sure. I will not go too much into the detail of the slide, so I will let the people have a look on the slide. At the end, as I said, we are a small team. We are only four people internally, and we have to be able to support this team and to grow up with this team on the different solutions and the technical solutions that we have to handle and support in production mode. This is quite important.

Basically, OpenShift is at least providing, as you said already, some packaged services that are easy to use. You have the support of Red Hat at the end on our side, to be able to get the right answer if we have any issues or any problem in production, but also in the development environment. That has been really better for us, to move on OpenShift regarding the overall ecosystem that OpenShift is providing on top of Kubernetes.

As you said, this is fully packaged, fully integrated in the console, fully integrated in the product. You can do whatever you want with the project, like GitOps for OpenShift, like pipelines with Jenkins if you want to continue with Jenkins. I will speak about it later on, but now with Tekton, all this set of technologies that you could find on specific pieces of open source projects has been brought together on the OpenShift platform, and we have the support on top.

Jonathan Le Lous

That is really important, the support phase. We do have only five minutes now to conclude. It is really an interesting topic. If you would like to ask questions, feel free to ask questions after this session, but maybe for the last four minutes, Alex, we could conclude on this part.

Alexandre Barbier

Yeah, sure. The lessons learned on this journey that started four years ago, as I said: this platform has to be as agile as the projects are. This is a key point. Within Airbus globally, the SAFe framework, the Scaled Agile Framework, has been set up for years now, and we had to find on our side, on the IT side, a way to support and to be fully integrated in this overall scaled agile framework that has been set up at the enterprise level.

We decided also to standardize and fully manage the pipelines, covering at least 80% of the expectations of the development teams. That means that we are not providing the OpenShift platform and letting people do what they want on the pipeline side. We are managing for them the pipelines, and we are standardizing the pipeline itself and the technical stacks that we are able to provide. This is quite important to keep in mind.

We have started small on the containerization and Kubernetes approach, just also to help our business start with this containerization journey and Kubernetes. OpenShift, as I already said, provides a lot of tools on top of Kubernetes that help us really a lot to be more agile and able to quickly deliver new services.

The image lifecycle is quite important in containerization environments. The image lifecycle is manageable via automatic building phases and updates, and we are able to deliver quickly all the updates that we have to handle on the ecosystem itself. This is also the way that Red Hat is providing to us to easily manage the image. The image of Red Hat is normally fully automatic, basically, but we have to take care of the security.

Now we are running on OpenShift 4 since some months now, from September if I am not wrong, and we had the opportunity with the next version of OpenShift 4 to deliver new services on top of the previous version that we ran, so on the 3.11 version. The pipelines have to be migrated from Jenkins to Tekton, because Tekton is the official service that OpenShift is pushing a lot, to be honest. I think this is a good solution. This is a full controller for agile instructions to run on the OpenShift platform at least.

We are also thinking about providing new services on top to support and continue to support the transformation of the company, including artificial intelligence, machine learning, 3D features, test automation, and much more. This is not the end of the journey; this is part of the overall journey we started some years ago.

Jonathan Le Lous

Thank you. That is a great conclusion. Thank you very much. It was a great journey, by the way. We are still continuing to work later. We learned also a lot of stuff on our side, and yeah, we really enjoyed our time. Let's talk. We are going to have a few minutes for Q&A session, and see you at the Q&A session. Thank you very much.

Alexandre Barbier

Thank you. Bye.