 You might have seen this picture of that bridge already in press, maybe it's already some months back. You might know the Swiss Alps, they have very famous mountains. One of the most famous ones is the Mount Toblerone or Matterhorn. And just in front of that mountain, there is now the longest pedestrian suspension bridge in the world, which ranges about a bit more than 1,600 feet. So it's quite a challenge for everybody to pass that bridge. So you watch down, you see 300 feet below, there is nothing. It goes side by side. Very interesting challenge. So if you have some time left after the summit, I can encourage you to go there for a hike. It's a beautiful area and take up that challenge. Also at Swisscom, we took a challenge. We tried to bridge things. We tried to bring people together. We tried to bring cultures together. And we tried to make our environment a better place. And in the next minutes, we want to present you a little bit, something out of our journey that we had, trying to bridge our beautiful cloud-native world with the classic enterprise environment. I'm going to start with a small story. So there is Hans. Hans is a developer at Swisscom. Hans knows the cloud-native ecosystem very, very well. So already for a couple of years, he has done some projects, pushed his code, consumed services, and he's a happy customer, mainly because everything is API-driven. That's not new for most of you. It's standardized interface and everything is self-service. So for him, he gets immediate feedback if he does something, if he issues something, it takes minutes to be ready. And the best thing in a large enterprise, you get built-in compliance. So it's very hard to do things wrong and break the rules. Now Hans got tasked to do a bit bigger project where he cannot solve each of his problems within this cloud-native ecosystem. So for that, he might need a very special database. Let's call that database Oracle for now, which is by design not that easy to run in that cloud-native space. So there is a classic enterprise environment where such services are built since decades and they're engineered very well with very skilled people who operate them. Hans also has an experience with these people from earlier. So there's also standard interface. It's called mail with a standard protocol, SMTP, and it's very fancy. On the other end, you get their people and they do natural language processing and try to figure out what you really want. The experience that Hans gets is, hey, you get feedback based on the human motivation on the other side. Things usually take days, weeks, maybe even months, and you experience the full bandwidth of these heavyweight manual processes. Now Hans came to us and said, hey, I really like the cloud-native stuff. Why can't we just do the same with our classic ecosystem? And of course we were thinking about that. And while we were having discussions, we came to a very important conclusion. We have two silos here. Nobody likes the word silos, but essentially there are two silos. And there is one thing missing. So at some point when you do a project, they need to interact somehow. And based on our experience, this thing in between is a black hole. Like today we had this teaser with the cloud boundary or cloud-native galaxy with all these planets and spaceships. And as you know in the universe, they're also black holes. And sometimes connectivity is kind of a black hole especially when you come from a development point of view. Based on experiments though, we found out or we could prove that there are at least... Can you press one? There are at least N plus two firewalls involved. So N is the amount of things that the people around us know about and there are for sure two additional ones that no one knows about. And with that, we continued these discussions and asked, hey, how can we improve this situation? How can we make the user experience better when it comes to these kind of services that our users want to consume? And there were people having very great ideas. They said... Can you switch? Stopped working. They said, use APIs. That will solve all of your issues and you can do everything by machines and you don't have to care anymore. Now, this is true. So it's a best practice decoupling teams using APIs that works well. We see that at very large scale with Amazon, Google and all these folks. That's kind of proven. But there is always a bot. And the bot started when a small story that we had with our connectivity engineers, they're brilliant people and they really understand this black hole where we kind of stop and say, oh, we cannot see how that works. So we're a bit afraid, maybe. They really understand it. And they built APIs for their connectivity stuff, really automate all these bloody infrastructures and so on. And we got a lot of documentation on how we can use their APIs which would make our lives easier. Everything started with a book full of sequence diagrams. They were complex back and forth communication and so on. Then we had an appendix full of network topologies that we had to understand and in the detailed specification of the API, there were tons of parameters that we understood. And our conclusion after that one was, hey, so now we need to learn, we still need to learn how network topologies really work and we need to learn and understand how BGP is working in order to use their API. And with that question, we had an interesting discussion, Matthias and I, and we were really thinking, hey, is there a way that we, how we can simplify that process, how we can force people to think, start to think in simple patterns and I think Matthias has a great answer for that. Yeah, so at least we tried with one approach and that was basically not our idea, so we spent the last three years to build up this cloud-native ecosystem and as you might know, there is actually already a well-established contract between applications and services which is called OSB API. And I'm not knowing what this is about, this is basically a very simple API that allows you to provision services to your users and also bind these services then to your app so that they can use the services. So this OSB API was well-proven in our cloud-native ecosystems. We have built probably one or two years to bring up these services which we're working fine so we basically thought, can we just break down these more complex services also in this API? So what we then tried is we went to the classic enterprise ecosystems, we went to each service teams which might be databases, Oracle ones, or a site-based one, but also all the services, for example the connectivity one or the internet team and also stuff like email service or messaging services and we tried to make them and to implement the OSB API and the idea would be that each team owns this OSB API so to say as a contract to the outside world and so to allow basic interactions to the cloud world. We tried this approach and we even went a step ahead because within Swisscoms there are a lot of different services so there's legacy services and there's new services and we have a huge zoo of services and we went ahead with this guideline which says we should produce each service where it makes most sense, for example which means the NetApp stays in its place we don't virtualize it or try to migrate it to Kubernetes but it's there where it is but we should abstract it away using the OSB API so that we can consume it everywhere. So there are a lot of these service producers as we call them which range from the cloud native stuff to classic stuff and Kubernetes could also be produced as a service if you want to consume that just as a fun fact and within Swisscoms we have a lot of different consumers so we don't only have platform as a service and that's also the container as a service but we also have an infrastructure as a service and the people there would also profit from having access to these services and also we have some customers that would like to access these services from their own prem since they're just migrating to the cloud or having some hybrid story and in between to allow this we came up with thank you Swisscom we came up with this OSB API as basic contract between all service producers and all the clouds on the top level would have to implement these clients and of course this is a little bit OSB API is very basic so we had to implement some extensions when it comes to events metering and logging we will get to that later and of course we also had to automate the black hole and so there was some connectivity automation involved and the plot twist about this is that the connectivity automation itself is also an OSB API so we have tried that now probably for the last year we tried all various sorts and forms of services to put into this OSB API and we have learned quite some stuff about it so let's share our experiences when it comes to strengths yeah, it's a standard so what do I mean with standard and what do you get out of it so when I say OSB API is a standard it means basically all the consumers when they have it planted at once they can use all services which is a nice thing so you save a lot of effort and for Cloud Foundry Kubernetes you get the client implementations right away since they're supported out of the box so that means it also goes the other way around so if you have your clients once working then you can basically also use the hybrid cloud provider service brokers for example Pivotal has recently released the AWS service brokers and also Google has the service brokers so if we are slowly moving to the hyper cloud then we might just plug the services in try to work this well and also you could use that across companies so if your partner company has a nice service you could just hook it up to your cloud portfolio it has a very simple pattern so what does it mean it actually forces you to design your services very simple so it means you only have these two operations so you better make your service interaction work with these two actions and this also means it also means some limits so we will come to that afterwards but what something that was nice was it was very easy to understand it forced you you could not have the sequence diagram with bi-directional communication it forced you to really be simple and it was very easy to understand so we could sit together with the connectivity engineers or with the database engineers and they would get the service broker API specification like in 30 minutes when we explained them it was very easy to implement so we had this one after this one whiteboard session they could just go off and implement it basically because they have also good libraries so it was very easy to really implement it then in the end and the last thing which might sound like a limit so open service broker API currently is based on polling so if you want to know about the state of your service then you have to actually poll it sounds like a limit but it actually also really constraints you to use basic rest and not being able to talk the other way around which then ends up in communication nightmares so we actually had a lot of service that really worked well benefiting from these these strengths but there were also a lot of limits so we had to figure out that we cannot just press every service into this API yes so I have the honor to talk about things that didn't work so well during our journey I'm going to start with a couple of technical things that we experienced trying to really build more at once services first thing is relations once you pass the level of my service is I want to consume API or I want to create the DB schema somewhere once it gets bigger and more complex you hit limits quite early in your process and and we checked out in the community and we follow proposal from others for example in that area we kind of followed how the Azure folks solve that issue with parent references but it doesn't feel like very native then another issue which also had to do a lot with more complex services or maybe not cloud native or cloud ready services is the binding concept so binding as we know is A built for apps and B is ephemeral and the ephemeral part is quite hard for some services because they usually assign credentials or users with ownership within your service and once you want to unbind or in other words a bit of that user it's quite hard because that user owns some objects and you don't really know what to do with these objects then another thing we already heard that this morning in the keynote from SAP by default the catalog is static so you cannot really dynamically change things without notifying the consumer platforms I think it's very interesting talk this afternoon as a follow up from SAP when they show more about their service manager I can really recommend to join that session I'm too far away probably No it's actually Swisscom trying to lock me in so next point that's not on the list here is day 2 actions or advanced tasks a very good example is backup restore that's not part of the OSB specification provisioning and binding and that's it whatever you want to do after you have created your service or one week later two weeks later that's out of concept which again has some limitations then on the cultural side we also experienced some limits so we found that not everyone especially when it comes to these highly engineered teams they know a technology very well but usually they're not the software engineers and they cannot become software engineers within a month or two so it takes some time to understand the complexity how to build software which serves all the needs that we expect as a consumer of an open service broker API then another thing that I like to name is the GUID problem I think a lot of you remember these times where we had naming conventions for everything and naming conventions were usually made in a way that you can read out the customer and the stage if it's production or not you could read like say the whole history of an application or a system just based on the name and with introducing OSB API as kind of the broker to create new instances you have to deal with GUIDs which from an operator point of view doesn't feel that nice so you kind of have to get rid of your pet thinking model where you everyday say hi to all of your pets and look how they are you just trust in the system and the last point and we had interesting discussion about the deprovisioning use case if that is really a valid use case so we really allow our customers to by themselves with just one call without a safety net a multi step process to be able to delete their data these were kind of the discussions that we had and I don't want to answer if this is right or wrong but just to give you an overview of also on a cultural level what things we hit after we've learned about all these limits to continue the journey with OSB API and all these services since it worked out pretty well for most of the cases so we thought about how can we mitigate these limits and we came up with a model that helped us pretty good which is basically the first step is to try can you do it within the OSB API even if it means you probably have to cut off some corners maybe don't do this requirement if it doesn't fit in do we really need this requirement try to really use the standard because it means if it's in the standard you don't have to do any more efforts on your other platform so it's best if you can do it within this API and for example one of the limits we had was this relation thingy and when we reached out to the community through the Azure guys they were like yeah with this parent reference you could do it just fine within the OSB API you can model relations that way and you can actually even use it very nicely from the CFC Li so that was something let's try to model it in the standard because this is where 90% or 80% of your services should go and it means less effort in maintaining them and if you cannot do this if you cannot cover it with the basic thing you can take a look at the extensions that are out there in the community for example for backup restores there are proposes out there and that's what we did when we really needed backup restores so there are these extensions out there and we hope they get merged at some point so that the Cloud Foundries and Kubernetes clients they support this kind of stuff so that we can do more advanced stuff but yeah try to keep it simple don't try to rely on too much extension because that's going to hurt you with maintaining and last but not least if you really really need to do something that's not possible within the OSB API and especially that goes for the binding problem so if you have to model oracle databases with schema owners you're going to delete all your data if these are binding so you have to use something different so what OSB API offers you there is actually you can delegate the whole management of your service instance to a third party endpoint which can be a dashboard which can be an API so you basically can say when I order I can still order my oracle database and I can still maybe bind it for an API user but then all the further management goes over this API which also has a nice side effect that the teams themselves can maintain this API completely autonomous so but this means the most effort and the least profit from standardization so we try to keep these numbers of services very low. So that's basically how we cope with this limits and maybe some different interesting stuff that you're going to notice if you're going to build a lot of OSBs is that if you have all these different teams and they choose the technology they want it's going to be a lot of different OSB technologies and for example the database team they use to WebLogic since 10 years and they want to use Java so they write the Java OSB and another team they are scripting guys coming from CIS admin background they want to have a Python OSB and the messaging guys they have all this fancy process engines that they use to configure their router so their OSB API is just a layer on top of this process engine or the mail guys they have everything API they have an OSB API on top of that so we've all seen all different kind of OSB APIs but as marketplace guys we somehow need to make sure that they don't have to reinvent the wheel and they don't have to solve the same challenges again so they all have the same challenges when it comes to security for example to state if you use OSB need state you have to solve that it needs probably as in canding if it as in processes and the security officer knocks at your door and says hey this OSB they are so important because it's basically at the heart of your business so if you don't have security there you can basically sell your business or you can just close down your business and so he comes to me with a nice order credential safely make sure that they're placed somewhere where it's secure and that you have stuff like audit and login since we need to know what happened if the critical operations go over this API so we thought about this what should we do about this and still keep the autonomy of the teams so what we came up with was basically this idea we shouldn't try to force everyone to use Java because that would just prevent the DB team from doing anything anymore we should instead provide guidelines and try to underline these guidelines with some tools and platforms that are really nice to use and get the job done so that the teams prefer to use our technologies and platforms than to build it themselves so for example to show you some guidelines we've come up with we have some guidelines regarding placement and connectivity we have created a VPN where everybody can hook his service broker in so that they can communicate with the client platforms very easily or we have created a guideline regarding audit, login monitoring what's required for you if you want to bring your own OSB and also how to secure your credentials safely you might know for example Cretab or revolt offers this kind of stuff and then we also have these tools and platforms that should make this easy so we have an open service broker that's publicly available on Github and this thing for example adds Cretab support to solve this it adds white box monitoring for the middle pillar and it also runs fine as an app on cloud foundry which is the second point so we try to push very hard to push these OSBs internally on the cloud foundry because these offers you managed services for example for logging or for monitoring so they can really cover the stuff on top so that's how we try to get some governance over all the OSBs that we have so after having spent probably two years with OSBs and OSB APIs what we do it again so probably what have we learned so these limits really hurt you in some use cases so we had discussions with some service producers who tell me why do you try to fit my service in this very basic APIs and we had trouble finding the right balance between standardization so these limits really hurt you so it's good to know them one thing that was funny was that actually we had some guys with the first OSBs and worked out within the cloud foundry and then some guys came up with hey can't we solve this problem also with OSB API and it was completely unrelated so don't try to force too much in the API just because you can model it somehow to fit in the OSB API it's especially important to know the limits it's not a silver bullet it does not solve the job it's just one specific form of an API that allows you within the cloud space to use services don't try too much to use it outside so our recommendation is also know your use case know what you want to do will it be limited to really service provisioning can be done with these two operations and especially have no the strengths and limits that we just highlighted before so with that being said if you have any questions you can ask us find us at the Swisscom booth anytime thanks a lot for your time and have a good meal