 Okay, hello everyone and thank you for coming today to our panel We're excited because we have an operator Swisscom who's actually got a live open stack platform in production And it's one of the largest deployments and we have Marcel here to Start off by showing us giving you some background on what it is And then we will go into a panel session for our last questions And then at the end there'll be time for some of your questions So, please go ahead Marcel. Yeah, thanks a lot Thanks a lot for showing up As I said, my name is Marcel Harry. I work at Swisscom. I'm an architect for our Application cloud our application cloud is a platform as a service and which we run based on Cloud Foundry We're using Cloud Foundry To manage diversity of workload and we're deploying Cloud Foundry on top of OpenStack We also build OpenStack on our own so we run it we operate it on on our own, but we Came up together with the design and the solution together with our partners here on stage We're using Red Hat OpenStack as the as the basis for for all the core Components and we're using PlumGrid Solution for the networking capabilities. So if you look at the picture, it looks more or less like that So on the top we have the platform as a service layer based on Cloud Foundry. We added Lots of integration Into the various environments we deploy this platform as a service into Based on our own development and then we have also We're also running a couple of services We're also running a couple of services based on On Docker containers and we're using flocker to for the persistency there On the infrastructure as a service layer and this is what we call our elastic Infrastructure as a service our elastic stack. It's purely based on OpenStack We're having Quantum hardware underneath or is the switches emc scale IO, but then The large distribution part is now red hat OpenStack We have Juno in production and we're rolling out metaka into production now and The networking part which is kind of very important for us. Well, I mean, we're a telco. So network is always important and and then there we were using PlumGrid and This really helped us a lot to integrate it into the different environments that we're deploying that to and Actually, if I'm talking about different environments, then we're not only deploying one platform as a service but we're having multiple instances of this application cloud and We're actually deploying multiple instances of this application cloud one I mean, we're eating our own dog food. So we have an internal application cloud we're where all of our developers are able to push their applications and Have an easy test bed to get started with with what they want to deliver and then We have also bigger internal flow projects like my cloud. It's a storage offering from Swisscom like similar to Dropbox for all our residential customers and actually everybody can go there and sign up and this platform is is run purely on our application cloud and we have a bunch of Virtual private offerings and customers where we're having we're having Dorma Kaba and We're also having Swiss three as As one of our customers and they are moving more and more of their cloud native workloads towards our application And we were also running a public offering developer that swiss though Swisscom calm and you can go and sign up there similar to other public platform as a service offerings within I'm all over the world Great, thank you Marcel. Thank you very much and I should have said at the beginning I'm Sandra Boyle senior analysts with heavy reading though. I think you probably gathered Which one was me? And I'm joined by if you'd like to introduce yourself Per Monclusa sitio and co-founder at plum grit I'm Chris Wright vice president and chief technologist at Red Hat And we know who you are myself So I'd like to start with you Chris In terms of the enhancements to open stack. Can you give us a brief synopsis? What they are and how they make things better for cloud operators like Swisscom in the latest release Well That's kind of a big question The top three the top four I think from my point of view Where we are in the state of of open stack and the evolution of open stack is we're moving towards a lot of stable functionality and Beyond the kind of base Features and then first day deployment and we're really looking at more and more operational Requirements, so how do you help run a cloud in in production and keep it up and do updates and Get insights into the infrastructure as you're building it as you're operating it to me that's that's where we are today in the project and There's always an important set of kind of Market-specific Features that are that are still coming in we've been spending a lot of time working with service providers and operators Bringing the the functionality to open stack so that you can deploy Especially network functions into open stack and have them operate efficiently and that's largely about virtual machine placement and good packet processing performance in Interversal machine in an open stack deployment so kind of a high level, but that's my view And I really think it's important that we look at the day-to-world of open stack today because we're not about Basic features and we're not about just the the initial demo install Great. Thank you. Thank you did a good job Chris At plum graves you provide the SDN to Swisscom Can you tell us a little bit about what that does and if you could also touch on security as well in terms of micro-segmentation and Being able to deal with security in a multi-tenanted environment sure It was interesting journey because when we started the project with Swiss Command Red Hat many years ago We started kind of designing the cloud for a few set of applications I mean you always start with something in mind the transformation business and we were providing originally the networking connectivity At that time it was more a multi-tenancy problem I mean security was kind of reduced towards a multi-tenancy problem And it was a mainly networking driven solution Where we had to provide everything that they were used to have in the physical wall switches routers DNS DHCP Security policy and so on translated into open stack and self-provision by the open stack APIs and horizon through APIs now as the project kept evolving what was happening is that the Swisscom cloud was training a specific application embedded within cloud foundry and the needs went from just providing the networking infrastructure capabilities towards Securing the specific workload that Swisscom was running and that was running containers containers over the top inside VMs and so on So the journey has been that as the project has continued The stack has become more robust as Chris was mentioning before from an operations visibility point of view But the features and capabilities that the network had to provide had to adjust towards Securing the applications and providing the right visibility on what's going on in the applications So we are working together now one on kind of the next generation things But this is the journey where the networking as the end layer in reality means much more when you put things together Towards making applications run because it provides some Visibility scale out and security aspects that are fundamental for running a private cloud Thank You Chris and Marcel one of the things I was impressed with was that from Swisscom's perspective you decided to go for micro services cloud native Horizontal path layer, which I think for an operator is quite forward thinking Are you happy with that decision? I mean has it made life easier? Is it more challenging? I think in the end, it's definitely worth going that path the The journey towards there. It's definitely has various challenges. So one of the the the bigger ones is in at if you start beginning with it you Need to have a platform where you can easily start Lots of services and if we're actually Talking about lots of services then for example on our open stack We're if we're releasing even new versions of our platform as a service and which is also built in this micro service Style of architecture. We're actually deploying Twice every second week. We're deploying Hundreds of new VMs and tearing down older ones so all this life cycle of these VMs are becoming very important and Then and that's that's the part of the operator and then as a as Someone who provides a platform you actually need to start convincing Developers adopting to these new schema and concept of of how to build their applications and also To add her for example to the 12-factor manifesto. So for example, very important Don't write into the local file system Configure everything and through through service bindings and and actually start building services Horizontally scalable and this is sometimes seems to be still very tricky but One once you have you kind of have the platform for it and people see how easy it can be to to actually deploy large Large Platforms using many services then then they see the value and start doing it as an example Dorma Kaba for example, they redeploy their whole platform multiple times a week and this is actually a platform that is Consisting over like 60 applications and they're deploying that and multiple times a week from scratch and This is kind of like the things when when we saw that people are building that that's it's kind of cool Definitely and what about containers and their role in Getting to cloud native and more scalable platforms for operators and do you see and Chris touched on this network functions And being virtualized and and also running in containers or is that you know too far out there? So from an networking point of view what happens is that there's many dimensions, right? You create a cloud for an IT application like the Cloud Foundry based one in Swisscom But there are many other clouds in Swisscom and other service providers that they focus on offering networking services In there it becomes more Convoluted because what you have is a combination of suppliers of technology You have the open stack components You have the SDN components that glue things in this case Let's say VMs and then you have VMs that would run network functions and those VMs could be traditional VMs from existing networking players that support multi-tenancy by themselves or Or they are not they are just VMs with a single networking application And what happened is that to do POC is and to show how you know a virtual ICP or an AMS solution works Is becoming reasonably straightforward. There's enough technology enough reference designs enough Knowledge in the industry that is starting to happen The problem then becomes how do I scale it? How do I create a service that I'm going to monetize that I'm going to support? I don't know in Europe I think there's 300 million households So how do you transform those in VCPs? Are you going to use VMs and are you going to go from 300 million households into maybe six seven hundred million VMs? How many servers are you going to need to support that? So what's happening is that there's this trend of saying I have to change that there's not enough Investment available for and have been ordered to buy so many servers So you have to reduce the footprint and this is what containers kick in Containers would be kind of the obvious answer Maybe not the only answer but one of the immediate obvious answers and what we are seeing is a lot of need of interoperability for NFB clouds between VMs and containers Because there's going to be a transition of how much time is going to take for traditional VNF vendors to move from Providing your network function as a VM and migrating towards a container some of them are already available But some are not and that's where we see This progressive push to move to containers for NFB Because otherwise it's going to be a capacity problem Then as Chris was mentioning before it's not only a capacity problem in terms of how many servers Do you need to run the VMs or the containers is a bandwidth or buckets per second problem? It's like how many servers do you need to handle all the traffic of all these? CPS and this is where technologies that have to accelerate the data path kick in and now the combination of both the data planes and Compute structure that you created for your network functions have to play together in order to deliver proper NFB solutions that Adding of value to be able to do that migration to this new paradigm Okay, I think it's important to that one of the things that that Perry said was it's a broad ecosystem essentially and moving Network functionality into virtual machines is is something that requires many of the vendors to change how they build their applications And so Marcel's talking about developers that are building IT applications using and you know sort of a cloud native development practice getting VNF vendors to Understand cloud native development is something it's an industry level challenge. It takes time to get people to move Applications from one design Kind of paradigm to another and we're still in the early stages of moving from physical appliances to virtual appliances so the next step of getting to fully decomposed Set of functionality spread across a number of containers to get the density And and even hopefully improve the packet processing performance. So you're not paying some of the penalties of overhead of virtualization I Personally think it's an inevitable Outcome, but I also think it's going to take some time to get there Yeah, so actually as you mentioned if it starts becoming like If containers are starting becoming important how people are packaging their applications Then it's actually a matter like we we kind of get a very isolated plot that we then can run but we can then also start running it at scale and then suddenly The hype about containers is not about anymore about Using the right technology or so it's more about okay How do we solve all all the orchestration problems and and one of of the bigger problems is certainly networked there Another one is kind of like storage, but then also how do we? shift traffic amongst the living instances because as instances are now spawned very quickly they might also die very quickly because The need is not anymore there or people are starting to deploy much faster or so so This this this might also change another part is also where it becomes very important Is that the things that you are actually packaged into that blob are not anymore are not that? static but are rather being Also coming out of a CICD pipeline where they are continuously being packaged again and being updated and and being redeployed and this is one of the things where also lots of in investment in terms of Developing the right tools for it and so on need to go into Okay, thank you, but ultimately do you think it's a positive thing as an operator Yeah, definitely. I would say as an operator. It definitely makes one of your life easier if you if you say well, this is We take your blob and we run it and as a platform as a service We say we take your code and we run it But nevertheless People are expecting to that This thing that you run is still up to date. It's still secure So if something like heart bleeds come out it needs to be it's very important that that you're able to easily Update all all of the running applications because what people are expecting is that you're providing Secure service, right? Thank you So we'll move on from containers though. I find them a fascinating subject To talk about your enterprise customers Marcel because you now have is it Swiss re that is A live customer and they're you know, some of the most conservative Companies in the you know insurance and financial sector. So I'm just wondering what sort of questions you get from them You know, how do they feel about open stack as a platform as a secure platform for them a reliability performance So, I mean if we look at how they are seeing the platform It's actually for them. It's it's part of a bigger strategy in moving their kind of Development model within the company to to a more agile way of Moving things out and also being able to easily Answer to To new demands within the company, but also from from their customers So what they want is a is a platform where they can very quickly Develop on top of it. However, they're dealing with with various very sensitive data. So for them Having it being very Strict and isolated in an isolated environment for them is becoming very important. So Running on-premise within our data centers within within Switzerland was was was one of the key points for them and then also where where Swisscom Came and together with them working on on their broader cloud strategy of of how they Do their journey to the cloud was was important as well Okay, thank you and in terms of what's next For you and and your partners what sort of things do you see that needs to happen in the future with open stack or with other with SDN or Any aspect of the solution. Yeah, so We're actually so we we started this journey like with over three years ago with a better alpha deployment and Then two years ago it became a little bit more better official and and since one year we're in we're in production and And now as people are adopting things were evolving also our offering where we're Where we see for example business demands of that well our applications that are running within the cloud they Need they have the business requirement to run within multiple data centers Whether it's for regulations or highway ability or or so So so one of the approaches we're doing now is that we're taking that that platform and we're actually deploying it Into multiple data centers, but exposing it to the user as one platform And so did the user developers they don't need to care about whether they're deploying into one or multiple data centers This is the part where we're taking part of it. However, we're not going to take the conventional approach where People would stretch infrastructure over multiple data centers, but we rather say we want to keep the infrastructure Isolated simple within one data center and we're actually delegating it more to the upper layer Containers are getting more and more traction still and Together with the network and I think the container folks finally figure out that networking is important for them and and so does for example storage is This is one of the things where we're investing more more looking into it and offering Possible solutions so that for example traffic originating from a certain container is being identifiable outside within traditional network environments and and On the open stack part and we started with a very strict set of project So we we really looked at open stack and we said well we need Compute we need storage. We need network and and this is how we go for and now We're adding more and more projects to actually support All all the different deployment cases that we see on top of open stack like we're adding heat We're adding cilometer And and so on to to actually support The the people deploying on top of open stack with additional tools to to make their life easier Okay, and Pear finally get your name right In terms of you know lessons learned from the Swisscom deployment What do what would you say are the top ones? Yes, basically what we learned was that the networking in general is a kind of a esoteric field that things kind of Magically work routing protocols are just the whole thing firewalls get configured and when things don't work It's kind of pretty involved Compound to that when we move towards this SDN overlay pushing it to the edge and kind of delivering a software solution What was happening is that networking was becoming even more complicated and it was Going towards the spaces like the servers that traditional networking people were not used to it So we started working with Swisscom early on we were focusing on functionality But quickly we realized that there's a partnership when things were not going well and here we have an expert on finding issues on the layer There were not enough tools enough Operational tools to understand what was going on. So at some point we started shifting We started to introduce products more towards operations and visibility cloud apex lab security and so on and tools that Help to understand a bit more What was going on so what we realize is this is every time there is a transition of technology going from let's say hardware Defined networks to server defined networks is not only the aspect on how you Deliver the capabilities in a more agile way a better way is how do you carry the expertise the visibility the aspect that I was shooting the Operations because otherwise regardless if it works or it doesn't work People have a resistance to say well, I don't understand what's going on And this is almost sometimes is even more important than just the features themselves That's was one of the experience that we learn working very closely with Swisscom Thank you and Chris would you say the same thing is it more about operational efficiency and Performance troubleshooting or what would you say are the key lessons that you've learned as red hat open stack? well, so as I mentioned at the beginning it really is about getting beyond just the The basic functionality and looking at how you run and get insights into your infrastructure because what we're building And one of the things that we've learned There's actually some cool things that Swisscom has has done that I think are worth highlighting which we didn't get to cover quite yet Which was really? Kind of a forward-looking approach to how you build and deliver infrastructure so traditionally You don't think of the service provider community as as really being agile and these guys have really done an amazing job of Deploying redeploying looking at how you make your infrastructure Agile and that's something that that we've learned from and It's something that we try to take to our customers has helped them see how they can Build their infrastructure so you're building infrastructure to produce a platform to run applications on and you're expecting your application developers to do Follow agile methodologies and have a CI CD pipeline, but also looking at how you manage your infrastructure that way I think is Something that that's really valuable for the infrastructure providers. It's a lesson learned for the infrastructure providers and then the the key thing for us I think is Operating at scale. We're building a large distributed system Things go wrong and if you don't have tools to dig in to understand what's going wrong You are dead in the water like you're really gonna have a major challenges at at sort of Getting things back on track and keeping applications running Which is the end of the day with the what the goal is here And then one other thing that I think is really worth highlighting from the particular stack that Swiss commas put together Looking at infrastructure as a supporting cast for an application platform and Really I kind of identifying differing layers of abstraction saying application orchestration is a really important task And it's done well by certain tools And infrastructure sort of hardware level orchestration another important task So we have the kind of open stack Substrate supporting a pass platform on top. I think is a great way to look at how you bring This this agility up and down the stack. Thank you So now it's your turn if you'd like to ask the panel any questions just raise your hand and we're happy to answer them Don't be shy Have a question here so the question was is is open stack at a stage where an Enterprise without the the breadth of experience and ability to invest deeply like a large-scale company I think Walmart was your example Can can bring open stack into production in their environments our experience is absolutely that's the case initially it was Really challenging and the early days of open stack there was a lot of expertise needed and there was a lack of that expertise across the industry and Part of that expertise was needing to understand exactly the details of of open stack as Tools improve deployment tools improve and and our focus shifts more towards the operational aspects of The cloud and less to the core functionality We're seeing just as an open stack vendor. We're seeing a lot of adoption into I guess you call it the more traditional Enterprise or smaller scale enterprise And maybe to add some some grace to that Open stack is a project a community project that there's multiple flavors on how to consume that you could get the code and Just try to do it yourself You could engage with vendors partners professional services companies that they are going to provide you support So what we are seeing is that different enterprises have a different level of tolerance or understanding of the technology And if you want to get deep into the technology and you want even to get the latest code the latest feature and so on You need a certain level of skills If you are willing to engage with partners and vendors that are going to provide your professional service or support is a different level of Skill if you want to consume it as a product different level of skill So I think there's enough diversity within the community that you can consume it in any way you want depending on the level of Expertise you have now different enterprises depending on their size their budgets their investments and so on Will have the ability to consume it in different ways and that's why a lot of people say oh I try to take open stock from The source code living in the open source community, and I had issues deploying it Well, it depends. Maybe if you don't know how to do that, there's other ways to consume it But as a technology there's many enterprises that are running now their workloads on open stock and getting the benefits of of the community Okay, any other questions Yeah, go ahead so the question is about upgrading open stack to the latest release and So if it starts with the the actual code the development process within the project historically The independent the individual services the communication paths between them You know you have basic things like ensuring that you have versioned messages in your RPCs passing between services and So we've spent maybe as a community a couple of years investing into ensuring that that That the low-level functionality is there to support essentially of rolling update and then more recently the community is as focused on Call them kind of community level of contracts between projects saying will ensure some level of backwards compatibility so that while you're doing a rolling update one service the can a newer service can operate with the rest of the cloud still still moving forward and So that's really where we are now We're finally at a point where you can actually do an update from one version to the next without having to Really either resort to disabling some core functionality for some period of time creating an outage or Or even the next step was a highly prescriptive way If you did this in the all the steps in the exact right order, you know, it will it will function It'll work at the end. So we're we're transitioning to The community being capable of producing code that's that's upgradeable from release to release now the next challenge is a wider array of Wider array of versions. So you're gonna be able to upgrade from and to end plus two that that gets more challenging unless you just do it sequentially and So I think that's that's kind of where we are now and if you look at somebody who's being really aggressive and trying to continually update from from trunk. That's that's still That's still not easy to do Yeah, and one of the the other important things is actually I mean Opens that by itself must have the capability that you at least maybe can go from version one to version two The other thing is also that you as an operator need to be able to continuously deploy Open snack in the same way and and I think this is where Also, the bigger opens that community now came together and Be became much better in that by providing the right tools of continuously deployment Continuously deploying open stack in a consistent way So and but also in an adaptable way and not only the death stack way of deploying it so So so so the other part is then also on the operator side that that you actually Are running you the infrastructure in a way that that you can continuously Redeploy it and because this helps you really a lot. So for example We actually deploy open stack once a night on the CI stack like from scratch on the full scale Just that all the changes that we do That we can make sure that if if if we need to redeploy it again Then then actually we're able to do so because previously we had everybody was working on various Automation parts and then at some point when it came together you had all this burn-in time where where oh this Automation needs to fit better together with this one and by having a Pipeline that where where you actually are Verifying all all these concepts over and over again. You're actually lowering lowering the frictioness and then you're actually delivering Things way more quickly. So actually Going from Liberty to Mitaka for us was just a few few days of work in the end That's the CI Approach that I was talking about earlier that Swiss comm is done. I think is really noteworthy. So if you're if you hadn't heard that before It's I think it's really impressive Okay, go ahead So the question was about how do you do we see the openness of Of open stack and like the different distributions and winners and whether we see that we can Point one tool also to a stack of the other tool and I think they're actually the open stack by itself If we're just following straight the open stack API, then we actually get the value out of of that because this kind of like makes the clear boundary between What you as a as an open stack Operator are exposing to the user and people who are deploying Things on top of open stack with their automation tools are if they are speak Lee only like Through the open stack API then for them. It's going to be very easy For an operator and this is what I mentioned before is also that they're within the open stack community For example, we're heavily using puppets to to manage the configuration parts on top of our system and before within the open stack community, there were various puppet modules flying around but Developers from Red Hat, but also developers from from other distributors finally came together and there's like now one Not one there are many modules But like there's like one set of modules under the open stack Ten that all of them are using to deploy open stack and this means like well It's it's whether you're using this one or the other one It's actually you use it exactly the same way and I think things like that are very important. Thank you all for Sticking with us. We're come up to the end of our allotted time And I hope you found it interesting and useful and I just want to say thank you to pair Chris and Marcel. Thank you very much