 Hi everybody. It's great to be here today. Thanks a lot for coming to this session. It's great to be here after exchanging on the mailing list and the GapDev and with issues. It's great to meet you guys. So this talk is an introduction to a both session I'm proposing tomorrow and how we can have that platform read to organization context. So let me introduce a bit about myself. I'm working at Orange. Orange is one of the largest tech operator in Europe and in Africa. It's present in 29 markets with 240 million subscribers. And so obviously this requires lots of development, lots of software. Indie thousand apps, developers, and ops. And so pass is relevant in this case. A short disclaimer, Orange is a federated group. So it's made of lots of different business units and entities that have large autonomies. And I won't be speaking for all of Orange. I'm working mainly in a small team, which is in the central corp, which is helping the teams in subsidiaries to sort of pass. So it's possible that you hear a slightly different voice in some other entities. So I've been working with platform release a few years and contributing to docs and to a few pull requests. And you can contact me on Twitter and at this email. So adopting a path to meet new business objectives often requires more than providing an out-of-the-box could-vendory instance. And the integration into the ecosystem, to the organization ecosystem, and support for the transformation of the processes might be key to the Cloud Foundry adoption. So I'd like to do a short poll on how you stand with respect to Cloud Foundry. How many of you are just starting to learn Cloud Foundry? OK, maybe 20%. How many of you are actually using and consuming Cloud Foundry? OK, I want to fourth again. How many of you are providing Cloud Foundry to others? Platform operators? OK, a little less. And how many contributing actually to Cloud Foundry, coding and vendors? OK, thanks. So I'll start with sharing some of our organization-specific requirements, and then ways we have adopted Cloud Foundry within the range. And then we'll think about potential future Cloud Foundry extensions that could maybe allow to get some of these org-specific requirements easier in the futures. And for this, I will be using the impact mapping methodology. So the impact mapping technology was introduced by Gaucho Adzik. The idea is to, when we introduce a path, is to formalize the objectives. Why are we introducing that? How can we measure that this goal is rich? And then, who can help us reach this goal in terms of actors? Who in the organization will help us deliver this? And then, what behaviors will we observe in this population that will trigger these objectives? And then finally, as a platform operator providing a pass, what can I do in terms of deliverable to trigger those behaviors and to support them? So I'll be sharing our impact map with this color coding. I've added on deliverables a bit more details in terms of what we already delivered, what stuff we have not yet delivered, but we see some solutions around, and stuff we have not solution yet, which is currently blocked. So as you see, the map is quite large when we expand it. So I will zoom through specific elements of the map. And to give you some context, you will have some breadcrumbs at the top telling you where we are. And if you want to, it might be fast at times. So if you want to take time to read it afterwards, it's online, either this URL or it's also in a JSON format on GitHub. So you can clone it, and maybe if you find it useful, try to do that for your own organization. So why are we introducing a pass in our context? So nothing really new. We want our projects to deliver faster, sooner. I'll let you read the kind of measurement that we have with a set of targets that the methodology, the impact mapping is suggesting us. We want our application to be more able to improve the quality of service and obviously to reduce the cost. Who will be helping us to do that? What are the actors in our system? So primary actors would be the one that would be consuming the pass, so the developers and the operation teams. So when we go and ask the developers, OK, how can you help us get those objectives? So improve those measurements in terms of delivering faster, sooner, safer, and cheaper? They said, do you think the pass can help us do that? They say, well, yeah, let me try. So can you try that on your own project? I said, well, I'd rather test that on toys for now. What do you need to test that on toys? Can you use a public instance? Not really. The corporate rules is not allowing me to go public for now. I could just use toys with random data, but if you want really me to use with real data, you want to give me a private instance on-prem. So that's what we're starting doing. So it's been really starting instantiating platform on-prem, on the two AIS that we have, vCloud and OpenStack, and taking into account some specificities that we have around specific network architecture with respect to outgoing traffic and to network isolation. So it's been really working well, and Bosch was really helping in terms of automation for that. So we have great feedback around that. And we connected to the UA for getting identity. We still have some work to be done around backups on where we're awake. Then we started providing access to the common services, SMTP, outgoing internet access through custom service brokers. Similarly for the logs, so we've been using Splunk to centralize the logs. And still lots of activities around that to make it more multi-tenant, to make it easier to search and find the logs. And the log search seems really something great we'll be looking at. And so our instance is there. It's running great. And so the first feedback we have from developers testing tools, so CMS development tools, is that yes, they reach objectives. It's getting much faster to provision. And so now we'll get back to them. Are you now ready to develop your own app and Cloud Foundry? And they say, well, only when the operation seems really we'll agree and we'll trust it. So what does it take? Well, the operation seems tell us we'd like to have the same level of quality that we have on traditional shared hosting. So they ask us for multi-AZ support. And they ask us for multi-data center, multi-regions as well. So yeah, it's not yet ready. But OK, can you still, developers, can you still start developing your app, even though it's not ready? We're working on that. So yeah, they start doing that. So all basics Cloud Foundry setup is doing great. Our prediction ready pass is mastering. Still some work. And so when the developers start developing their apps on Cloud Foundry, they have two ways. The most logical one, which looks really promising, is adopting the Cloud Native architecture. And luckily, the industry and Matt Stinn in particular has been doing a great job at documenting that. And so the Spring Boot support, we are mainly Java development. The Spring Boot support with prediction ready support, support for microservice architecture seems really promising. So we're working actively on that. And yeah, this looks great for innovators. But also we have lots of legacy apps that will take time to transform and to adapt. So we are thinking, OK, can we help the others as well? Can we help the existing app to conform to 12-factor apps? So this, we've started with apps that would have some state, session state. So starting some work around providing session state store. Then as well, the apps that are using the persistent file system, not really for intensive writes, but maybe for configurations that are saved on disk and that needs to be present across restart. So we're working with RaxiS and either with native APIs or with the file system abstraction using Fuse. And as well, they exchange files with other apps. So working to provide gateways so that the section is easier. And again, and also the single sign on SSO. So then yeah, we have few apps that are being developed like that and the developer's really happy. So we get back to the ops and we ask them, are you ready now to operate that? And so again, they have two choice. Either they adopt the kind of cloud native practices, which is greatly described. And so this translates into versioning the app config in Git, pulling the app binaries from repository manually or in script prior to pushing and automating development workflows from CLI individual steps. And the app would be providing some production features for troubleshooting, for dynamic config. So yeah, it's really promising this so that we are actively working on that. But as well, we see some limitation and obstacles in our case, which is the organization is slow to change, maybe slower than software in our case. So we're still lacking some dedicated ops in many cases. The project versus product transition is not yet done. So we see a lot of time projects and not long-term product teams. Even in some case, we have auto software for a number of cases, which makes it hard to have business capability teams, which is mainstream practice. And another aspect is the transition from centralized governance to decentralized autonomy. The fact that business capability team are really at the autonomy to do things, it takes time. Also, legacy apps takes time to transform, technically. And sometimes we see gaps in culture between developers and ops and in tools being used. So we were also asking, how can we help the vast majority? And in our case, it looks like getting from centralized governance to decentralized autonomy would be easier for the organization to grant it if there is transparency. If the organization can look at what the teams are doing and trust it, trust what they do, especially for the security aspect, but not only. And also to provide a common baseline in terms of operations, so that there is less specificity among apps. So we can have non-dedicated ops that would operate the apps in a similar way. So for this, we are prototyping with an add-on on top of Clutronry, which is called El Paso. And so our past user can either use Clutronry directly or they can go to El Paso through its UI and APIs. And El Paso will drive Clutronry and the other services that are not yet available in Clutronry. And so in this, in El Paso, we are enriching the data model of Clutronry with some stuff that are specific to our needs. So mostly some metadata's that are necessary to integrate into the organization process. So we have notion of application, which we could have called that product to avoid the conflict naming with CF apps. But well, it's called application for now. We have set of users and for each application, there is a version list of releases. And so the releases get a set of processing service and data services. And so it's kind of a template. El Paso provide the templates of applications with the associated metadata in it. And so this translates into the CF model through a mapping mechanism, which is pluggable, and which allows us to add some logic and to use to leverage the metadata that is been inserted by the team. And so this provides visibility and this allows us to add some value and some additional security. So for the standardized operations, we still have some work to be done. But for example, on the replicable aspect, El Paso is capturing what the application is supporting in terms of environment variables. And so this is version in the architecture, application architectures. And so it makes it explicit. And so the intimacy, the required intimacy between developers and ops gets a bit reduced with this explicit config. Similar, the binaries region are trust and actually El Paso will fetch the binaries from the Maven corp repository and will do the deployment. So we have less reliance on scripts or develop operations to be pulling the artifacts. El Paso is doing that. We still have a lot of work to be done on logs to make it easier to get logs, to change log level dynamically. Similar on metrics, still a lot of work to be done to be able to get the metrics through GMX, the container level metrics as well. It's a bit maybe too small for you to read. So yeah, for getting the normalized, the baseline operation across apps, other stuffs we are challenged with is the app state. Getting the teams are requiring automated backups and restores or snapshot across the release deployments so that they can revert. If ever that automated database scheme upgrade is failing across apps. So lots of stuff to be done around the app state on the troubleshooting as well. To ease the troubleshooting without the app providing the features like in Spring Boot, a creator. Would like to find a way that Java applications can be troubleshoots similarly. Okay. So that was for the ops. Another stuff we've been trying to do is to involve the existing shared infrastructure experts in the discussion. And so that they can help us better reach our goals. So when we look at the other actors, the off-stage actors, so the one that are not directly using the pass but are influencing is adoption. In your case, we have also the transferal architects. And so we are starting asking them, okay, can you review what the cloud front is doing and challenge it against the current best practice and the recommendation that you have across the years. And so this led to some interesting discussions, such as for example on the PHP side. One requirements to have a different user between staging and running. So that when to avoid and to prevent code injection on the file system at runtime. So different group permission between some files so that if the application is vulnerable, code won't be injected on the file system. So relies on username space. So yeah, this has led to some interesting discussion. And then some requests back to the path and to the Clotunary community. We're also working with transferal architect also as a way to reduce the kind of resistance to adoption. So to get their feedback and to have them capture the best practice and what they have acquired for the years to, so that then they can project to us. And to use as well Clotunary as a way for them to evaluate upcoming technology as part of their work. So the Bosch Docker release seems really a great way to test that, it looks really promising for that. Okay, so how can we adapt Clotunary to organization specific request requirements? So first off is we use the existing Clotunary extension and customization mechanism. So you've seen some of this during the impact map screenshots. There's a lot of stuff we have not yet explored but yeah, this exact customization mechanism give us a great possibility and we have a lot more to explore on our side. Another possibility is to for Clotunary and extend it. So to insert some additional components to replace some components. So there have been some great examples and blogs. No router from LDS Church is one example. Some custom DAs. We have chosen not to use this, not to follow this route so far because of limited resource that we have and as well for, because of the time it takes to adapt to core Java skills to Ruby and to Golang. And so one other alternative to adapting Clotunary to organization specific requirements is that what's presenting is having an add-on on top of Clotunary to capture additional metadata and to fit better in the processes. So we can think a little bit about what potential future Clotunary extension could help us to remove some of the specifics that we have done or at least to be a smoother integration. And so one thing we were thinking of is the ability to have metadata attached to the Clotunary entities a bit similar to AWS allows us to put some tags on instances and services and then query those entities and to get charged with breakdown of those tags. So this would really help to be maybe in a form of tags, tags to be attached to application, to space of two services to tell whether the application is production of development, what kind of absentee it's related to, the AdCobb name that would fill then the configuration management database, the CMDB on the upside that would fill the as well the change management processes. And another aspect we were thinking about is to intercept some of the CCAPI verbs. So maybe through the upcoming router service or maybe some kind of plugging on the Cloud Controller in order to have some more fine grained access control to be able to more finely tune which entities that we need to control or potentially to do transformations on the verbs such as maybe pulling dynamically the binaries. I do a CF push by putting the Maven artifact coordinates and dynamically this interceptor will pull the binaries from the repo and get it. And maybe extensions and new verbs. So I'll be talking a bit more tomorrow about El Passo open source that I was presenting before. We are open sourcing that and I'll be detailing more with a screenshot use case in more detail that we're trying to achieve. So the idea of this introduction was to see if we could share or organization specific requirements the way we have adopted cloutonry to those so far. What challenges are remaining? So I'm inviting you to meet tomorrow at 10.40 a.m. for our related both. And for this, thank you very much.