 Hi everybody. Thanks for coming this afternoon. I hope you're enjoying this summit with great talks and great exchanges. So yesterday I had a both introduction about adapting Cloud Foundry to organization specific requirements. So I gave some background around the range goals in using a pass and today I'm going to go a bit more specifically about what we've done in a range. So let me introduce myself. I'm Guillaume Berge. I'm working at a range. So reminder, a range is one of the largest telecooperator in Europe and in Africa. It's present in 29 markets with 240 million subscribers and so this requires obviously lots of software in the thousand apps developers and operators. There's one specificity around the range is a federated group. So it's made of a set of subsidiaries which have large autonomy and so this are some specific challenges around getting past adoption with this context. So I'm part of a small team called El Paso which is promoting the use of a pass within these subsidiaries and specifically for internal IS. And so the disclaimer, I won't speak for all over range. You might have different voice for some entities. So I'm specifically targeted for internal IS with the business unit we're working on. So pure of that. Is El Paso Texas our close? We are located in France in Grenoble in the Alps and here is my contact. So today I go briefly about secret funder adoption within a range and specifically the El Paso add-on. We have been prototyping experimenting with on top of CodFoundry. It's going through our product goals, our feature overview, screenshots, internals and future works and challenges and we'll spend a bit minutes to think about potential future extension for CodFoundry that could help. So a bit of history. So my team, my team El Paso is originally doing some support and expertise in Java application servers and Java frameworks. And in 2010 when IS was introduced in Orange, we thought that there wouldn't be the silver bullet for apps. There would be the transformation for our team to use configuration management. To automate on top of the ass would be just too large to tackle and the amount of sharing, there would be possible amount of apps would be reduced. And so we are thinking at that time, how can pass help with this migration to cloud and get some shared automation? How can we get similar to an app engine on prem? So at that time there was no open source pass available. So we started thinking, okay, can we prototype to get a feel of what the private pass would look like taking into account our specificities in terms of specific packages on top of a standard distribution, but still with naming conventions, specific file system, specific stuff internally, specific MySQL and Postgres packaging as well, specific application servers, network architectures, and yes, so VMware vCloud, which was introduced at that time. So we're starting prototyping on vCloud, dynamic VM generation, image generation and VM spawning, and doing a csh-pass config and building on database as a product for Postgres and MySQL. And so getting some feedback around how it could be used and so it was great learning, but a lot of work obviously to maintain that. So when Cloud Foundry was open source along with Bosch in 2012, we tried Bosch on Amazon first because it was not yet available on vCloud. And then it took a bit of time to be available on vCloud. So we started prototyping how we could migrate the core for prototype onto Cloud Foundry and using Pivotal.io, Pivotal website on iO, and there was great learning and could get about similar feature parity with some holes, but we moved lots of stuff, we were prototyping. And so in 2014, when the vCloud CPI was released, we started installing Cloud Foundry internally. And we modified our El Paso prototype to leverage the on-prem CF instances. And now, this year, we are looking at having dual hosting mode, so either direct Cloud Foundry access and access through El Paso. So what's really about El Paso? I like to call it a product with respect to a project in the sense that we are a team which is stable in time, which is working as a product, getting some spec, automated tests and all that. But it's not really a product that we want to support outside of range. It's not a commercial product. It's more like it's not yet production grade. But still, we'd like, we are working like in a project, in a product mode. So really, it's about we're using El Paso as a playground for us as a platform operation teams to learn what it takes to develop a Cloud Native apps so that good playground for us to break the monolith and try to apply some of the Cloud Native architecture best practice. And to try to solve that in advance before our customers or colleagues running their apps and Cloud Foundry will tackle those problems. So it's been great learning for that. And it's also a lab for us to experiment how to use adoption within a range with some range specific features. So I'll go with a bit more detail on that now. So El Paso is another on top of Cloud Foundry. So the user can either go straight to the CC API with your CLI or whatever ID they use or they can go to El Paso with its UI in its API. And El Paso will drive both Cloud Foundry and other dependencies for the APIs. So in terms of goals and use cases, yeah, the Cloud Native architecture are greatly described at Stein, describing going from centralized governance to decentralized autonomy. And in your case, the organization is kind of reluctant to provide this autonomy. And we get a feeling that it would be much easier for the organization to grant this autonomy if there is some transparency. The organization can see what the business capability is doing in terms of security, some dependency to other apps so that it can provide trust to the business capability teams. So we're trying to provide some of this transparency through the El Paso admin. The second aspect is we're trying to help the one that won't be able to get this transformation soon enough to Cloud Native architecture. So the Cloud Native architecture requires some important technical changes that might be kind of optional but it's still. And some organizational changes as well. And some of our teams, so it's great. It looks like the future. It's very promising. And the innovators are adopting it. And we are thinking, what about the rest, the vast majority of users? In your case, we have some other context where the dev and apps intimacy is made more difficult because, for example, we have shared apps in a number of products or projects. We have some outsourced development which makes this intimacy between dev and apps difficult. So we are trying to help these type of users that won't be able to pick up the Cloud Native architecture practices right now. So we are trying to provide a kind of a common basic ability regardless of what the app is providing. And I'll get to that in a minute. We're trying to integrate the pass and Cloud Foundry into our ecosystem and work processes. So kind of capture some application metadata such as the application corporate ID that would need to be put in the CMDB. The type of environment, is it prod? Is it dev? So that some specific treatment can be made for dev or prod. Being able to support the impact analysis when there is no voltages, being able to look into change management, connection to the enterprise service bus, stuff like that. And as well, help capture the existing best practices that have been required for the years and put that into a pluggable thing. So what are current features? So we have some organization specific metadata that Elpas was collecting. And then basically it's a version app template where we'll have reproducible deployments without relying on the Cloud Foundry user to pull the binaries from a repo and use chat scripting between dev, QA and apps. So I'll get back to that in a minute. We also expose a knock specific service catalog with a granularity which is a bit different from what the underlying Cloud Foundry is exposing. The common operation base, so fetching the artifacts from the Maven corp repo. Formalizing what an app is supporting in terms of environment variables. So having some list of supported variables along with the semantics. The logs. And so let's start with screenshots to give you a better idea. So the first concept is the concept of application. Really we could have called that product to avoid the naming conflict with Cloud Foundry apps. Maybe we'll rename that for now it's application. So an application got some metadata, code, description. A list of members and the visibility whether it's public and anyone can fork it and use it kind of a template. Or private only the members can view it on releases. And then associated to this application there is a list of releases that would typically be for example this index example that sprints with a state machine associated to each release. And so here is an example of an interactive development. So we have a single app with what we call processing service. This is where the app binaries are pulled and a web UI service which is bound. This little check box represents the binding. And so in second version the user is adding some config and product database. In V2 the architecture doesn't change from what we see on the diagram but there is a new version artifact in the repo which is specified in the processing service. And in V3 they start breaking the monolith and so they start adding a back office service to manage for example the set of product which is being sold. So then they have still had the user facing web UI connectivity basically the routes and we'll see potentially some other stuff. And then back office. And they start breaking the config set into something which is common to front-end and back-end and something which is specific to UI and back-end. And then they add the messaging across the two apps. In V4 they start consuming another app API. So the dependencies may displace it here. And in V5 they start exposing an app again in the enterprise service bus. So basically the service catalog we split that into what we call external service. So that service which is external to the app which allows the app to communicate with the outside world. So typically the web UI and the API consumption and the explosion and as well for asynchronous messaging such as MQP outside the app. And then internal services are the services that the app is using to provide its service. So we have processing service with basic Java processing service which maps to Java build pack. And we are looking at also expanding that to analytics apps. Maybe apps running on Adupe, on Spark and other stuff like that. So to kind of expand the catalog beyond also maybe what strictly a platform is proposing. And then we have data services and communication services within the app. And so each service gets some what which is now called arbitrary service params into the service brokers. So similar. Each service gets some specific metadata which is added. So for the processing service it is the Maven reference, the reference of the artifact that El Paso will fetch from the cop repo. And as well some sizing, ability to generate a little word. For the web UI it is not only root. There is also some potential decision to choose whether it would be HTTPS only or HTTPS. Mentioning whether this web UI is stateful and so whether session state store should be provisioned to the app as a net result and session affinity being preserved. The config aspect is that we are trying to capture in this architecture of each version the list of environment viable that are supported along with associated semantics so that there is less of a need for intimacy between the developer and operations for the case where the development is also for example. So the contract is made explicit so that it is easier to collaborate for the ones that are not the chance to be part of the same business capability teams. Similar for web service consumer. So explicitly consuming another service and this would drive the enterprise service bus subscription as a result. So an application architecture for one version as this and the list of config and then we choose to instantiate it for a specific use case. So for development, for testing, for pre-prod, for production, we can override the default config and according to the contract specify some non-default values and be one if we try to override an environment variable which is not supported. And then we have this consistent way of displaying the access end point. So the web UI URLs, basically the routes, the access to the logs, so both for the HDP incoming access but as well for the processing services and we hope to add that to the other service as well that would produce logs, so slow query logs for example on the database and metrics as well. And so as we have seen a little bit, El Paso assists its own specific data model. So an application, the set of users, a list of releases with an architecture for each of them with a list of processing service and data communication and management service bound and then one architecture is instantiated into one of multiple environments. And so this maps into Cloud Foundry model for a pluggable mapping that we call projection. So currently an environment is mapped to one space which is creating dynamic space, assigning space rules and then within this environment, so processing service within the architecture is mapping to Cloud Foundry app, we see slot drain, build back programs and we are looking at adding more stuff such as security groups specific to the processing service. And so this is pluggable and version which help us with obsolescence management, specifically when version of build back or GVM needs to be NOL. So Cloud Foundry, El Paso is developed in Spring, Spring Boot. So as UI and user facing API and then internal API. It's model based so what the user has specified is stored in what we call the logical model. And then there is this projection phase which maps into the desired state for both Cloud Foundry and the other dependencies. Then we have an orchestration layer with a set of plugins that text the desired state and make the incoming calls through the Java client to Cloud Foundry and the other dependencies through the API. So previously we were directly spawning VMs using the Cloud so we deprecated that in favor of Cloud Foundry. And we are kind of starting as well to break the monolith of El Paso itself and so moving some of these plugins into service brokers. So we moved Splunk into Splunk service broker. We're in process of doing the ESB as well, a service broker with arbitrary service problems. And as well considering using some of the Spring Cloud config server, history and dashboard as well. Am I doing both time? Okay. So there's lots of future work and challenges ahead. The most obvious one is great to be instantiating the application first. But if I'm not able to upgrade, it's worthless. So that's our main objective now to be able to do upgrade and rollback automated workflows for this application template that we instantiate. So having blue, green including state snapshot and restores because when we upgrade an app between two releases, the app would typically include schema migration on the bound services and it's possible that there is issues and so users might ask us to revert that in case of issues. The other aspect is getting some better basics operations. So we are lacking the ability to trigger freedoms. We are lacking the app and container matrix to be displayed into El Paso. So we'd like to collect app GMX matrix and make that available into the UI and APIs, connect the APM and profiler. Another interesting stuff that we'd like to experiment with is to have the mixed El Paso manage and user manage modes. So the user can start off with El Paso and describe the architecture and instantiate environment and then choose to use the CLI instead. But we want to preserve the reproductability and we don't want to let the user go mad and mess everything up. So we are thinking about lock and at log mode similar to App Engine when you have managed VMs. You can choose to unlock your Google app and then to SSH into your managed VM. At this time Google apps backups, sorry, stop doing anything with your app, stop monitoring it, auto scanning it and it's your responsibility. And if you relock then at this time App Engine would delete your managed VM and recreate it from the app bits. So we are looking at doing something similar. In that when you unlock your El Paso management and use the CLI, once you relock it, it would delete your app instance and recreate it. It would obviously keep the persistence services. The other stuff would be able to use CLI plugins so that we have parity in terms of what you can do with El Paso UI and APIs and what you can do with the platform with CLI. So I have additional verbs there. And maybe in some of the case where you are using CCAPI directly to be able to capture that so that we can still fit the CMDB and the management system so kind of capture the event logs and send that out. Other stuff would be some more around specific projections. So fine-tuned security groups since El Paso is capturing the architecture of the application with all the dependencies and it's instantiating the service instances, actually making other calls to create service instances. We can set some fine-tuned security groups to only the service instances which the app is bound to and only the dependencies. So if the app is compromised, then it will do less harm. So yes, sending to CMDB, getting some more specific monitoring with custom L checks that could be outside of clatronry and integrating with the corp SSO. And another stuff that we are asking, maybe we would like to prototype with El Paso, is support for multi-region and multi-clatronry instances and deployments. So first starting for the case where El Paso is deploying these apps, so it's El Paso managed and the state is replicated, the service is ending the replicated state across the regions. Another use case we are thinking of is mixing public and private. So since El Paso is kind of the entry point for asking the deployment, then El Paso can choose, for example, Dev environments go public and product environments go say on-prem or maybe some other strategies such as splitting the application, even leaving maybe some choice to users. And some other use case maybe could be to on-prem to mix open source and commercial clatronry instances. So again, Dev could go to open source clatronry instance and product could be to commercial one with commercial support. So we are open sourcing El Paso. Why? Because I was keen to have exchanges with the community, to have feedback and also to learn better ways of reaching our goals. And if ever there are some ideas that are interesting to the community to team up to work on that. And maybe some of the work we have been doing could be used at maybe a smaller scale, just the onboarding to clatronry. So the user registration, creation of space or orcs could be some stuff that could be used by others, not pulling out the full service catalog that we have. So the status is we are late. We thought we would be ready for the CF submit and we would have like to have the code on GitHub for now. But we have been stuck with legal and with management. So I think we are kind of two weeks late for that. We hope to get that ready for about two weeks. So our plan is to have the source and documentation public. And El Paso is dog fooding. So we can instantiate El Paso with El Paso. So maybe we were thinking to have a public instance of El Paso running maybe on pivotal CF or on Bluemix or maybe on private cloud exposing on internet. And that you could use that with an architecture which would be the one of El Paso and override the default credentials to provide your CF credentials so that you can spend your own El Paso instance and play with it. So we'll have to think about that if there's a chance. So what potential, we are thinking about potential Cloud Foundry extensions that would make the integration between El Paso and raw Cloud Foundry usage easier. And potentially that could deprecate some of the stuff we've been doing in favor of standard built-in Cloud Foundry support. So lots of stuff we've been doing is attaching some of our specific metadata so that the business capability can provide some visibility to the rest of the organization in what they are doing. And that's easier for teams to collaborate with the different roles they have, QA and Ops. So maybe this metadata, if some metadata could be attached to CF entities, maybe in the form of tags, so attaching some metadata to orgs, to space, to apps, to service instance, and being able to queries those entities by tags. A bit similar to Amazon web service which allows you to put some tags on EC2 instances, on RDS as well, and then to have consolidated billing by those tags. So it could be cost center, whether it's dev prod. And maybe those metadata could as well be exported by Cloud Foundry at the location where Cloud Foundry export data. So for example on the syslog grains, could have templates to include this metadata. So then in my consolidated logs, I could know that this is a dev or prod or what application could. Another thing we were brainstorming is about being able to intercept the CCAPI dynamically to maybe have some final access control or to transform a bit what is requested by the user, or to add some new verbs. A bit similar to what the Observer folks are doing with their staging pipeline, which dynamically they can add some stuff, some stage dynamically. So maybe this could be possible through the upcoming router service that would maybe at some time be applicable to CCAPI to Cloud Controller itself, so be able to put a router service on top of Cloud Controller or maybe some kind of plug-in to Cloud Controller maybe. So I'm close to conclusion. So I wanted to share that maybe having another on Cloud Foundry could be an option to add some org-specific on top of Cloud Foundry. So it provides some freedom to add some org-specific features, but as a flip side, it has its own challenges, especially keeping parity with what our org Cloud Foundry is providing. So we would be happy to share with you guys and to team up to collaborate if some of these ideas is useful to you to get some of your feedback. And that's about it. Do we have time? I'm not sure about timing. That was 50. How much time do I have? Okay. You have questions and comments? Okay, thank you very much.