Well, so you're saying you live around Toulouse, right? Yeah. And so, like, if you were work aside, like, if someone was going there, like, say, like me, importantly, like, what would you recommend would be a, just something relaxing to do? Like, what's your ideal day in Toulouse? Toulouse? Ah, make a small visit of the capital, I think, a nice place in Toulouse. Yeah. And if we have time, we have the mountain, the scenery of Toulouse, one hour by car. Ah. So, I think you call... So, sort of outdoor activities. Yeah, outdoor activities. And you can visit a big town called Carcassonne. I think you already saw in some medieval films. Ah, right, right. Very nice, nice medieval. Are there some castles and things there? Yeah. Oh. Big, I don't remember, a lot of films. Well, you just, you just, well, first, why don't you introduce yourself? Okay. I'm working in France, Kallem, since 19 years ago. And so, I have started as a developer, and now I am in the support team to help the developer. I am the global architect. All right. Because in the team, we provide tooling, framework, CICD for the developers, so a lot of things. And I check all the consistency between all the people provide. For example, a new language arrived. We don't know Node.js, for example. So, we need to align the tooling. We need to align the framework. So, you're sort of like a product manager for the developers. I mean, if you think of it, well, I mean, tell me if I'm wrong, but if you think of them as customers, right? Like, you think about what it is they do and what they need and try to help deliver. So, clearly, one pillar of TechSE is to still be customer-centric and be sure what we provide and fit for the end users. Right. And then a background as a developer is nice for that. It's always good to have. What did you develop in? Like, what languages did you use? Languages? It was Java, mostly, because Java started a long time ago in France.
2:00You know, I think it was like two days and you need to beat all yourself. Right. And when we are starting, for example, when I have started, if we want just to have a table and sort the table, you need to implement all in our table. Yeah. In fact, in the team, we have started to develop a set of subcomponents, like what's later called the GSF. Oh, right, right. And if you have already set up in France, we have called that Welcome. And I am with another guy, two guys, we have developed that. And we have spread this framework in all Air France, and I think in 2010, most of 50% of the application use it in Air France. And now is, of course, legacy one. And then, so, is that a collection of services? Or what was that again that you just said? It was a tag link, in fact. Ah, okay, okay. In principle, so we have just write RF dot dot table. Oh, right, right. And that generates a table for you. You have just to say, okay, I want to sort this colon. And all the code was generated behind. Wow, so it auto-generated. It was very nice for the date. Yeah, yeah. But today is... Yeah, yeah. Yeah, I was just talking with someone who had been working on another application, and they were describing that the application was basically a database, right? Like a UI on top of a database. And I was thinking, I don't know if it was fondly, but I was remembering all the, you know, your joins and outer joins and all your crazy SQL stuff to, like, pull that together. And yeah, automating that is certainly nice. Yeah, so in the end, when we presented that to the developer, they reduced their code by two or three at this time. And they quick, very fast, their development. And one thing very interesting, and today, very hard, is all the skin of each application was the same. Because inside the tag link, they say, okay, I am a button, I am here in the screen.
4:00Right. So I need to be at this render, this rendering. So by this way, it was very powerful for the developer, because they have not to learn a brand image or things like that, because all was behind. Right, right. Yeah, that's a good project. And how, like, how widely did you say the result of it is used now? Like, how is it used? Today, it's decreased, I think. Right. Because the application was rewriting, and today we are in Angular. Right. And, but, yes, I think in 2010, it was used by 50%. Right, right, right. So it was much. So to that end, so the team that you're on, I mean, you think it would be fair to say you support developers, right? Like you kind of, I don't know what you call it internally, but you support the developer services and tools, and I'll advocate for them, as it were, about what the platform needs to look like. Yeah. And so how, how did that team come about? In fact, at the beginning, when Techassist started, I said, okay, it was an entity, but no problem, I am project, I'm doing what I want. Right, exactly. You had to centralize it. And it was the beginning like this. But what happened after two or three years, in fact, when there is a, this project need a migration, if I use the technology, I don't know, for example, Ruby. Right, right. And now we say, okay, I want to move. Ah, because now the stack of operations has changed, and the developer is not there right now. So the project manager called to Techassist and said, okay, could you please me? And we said, I'm sorry, we don't use what we provide, so we can help you. And so by this way, now the project manager said, okay, is it validated by Techassist and can support us after? Right, right. And by this way, in fact. That's always a good thing to check, right? Yeah. And by this way, now, for example, when the project starts, we are invited to what is called the launch meeting, just to be sure of what the project want to do. Now it's not an architect thinks, et cetera, we are more technical. Right. And we can say, okay, this framework is good, yeah, no problem, for us it's perfect.
6:04For example, Julian does that. And by this way, we can keep our expertise level and spread expertise level. So when they have a problem, they can call us, and mostly we try to find the solution for them, and sometimes we do code review, and we can help to say, okay, it's not this way, or this way. And we should adapt to this. Right, right. So this is sort of like the front end of, I don't think people say governance too much anymore. Yeah. But it's the front end of governance in what your team is trying to do is help the developers, make sure you can support the tools and the service, the things that they use. So if there's a new thing they want to use, it's a good idea to make sure you can support it and work with them early enough on, I guess, over lunch. Actually, when we start new things, for example, Kafka or things like that, we try to be close with the teams to help them to start. Right. But we aren't alone because sometimes there is a part of operation, so that we can help and we have a time to be sure what we provide is in the right way. So we go to the confederate, we try to keep the good feeling and to say, okay, we need to move in this direction, this direction. For example, for Cloud Foundry, at the beginning, it was in Tech SE, but in Amsterdam, and it was the first setup with the open source version. And we said, okay, we have implemented Cloud Foundry. These developers are very okay and very powerful. And after, we have tried to say, okay, now please, operation, implement it. I'm curious, and this is a good instance. It might be too big, but how do you walk through that? Do you have a system, a process that you go through that? At the beginning, it was not a process. Is it more just talking with people? No, at the beginning, we have started in Tech SE to implement the CICD, more on the CI part at the beginning, as it was 10 years ago. And so it was good because, in fact, we are autonomous. Okay, I have my JI, I have my bucket, I have my bamboo, and all it was perfect.
8:06And to deploy, please, call operation. Yeah, yeah. In the test. And by this way, that's why we say, maybe if we want to have a sandbox, something like that, in kind of sight, people say, okay, Cloud Foundry is powerful. So they have tried to implement it. They have implemented. Project moved. And when we said, okay, operation, maybe you need to check, it can be powerful too. It was a little bit, at the beginning, difficult because I say, okay, but we provide tools. What do you have in Cloud Foundry, which should create in our tooling? Right, right, right, right. So beginning, I started with this, and at the end, I say, okay, we are going to build a joint Cloud Foundry team, and we want to deliver the Cloud Foundry solution. And so, I mean, it strikes me that you're right in the middle of developers and operators, right? Yeah, it's a subset, in fact, of TechCase. It was the team with managers, CICD has done that. Oh, right, right, right, right. It's not the team with managers framework or anything like that. They have used it. I say, why, yes, it's powerful. Just I have to click, and I can't deploy my application. It's incredible. Right. So starting like this. So like in the instance of a PCF or something else, like how do you, what are the differences between sort of working with the developers and working with the operations people? Like you're saying. It was difficult because what we see, we have started with Cloud Foundry open source. So when we, operations wanted to start, they say, okay, we are, today you are using Tomcat as an open source. So platform is an open source. We are going to implement it in an open source. Right, right. And this is what the developers were saying? The developers, no problem. They want the platform. Right, right, right. No source or Pivotal, no problem for them. But what we saw is fact is the transformation in Ops was more difficult with the open source version because what we see, they have a lot of silos. And so you need to convince one department. They say, okay, it's interesting, but I want to add the databases. So the other person, do you have a budget?
10:07No? Okay. And when things, when Pivotal guys arrive, they say, okay, we can help you to set up. We can help you to enable all the team. What is a container? What is a concept? What we need to work together and break the silo. And have some person outside the company help a lot. Because they are most earned, in fact. You know, that's an interesting point that having, working with developers can be faster because I guess there's less of them. Right? Like there's, it's sort of. That depends. In fact, you have some key developers. Right. Like you know it. And so when you say, hey, please, you ring the coffee. You say, you want this? I can do it very quickly like this, like this. Right, right. And by this way, you can propagate. Yeah. So that's a good point. For example, when we have started the Pepe transformation, of course, we are going to see some developers we are knowing because we say you have no budget. You need to take a new budget, this transformation, but you have some people from Tech.se and Pivotal came and helped you to set up the transformation. And of course, it was more easiest when you're knowing the developer. Right. What we see is for the early adopter, it's easy, but after you want to scale, it's not enough. And now, for example, we are going to buy it by the hierarchical way. Right. Like, okay, we wanted to re-platform, to modernize application. So you need budget, you need to evaluate. And you see, it's much larger in scope. Yes, it's more larger than what we are today, in fact. Right, right. And so it sounds like with developers, before you get to the larger in scope, you know, application transformation stuff. But initially, it's a lot more casual to talk with them. I mean, you know, as you said, you can talk with them over coffee and you know the key people. But then, as you were saying, in operations, there are many different silos.
12:10Yeah. And so you almost have to go visit and learn all those different people. The good point is when we see Cloud Foundry open source as really difficult to implement in apps, there is a high decision in France-KLM to say, okay, we are creating a new program dedicated on the containerized platform. And there is already a lot of initiative around Kubernetes, Docker, things like that. And they say, okay, we put all the people in the same place. We create a virtual team. Right, right, right. And in this virtual team, me and Julien are the dev representative. So we have created what we call the MVP. And we say, okay, we have done a survey with the developer that the features I want, we have created a subset because at the beginning, it was more than 100 of requirements. As always, right. If we say that to the, please develop that we have 100, it's very hard. So at the end, we reduce it to 40, I think. Okay, that's a big reduction. And most of them are more about the platform concept. Yeah, yeah. And some of them are about the services. Okay. For example, in the services, we said just, please put in self-service a post-gray and release. And the rest was more, okay, I want to be able to manage myself, my environment. I want to be able to declare automatically the DNS. But I think we were natively, in fact, in the platform. On that point, I'm curious, like, so what were, like, some of the 60 things that were cut? Like, it's interesting to think about, like, what actually are the high-priority things versus now? Mostly it was services at the beginning because, for example, we wanted Oracle, we wanted MySQL, RabbitMQ, a lot of services. Right. And some of them are most about the autonomy of the developer for existing things inside the platform because today we can reach them by a cup, for example, in platformery. I guess what you're saying is, so you might have, I'm just making up some numbers, you might have 50 existing services, whether they're data services or process things. And, of course, you've got to do all 50 of them, right?
14:12That's all priority one. But you can kind of systematically go through and say, well, they already exist, right? So we could do a minimal amount of work to make it so you can use them. And at some point, we could integrate them more fully into the platform. But you can, they're not so high-priority versus other ones that we need to make more native. Yeah, for example, when we have kept Redis and Postgre at the beginning, it was just because all new projects in R-France KNM should be used as a rational database of Postgre. So as we said, we are going to put this one. Yeah. Because mostly of applications have other databases at the minimum. Right, right. And for Redis, it was simple. If we started to implement a Node.js application, and if you want to distribute caching, it's Redis, it's not Postgre. So that's why we put these two in the I-priority. So you have that prioritization of services. Yeah. And I guess, where does that go? Is that what goes back to operations to work on, or does your team work on that? No. In CAD, we are just providing the requirements. We explain what we want. And after it's in this operation, they should provide us. But it was very difficult at the beginning because to push the requirement of the size broker, we have four teams in operation can handle it. And that's a good thing. The last month, they say, okay, we're creating only one entry point. So for me, it's not simple now. I speak with them, and these people are going to dispatch in operation. Because, for example, I have the database team. I have the storage team, et cetera, et cetera. So each time I want something, I need to discuss with the architect of ours or the responsible of the platform. So now, in operations, they have rationalized. Right, right. So for us, it's not easy. In fact, if we check with the operation, I already have the services for the current stacks. Right, right. And so what we ask them is just we wanted to be able to consume as a self-service. And so, by the way, we ask us to create a service broker.
16:12There is a service broker today inside the platform. But when we ask to the operation, please install it, they say, no, it's difficult because we don't manage this stack. We don't manage this OS. And they say, no, we wanted to use our current ready implementation. And so for that, of course, I need to create their own service brokering to do that. So now there is one dedicated team to do it. Oh, right, right, right. That's sort of like the service broker team. So having gone through all of this for a long time, if, let's say, someone was starting new doing this, right, outside of Air France KLM, like, what's, like, the playbook you would give them? Like, what's, like, the recipe you would give them for putting this together, a team like this together? In fact, today, when we have new people arrive in Air France KLM, we have explained what is working in Air France, what is a CICD, what is all the tooling that you should use, the starter pack, if you want. Sure. Your initial sort of on-ramping training. Yes, just to see, yes, what is the entity, what is legacy, what helps they can provide for us. And after, they have, in the wiki, all information to set up their own environment for themselves. And today, when we wanted to improve it, so we have created the TechAC Pro, where it's coaching for the first sprint, if you want, where we work with us. Because previously, we are just waiting, the developers say, I have need to help, and they come, and we have to solve the problem. And two days later, they come again, and they say, I have a problem. So now the idea is, okay, you start, we are going to help you to set up your environment, and we are more close for one week. Thanks, for example. And we help us to set up, and to be sure the CICD is implemented, the code is set up. Oh, like in version control. Yeah. Yeah. So there's almost, I mean, we at Pivotal call that kind of process like a dojo, right?
18:16Yeah, like a dojo. Which is a fancy word. I think we are learning today, with Pivot transformation today, we learn about the pairing method. Maybe it's something we can put inside, in place, we are going to see. Because what you see was powerful for that. So maybe it's a good idea to enable the people by this way, too. Yeah. So that seems like a part of the cookbook of setting it up is, and to say it out loud seems obvious, but people probably don't do it, is you should do some training, right? Like when you come up with the common services for developers, and not only do you want them to use the existing ones, but understand the process of getting new ones added, you've got to train them about that, rather than just sending them like, here's a wiki page to read. Good luck. Yeah, but no, that's why we wanted to focus more on the coaching. Exactly, exactly. Because what we see in the people, even if you have a nice documentation, most of the developers don't read it, and it's hard to keep it very up to date. Exactly, exactly. Because it changes very fast. So yes, we put effort today on the coaching part. So the coaching part is a huge amount of the process. Yeah, the process is, yeah. All right, well, as the final question. So when you're thinking about like, you know, everyone, including myself, go on vacation for a while, come back, it'll be a nice fall. Like, what are you planning on, like, what's a problem you're planning on solving over the next like six months or so? Like, is it just down to the services to implement, or is there a part of the process you want to fix? Like, how are you going to improve the team? I think two things on upside, what they should deliver now is the brokering and the PKS environment, because it's not yet common in France, KLM. And the last one is to enlarge the service brokering we have today. Right, right. That's the main point, and continue the PPP transformation. Right, right. Yeah, that'd be interesting. There's not that many people. So it was not the last question. No, I'm always bad at that.
20:16I usually ask like one or two more questions. Last topic area, let's call it. But you'll be in an interesting role, because there's not that many organizations like Air France, KLM, that are figuring out providing Kubernetes as a service, right, like with PKS. And so that'll be really fun to, like, see what that's like, right? Like, to see what people actually end up using and how it's supported. And there'll be a lot of over the next, if we talk in a year, you should have a lot of good stories about what that actually looks like. I think in the story, as I said previously, I started a long time ago. Yeah. In KLM's side, there are already a lot of applications running on Kubernetes. So we have a lot of learning about how to integrate in the JCD, how to do patch management. So I think we have the best of the world. Yeah. With PKS and PKS, yes, we can bring a new stage. Absolutely. For Skyrim. Yeah. Well, thank you. It's, you know, we, there's always a lot of discussions in the community about, like, doing platform as a product and developer services and getting a little notion of the actual, what would you call it, the struggles slash exciting learnings, right? The way it actually works and the people you need to talk with and the processes you arrange are not so great. They're not documented as well as they could. So I think you can give us a little look at it. So thanks. I appreciate it. Thanks. Thank you. Thank you.