 All right, I think we're ready to roll. Hi, everybody. My name is Roz Roseboro. I am a senior analyst at Heavy Reading, covering the Telco Data Center. And I am thrilled to have this panel today to talk about the Swisscom PAS deployment. I find it's always really interesting to hear from a user who has actually had some experience with this. So we can see what it's really like to use some of this new technology and get some insight into some of the lessons that they learned, some of the challenges they faced, and, more importantly, what some of the business outcomes were. So just by way of quick introduction, I will have you guys each introduce yourself over here. And then I'll hand over to Marcel, who can give us a little bit of a kickoff. So start with the right. Hello. Uh-oh. Hello. Yeah. There we go. So I'm Perumun Kluus, a city at Plumgrid. We provide an SDN solution for OpenStack. And we are here to discuss about how the network had some role on this Swisscom project. Chip Childers, I'm with the Cloud Foundry Foundation. We're the home of the multi-founder development around the Cloud Foundry platform. I'm Chris Wright, Chief Technologist at Red Hat. Yeah. And so I'm Marcel Harry. I'm leading the architecture of Swisscom's elastic infrastructure as a service and the platform as a service. So maybe we just jump into how that looks like. So we have on the top, we have Cloud Foundry, which powers our application cloud. So this is our platform where we drive innovation by enabling developers to easily push new applications to the cloud. We are a certified Cloud Foundry provider. And we're usually amongst the first ones delivering new Cloud Foundry versions to our users. This platform we build on top of OpenStack, obviously, as we're at an OpenStack conference summit. And there, as a basis, we have the Red Hat OpenStack platform, providing us all the APIs and the base functionality for our infrastructure as a service, which we called our Elastic AAS. And then we got PlumGrid, which we use as our plug-in within Neutron as our SDN driver, which does not only give us all the Neutron capabilities, but also allows us to go way beyond what you can do with standard Neutron. And then when we look a little bit more about the use cases that we got on top of this stack, we have, for example, Dorma Kaba, one of the world-leading security and access devices manufacturer. So they are now building, on top of our application cloud, they are building a new innovative platform to manage their devices. And they are really the kind of customer you would like to get, because they were the ones that saw the potential of the platform and then started pushing us to new levels of what people expect that you can do with this platform. We have also our public offering, developer.swisscom.com. Anyone can go there, sign up, and push applications, application instances immediately. So everyone here in the room could go there and sign up. And for sure, we're not only providing these platforms to our customers, but we're also using them internally. So we really believe in what we're building here. And so we have also leveraged an internal application cloud that provides our thousands internal developers an easy way to get started, but also leveraging access to legacy backend systems. And an example of that is the service MyCloud, which is a cloud storage-like service that is offered to all our residential customers. And here at the summit, we're actually able to make an announcement. So the world's largest re-insurance company, Swissry, is going with us, Swisscom, on their journey to the cloud. And they're using this platform here, the application cloud, to deploy new applications in a cloud native fashion. This is going to be live tomorrow morning, but I was allowed to make the announcement here as well. Thanks, Marcel. OK, well, first, what I'd like to do is ask the technology providers a little bit, if you can give us just a little bit more insight into what each of your respective platforms or solutions were in the context of this particular appointment. So again, I'll start over at the end with a parade. Hello. So it was a very interesting project because essentially when we first met Swisscom, they came with the idea that they wanted to transform their company into the cloud. They wanted to understand what would it mean in terms of their business to move their customers, their large enterprise customers, into a cloud kind of technology. And they came with the idea of creating kind of an interdisciplinary team. So from a vendor point of view, it was an unusual relation because basically we had all the people that understood from the physical network to the storage, to the compute, to the application, in this case, the past layer with Cloud Foundry. And it was very easy to essentially create this collaborative initiative where we would discuss what it means in terms of specifically to plan it from a networking point of view, how to eliminate with some of the folks in the audience the villain problem into their fabrics. And then after that, how to create a proper addressing scheme and how to provide a proper security infrastructure and so on. But the good thing was that we could essentially have access to a very deep discussion not only with Swisscom, but with all the other partners in the project. And that created kind of a very agile and deep definition of what we wanted to achieve. And in that, basically, we learned a lot. As a vendor, it was not only what we were giving to the project, but what we were learning from everybody else, from Swisscom and from all the other vendors. And that, I think, it created a much robust architecture in the sense that we learned the applications of networking for Cloud Foundry and split DNSs and things like that. So that, I think, was the experience where everybody provided their technologies, but at the same time, the willingness to adjust and to collaborate to fulfill a vision that essentially Swisscom was bringing together by setting certain goals and certain expectations. So in this sense, it was a pretty amazing experience. And from our networking perspective, or a virtual networking perspective, what we brought is the ability to essentially connect multiple workloads, being VMs or containers, and segregate them into certain spaces to provide the proper security and connectivity elements of the project. So I always feel a little bit like the oddball at infrastructure conferences because the Cloud Foundry story is actually very application developer-centric. And it's focused on optimizing that experience. And so in order to do that, we rely on a stable OpenStack platform, stable networking underneath it. But our technology is very much about how do you take a developer and help them iterate faster? How do you actually move fast but do it safely through rapid iteration, making sure that all of what I consider to be the atomic building blocks of good application lifecycle are built into the platform. And then they're easily strung together in a way that lets you do complex rollouts, like whether you're going to do canary node style deployments. You're going to do red-green deployments. And it's all optimized around that application. And the Cloud Foundry challenge is that when you push a single application, that's really, really easy. It gets a little bit more complicated when you talk about real-world systems that involve multiple microservices talking together. How do you coordinate all this together? I think just as importantly, how can a platform that works at the application layer effectively communicate with systems that we might call legacy even though they're virtualized? They're not bespoke applications. They exist today within VMs running in an OpenStack environment. How does a Cloud Foundry environment actually interact effectively with higher-level services that might be provided by OpenStack underneath it? So that's the perspective that CF brings to it. And we're lucky enough to have Swisscom be one of the early adopters of CF. They're also a member of the board of our foundation. And as Marcel said, they move very quickly. We, on average, release a coordinated release of Cloud Foundry software once every two weeks. That's pretty rapid. In fact, if we could speed that up a little bit, we might like to. And that's a fairly complex system. And so providers like Swisscom that stay very close to the leading edge is very useful for us. I think this works. So I think Perry was putting it well in terms of a big component of this success of this project was about the early-stage collaboration and bringing direct customer requirements and vendors together to do, to understand what are we building? So from a Red Hat point of view, we're providing OpenStack. I don't know if anybody here knows about OpenStack. But a couple, there's a couple of people. OK, so obviously we're providing the low-level platform infrastructure for this application platform for Swisscom. And a key integration point for us was working with Plumgrid to ensure that the networking requirements were met from our point of view, which is providing Neutron as essentially a tenant-facing API that's pluggable and the plug-in coming from Plumgrid and then the rest of Plumgrid's infrastructure building out the networking solution. So I think since we're at the OpenStack conference, that the OpenStack pieces are pretty straightforward. And again, that critical kind of relationship where we start early, we understand what we're doing, we have engineers directly involved trying to build something is what makes projects like this successful. Thanks, guys. I want to ask Marcel. What surprised you the most as you were working through this deployment? Were there any significant challenges that you anticipated that didn't happen or things that you didn't anticipate that did happen? Any significant barriers where to overcome? I realize that's quite a lot of questions, but I'd like to get your thoughts on how this whole process worked. So I think one of the most amazing parts was how quickly we were able to move forward. Because if you look at how things are currently being developed, like two weeks' release cycle, I think keeping up with that pace is quite amazing. And it's usually also amazing to see how if you bring people together as we did as part of that project, it will start become very quickly. So problems will resolve very quickly. One example is, for example, we kind of started using Cinder in a way how maybe no one else used it before. And then we really hit corner edge cases, sparks between Nova and Cinder. And while having direct access to developers working on these particular projects really helped solving the problem very quickly. And then also we had to be able to deliver these new developments very quickly. So I think that the pace, how we're still going on, that's really the amazing part. Thanks. I wanted to ask you, Paré, about was there anything particularly unique or challenging about this particular deployment? I know you guys have been doing this for a little bit. Was there anything unique to this particular implementation? I mean, all the projects have something unique. And here has been essentially this notion of what's the role of the network. And traditionally, people would think, oh, it's to connect point A to point B. But in this case, it was more like a sense of providing to the virtual elements whatever they need to provide in terms of connectivity, switching, routing, that security policy, and so on, and isolating from the network. But in a way, that would be very flexible. And this sometimes is kind of more the mindset of companies like Middleware, basically where you have certain end points that expect certain things and certain requirements from a network and the other things, and the ability to essentially adjust whatever requirement comes. And what was surprising to us is this notion that especially me coming from a traditional networking background, seeing the true meaning of that the network is much more than connectivity, and working towards going up the stack, going up the stack and solving one problem after the next, after the next, in the sense that there's no true solution just providing simple networking elements, you have to provide what we call now a networking suite, a collection of networking technologies to address whatever the applications drive the requirements. And this was this new encounter with the meaning of cloud. Because until now, a lot of IT departments in traditional companies, they segregate networking from storage from compute. But what we saw is that within a true cloud stack, there's no these artificial boundaries. Problems keep coming, or new architectural decisions have to be taken, and each component has to truly adjust to the needs of the full stack. And this probably was the biggest realization of working with Shiskom in this project. A little bit about how the Cloud Foundry platform, a little bit more about the relationship between that platform and the underlying OpenStack platform. I think that might be interesting for some of the folks in the audience. Sure. So Cloud Foundry is actually two platforms in one industry movement. We've got the traditional platform as a service experience, which we call the elastic runtime, and a lot of other bits to support it. But underneath it is this layer that we call Bosch, B-O-S-H. Bosch is, if I can sum it up, it is a tool designed specifically for distributed systems release engineering. That's kind of a mouthful, right? It's got attributes of configuration management. It has specifically a plug point called the CPI, or Cloud Provider Interface, that's designed to work with any number of different options for what the infrastructure might look like. And in most cases, we're talking about infrastructure as a service. In this case, specifically OpenStack, we happen to have plugins that work directly with vSphere or public cloud providers like Google, Azure, Amazon. The most important integration point today, and it's, I think, going to change a little bit in the future, the most important integration point today with OpenStack is that CPI layer. We've been really fortunate, too, to have a lot of users that work very specifically on making sure that integration works very well. As you all know, in the past of OpenStack, there had been a lot of variation in what does it mean to actually be an OpenStack-based cloud. So that's a big area that the Cloud Foundry Foundation's looking to address. But I think, most importantly, the work that's occurred within the OpenStack community around ref stack is really important. We actually have some experimental work going on right now that's taken the basic Tempest test suite that was built into ref stack and build a series of tests that can be run through the same infrastructure that allow you to confirm that CF is going to deploy and operate and be operated well on any particular OpenStack target. So that's the most important integration point for us. Now, there's some futures where, up in that elastic runtime layer, I mentioned this earlier, when different application microservices need to communicate well with each other, while we want to keep the developer experience really simple, in fact, extremely simple, there's a need to kind of pierce the veils of abstraction a bit to make sure that, if you have a need for connectivity between different services, that we're doing that in the most efficient way. And that's going to require kind of bubbling some of those abstractions all the way down to the SDN layer. You were talking about some future looking things. I was actually going to ask Chris about that. From a developer standpoint, are there some things that you can speak about that will get them excited about looking about what you guys are doing to enhance or extend things in OpenStack? Well, from a developer point of view, Red Hat has a very broad kind of technology view of the world. And from a developer point of view, we provide a bunch of developer middleware components and toolkits. And specifically, we actually have a application, microservice container application orchestration system that would be something that's competitive in the market with Cloud Foundry called OpenShift. So most of our focus from working with developers is in that context. And for us, that means we're building tooling around, enabling Docker images as your core service, and Kubernetes as the orchestration system combining your making an application out of composing or aggregating all of these different services together. So that's our perspective. And in terms of where we're putting our focus on building developer tooling, of course, we have a lot of middleware. So it's an interesting world right now where the legacy applications are well understood. It's often Java applications running in enterprise application platforms. That's something that we provide. We're also looking at how we can bring those concepts as services into a PaaS system. So as a developer, you can consume services without having to take on the legacy model of what looks more like a monolithic application. Now, those are all slightly out of scope for what we're talking about here, except that it's very much solving similar problems. And I think these are the problems that are really interesting for the industry right now. And these are what people are trying to migrate to, and get away from the models that we've been working with for the past decade and move to the next round of application development. Thanks. So Marcel, so what advice would you give to your peers here about people who might be thinking about deploying something somewhere? What are some of the things that you learned that would be useful to them? I think start small, start quickly, and iterate quickly. I think this is like we kind of try. We kind of took that approach. Maybe we could have even started even smaller and even quicker. But nevertheless, it was very good to put an infrastructure very early into so-called beta phase of availability where people were able to test things out. So within weeks, we delivered the first stack running everything on top. And then within months, we went into some kind of beta production, where we clearly said this infrastructure is not yet ready, but here it is to go and play around. And from that, we also gained a lot of feedback. And we saw use cases of people, how they were using the platform, which we didn't expect. And so we were able then to take that feedback back and iterate it more and adjust things accordingly. So something that we, for example, did was we brought in that notion of Black Friday, where we said, OK, every Friday we're just going to hack on the platform itself, and it will be unstable on that day. And on the other days, you should be able to try things out. But this is the day that we're rolling new things out. And at the moment, we're really in a, I mean, we have also a bunch of services on top. And so besides the two-weekly release cycle of Cloud Foundry, we still roll our own weekly release cycle, where we also push the development of our value added services out to the people. And making it that from the beginning on very quickly is kind of, I think, a key, because then you can adapt way faster than just being in the dark for two years, and then you come out and no one wants it the way how you thought it should be. It's interesting you say that. I was actually going to have one more question that I don't think I told you I was going to ask. But it occurred to me when I was listening to some of the keynotes this morning about the fact that success with Open Stack, like most other things, is one-part technology, nine-parts people in process. And I'm curious, does that resonate with you guys? Because in my experience, that has certainly been the case. And I don't know that it's going to be any different here, but I'd be interested in what your thoughts are. And then after this, we'll open it up to audience questions, because I'm guessing you guys have a few things you might want to ask too. Yeah, I think that people are a very important part of the process, because we're moving away from how we used to build IT and how we used to run IT in the past. So this very fast pace changes a lot of the roles that have been there for years. It also changes the way how you deploy things, how you build things, how you lifecycle things. And it's important that people are onboarded there very early and getting taken with on that journey through in that migration or in that transformation towards a more DevOps culture approach and also yet being in a more CI CD driven approach where things are pushed automatically, are tested automatically, and then validated and accepted to the next stages. So we see this all the time. Almost every encounter we have with customers, the technology choices are, there's some questions there, there's some challenges. How easy is it for us to adopt the actual technology and the process and organizational challenges are significant? And we actually talk through that with our customers right up front saying that we've got our technology, it's a small part of the picture. We have what do you need to do to consume this technology as an organization, as really the more challenging problem to solve. And some concrete examples are even in this context where you're talking about networking and networking not only over the top of the physical fabric, but what's the relationship between virtual machines and containers. In an organization, you typically have silos and there's a group that owns the network and there's a group that owns the servers. And we thought, great, we've got clouds. Clouds kind of break down some of those barriers. And we can have simple policies that write on top of the physical fabric so that we don't have to go ask the network operations teams for permission to do things. And turns out that's actually not true. You still need to go talk to the network people because you're using what they're managing. And they're looking at this from the perspective of what security compliance and a whole set of availability agreements that they've made with the organization that might look compromised to them. And so this people process organizational shift is really important. It's not just technology. So hopefully a number of you are familiar with the concept of Conway's law. It's that any system that you're building will end up being a model that matches the communication paths through your organization. So that's one of the laws that we've all kind of learned in technology, in particular in the application development teams. But I think the exact same thing applies to the way that you build infrastructure style platforms. One of the ways that I think about how technology relates to organizational transformation and how you use iteration to change quickly is that platforms fundamentally about making promises to their consumers. And a good platform is also going to constrain the choice that a consumer has. So that consumer knows what's in the box and what's outside of the box. And that's actually a freeing feeling. If you've got all the options in the world, anybody ever gone into a restaurant that's just had way too much on the menu? You have a hard time picking what you want for dinner. But if you constrain it just right, not too much, then you actually get freed up to make a decision quickly. And maybe you try more food then because you're going to just quickly decide the next time you go there that you're going to pick something else. Maybe my analogy is a little bit flawed. But the general idea being that the more that platforms are able to support constraining their consumers, the easier it is for then the team that supports that platform to know that they're actually fulfilling the promises that they're trying to fulfill. And maybe following the analogy of the restaurant, I think what's going on is that we all got used to be very good at certain topics. And now the question is, when we go one level up, there's a resistance in the people because concepts that are not familiar to the area of expertise that we all manage now get stretched. And the choice becomes a little bit higher. But now my influence and my capabilities become much broader. And sometimes as humans, we want to have control of little things. When we go one level up, the analogy of the restaurant, if there are too many choices, then we don't know what to choose. So we need some sort of an abstraction that now, instead of letting us pick the plate that I'm going to have for dinner today, now I can organize a dinner for 100 people. Because now I can essentially choose two options, decide what type of tables I'm going to have, what type of clothes, and so on. And the usefulness of infrastructure as an abstraction is this, is how do we, the people involved in technology, become more effective. And we've seen this going from the computer science world programming from assembly to high level languages and things like that. But essentially it's this kind of compromise that as we go higher in the stack, we become more effective. And the tools that we have to provide in order to succeed in this cloud transformation is that it's not to get caught in certain details that are going to make these complex frameworks even more complex, but rather than to provide the proper abstractions that with less time, less people, we can do more so we can focus on the things that matter. And this is kind of this transformation that we have to go from specialization to more a generic and a generalist understanding of technology. And then we all become more empowered, more effective. And this is the transition that I think the cloud is bringing to the IT industry. Thank you. So now we've got about seven minutes or so left. Are there any questions in the audience? I can't see. Oh, there's one over there. Rene Busson, Chris Research. It's a question to Swisscom. Your application cloud on which technology is it based, I think, not open stack, because then you would mention it, right? I mentioned it before. It's based on Cloud Foundry. So we're a certified Cloud Foundry provider. And the application, like we're fully, so to be certified, you need to be fully, not only, but you need to be fully API compatible with what the open source project Cloud Foundry provides. So this is what we're based on. And the infrastructure layer? The infrastructure layer that is used to deploy that platform is open stack. So actually there was this slide here which should make clear what we're based on. Anybody else? Oh, another one over here. You mentioned additional services above and beyond Cloud Foundry. Are any of those services based on open stack technology like VMs or containers? And how do you expose those to your customers? So this is something that I think Cloud Foundry solves really well. Cloud Foundry really takes the approach of running cloud native applications and then leverages a well-defined API to bind services to your application. And these services, they can be implemented however you want to implement them. And what we did is we took an approach where we built a stateful services platform that is based, that is using Docker as a technology to quickly spawn containers and then uses Flokker, a plug-in that talks to Cinder to provide the persistency for these containers while keeping them easily movable around on VMs. So the services are either like standard open stack VMs or are Docker containers powered where the persistency is powered using Flokker. And then maybe something else is, I mean, Cloud Foundry is a platform that is based or is an open source project. So it kind of works together with all the different involved parties to make one project. And for example, what we see a lot is integrating an open source project into various enterprise environments for virtual private instances. It usually requires some kind of integration with their system, whether it's authentication, whether it's their network, and these things. And these are all the value-added services that we put on top of the standard open source platform. And wherever possible, we feed them back into the project itself. Yeah, Mike Ernesto with Verizon. Question on the networking piece. You mentioned that that was integral, kind of linking the two layers, the pivot on and the open stack. Was Plumgrid an integral part of that, or are there other network options that might be part of that to reach certification with the Cloud Foundry? Yes, there's multiple aspects. Plumgrid, we provide an environment that we call a virtual domain that encompasses an application, basically surrounds the application based on identity based policy. And based on who you are, you can connect to the network or not, and then there's different features in networking. And the next what we provide is security groups based on certain parameters that go beyond some of the criteria that OpenStack provides. And now we are working with the Cloud Foundry Foundation in the open source community to expose some of those concepts as part of a collaboration with Swisscom, Cloud Foundry, and Plumgrid, and other members. What we want to go from making it kind of a tailor solution for an OpenStack Cloud Foundry Swisscom environment to have the ability to make it part of Cloud Foundry deployments, regardless if Plumgrid is present or not. And for that, we are using a project, a Linux Foundation project called Iovisor, that allows us to essentially extend the capabilities of the network layer within the kernel of Linux and completely open source. So that's from a Plumgrid point of view, we have solutions that we are deploying with this project and others, but then we are working with the community to try to have an open source implementation of similar concepts. It's a question again for Swisscom. Red Hat also has its own past solution, OpenShift. Did you consider this and why didn't you choose OpenShift instead of Cloud Foundry? Frankly speaking, what was the decision against OpenShift? That was before my time. Is that one over here? I mean, well, maybe let's not answer that particularly in that direction, but taking it more away is I think at the moment we have a huge bus within the container environment and platforms there are way more than just scheduling your applications. And this is what the two projects provide. And one is OpenShift and the other one is Cloud Foundry. And I think at the moment these are the two big platforms that are around as open source projects. While then if you go down a little bit, you see that within the whole middleware layer that is actually orchestrating the containers, there is still a lot of bus around, still a lot of things being tried out. So I think it's actually, in general, it's something that is still moving very quickly and a lot of things will still change at the moment. I think we've got time for one more. Just a quick question. Might be a yes-no question, but is there like a scaling feedback loop between Cloud Foundry and the infrastructure service layer? Sorry, I was disturbed. Can you repeat the question? Yeah, the question is, is there like a scaling feedback loop between Cloud Foundry and the OpenStack service? So in general, there's Bosch who's deploying Cloud Foundry on top of OpenStack. And there you have means to hook into these features. But maybe that's more a question for Chip. When you ask the question, do you mean is it automatically growing unbounded? Yeah. Yeah, no. There is some work that's going on to think about, so because Bosch is a platform in and of itself, it solves a set of problems and it isn't really all about the developer, it's actually about release engineering. There is some work going on right now to think about how it can be more intelligent and have some logic coded into it to allow its jobs for which the elastic runtime of CF might be one of those jobs. MySQL services, all kinds of different capabilities might be a job to allow that job to scale based on demand. To do that effectively, though, it's not as simple as just auto scaling based on, I don't know, traffic or memory utilization. It's actually, you have to deeply understand the internals of the individual cells in that elastic runtime cluster. But there is some thought going into it right now. All right, unless there's anything else, I think that's just about our time. Oh, one more? Sure. So I don't believe there's a licensing problem. So I work for a foundation. I don't work for a vendor. All of our software is licensed via the Apache Software License Version 2. There are today seven certified distributions or providers right now from Pivotal, Pivotal, HPE, IBM, Swisscom, CenturyLink, just a good number of them. And there's more that haven't been certified yet. And there's also a lot of use of it that's happening just based on free open source use. Cloud.gov is a great example. So Cloud.gov is something that the US federal government's GSA launched to support the transformation of agencies. Yeah, I'm not familiar with that either. I mean, Red Hat as a company, I guess you're getting perplexed looks from two people who should know the answer. So I'm going to go with inaccurate FUD for 10. We look forward to Red Hat offerings, yeah, as a commercial distribution, anything you'd like to. Welcome them to the party. All right. And I thought I would mention that OpenShift does do auto-scaling and OpenStatic. All right then. So thanks, everybody. Enjoy the rest of the show.