 Think we're going to soon start If I can get the slides The orange slide back on the screen. Yes, great So I'd like to welcome you in this room. I was a little bit surprised that there were so many people actually interested in the telco view around OpenStack knowing that it came from Many many OTT companies small startups plus the usual Suspects in the valley around open source, but certainly not at the beginning from Telcos there was a rally of many many key players in the telco world in the last two years And it it brought us to really re-envisage the way a telecommunication service provider would operate in the future What I will share with you today is not so much about the technicalities and by the way, they were several shows open with Fantastic contributors to the OpenStack code so I wouldn't want to compete with these guys It's more about the transformation that we do go through as a telecommunication service provider When we envisage going to the cloud, you know, we have Our CEO who claims that orange Is a leading operator in the internet era? Many of us will probably wonder what that means. Well, probably moving to the cloud is one of the most Concrete tangible thing that we can use to exemplify the change Gonna cover five items At any moment, please feel free asking questions The only value of this is being an exchange Start with a little bit of what we call the cloud manifesto pretty interesting change of mindset within a telco The opportunity for us to change the way of working as we go to the cloud Why do we believe that we do we need to do some things specific to a telco operator on the grid What could a target or bad is them look like when you look at the telco inside and More more generally, how do we position orange versus many open source projects and communities The first thing is when moving to the to the cloud manifesto Actually, we like to to thank the guys who years and years and years ago on the research side worked out I would say against all established opinions that there would be a massive disruption in the market thanks to open source Solutions like open stack and if you remember at that time Vmware was a king of the world was about to virtualization Getting gradually into the cloud and open stack was still at that time a Small potential alternative, but the guys detected that there was a great potential and they helped Shaping our policy towards the cloud they helped us also identifying the key options that we would need to take In order to be successful when transforming the business to the cloud and I insist on Transforming the business to the cloud and not transforming a technical stack because most of what I'm going to be discussing today Is more about the transformation of the company Than a pure adoption of a technical solution look like We Let's say a bunch of five key decision makers on the technical side in orange Finally agreed to consider and to state that we were something like 10 to 15 years late regard to OTTs and That it was more than time that we should catch back One of the key thing with OTTs is that these guys are different have a different way to manage technologies Have a different way to manage the business. So we are trying to find out what these guys were doing Which we could take well actually we we are lucky enough that they are open sourced many of their technologies So one of the key things is we could take over a lot of their of their technologies The other thing is we also try and take the way they do business now Agility is typically what is made the mark of their DNA and Most of our customers don't tell us that we are agile Don't know why they also Try and make this agility in the time to market the Main feature of the whole organization a to z Which means a global and deep transformation for a company like orange Which was established on a very classical pattern a classical pattern means that Somebody in the marketing will think of the next service will Write a thick document specifying what they would like Hand over to the guys in engineering who will try and decipher that and put that into technical words Would get somebody outside of the company developing it or would source a solution Which would be close enough on the requirements then would hand over that workload to the operations would struggle to get something Operated etc. etc. etc. and in the end the guy who made the Expression the requirements will actually discover that what he got is completely different from what he actually Drammed off and it's really something which was repeatedly Repeatedly they in they out happening in a in a company like orange One of the key thing here is to say okay We want to change the paradigm and again, it's not a question of technology. It's a question of cultural shift Get the customer inside the room. Okay, fine. Everybody says that since 20 years, but I do actually do it Get the marketing to work Day-to-day with the technical guys who are developing the solutions so adopt Different posture different mindset make sure that the guys gets into a product on a mode According to whatever Agile me so that you can sink off And make sure that the whole set Infrastructure among stores us will be compatible with that today an Engineer who would want to provision a platform in orange would take weeks and weeks and weeks and weeks That's the reality today. He will have to struggle across many heterogeneous Technologies he will have to get flows open from one island to the other in the data center Sometimes from one data center to the other which is even more complex because you will get across multiple teams Well, how does he get? The benefit of what is the day-to-day life of an OTT player, which is how do you provision? More or less freely the same platform in minutes and spend your time Focusing on the service itself on the definition of the application and not on managing the bits and bolts of the infrastructure Also, how do you enable the the? new service That will want to get released on the market to freely Consume capabilities resources Exposed by the rest of the legacy stack, which means how do you open APIs? How do you loosely decouple? Modules of services enablers etc within the setup all of that is bread and butter for any company on the west coast and It's certainly not the way most telcos operate today So there is just a deep shift with regard to how the company from a to z will Operate there is also another another big risk is that we would confuse the cloud and the virtualization Virtualization is things which we are doing over the last Five to eight years depending on countries and we do have most of our workloads running on virtualized infrastructure But that brings no change. What I mean there is that it doesn't help you get a service Promote it to the business to the market in minutes You're still struggling with the same urbanism You're still struggling with the same question of having multiple teams cooperating together to get a platform provision now When you would want to put a code from a legacy world on to a virtualized infrastructure You do struggle but most of the time you will succeed What does it bring you if you face reality in most cases a legacy code will best run on a good bare metal stuff And if you put it on a virtualized infrastructure best case it will get a little bit less robust a little bit Little bit less performant But you may still may make it work and then you move it to the cloud. What do you get? Pretty nothing no advantage on the contrary if you do embrace deeply what the cloud means in terms of Leveraging on the infrastructure very differently Leveraging on the elasticity the resilience that you will get not from the infrastructure, but from the code Massively spanning multiple instances of your applications across multiple data centers to reach the level of Resilience that you need then you will get a very different world. But what does that mean your coders need to code differently? Your operators need to operate differently. You need to be able to monitor that Well, most hotel codes do not have the tools To monitor that today, etc. Etc. So again when you look at the way you would redesign your application it is a challenge because the simple Level of readiness of the infrastructure and the process is not there in most telcos and then Again, you need to adopt what makes OTT is much more agile and efficient which is Where it makes sense and I insist on the where it makes sense Go DevOps the whole way Meaning get the marketing the engineering team the operations team in the same room working together as a project team Which again goes against culture Goes against the usual way to do business. So it is a deep transformation Having said that most key Technical decision-makers in orange acknowledge the fact we also set the ambition which is that's nevertheless where we want to go And we're gonna unify The various efforts across the orange footprint to really make it happen in a reasonably short time frame reasonably short time frame compared to the History of a company like orange not the history of a startup So we do not have a view that a company like orange can transform in one year. It will not happen But we have a view that by 2020 We can have our eligible applications Really cloudified Operated in a different way moved on to different infrastructure infrastructures Eligible applications. What does it mean? Well, most probably you do not want and you have no return on investment To cloudify a very stable back-end which runs on its legacy infrastructure. Don't touch it Just put APIs on top But wherever you interact with a customer where you wherever you have a front-end Systematically cloudified Benefit from elasticity allow the customer to really drive the way he will consume the service So reverse the relationship between the application and the customer the application and the resources He will actually use make sure that you digitalize Completely the relationship with a customer and that the customer will benefit from the cloud in its turn not only you Networks are going through a massive transformation right now All vendors are trying to get their Appliances transformed into a piece of software that gonna run on OpenStack fine By 2020 will the whole network be transformed? Maybe not But at least all the core network will be all the vast will be Everything that is really non-adherent to the copper or fiber cable everything Which is non-adherent to the antennas on top of the roof all of that could be massively massively transformed and Then what we call services is all the rest service platforms All of that will be cloudified because it's the only way for us To still be alive in 2020 facing OTTs which go faster and again Who are ten years ahead of us with regard to the technology? So we made that public inside the group any partner who is interested can can get the McLean manifesto in itself for Decision-makers with an orange to publish inside the company a manifesto was already a shift of culture Right try and put your guts on the table and commit that you're gonna transform the company by 2020 Is something that is not so usual with in orange? So just wanted to highlight with a slide that the cloud thing is not and Will not be a technology challenge It is a deep deep cultural transformation of the whole business There is no team in orange which which can say that the cloud is something for the others We are all involved Usually when you take an operator Today and And some operators claim they have advanced and changed but what I see with my peers when I discuss with them is Pretty much looking like that. You have a marketing BU and you have marketing people who are dreaming of a service The run on their own Then you have design teams or development teams which will try and do something out of it Mostly with components because Usually We do consider large scale services which have a strong functional complexity and They will dump the code over the fence to people who will go try and get it integrated with the whole rest of the setup and Here when we say integrated it's With plenty of technologies that you guys never heard of because maybe you're too young sometimes to even have heard of it All right. This is not by far an all IP world We do face the difficulty to integrate with what we have which is a pile of very diverse and very legacy technologies And get the quality under control, which is not always so easy And then hopefully you will pass some some steps of quality and you will hand it over to operation who soon Will discover what this service means because beforehand they had no real touch With the service So the moment you hand over is sometimes the first time they ever hear about the service and they get the shit posted over the fence now Most of the enablers we have are running on legacy infrastructure When I say most it's probably 99.5 percent of our enablers which are running on legacy infrastructure to date it's moving and When you could look at the number of workloads moving on a cloud it's growing fast, but still compared to the stock It's a teeny bit One of the legacy one of the challenge is really to get proper APIs on those legacy enablers so that they would behave as if they were cloudified towards Cloudified workloads and then you have a nice computing grid plenty of tools around Pretty much empty to date With a very strong ability to expose APIs, but again So far few tools Services people are using those APIs getting it's really changing fast. It's growing fast But still compared to the stock. It's a teeny bit when we say cloudify we start very often because we are rational people talking about the green bit How should we evolve the processes? How should we get the guys to work together as one team and not as Four different silos running in sequence and very often you stop there and then you fail Because simply the problem is not the process the problem is culture and skills Culture Getting the guys who is in marketing to consider that he should actually talk to work with the engineers getting the engineers to consider that the guy who is Bringing him marketing details is not is not simply talking bullshit, right? Because the guy doesn't know how to code Seeing like that. So we need to get a cultural shift By having people dreaming of collaborating within a end to end project instead of Considering that they are the expert in their domain and that they should be consulted Moving from consultation to contribution is a first step then getting a level of trust Across the organization that a project team could actually make the right choices That they shouldn't go through committees validations senior management kind of approval But that if we gather the right people in a project team with a right skill set then we should trust there That they will do the right choices That's a tough one and That's 100% against the traditional telco culture sharing Just one one kind of sharing which is antagonistic to our culture today Service hay will consume a capacity exposed by service be in a nice SOA mode Well, the first thing and the team in service a should do is talk with service be because you never know and By the way, because the service be will demand that they are consulted before the service is consumed by anybody else In the in the in the cloud world. It is a nonsense, right? You expose an API and happens. What will happen? And if somebody will use it It's great thing because that means your stuff is useful and if nobody is using it then Darwin will kick in And soon your stuff gonna be demock decommissioned. It's completely different mindset When you will go there, you will also consider that simplicity is driving the show If you take a classical provisioning fixed provisioning mediation in a telco operator This fixed provisioning will probably manage 100 plus use cases Because each and every possible service which came on top wanted their own stuff implemented in a mediation, right? That's a weakness of being able to doing it The technical guys were saying yes, we can do it. So they did it Now in a new world you would probably say Let's expose three or four of these use cases for an API And leave the choice to the project Either they can cope with one of these use cases or they're gonna have to go through a end to an integration process And then believe me They will find a way to cope with what is exposed Because if you take five minutes to consume what is exposed versus six months to get the end to an integration dawn It's a life and death sentence on a service skills If you take for instance the the marketing boy Today has a conviction He visualizes he has a mental map of what he wants as a service This mental map is actually extremely difficult to share. So he tries and describes it hands it over to the engineering engineering will understand it with their own EDM and They will probably understand it differently What we tell them is don't have any conviction maybe start with something small and Then put it at the test of the customer and listen what the customer will say and if the customer love it great If the customer doesn't stop it and if the customer loves it listen to what they want more And then your whole road map is driven by the customer, but that means The design people will have designed the service in a way that you can collect usage data The operational people will then have an open ability to collect the data and to expose it back to the business thing like that Well Marketing will evolve. What about the technical guys? The risk we face is that we have for instance software developers who believe that they can code and By the way, they can code But maybe they can code in a legacy way And we tell them to move to the cloud we tell them okay forget about all those nice licensed database engines With a brand name starting with oh Go for open source stuff. No sequel Make sure that your service will actually consume very small VMs But you will actually span them elastically by numbers Make sure that whatever you do is stead less That it can crash and by the way, I'm gonna crash some of them voluntarily. I will send chaos monkeys on it Seeing like that is completely different world. So we are risk-killing our developers technical architect very interesting when you go into the integration today The guy receives a document showing what the service should look like He understands the software which gonna run all these softwares and piece of software which gonna be run He will start writing a world document With this word document describing the hardware the software the network configuration All the flows to be open blah blah blah. It will give it to maybe a Subcontractor who will actually implement that or will provision it on the on the virtualized infrastructure, etc. etc etc 6 months Tomorrow same guy Should just script an XML page and push it to production not exactly the same skills Not exactly the same relationship to the project Not exactly the same way to collaborate and having iterative Definition of the infrastructure as the project will develop and if you know that the next release is tomorrow and not in six months at Each and every of these steps you will allow for much more trial and error Because you know it can be corrected the the debut the day after while if you know it gonna take six months You bloody sure want your bloody want to make sure that it's gonna be perfect And perfection doesn't exist. So you just delay everything it's a very very very strong shift of Mindset and ways of working the key word behind that allowing for all of that to happen is two things You need the security to be preserved So the first things we did Before dreaming of whatever automation tool infrastructure whatsoever was how do you completely revamp the security of bannism? When you move to the cloud What does that mean moving to the cloud from a security perspective as a telco because believe it or not? We we believe we think we we know roughly how we should manage security here, but It's not so clear when you go to the cloud Well Most of that is parametric Security Parametric security in a cloud has no meaning So how do you take sure make sure that you empower a project with all the right tools and capabilities to secure their own app? Shift The other is automation If anything is manual, it's dead It's dead because you will continue doing the same mistakes So there will be faults as you will move software to production But also is that because we are competing in a world which now counts minutes as we were continued years ten years ago And we simply cannot afford any manual stuff What is so specific with telcos that we should have our own flavor on the oven open stack? Well, the first thing is we would like not to have And ultimately I think every bloody business will need the same level of Resilience variability and the same open stack in the end will meet everybody's needs But to date we saw and we spotted several problems which made Open stack as it stands today Not really compliant with our needs. It doesn't mean that it is a fatality for instance You are a startup You put a workload on the Amazon cloud. You don't care You don't need intranets you don't need secure networks blah blah blah you expose everything to the Internet And if needed you will do some VPNs between one workload or the other and it will work, right? However, that may not be scalable That may not be scalable. That's the one problem. The other problem is it is so Contradictory with a previous way of operating that you may not see a way to get it interoperating between the new world and the legacy world So you need to find a trade-off So for instance, we need to be able to manage internal networks as Well as internet connectivity to the workloads So we defined urbanisms which we can deploy Automatically on each and every network on each and every project that could allow us for managing various protocols and Interconnection with a legacy world also We need to be able to interconnect with legacy software and sometimes to just bring as legacy software on it While bringing legacy software need is a nightmare. We try and not do it That the best learning is don't do it if you can avoid don't do it Just take new software cloud ready put it on it legacy software. Don't do it There are all the things like VMware, which will cover we need really To have a standard way of working on the grid what I mean here is that we do offer cloud services to our customers These customers are mainly large B2B companies, right? So the CIOs which we meet Actually face exactly the same challenges as the ones we do face within orange Somehow I'm a CIO of a large company because I'm managing plenty of workloads running on plenty of different legacy stuff And I'm trying to to translate to the cloud. They do exactly face the same challenge So we ended up with a conclusion that once we will have our setup ready. It is actually Completely adapted to large accounts needs. So we're going to use it Exactly the same stack the same product the same setup for private instances running orange networks and services for Private instances that we do deploy for our customers or for public instances that we use to offer to SMEs or large accounts Why because getting to that point Secures that will make no trade-off on the security on the scalability on the on the urbanisms and the design and then there is a Deep conviction around the code We do believe that there is a need to control the code hence an open source solution is ideal Two reasons for that first we need to know on what We put our customers data Because we have an accountability Towards our customers that we will be able to manage the privacy in the security If you go on a black box You just do hope that the guy who delivers to use a black box does his job well If you have access to the code you can audit whatever you want And you may help securing the solution which by the way we do So we contribute back to the community plenty of things which we See the second is This open stack stuff is Not a question for data centers most Companies will envisage open stack for the data centers only because That's where they operate, but we do operate outside of the test centers as well Our whole network Will gradually shift to open stack So we need to find a way to get the data centers and the rest of the network to interoperate Seamlessly I need the same OS For my network and for the data center and I need a totally seamless integration So for instance, that's why we contributed back to the open stack community things like BGP capabilities within the neutron So that we would see only one bloody network and we wouldn't have to consider that there is a data center on one hand and the One on the other hand all of that Made us also touch by working with the code contributing back things etc. Identify we identify few areas where we do believe there is a possible Differentiation of the operator Without mingling with the code so keep the vanilla open source solution But somehow put a little bit of differentiation on top if we were then to For see a little bit where a large operator would go and I think this is a pretty high level so Many many of you in the room will Potentially find it useless, but it helps federating the views within a company like orange and it also helps orange and other telcos to cooperate on a Shared pass towards the cloud first There will be a basic infrastructure Most people do spend a lot of time Do most of their transformation time on it? We do believe that it will happen We do believe that we didn't have to put too much effort on that meaning Open stack as a community is delivering we are Contributing back some improvements. It will work We put here access network because eventually in time It also will run on open stack Why because we're gonna? decentralize a lot of caching and storage very very close to the customers But all of that will be managed as one single aggregated network So you will have potentially in a country like France 500 pops with open stack capabilities and Those 500 pops will be managed as one very large and virtual data center Because you will need to co-locate Data's at the closest possible point to your customer. We will use pass on top of this infrastructure because It helps us getting the same agility as the ones otts will claim and whatever we do will Bring data back to our analytics capabilities in order to get a quasi real-time understanding of what customers like don't like what they use what they don't use and By the way also using that big data to detect what is going right or wrong in the network orchestration for a C ski it's it's very often Not of a concern for SMEs or for startups, but for us it is fundamental We are not providing all the bricks and elements to build a service But we do orchestrate bricks and elements to deliver an end-to-end service Service chaining is at the very beginning now We do believe that a proper service chaining policy a proper resource allocation policy will make a difference from one operator to the other Hence we are working with many partners to try and understand how they can come with solutions Bringing really and every type of orchestration, but not only Extending this type of orchestration to any potential asset that would run on the grid and Then you have an is because you still need to build the customers If not, I wouldn't be I wouldn't have the pleasure to stand here on the one hand some services Will adopt the DevOps model Why because we can easily decouple them from the rest of the pack We can put APIs between them and the legacy world So if you can then the advice is to adopt such an approach Not everything will go there will be Networks functions, which will probably not go in a DevOps model Why because we go really on service chaining a long chain of Basic elements those elements are standardized they obey to interfaces which are standardized blah blah blah so We don't see any value in the DevOps mode there and then there will be plenty of service platforms Which either will be legacy and not adapted to a DevOps model or? Intrinsically will get no advantage of a DevOps model because they will not need to change on a weekly basis And all of that need to work through API's so that you do not allow for integration to be the model anymore, but simply and only lose coupling and API consumption It looks like completely simplistic stupid But again if it is from a technologies perspective easy to do It is a fundamental change in the culture of the company Now what would take maybe five minutes to adopt in a startup on the West Coast? Will take yours and yours and yours to implement in a large organization like orange and I do believe that All the telcos face exactly the same challenge now. We do believe in open source as a A true source of innovation and a true catalyst of innovation within orange We do have numerous R&D teams working on Open source projects contributing back to open source communities and leveraging massively on open source components When we do deliver some services Probably when you look at that Especially the greenish part, but probably as well the service platform, even though they are not in a DevOps mode Will 99.9 percent rely on open source components and that's a deep shift as well. I rarely saw a so drastic and so fast move out of traditional legacy Commercial solution it is really a shift which is embarking Hundreds and hundreds of engineers Learning what is available open source on the market and leveraging properly on it Databases Meaning we are for instance contributing to Cassandra. We're also working to with MongoDB Jenkins Android meaning the OS question is really Central to us. We do contribute to many of those open source projects and one of the one of the decision which we took thanks again to the the R&D teams who were really pioneering in that respect is that we decided massively to adopt open stack as a cloud technology for whatever Will be open stack ready Again a repeat a lot of the legacy codes are actually not at all fit for a cloud and Those stuff will probably not put on open stack because it would bring more problems than solutions But whatever code we're going to source as of now Can be audited and will be meted against what we call the Cloudification or the cloud readiness and so that we know whether we are buying a legacy code or a cloud ready code Since we are sourcing most of the code we do operate It is now showing that the industry is at a very variable level of readiness versus that transformation And actually it is changing the landscape because we see our classical providers struggling through this transformation the same way as we do Transforming their business many times from appliance providers to software editor But still not rewriting completely the code and they face small companies Who did it right from day one because they were just in the right DNA for that and rewrote their code from day one and Come with a code, which is cloud ready 100% leveraging on open source solutions Horizontally scalable to meet whatever volumes would want Things like that do impact orange, but they also do impact all our ecosystem and We see a complete opening of the set of partners We have Been obviously focusing a little bit more on the network side and other things So we have for instance contributed back to open stack several improvements on the neutron module We're also part of open delight. We have been working at integrating Open control on open stack So one of the key challenge for us is ready to get open stack as a global global OS across data centers and Networks and making sure that we can operate that seamlessly We do believe that not the whole Pass has been gone through for instance on the storage side We think self is a project that could really bring open stack storage to a next level I mean the truth being that at this moment in time in my open stack implementation. There is still a filer Used to provide block storage, which is heretic. I mean it shouldn't happen. Well, it still happens Now if I had the right Distributive block storage capability, I wouldn't have to go there Seeing like that We need to make sure that it is carrier grade carrier grade doesn't mean that we want a specific flavor of open stack It means that we need to contribute back few few improvements so that we can Deploy it in operation and this is not a far fetch kind of Forecast meaning before the end of the year We're gonna have some workloads in production real workloads with with real customers Etc etc. Not just test stuff on the R&D side We need to get an open NFV Orchestration an open NFV project which will really help federating many many players in the ecosystem to find out what the right model will be Knowing that the model of engagement between the suppliers and the telco providers will change deeply and We need to find ways to get the pass Cloud foundry OpenShift whatsoever to gracefully interoperate with the NFV orchestration Several companies are working on that. We didn't see yet for instance the the breakthrough in a proper integration and a proper handover between a pass and an NFV orchestrator Just project yourself in this new world Vendor would come to a range would put their source code on the pass and the source code would be then push pushed into the continuous deployment Chain and would end up in a data center as an operational workload This is a completely different model than I come to tell you that they are gonna implant in your implement in your data center and appliance I've been spending far too much of the time I don't know if we have still a bit of time for some questions. If you have questions, there are mics in the LA's so feel free I'm pretty interested You need to go to the mic. The mic will not go to you. Sorry for that Oh, it's also Huawei technology. I have a question from based on your version. I'm very interested How will be the R&D? R&D sites in the future of orange Will be more than today or Can you hurt? There is sabotage No sound anymore the control room. Yeah, here you go. Yeah, it's better now. Yeah, okay It's also in Huawei technology. I have a question regarding the based on your vision regarding How is your vision the R&D R&D sites of orange would be Will be more or will be less What do you mean by R&D sites? Yeah, you are R&D team sites. Yeah It's if you do the open source come back and do the Contribution and you do more than today. What's your R&D doing or the R&D sites? Well as a general trend operators do not grow at this moment in time, right? Especially when they are faced to a competitive European market. We are not in the US so We do decrease now having said that there are such gains in productivity That we could still benefit from a larger Production in the years to come with fewer people If we are successful at upscaling them and the key question for us as an R&D team is not so much the number of people But the number of people who are cloud ready As I took the example if I have a technical architect today who is used to describe the whole architecture in a word document Tomorrow you will have to script this same architecture and Push it to origin and push it to The infrastructure so that is a complete shift now we do see The opportunity here to redefine how we do R&D with our partners Because most probably there is an opportunity to rebase completely the engagement model With our partners If you take I always take the same example you take prepaid IN Very very critical piece of hardware Today you deliver the whole thing Tomorrow I will probably ask you to put your source code at the beginning of my pipe Somewhere in a pass. I will guarantee that the source code is protected I don't look at it blah blah blah, but it will then compile and deliver in the continuous integration chain Your application will use my compute my storage my databases Will be orchestrated by my orchestrator So it's really only the application that is left and this application is under your control. How do we engage? from an R&D perspective so that you can commit on the performance of your solution and We can take on a ship on the end-to-end service It's a very different world But the numbers of the people is not my concern the readiness and the skill the upskilling of the people is really what counts I Go question that you have mentioned when you choose open source to develop for services And you need to manage the code is that you can have full access of the code and then this will help you For take care of user privacy and privacy for security reasons What I want to know is on the other hand Other guys also has fully access with open source codes And they are easily to find the weakness in the code So it's harmful to security issues Well first It's not because you Share an open source code that you will get Less secure what I mean here is that the the dream that because the code is hidden Nobody will be able to Reverse engineer your code and we and nobody will be able to Find out the weaknesses. I think has long gone. We have demonstration every day that the code can be reverse engineered of obfuscation thing like that fail most often the true the true way we believe to manage security is to understand Where there are Weaknesses and there will always be and to manage around those weaknesses So that's why for instance, we had a work on the security urbanism on open stack Because we do believe that There is no way we're gonna get perfect codes So we need to be able to have very dynamic measurement very dynamic countermeasures Implemented when we do detect Strange behaviors around a piece of workload. Hi I work for a company that develops optimization NFVs and One thing you mentioned a couple of times there was NFV orchestration I think we've struggled to identify really a leader in that area or clear API's Do you think there's a gap here or somebody needs to fill that that gap or define API's so Fenders can develop against that and people like orange can deploy it without having any vendor lock-in Well, we saw few companies having Something which starts to be reasonably demonstrative, right The risk for us and for the industry is that as you say we would fall into a proprietary implementation hence the open NFV forum where we do try and have a Completely neutral definition of which API's and capabilities we should have In such an orchestrator so that not only is the orchestrator editors could come with solutions Which would test against that scheme and also any? Software editor would then be able to Certify that their workload would work against those orchestrators and it is critically important that the concept of Interoperability which is I think in the DNA of operations in in the telcoside would translate in that new world Open NFV for us is a right vehicle Thank you. I'm from Amdox. I have a question. I saw your Presentation you mentioned about carrier grade open stack To which level do you look at carrier grade open stack and another one is what he said before about commercialization of any of your orchestration We see a lot of companies doing that. They're trying to do that We'll orange ever consider to go to a commercial version of NFV because Whatever we see here is apparently not not that good So carrier grade again The purpose is not to have a telco version of the open stack But to enrich open stack to cover as well the telco needs for instance We saw spoff in neutron and that is not acceptable for a telco So we need to make sure that open step keeps evolving and enriching to cover our needs Second well, it's a bit early for NFV orchestrators because every guy who so far developed an NFV Orchestrator developed it because he wanted to sell the workload below Right, so there is very often a tight lock-in between the workload and the orchestration Which is exactly what we don't want And as I said, we need to get still a standard de facto not standardization in But the de facto standard to emerge was a got to APIs and capabilities that we expect from an NFV orchestrator Which also means that probably we need to get from the open NFV initiative the ability to certify that a such an orchestrator complies with what Open NFV will promote as a future standard and Yes, we aim at going for commercial releases because we don't believe that Our added value is to reinvent the wheel But what we will be attentive to is whether we can or not have some few elements of differentiation in that orchestration But very very teeny time Thank you all