 My name is Colin Stevenson. This is my colleague, Prasad Bipartakar from Pivotal. We actually work on the Pivotal global ecosystem team. And so what does that mean? We work with a lot of our cloud provider partners at Microsoft, Google, Amazon. We also work with our system integrator partners. Some of you may be amongst them as well. So thanks for coming to the session today. We're going to be talking about how to quickly build Spring Boot applications to consume public cloud services. As you know, the public cloud service providers out there offer a variety of services. And we thought it would be helpful to jump start bringing Spring Boot from Pivotal with these services and make it easier for you to develop these applications. So if you're not aware, there are these service brokers available. I think some of them were mentioned last year. Since the last CF summit, we've seen an expansion of the service brokers for Cloud Foundry. This example is obviously Pivotal Cloud Foundry. For those of you who use the Pivotal distribution. And the nice thing here is that these service brokers work across these different clouds, right? So as long as you have connectivity from wherever you're running your Cloud Foundry foundation, you can deploy these service brokers. Now, you see these tiles here. Those are obviously Pivotal specific. However, at least two of the three are open source and working Pivotal working with the Microsoft team and the Google team. And then on the AWS side, we've built out the service broker. There is also a open source alternative to a number of those services. So have no fear. If you're full bore on open source, not using Pivotal, that's perfectly fine. There's options out there for you on those as well. So what's in the box? Obviously, these providers have a number of services available. These are the initial, the most common ones that a lot of our customers are using, the ones that are typically asked for. The list will grow over time. So Google Spanner, for example, they just added that to the broker. So we're working closely with these teams to make sure that as more services come on board, as services change, for example, on Azure DocumentDB recently got a nice upgrade to Cosmos DB. If you've heard of that, they announced it at Build a few weeks ago. We're working with these teams so that they're constantly being updated. To provide you the options to be able to use these with your Cloud Foundry deployments. And now with the open service broker API model, we're seeing this expand potentially out to other platforms beyond Cloud Foundry, which is great as well. So one of the questions is, isn't that vendor lock-in? What does that mean? So for us, certainly consider the benefits of using these managed services. A lot of customers might go all in with one particular cloud provider. Some of them are talking about using multi-cloud or hybrid cloud. How does using these service brokers and these services affect my deployment? What do we need to think about there? So there are certainly benefits to using these managed cloud platform services in a lot of applications that you may get advantage of not having to worry about the overhead of now handling the clustering mechanisms or the disk sizes. They're still monitoring that goes on, but oftentimes you can offload a lot of those capabilities for a lot of applications in the enterprise. Ask yourself, do you really want to manage those yourself? In some cases, especially legacy databases, you'll continue to do so. But we talk to customers all the time about how do we move those over? If I'm using MySQL on RDS versus MySQL on Azure, the switching cost is fairly low at this point. It's not too hard to move those. And ultimately, as we showed, we can deploy these brokers to any cloud foundry deployment, right? So if you're running cloud foundry on Azure or Google and want to connect out to those AWS services, you're able to do so. So everyone's probably familiar with CF push if you're here, shouldn't be a surprise, right? This is what gives our developers velocity to deploy these applications rapidly that they're building. Once I have that app, I'm very likely going to bind it to create a service that I want on demand, provision on demand. And while there's a number of marketplace services out there available, open source, or from different groups like from Pivotal or otherwise, this create service could be reflected in a lot of different ways, right? It could be a Bosch managed release. It could be something to one of these cloud provider services. So the goal there is that we can get those very quickly and then ultimately we're binding that service, right? So what happens when we bind it, we might restart or restage our app. So that we can get our VCAP service environment variables. Now, in working with some of our customers that are using these public cloud services and they're using Spring Boot, developers know how to build great code, but they might be doing that boilerplate code over and over. And there were no kind of out of the box, there was no out of the box way to use these services from a cloud foundry specific standpoint. So what we wanted to do when we started working on this project and what Presad will show and some demos and walk through the code is how can we quickly, you know, for developers using Spring Boot, which a lot of them are, how can we quickly use those services? How can we get rid of the boilerplate and kind of adhere to the values and the standards that the Spring development team have instilled for a very long time now. So Spring Boot's to the rescue, right? You have Spring Initializer, you can go to start.spring.io. Unfortunately, what we're gonna show isn't quite there yet, but that is our goal. So if you go there today, you're not gonna see these, but we're getting there. But this lets you generate the dependency map. So who's use Spring Boot? Anyone use Spring Boot? Okay, good, so you know what this does. In our case with creating the starters for these public cloud services, you're able to get all the dependencies from those cloud providers into the packaging you need in your Maven Palm file, for example. Who's familiar with Autoconfig? Okay, so not everyone. So this might be new. So Spring Boot Autoconfiguration, if you use it, first of all, you do have to opt in, right? This is up to you as a developer to choose to use this capability out of Spring Boot. It's not a requirement, but what it does do is it looks at the jars on your class path and determines at runtime what it should do based on seeing that jar. So in this case, if we see an Azure document database, jar on our class path, and we have some code that's going to interact with that service, it will automatically configure that Spring Bean for us. So that's what we're gonna dig into here more. The other thing is these are non-invasive, right? So you can override these if you need to. You can override the properties that are provided that we're providing by default. And you can also exclude. So if we're bringing in a massive Azure, Google dependencies with our starter, but you want to actually get rid of a few of those, you can exclude those as well. It's very easy. It's just simple annotations in your class. And so with that, I'll hand over to Prasad and he's gonna go deeper with some demos and walk you through how we built these starters that an honor can take for the services. All right, can you all hear me? Great, thank you, Collins. So again, my name is Prasad Bhopadikar. I am a partner solution architect at Vivitel. And in the next 15 or 20 minutes or so, I'm gonna talk about these Spring Boot starters that our team has written, which, and we'll take a look at how they enable you to quickly build your Spring Boot applications, especially to consume all these cloud services, right? And again, to mention, this was a team effort. Our team actually worked on this. Colin, myself and a couple of more colleagues on our team, Matt Jeffries and Mike Goddard, who are not here at the conference. But yeah, it's been a solid team effort on our end to do this. So as far as the agenda goes, this is what we are gonna take a look at. We'll look at a quick look at the service brokers. This entire presentation is centered around the Cloud Foundry Service Brokers, right? So we'll get a good understanding of what the services, what are the services we are talking about here. We'll look at a couple of sample demo applications. These are apps that we have built, and they are gonna be part of the GitHub repository that you will all have access to. So you can build your client applications, model them after these sample apps. Later, we will take a quick look into the code itself and look at how the auto configuration dependency management is handled by the Spring Boot starters. And then in the end, time permitting will quickly run through the resources roadmap and do Q&A if possible. So before I get started, I saw a lot of hands go up when Colin asked who has used Spring Boot. So very good to know that you are all familiar with Spring Boot. Who has pushed an app into Cloud Foundry? Great, so you guys are not strangers to writing Spring Boot applications and pushing them into Cloud Foundry. Has anyone written any app and deployed it to Cloud Foundry that talks to any of the cloud services? Okay, so a few of you have done that. So here the idea is that we wanna enable you to do that very quickly and adopt some of the best standards there are, right? So I'm going to exit from this presentation mode here and I'm gonna open up my web browser and let's take a look at some of the services that we are talking about. So this is the operations manager. What we are looking at is an instance of PCF which is running on Microsoft Azure. And if you take a look at the right tile which says Azure Service Broker, this is the service broker which actually brings several of the Azure services into your Cloud Foundry marketplace. I switch just my view into the pivotal apps manager. What this is, is this is the console for the developers where devs get to see their apps. They can instantiate services and bind these service instances with their applications. So let's say if I'm a developer and if I have access to what we call as the marketplace. So in this marketplace, as you see, there are five Azure services that are listed here. DocumentDB, Redis Cache, Service Bus, SQL Database and Storage. These services, you are seeing them here in the marketplace because of that Azure Service Broker that we saw. That service broker is responsible for bringing these services into this Cloud Foundry marketplace. So similarly, just like this, I have another PCF instance here which is running on Google Cloud Platform and you see the GCP Service Broker tile and this one brings in these services into the marketplace which are seven Google Cloud Platform services, BigQuery, Bigtable, Cloud Storage, Cloud SQL, Machine Learning APIs, Popsub and a very recently added spanner into the mix. So with that GCP Service Broker, you have access to these services into your Cloud Foundry marketplace. And very similarly, there is a tile for, excuse me, the AWS Service Broker also and when you install that service broker, you get nine of the AWS first party services. So that's what the service broker does. It actually brings in all your services, the appropriate services into your Cloud Foundry marketplace. So you as a developer, it becomes extremely easy for you to just instantiate the services using simple CF commands and then bind them to your applications. Now, just one thing, I'm not going to explain how the service brokers work, but it's very important that you have a good understanding of it. There's very solid documentation in the Cloud Foundry website which I highly recommend that you check it out if you are not aware of the concept of how the service brokers work. So just another one very quick thing, as Colin very clearly mentioned, that the Azure and GCP Service Brokers are open source. So even though these consoles and dashboards you are looking at right now, they are specific to Pivotal's distribution of Cloud Foundry, you should be able to use the GCP and Azure Service Brokers. And also one thing to mention here is that the Azure Service Broker has been written and built by the Microsoft engineering team and also the corresponding GCP one written by the Google engineering team. So very solid work there by those guys. Great, so let's take a quick look at a couple of demo applications, right? Now these demo apps that we are going to look at are of course built using the Spring Boot starters and we'll take a quick look at a couple of them. So I'm going to go back into my dev console on the instance that is running on Azure and as a developer I'll go into my dev space here. So what we are looking at is an application which is deployed onto this Cloud Foundry instance which is called as Azure DocumentDB client and this is a Spring Boot application built using the starters. I'm going to click on this link that says service. You see there's one service instance which is here called My DocumentDB. This is an instance of the Azure DocumentDB service as you can see. I'm going to click on this and you see that it shows the bound apps. What this means is that that instance, My DocumentDB is bound to these apps and right now in this list we are seeing only one application which is my Azure DocumentDB client app which I show in the view of all the apps. So what this means is the developer instantiated the service and then bound it to its application and because of which now the developer is able to talk to that service, right? So I'm going to go ahead and run my application and before I run the app, I'll tell you that this is a very simple app. All it does is it provides a few crowd rest endpoints to create documents into the DocumentDB database. You can either create a document, delete a document, update a doc and things like that. So before I actually run the app, this is my Azure portal and as you can see in my document, there are like four documents right now in this database. So I'll go ahead and open up Postman to run this and I'm going to just invoke this simple slash write endpoint and pass a couple of parameters, their name and category. What it does, this app does is that it takes those values, creates a simple JSON document and writes it to the DocumentDB database. So I'm going to go ahead and click on Send. The doc got written here and if I refresh this view, as you can see that now we have five documents here. So it was a simple app that just wrote and a document into the DocumentDB database. Before I go into the code, I wanted to show you another app. So this app is a app which talks to the GCP cloud storage service. My app name is GCP cloud storage client and it is bound to this service, Google-storage.srvc, which is of the type of Google cloud storage. Again, very simple application. All it does is that it will read all my file names from a particular Google storage bucket or it can also upload files into it. So this is my GCP console and I think PB-bucket-1, this is the bucket in which I'm going to run this app to actually upload an image here. Okay, so let's come back here. So this is my, it's a simple post call. I come into the body, I'm gonna choose a file and let's say, let's choose this White House image and then if I go ahead and click on Send, I get back a true, I go back into this console if I refresh this page, as we see that this file got added. Very simple applications, nothing too magical about these but what the point I'm trying to illustrate here is that we use Spring Boot starters to write these apps and because of this a lot of, there was no need to write any of the boilerplate code and these apps were built extremely fast. So now before I go into the code, I wanted to open up the terminal and talk about what happens when you bind a service and what are the things that you as a developer would need to do to consume this service if you are not using these starters, right? So this is again, I am connected here to my PCF instance running on Azure and I do a CF apps, I see my apps and this is the app we saw from the console view. We also saw these services into the console view but what we did not see is the environment variables of this application. What happens when you bind a service instance to an application? The credentials associated with that service instance, they get injected in your application's environment variables. So if I run a CF ENV on this app, my Azure DocumentDB client and if I hit enter here, if we take a look at these vCAP services section, this shows all the credentials. These are all my DocumentDB, Azure DocumentDB service credentials, yeah. Okay, good enough? Okay, great. So these are the credentials, these are the vCAP services credentials that get injected into my application's environment when I bind that service instance to my app. Now think about it, if I'm a developer, I have these credentials, they are injected into my app's environment and I wanna write the app to talk to the DocumentDB service, right? So even before I get to the point where I can actually call the service, I need to use these credentials and execute of certain steps in my code to even get to that point, right? So that I can actually call these services. So what would those steps be? I'll go back into my slide deck here and these would be the steps that you would need to do as a developer. You would need to first of all write code to read all these properties from your vCAP services environment. You would need to add some JSON dependencies so that you can parse the JSON, the vCAP services JSON and extract the credentials that you would need to connect to the service, right? You would also need to add the dependencies for all the class libraries that are provided by your service provider, right? So Microsoft and Google and AWS, they have all provided the class libraries that you need to connect to these services. So you would need to add those in your dependencies and lastly you need to write the code to basically instantiates the appropriate beans. So for example, if I'm trying to call the Google Cloud Storage Service, I'll need an instance of com Google Cloud Storage Storage because that's the instance that actually is populated with the credentials. Similarly, I would need an instance of document client to be able to talk to the document client service, right? So the one big key takeaway that you wanna walk away from this presentation is that the Spring Boot starters eliminates the need for you to write this boilerplate code. So that's like, that's the one major key takeaway here is that. So when you write, when you have your dependencies added to your Spring Boot starters for that are written for Azure and GCP, you absolutely do not need to write this. You have these beans handed to you in your client application and then you just go from there, you start calling your services. So how does this work? So this is the dependency graph. Just like a very simple illustration of all the dependencies are managed here. At the bottom, you are seeing all the client apps. These are the apps that you would write. And then you would have a dependency defined in your class which says that your app depends on the Azure Spring Boot starter module which in turn depends on the Azure Spring Boot auto configure module. And that's the project where actually all the magic is happening. All the dependencies are managed there and all the instantiation of all the appropriate beans also happens in that project. And that's why you do not need to write any code to do that. Similarly, this is a very similar dependency graph for the GCP starters. So that's how it works. So I think it's time to dive into the code and let's take a look at how this works in the code. You're all developers here, right? So we wanna take a look at the code. So, okay, yeah, I'm trying to control shift. It is, is this visible? My control shift plus is not working. Oh, okay, great. How do you do that? Oh, control one, okay, great. Sweet. Okay, great. So this is my document DB client application, right? So in my have a class here, okay, which is, let me open up my, what's the view here? So where is my document DB DAO? All right, so this is my DAO class, right? This is where I actually make use of the document client bean, which actually caused the document DB service, right? So if you take a look, I have my document client being directly injected into the constructor. So I did not write any code in my client application whatsoever to instantiate this class, right? So how is this happening? So in the dependency graph, we saw that the client app depends on the Azure Auto Configure. So here's the Azure Auto Springwood Auto Configure project. Now, well, let's take a look at what magic is going on here. So if I scroll down and this under source main resources under meta inf, I have this file called spring factories. And in spring dot factories, I specify two properties here. One property is the environment post processor. And then the other one is the enable auto configuration. So think of these as just simple hooks that tell your application at the startup to instantiate certain beans. So what the environment post processor is, is that it is mapped over here to a class called vcap parser, which is specifically written for these Azure starters. So what the vcap parser does, and let me open the vcap parser here. So the vcap parser is the class that actually takes all the vcap services, credentials that we saw in the app's environment. So it will extract all these. It will do all the JSON dependency management and extraction parsing of the JSON to extract all the credentials. And then the next step is that the enable auto configuration. So there are different classes written for enabling the auto configuration for all the different services. So the one that is written for document DB will come into play here. It will take all the credentials that were extracted by the vcap parser and construct my document client bean, and which then get automatically, I can just as a developer inject, have it injected into my client application. It's very simple. There's not a whole lot of stuff that is going on here, but the benefit, the real benefit here is that it not only increases your efficiency as a developer, that you do not need to write the boilerplate code, but it also enforces you to adopt all these very good development patterns that are written by the experts in Spring Boot. So that's why adopting Spring Boot starters is of that much, it's a lot of benefit that comes with adopting the Spring Boot starters. So as far as the demo goes, that's pretty much there is, that you just have defined the dependencies and you have the beans created for you, and then you just use those to talk to your class. To your services rather. So going back into my presentation mode here. All right. All right, so let's quickly take a look at some of the resources that we've got for you. So the talk to links are the Azure and GCP starters. These are GitHub repositories that you will have full access to. I think at this point we have the Azure starters, which is already public. The GCP starters link is not public yet, but it will become public very soon. If you are looking for an open source option to consume AWS services, the AWS service broker mentioned there, that's a pretty good place to start. I think it offers three or four different AWS services currently, and last but not least, I initially mentioned that if you are not completely familiar with how the service brokers work in Cloud Foundry, there's some really good documentation on the Cloud Foundry website that I think you should refer to to get a good understanding of that. Roadmap, we have the Azure and GCP starters. We want to write starters for AWS also, and hopefully we will have them ready pretty soon. And but the main, the final ultimate goal for us as Colin mentioned is that we want to make these starters available on start.spring.io. That's where all the magic happens. So this is start.spring.io and if you have, who has used this? Okay, a lot of you are aware of this because you are Spring Boot developers. This is really awesome. You just come here and specify what dependencies you want in your class, in your project when you are building it. And you just define your dependencies here and you just click on the generate project button and in half a second you have a project that is bootstrap. It's such a quick way to get started with writing your applications, right? So what we want is our Azure and GCP and AWS starters to be available here. So a developer can just come here and type in, Azure and the starters would be available here. So you don't even need to get a handle of the GitHub repository in that case. But until that is available, the repo is available for you all and you could always use the repo for until this is available. And then some key takeaways here is our, you know, I'll say use Spring Boot. Most of you are already doing that. I just can't imagine a reason why anyone would not use Spring Boot. It's just mixing so fast and quick and you are always, you know that you are writing your code to the best of the standards. So always use Spring Boot. Spring, the service brokers use them. It's a very good way to consume all these cloud services. And these brokers are constantly evolving. So we are working with our partners to add more and more services into the brokers. So I just mentioned towards the beginning of my talk that Spanel was added into the GCP service broker recently. So, you know, I mean Spanel was announced and just within like a month or two, it was already there in the service broker. We are working with our friends at Microsoft to add more and more services into the Azure service brokers. So the brokers are evolving and they will continue to evolve. And you know, if you're writing apps to consume these cloud services, absolutely go ahead and use these starters, you know. So that's just gonna save you a lot of time. Just to add real quick, the starters and the code are open source. So the Azure repo that Prasad showed, if you go there, feedback, contributions, PRs, go for it, GCP will be the same, you know. We're planning to make sure that these are all open source and continuing to work with our partners, you know, at the cloud provider companies to carry these on and make sure that they're industrialized and kind of productized moving forward. Terrific, thanks, Colin. And lastly, you know, if you like spring, this is the conference you wanna be at. Absolutely, December 4th through 7th, this year later at the Moscone Center will be the spring one platform conference. And we are really hoping that by that time we make a lot more progress with the starters. All these starters are ready and up and available on start.spring.io by then so that we get a chance to, you know, talk about it again at that conference. That's the plan, we'll see how things go. But, you know, I think that's all I've got. Any, could we have time for Q&A? Any questions? We're around, so. Yeah. Yeah, yeah. Something like Azure Blob Storage or S3 or whatever is on Google. Like they're all similar sort of Blob storage but with different APIs. Is there anything that I can use to get a common API across some of those things that are similar on different platforms? So the question was, is there a common API to talk across those? I've seen some things that can help abstract that. There's effectively layered storage software to give you an S3 endpoint and then you can mediate behind that. I don't recall what it is off the top of my head but I think there's some things out there to help from that standpoint. Yeah, so as far as the service broker goes, the service broker comes into play only when you establish a contract with the service. So when your app is actually talking to the service, the service broker does not even come into play. So that's like, that's how the service broker and service connectivity from apps to, you know, in your Cloud Foundry apps to a service works. So now the service broker does not introduce any latency. All right, thanks everyone. Have a great day. Thank you.