 So my name is Georgie. I work at SAP and currently I'm software engineer for the CF foundation services API team and I work out of Sofia Bulgaria and Hi, everyone. My name is Sam Gunnaratna. I work for Pivotal. I'm an engineer I work in London and I work on the same team as Georgie And so our team's focus is really like the services experience in Cloud Foundry And more specifically we look after the open service broker API implementation in CF So as authors of a platform like we spend a lot of time thinking about Brokers and broker authors and the specification. We spend a lot of time thinking about it in a very like abstract way So this talk is really us so taking a step back and trying to think about it more practically And really trying to understand does the specs sort of live up to the reality of what it claims So what we'll do is we'll do a little level-setter and talk a little bit about the API And explain it will then have a look at the ecosystem to see sort of what's evolved over the last two years of this thing being An open project then we'll dive into really the title of the talk Which is our demonstration and then we'll end with some questions and some learnings at the end Great, so we'll try and get through this bit a little bit quick. So what is the open service broker API? So this is a specification that started in Cloud Foundry a number of years ago put simply it's a way for Your applications running in Cloud Foundry to have access to backing services and the classic example is I have an application I want my application to be stateless. I need to store some database. Give me a backing data store And so two years ago the Kubernetes community were thinking about similar abstractions and so instead of going off and forking and making their own specification they decided to work with Cloud Foundry on the open service broker API, which is a run by a committee of these companies and the goals are exactly the same as the original specification except on The Kubernetes platform as well as Cloud Foundry. So it's all about managing service life cycles Okay, what does actually mean? I mean, we will need a little bit more details in order to understand the specification a little bit better So as part of the specification, we have two main actors in it The first one is called the platform a typical example of a platform is Cloud Foundry or Kubernetes This is the place where our workload lives The second actor as part of the specification is called a broker This is the component responsible for creating service instances of a specific type An example of a broker is the MySQL broker, which is capable of provisioning small, medium or large plans So what actually happens behind the scenes when a Cloud Foundry users types the CF create service command Then the platform behind the scenes makes a provision request. This is another term of the specification to the broker and as a result of that provision request, a service instance is created This means that we have our instance available out there in the cloud waiting for us Okay, so far so good. We have it But the next thing that's logically we need is we actually need some kind of information in order to connect to that instance This in the very Basic example is some URL username and password to connect to that database This in the terms of the specification is called a binding So again the platform makes a binding request to the broker based on some kind of user action And as a result of that binding a set of credentials are returned back to our application or our container And we could start working with our instance as normal Okay, to summarize what is actually the OSBapi as you may see from this diagram The specification is exactly the boundary Which defines the contract between the platform and the broker and define some kind of common workflows related to service instances Okay, but why is this important? So Because this is a Specification what it Facilitates is like this sort of model where you can have a platform and then a series of brokers offering different services And the reason you want to do this is you want your developers to have access to like a toolbox of services to build richer applications But the soap and service broker spec doesn't really have an opinion about where these services should be deployed so It might be that you have one of your brokers Hosted on-premise and there's lots of reasons you might want to do this Maybe you have data regulatory needs or for performance reasons or maybe you're backing an existing service that you have in your organization But equally you could also just get a service from a cloud provider So in the case where you want to use I know some like data service and you don't actually care where it's hosted You just want you want access to that service like why not get it from an expert who like an expert provider Who has a lot of experience running these sort of services? So and this is sort of like the heart of our talk And so sort of sparked the question like how many services are available from these sort of cloud providers? So we spent a little bit of time scouring the ecosystem of six different providers and found there's like 200 services offered by like all of these providers and It's a mixture of both SAS offerings so you just get a URL and you register it in your platform and Like artifacts that you download and then deploy on-premise And because everybody likes logos Here's a lot of logos of all the services that are available that we found And what was great during this like exploration wasn't just the variety of services It was the fact that if for example, you want a Postgres service There's actually a bunch of different providers that offer that service So what that means for you as a consumer as a platform operator is that you can pick and choose which Provider you get your Postgres from you could pick based on price or SLO or performance and if you're not happy you can switch So I guess most of you have started wondering where are we going with this talk because all the things so far were kind of familiar We saw them on previous summits on previous talks We didn't tell almost anything new as part of this. So what we actually wanted to do Some and I wanted to put the specification to the test So we wanted to validate how easy or how hard is for a developer to actually consume Multiple services coming from different cloud providers. So what does the developers do when they want to test the thing? They create an app. So we did We have created a very simple application with the purposes of this demonstration The application consists of two basic nodes a web node and a worker node a user is allowed to upload image to the web nodes and Then an image is passed to the worker node via messaging queue system then the worker tries to classify that image and Extend some kind of meaningful information from it relying on already trained models coming from an image classification service and Once we have our classification we store the end result and the input image in a relational database I guess most of you might be familiar with such an architecture because a lot of Real-world applications rely on similar services So how actually our app look looks like back from different cloud providers? Because we think we are kind of pragmatic and we also believe in using the right tools for the job We decided to rely on the message queue coming from the Google pub sub as our Inter-process communication system We we also use the IBM Watson vision recognition service with for the image classification And last but not least we use a relational postgres data postgres database coming from the Azure cloud So right now some is going to demonstrate you live What does it how does it look like from CF developer perspective to work with such application? That is backed by those cloud providers Okay Can everybody see? Okay, can everybody see that? Excellent Okay, so I have access to a cloud foundry environment right here And the first thing I want to show you is that we have some service brokers registered here So I can run the service brokers command and you can see we have three brokers And as your broker a Google broker and an IBM broker Next what we'll look at is we'll look at what services are available From those brokers and we can do that by looking at the CF service access command We'll just get those so you can see here. They're ordered by the broker so at the top These are all the Google services then we have the IBM services lots of Watson goodies and At the bottom a bunch of Azure mainly data services, I think But for the purposes of this demonstration, we don't actually need access to most of those so we've only enabled We've only enabled for three services that we need so that's a postgres from Azure Pub sub from Google and the Watson vision service from IBM So if we have a look at our applications, we have the two apps that Gilgit was mentioning a web app and a worker app This is just both regular like CF go apps and they're stopped at the moment So what we'll do is we will create the vision service from IBM Specifying the service name a plan and then an arbitrary name the service vision so go ahead and do that and this is going off to IBM's cloud and Provisioning some abstract concept of a service that will allow us to get credentials with the bind operation in a second Let's see how this goes All right amazing So next we'll do the bind operation and you remember from that diagram It's the worker application that she needs access to the vision service So we'll bind it just to the worker app And this will go and get the actual credentials the API key that's required to go and talk to the vision service Okay, so for the rest of the services we've pre provisioned them just because it takes a lot of time so you can see the applications So the services on the left and then how the bindings work in the middle in the bound apps column So our postgres and our pub server bound to both the worker app and the web app and our vision service is just bound to our work app So next what we'll do is we'll start both our web app and worker app and Just while we do that what we'll do is I've got it there already We'll have a look at the environment for the worker app to see what their vcap services look like So the first service you can see that is the Azure service You can see it's got a postgres connection string or very sort of vanilla And this is typically what service bindings look like For the majority of service brokers the Google one's quite interesting. It's a completely different authentication model You actually get back private key information that you use then to communicate to Google service and Finally the IBM service is again different. It's an API key that you get back along with the URL Let's head back. So our applications have started now and I'm going to Look at that and look at that. There we go So actually pretty proud of this UI mean you're beyond UI designs, but this is top-notch material design I can promise you So as you said what we need to do is upload an image Fortunately There we go. I'm trying to find my cursor here So what we'll do is find a nice image here Again, if you can see that on the screen, let's see if we can write you. Yeah, this one wait not that one This one. Okay. And so what we're gonna do is we're gonna take this image We're gonna upload it. It's gonna go to our web app. It's then gonna be sent all the way to Google servers Wherever they hope they're hosted It's gonna be picked up the subscription by our worker app sent all the way back to our cloud foundry then go off to IBM servers for classification then the results in classification and image are gonna be sent to as your servers to be stored and then picked up by our web app So if we open that and click load here We have some very simple logs for our worker app so you can see it's received the image It's classifying and then it stored it again in as your and finish processing the message And if we refresh I can confirm with the power of three clouds that this is a lion everybody Yes Thank you very much and You've already seen it, but this is pretty great. We've also got a not a lion And we'll see what Watson service thinks of this So if we upload it, it's the same process And it's actually pretty good It's determined that that on the right is is a dog and that on the left is a lion So I was actually very impressed by this. It's actually awesome Cool, but the main point is right is that like we're like as developers we just pick to these services And we built our application like using all these different Services from like the expert that we wanted we want like we know IBM a great like Watson services So we'll have that like maybe our app would be higher throughput. So we want the Google pub subservice, you know all that sort of thing Okay, let's head back to the slides Okay, so we talked about three different brokers and like the ecosystem of brokers that's emerged But as we know like the open service broker API has brokers and platforms. So what about an ecosystem of platforms? And so this is what we sort of wanted to do Where we had Kubernetes doing exactly the same thing talking to the same set of services and that's what gilgi is going to show you now Okay, thanks some thanks for the nice demonstration Okay, so right now I'm going to show you the exact or almost the same workflow but From a Kubernetes developer perspective or how we actually could push that exactly the same code base with exactly the same application but to Kubernetes and I have pre-configured a demo magic script So just to save you my poor typing skills So don't be impressed with my fast typing skills. It's a script But the demo is live. So it's not a recording. So if anything goes wrong, you will notice it immediately So the first thing that we did Similar to the CF we have configured the Kubernetes cluster and installed the service catalog in it and also registered three the same three brokers the Asia the Google and the IBM broker and this is currently part of my of my context So I have a cluster which is called something and Georgie and it's installed with all those things that we need Okay, the next thing that I'm going to show you this is the equivalent of CF marketplace command But in Kubernetes term, I'm using the service catalog CLI and in this case It's called get classes Which will return me return me the list of available services as you may see This is exactly the same list of services But just put in different order, but we have services coming from from Asia We have services coming from Google the spanner. We also have our Watson vision combined service that we are going to use as part of our worker notes Okay so the next thing is I'm going to describe or to get more details about about the Watson vision service and see what are the available Plans that that it has so it has the same set of plans as in the CF scenario It has a light and a standard plan and it also has a longer description about Specifying what are the pros and cons of the different plans? So the next thing that I'm going to do is trying to provision a service instance Or this is the equivalent of CF create service command that I guess most of you are already familiar with so again we The the the command is different. It's called provision But the semantics and the thing behind the since is actually the same So we just specify a name I identify for our service instance And we specify what is the class or the service and the plan that that the service instance should be derived from So we get an immediate response for that operation However, all operation in Kubernetes are asynchronous So we still need to run additional command in that in order to get the real status of that operation So this command in the terms of service catalog CLI is called described So I'm describing an instance and give the identifier the name of my instance So as you may see from the status field the service is ready It's available out there in the cloud somewhere in in the IBM data centers. So We have it ready ready good to go So if you remember the diagram That I've shown you earlier about the details of the OS Bappie We need one more additional thing to connect to that instance. This is the binding actually and As you may imagine the equivalent command in service catalog is called bind and we provide the name of the instance And we add additional identifier. This is the name of the binding So we actually put some kind of label for the binding Remember this name because later on we will use it. We call it vision binding just to associate it with our service instance, but it is it's a thing that we will use later on Again the same immediate list response, but actually behind the scenes something asynchronous might happen I'm going to again describe the binding based on the identifier But provide the additional show secrets flag which will actually try to decode my binding and Present in plain text what were the credentials that the broker has returned to the to the platform or to my application So as you may see and I guess as most of you may have is expected We have a new URL. This is the place where our service actually live and we have an API key Which we will use to authenticate and authorize our application when it connects to that service instance Okay. Yeah, the As some already explained the process for the other service instances is exactly the same I mean if you want to provision and bind a postgres or the cloud pub submessage in queue The process is exactly the same you just change the names and just change the values of those parameters So just to save us some time We have preconfigured those instances that are necessary for our application to live and we also have a corresponding bindings which are for the for those service instances So the next thing that I'm going to show you is how actually to connect that binding or start using that binding as part of our application environment This in the Kubernetes world happens in the deployment descriptor file or happens in the app environment section This is the environment that is available for our application when it boots So what we did here was actually when we used the binding or we the rep or Reference the secret that is associated with that binding and put that as a value as a new Environment variable that will be available on boot time of our application and our application knows how to Work with this vision API key environment variables So our library could start and could could work the same thing happens for the URL here Okay, let's let's test this thing Let's see whether the application actually will be able to start and work with with the service instances and with those bindings This in the terms because I we have created the separate deployments for both components this in the terms of Kubernetes We create those deployments using the cube CTL out of that Deployment descriptor the yaml file that I've shown you so yeah again Asynchronous operation, so we could not be a hundred percent sure that the thing is Running so we need to run one more command and describe our and get our deployments And as you may see our deployments are already available or our apps are already available for consumption or Just to one side note here because in Kubernetes Slightly different than than in CF when an application or a container is started It doesn't have a public IP address or a DNS address Associated with it. So we here need one additional resource in the terms of Kubernetes code a load balancer service Which will actually map a public IP address, which we could access from a browser to our application running as part of the of the cluster and as part of the pod so we have pre-precreated that load balancer service and It is available on this external on this IP address So when we open the address you could see the same pleasant UI that some already shown You so right now I won't get into the details of that because the process is pretty much the same I will just try and see whether it's working. I'm going to use this image for for the For the classification hit the upload button wait a few seconds hit the refresh and Yeah, it's working. So we have our image classified and as you may all see a pretty good and concrete classification so it looks like a good that food that everyone could have once this presentation is over Okay, this was the the demonstration that we wanted to show you how it looks like actually from Kubernetes developer perspective and how we actually could use The same code base and push it to a different platform The last bit that we wanted to share with all of you and that we thought that this is going to be interesting for Everyone were the learnings that we made during preparing for this talk and during create Creating this demo. There were quite a lot of things if I have to be honest The first thing that we were quite surprised in a good way Despite the fact that we are every day working with the specification and we know how powerful it is We we were very surprised about the huge variety of services available out there coming from different providers So it's definitely a good thing and I personally felt like a kid in a candy store When I saw how many services I could consume as a developer The next thing that we are happy about is how actually similar working from both platforms looks like from a CF related From services related Workflows, I mean the user experience there is pretty much the same You need to learn a few new flags and you need to learn to install a new CLI and you're good to go You can switch or you can use both and you don't have to learn almost anything new the concepts But the concepts are exactly or pretty much the same The next thing is Like this worked like we sort of set out with this goal of trying to consume these Three services we sort of came up with the name of the talk and then we were like right We'll go and figure out how to do it, but the good news is it worked Which is awesome, but with some caveats So for the eagle died amongst you when I did the CF service broker command You might have noticed that the URLs of the service brokers were actually Cloud Foundry apps And that's because to get the providers work and we actually had to use proxies And for different reasons so for the Google case, they actually support a very custom JWT a wharf Flow that Cloud Foundry just doesn't support So we had we have a proxy for that and for the IBM case their services are actually private to IBM cloud So I think Like I've talked to a few people about this and from our this this is this definitely wasn't possible a few years ago So like the general direction is that these things will be consumed and other providers are working on offering full sass offerings of their Brokers in which case like the proxies won't be like required The final thing that you might have sort of wondered is In our demonstration we pushed the same app to different two different places and same set of services But we never shared data across the two platforms And I don't know if you saw Florence talk the keynote this morning But that's the sort of thing that the service manager project is hoping to address So hopefully next summit someone come along and do an improved version of our talk and maybe show the web app running in CF and Work apps running in Kubernetes and communicating through services awesome Well, thank you very much. That was our demonstration showing, you know different cloud providers Services all being consumed one app and two different platforms Does anybody have any questions if you're interested in the stuff? There's two other things happening at summit I can shout out to so there's first of all if you're interesting about services in CF Nikki is doing a talk later about the services API team in CF I think that's at 5 30 and then if you're interested in like Kubernetes and CF experience for services Luis and Alex are doing a lab. I think there's one session tomorrow where you can go and play around with that life If there are no questions Thank you very much. Thank you