 Hey everyone! Welcome to the subtle art of keeping your service broker multi-platform compatible. I will immediately start because I have more than 30 slides and less than a minute for every one of them and I'm all against the odds because it already took me half a minute to just say the title of my talk. I'll have three simple goals as part of my presentation. The first one will be at the end of this session everyone including me to have a better understanding how we can build a service broker which is compatible with as many platforms as possible. The second goal will be due to the fact that this is one of the first breakout sessions that you participate during this summit. I will try to give references and give some suggestions for other talks which I believe are related to the things that I say so if you'd like to learn more about those specific things you you can do that later on. And last but not least I will try to set a very very low bar with my presentation. The reason for that is because I believe we should always start with low expectations then gradually during the conference when we exceed our expectations we could have an overall great conference and awesome experience and all of that will be due to my talk and my poor performance on stage. I'm going to use the following agenda to achieve my plan. The first question that I'll try to answer is who am I and why do I even dare to talk here about platforms and brokers. The second one will be the why behind the talk or the reason that made me submit this this session. And the third one will be what are the things that I personally believe affect every single broker-author in case they would like to be compatible with the different platforms. So who am I? My name is Georgie if you already don't know that and I've been part of the Cloud Foundry community for three and a half years so far. So during my career in Cloud Foundry or as Cloud Foundry contributor my former team exposed the so-called metering and aggregation service CF Abacus to Cloud Foundry users by developing a service broker. So in other words I've been into the role of broker-author or implementing a service broker specifically for Cloud Foundry as a platform. Then the things have slightly changed. So I moved to another team which is actually a Cloud Foundry foundation team the so-called services API or SAPI. And if you are not familiar with what does this team do maybe the first sentence of the team charter will help you clarify that. In general the SAPI team aims to improve the developers and operators experience related to services and we mainly do this by adding improvements to the cloud controller to the CFCLI and to the open service broker API specification or in other words I've been also into into the role of implementing a platform or Cloud Foundry. So then the second question the why behind the talk was actually a presentation that last year in Basel my colleague Sam and I did with the presentation was with the fancy title one up two platforms three cloud services. For whatever reason the people after the talk decided that I know what I'm talking about so they approached me and asked different questions and for majority of them they were into the following situation. So they were having a service broker which offers their services to a marketplace in Cloud Foundry and they were looking forward to extending their service offerings to actually users running their containers in Kubernetes. And quite interestingly even one of the people was looking actually for concrete reasons why their specific service and their specific broker won't just magically works and won't just be able to register successfully in case because his manager was quite sure that because the broker is OSBAPI compliant it should just work at the end of the day it's OSBAPI the specification is there and it's abstract enough and good enough and both platforms support that. However on stage and when you're demonstrating something like in the case where Sam and I did as part of the summit where we showed how easy is to actually deploy a single application without any code changes to Cloud Foundry and Kubernetes and this application actually to consume services from IBM cloud from Google cloud and from Asia. However when the things come to production and when the things come to different services and different offerings and different brokers the things are not as trivial as on stage and as some demo and the reason behind the talk is simply to just give you the other perspective or the other point of view about what are the things that you need to consider if you aim for a broker that is compatible with the different platforms. So I'm going to start with a brief introduction to the common terminology that I'm going to use later the talk. Most probably most of you are already familiar with that but bear with me I'll try to keep it short. So open service broker API or OSBAPI or just the spec how we usually reference that is actually a document so it's a read me it's a document which defines a contract between platforms and brokers. So what do we usually refer when we say a platform so a platform is Cloud Foundry or talking or getting given a little bit further into the details the component from the Cloud Foundry ecosystem which is responsible for implementing the platform part of the specification is called the cloud controller. This is the main component which my team contributes to. The second component or the equivalent in the Kubernetes ecosystem is called the service catalog. This is the project which actually bridges together the container orchestration of Kubernetes together with the concepts of the brokers and services and bindings and all that kind of stuff. So the next abstraction or the next main actor as part of the specification is the well-known broker. So brokers actually just advertise a set of services and plans via their catalog and they handle some requests based on some kind of user action which provision or create service instance which creates a binding or the the equivalent destructive operations like unbind or deprovision or delete of a service instance. So it's a pretty powerful abstraction where you can fit a lot of things and you can actually connect those platforms where your workloads live to different kind of service offerings. So a typical example that a lot of people use to actually give something concrete about a broker is the MySQL broker or the MySQL broker which advertises a service which creates a dedicated relational database for you and the plans usually are small, medium, some kind of t-shirt size plan. So once we have this common understanding about the terminology what are the different types of brokers based on their deployment mechanism that are quite popular today. So the first type of broker is the one that I call and usually most of people refer as one deployed alongside in the platform. So if you if we imagine that this is some kind of private network which the platform lives in those service brokers are usually deployed via Bosch and they live right next to the platform in some kind of inner private circle or inner network of this platform and they communicate or interact together. So an example of such brokers is the service fabric or the on-demand service broker. So usually they expose their service offerings via such kind of a broker. So the next type of brokers are the one that live on top of the platform. Most of people and most teams start with this because it's simple. In the Cloud Foundry case you have a stateless Cloud Foundry application running on top of the platform and you just delegate or you just cut some resources for the users in case they provision a service instance or create a service instance. And the third type which is kind of newer at least for me are the one that are called hosted brokers or some kind of central brokers. An example of such broker is the Google Hosted Broker which is actually a single central broker where every single platform no matter it's a Cloud Foundry deployment installation on whether it's a Kubernetes cluster with service catalog actually registers this central broker and they are all sharing the same logical broker. Behind the scenes it's something running in the Cloud which of course is some kind of distributed system but for the end users they look like a single instance of this broker. So then what are the things that every broker-outer needs to consider when they try to be compatible with the different platforms most probably Cloud Foundry and Kubernetes. So if you already saw from the diagrams there are some specifics about the networking and this is one of the topics or the first topic that I want to talk about. So networking is quite crucial so if you remember that the first diagram where we have the broker which is deployed alongside the platform and they're living in some kind of private network imagine this is a Cloud Foundry running on AWS and if we'd like our Kubernetes cluster to actually access that Cloud Foundry running on a separate. Let's have a platform to be a Kubernetes cluster running on GKE and if you'd like to register that same broker in the service catalog in the Kubernetes then we just the things just won't work because there won't be a networking connectivity between the two Cloud providers so you have to do some additional effort to actually ensure that connectivity and today if you saw the talk from Ralph on the keynote about the demo that he made so basically those charts and the diagram that you saw are some of the things that you need to take care of so does that mean we should always aim for brokers which have a public endpoint or a public address assigned to them well I could not say that there are some pretty good reasons why certain brokers make sense to be in a private network and I'll give a concrete example of that later on during the presentation but in general it looks like the trend the last couple of months or even a year is the following so a lot of companies especially running multiple platforms multiple Kubernetes clusters are aiming towards some kind of centralized place which actually aims to manage your brokers and connect your broker to different platforms so you as a broker author just have to register your broker once in one place this centralized control plane and then the broker this thing this component is responsible for connecting it to different platforms applying some policies and doing some kind of other stuff so currently there are two initiatives going into that direction the first one is called the service manager if you attended this the the Basel Summit last year most probably you saw a demo from Florian and maybe you have attended the talk after that if you're interested into learning more about the service manager you can ask Florian or yeah or you can ask me and I'll try to do my best to answer you same question the next initiative that is going into that direction about having a single centralized control plane for managing your services is called ISM which stands for independent services marketplace so tomorrow there is a talk from Matt and Laurel with the title one marketplace to rule demo I will reference that in my last slide if you'd like to take a picture of when it actually happens and where so the second class of things that every broker needs to need to consider at least from from my opinion is the authentication so just a few releases from the last version of the specification the only authentication method between platforms and brokers was the good old basic out there are a number of problems with with this technology because it's quite dated and this is actually the reason why certain brokers somehow mitigate the fact that they support only basic authentication and they don't want to go public so they don't want to have a public DNS route assigned to them and they prefer to stick to stay in some kind of private network just to not be exposed to the internet and not be protected just by a basic authentication so the latest version of the spec is quite loose so it's not anymore the case that the basic is the only authentication method today the spec actually supports a bearer token authentication flow however it's agreed upon out of bound between the platform and the broker how actually fetching the tokens refreshing the tokens revoking the tokens invalidating them works so it's somehow in a way a black box for the platform and Kubernetes today supports opaque bearer token authentication however it's very tightly coupled to the way the Google authentication server works and it won't work with you are a you a or the AWS authentication server and so forth so today if you'd like to have a service broker which is compatible with both platforms your your only chance is by going basic so I guess if it's an already known problem what does the community do in this direction to actually improve this and make the things better today there is a proposer with the title declarative authentication flow which aims to put some kind of standard between how the platform and the broker should negotiate the authentication flow so it's not anymore a black box it's some kind of different color box in a way and it should become a part of the spec how brokers and platforms should should handle this flow but it's still a working progress and it will take some time until it it makes its way to the specification and to the brokers so yeah and the third class of things that I wanted to share with you about what you should consider if you have to if you want to have a broker compatible with the different platforms are the so-called pitfalls or spec interpretations or something in this way so due to the fact that the specification is written by humans it's also read by humans and implemented by the later usually humans tend to have different or read the same thing in different ways so they make some kind based on their context or based on some assumptions that they make which leads into different end results so to say so I decided to just put two examples of the things that I know and that we faced last year but there are plenty more and there are a lot of uncovered things between how certain things are done in cloud foundry and how certain things are done in Kubernetes so the first example is the service and the plan name so the latest 2.14 release version of the spec is quite strict about what you should put as a plan name or as a service name as part of your broker so it must be a CLI-friendly name and a CLI-friendly name is defined as something that contains alphanumeric characters periods hyphens with no spaces no underscores and etc and service catalog actually enforce that constraint pretty strictly so in case you have an underscore union or service name the broker registration will fail however it wasn't the case at all in cloud foundry so cloud foundry always allows spaces or comparisons or underscores or on or all that kind of stuff which means that you could have a service broker with us with an underscore in its name and it will successfully able to register in cloud foundry but it will fail registration in service catalog in Kubernetes so the things that have changed in this direction is that the spec is currently the late or the current work in progress version of the spec is quite loose so it starts recommending some stuff and recommending a CLI-friendly names but don't force and don't have this must in there but it's a pretty good example how you could be affected with such kind of tweak the next thing or the next pitfall that I wanted to show you are the limits or here the spec is not so strict about what you as a broker outer should have as a limit on certain string fields so the recommendation here is that you have 255 characters otherwise you compromise your compatibility with the different platforms however last year we worked on an issue in our team where we had a service broker which was successfully registered in cloud foundry and fails registration on another cloud foundry instance and the interesting bit here was that they both were running the same cloud controller version they were having the same API version and when we get deeper into the problem it looks like the the root cause of it was actually the relational database that was was backing up one of the cloud foundry platforms was different than the version in the other the first one was using Postgres the second one was using MySQL so it turns out that for this specific field or for some fields some string fields the in MySQL case it defaults if you have a string field and if you don't specify yourself a limit it defaults to 255 characters and in the Postgres case it defaults to a text field which has an enormous or pretty big limit so this is another example of how within the same platform you could have different interpretations or different implementation details which could fail your broker registration and at the end of the day could break your delivery pipeline because imagine there are some fields like which are generated automatically like dashboard URLs or have some very long goods and you don't have control about how many characters you actually specify because it or you have a control but it's not so direct and still this could affect you and the last thing that I wanted to finish my talk with is or what are the the things that every broker author should consider unfortunately I don't have a silver bullet which will work for for every broker because depending on your broker depending on your product requirements on your security requirements on your service you you could have different problems into providing a multi-platform compatible broker however the things that will work for for majority of the users are know your audience or know your platforms and ideally validate against them or test as part of your continuous delivery pipelines continuous deployment pipelines test against the platform that you aim to deliver your services to. There is a talk today later on called testing production environments and validating OSBAPI compliance so if you're looking into learning more about specific use cases or how different companies does validate that I encourage you visiting this talk I'll reference it later. Then the second takeaway or the second thing that should work for for all service brokers are try to avoid as much as possible some platform specific context or features for example space good and or good only makes sense in cloud foundry so if you rely on those those those things it won't work in Kubernetes there we only have namespaces or if you have a service broker which is a syslog drain or volume mounts broker or something like that it's only a feature supported in cloud foundry today so it won't work in Kubernetes. The next thing is that if you remember the slide about the centralized components which should manage brokers and platforms on the one hand and the other so expect more platforms in quotes in future so technically speaking this centralized components which will actually bridge or will act as a gateway of brokers to platforms will actually be one or will be a newer platform in implementation according to the to the spec terminology so you could expect more interpretations coming from that there might be even some books or some kind of false assumption that someone did a long time ago due to historical reasons and then this new central component just reviews that and and makes it obvious so this could is something that you should also consider and at least for me it looks like the trend is more hidden or heading into that direction about having a single centralized place for which connects different brokers with with different platforms and last but not least if you are a broker author your best bet to actually know what is going as part of the specification is to participate into the community so there it's a living thing so it's constantly changing if you attend into that community you we can have your feedback for certain things that platform makes sense and that platform think it makes sense to provide to their users so your your feedback as a broker author is very valuable and you can also be informed at a relatively early stage before the things get through the platform or to the platform whether some some spec changes could break your broker and could break your compatibility with one platform or the other and it's a pretty good way of actually connecting to user groups the platform authors and the broker authors and on that terrible disappointment I would like to thank you all for your attention I hope you have an awesome conference overall and if you have any questions right now is the time or you can find me somewhere around I like talk or a session submission for the next summit so I'm very keen on getting some inspiration from the conversations that I'll have with you so here is the slides for the references that I gave you can take a picture if you'd like and if you feel interested into learning more about that thank you for your attention yeah yeah so the question was about the declarative authentication so yeah it's a thing that currently is standing as an as an issue on the open service broker API specification and there is a document with some findings in there which our team the SAPI team did so in general the goal there is try to put some kind of standard and this authentication phone not to be agreed upon out of bound between the platform and the broker so in a way not to be a black box but just have some kind of a way to define how or what are the support that authentication flows of the broker and whether the plot or how the platform could act to actually execute them or follow them in in general there are a couple of options written there but the most simple one is that imagine that we have a slugger or open API document which describes which is a niamala describing that okay I have an endpoint which should serve post or we should respond to post request and the results or as a result of that post request I should return some kind of body and some kind of flow described in in an open API document about how the flow should work there are a lot of uncertainties there if I have to be honest it's not a trivial thing especially if you aim to provide something that is generic across the different authentication servers because our investigation was actually there is not much common between the Google authentication server the UA the Asia authentication server the AWS server so it's so few things that are common between those those servers so it's not trivial to put some some kind of yeah have a standard thing there cool thank you for your question any more questions I guess that's not so yep thank you