Duration 28:21
16+
Play
Video

Building and managing APIs for serverless with Google Cloud

Chris Latimer
Software Engineer at Google
  • Video
  • Table of contents
  • Video
Google Cloud Next 2020
July 14, 2020, Online, San Francisco, CA, USA
Google Cloud Next 2020
Request Q&A
Video
Building and managing APIs for serverless with Google Cloud
Available
In cart
Free
Free
Free
Free
Free
Free
Free
Free
Add to favorites
4.72 K
I like 0
I dislike 0
Available
In cart
Free
Free
Free
Free
Free
Free
Free
Free
  • Description
  • Transcript
  • Discussion

About speaker

Chris Latimer
Software Engineer at Google

I turn problems into actionable solutions through an application of my diverse background and an ever growing wealth of solution driven knowledge. I am passionate about improving systems with both technological applications and data driven insights.

View the profile

About the talk

Serverless APIs enable developers and enterprises to scale data and services out of the box without the burden of managing infrastructure issues.

Learn how you can use Cloud Endpoints to do this today and get a sneak peek into how you’ll be able to do this in the future. This session includes a demo on how to build, publish, maintain, monitor, and secure a Serverless-based REST APIs.

Speaker: Chris Latimer

Watch more:

Google Cloud Next ’20: OnAir → https://goo.gle/next2020

Subscribe to the GCP Channel → https://goo.gle/GCP

#GoogleCloudNext

SVR215

product: Cloud Build, Cloud Run, Cloud Functions; fullname: Chris Latimer;

event: Google Cloud Next 2020; re_ty: Publish;

Share

I am Welcome to our session today. My name is Chris Latimer. I'm one of the product managers here at Google cloud. And today, I'm going to be talking to about building and managing apis for serverless with Google Cloud. They're going to be five, things are going to look at today. We're going to start off by looking at how we can build Services. We're going to use the cloud code plug in that. Juicy provides the developers to make it easy to get started. With gcp development, we're going to look at how we can deploy their services to Cloud run. And then, we're going to look at how we can

combine multiple Services together to form an API using gcps brand new API Gateway, which is just announced in beta. Luckily, I'm not a p, i created, we're going to see how we can secure that API and then finally, once everything's up and running, we're going to take a look at how we can monitor that API, using Cloud login and five monitoring. If anything is not working. The way we expect, we can get alerted to that. Fire. We're going to look at how we can build Services. We're going to use the cloud. Go plug in that comes with IntelliJ. Now, you can also use

visual coded if that's your, if that's your preferred IDE. Now there a few steps that I've already taken ahead of time. So I've already installed IntelliJ, I've already installed the cloud code plug-in. I also have been stalled doctor and the g-cloud clico. If you're going to follow along, you may want to do the same steps on your workstation. So let's jump to the demo and take a look at how we can build a service using to Paco plug in and then get that deploy to Papa. To get started in IntelliJ, we're going to select create a new project and we are going to select the cloud run

option that comes with the cloud code plug-in and I'm going to pick the Java version will give this a name will call it customers API and click finish. Once this is done, IntelliJ is going to look at the project structure. It's going to detect that we have Maven, pom file, We can add that Bond file and in switch this over to a maven project. Now inside of IntelliJ, that's going to give us all the standard Maven features that we want. If we take a look over at the code baseball, see that within the file system, the cloud cover. Plugin has given us a good starting

point. It gives us a spring boot app that will run right out of the box. So if I can figure my SDK and tell IntelliJ, want to use job 11. I can then click over here on this spring Boot and select the spring boot. Run option. This is going to start my application locally and so after a few seconds, this is going to come up. And it's going to start successfully and we can verify that by looking over here at the log messages that are printed with the console. we say that it successfully starting now, listening accepting traffic

If I come into my browser now and I hit localhost 8080, we can see that this app is in fact running. So right out of the box, we can get a web application working. But what we really want is we want to make her service that we can deploy to Cloud run. And so, rather than walk, you through the individual steps of how to create an API inside of spring boot, which is well, documented Elsewhere on the internet. I have already pre-configured this in my get repository. So I'm going to start off by checking out a tag here called basic API and then once I do this we can go

back into the IDE in here. If we look at the file system, we're going to see. Now that instead of the web app, we have a controller and entity in a service inside the controller. You can see this is a r s controller, it has a single mapping 2 /. And the way that we are going to process these incoming request is we're going to use a service call customer service. Looking inside here, this is just a mock service. I don't have a database behind here but it is going to populate a list of entities. A list of interviews. Customer that has a number of different fields associated with it.

We can now run this the same way that we did before. So we'll use the spring boot plug-in use the Run Target again. We're going to see messages printed out here to the console and after a few seconds we're going to see one that says that our app is started successfully. And we looks brought her here to the right, we do see that same message. So once that started, we can come now over and to the terminal window and let's issue a curl command on localhost 8080, we can pretty princess Jason with a python Json tool.

And there we go. Our API is successfully now running locally here on my work station now we're ready to deploy our microservice into Cloud runs. It was quick on Eddie configurations up here. This is going to bring up a form. That comes with Cloud code, we can pick our to city project. We can pick our region that we want to deploy our service into we can select the service name and then whether we want to have authentication or not this case we do. So it's like that last thing we need to specify is where we should upload. This container image, this case we're going to use the Google container

registry. So we'll give it a name here of customers API and note that my project is also testified here. Also important to note that I've already pre and nabal the Google container registry on my project before I started this demo so that you make it an air if you tried to upload this and you haven't been able that service at your project. Now, let's go ahead and save our configuration here and now let's run it. So as this run, it's essentially going to do all the steps that we need to actually get our container up and running on cloud run. So it's going to build a container

locally. It's going to interact with GCR. It's going to create the necessary tags that it needs. If it finds the container and the cash, it's not going to rebuild it and then is ultimately going to deploy this to Cloud run. And after a few seconds here, we should see is that it'll come back and say it's the parade. Now accepting traffic in. Traffic is going to be accessible via that you are all that you see right here. Now, remember we secure this API and so we come back to the terminal window and we try to crawl that URL. We're going to get a message saying that your client does not have

permissions to the make this call, and that was back here on this configuration where we said, require authentication. If we had said, LOL, I'm not going to cater connections. Then we would have been able to access the safety. I just fine as is, but we really want the gateway to be that entry point into our API. So we wanted to say, we want to tell Cloud, run to authenticate these requests. So they're all of our clients have to come to the Gateway in. The only authenticated client is going to be able to call in to our Cloud. Run back in directly is going to be the Gateway. So we see that

the API has been deployed. We can hit it here locally using curl, but let's jump over to Cloud console and just verify that everything was fine. There will navigate down to Cloud run. And just as expected, we see the customer API deploy green check mark next to it. Everything is looking good here. So let's jump back into the presentation and recap what we've seen so far. Alright. So coming back from the demo. Let's take a look at what we just saw the birthday. We saw is how to get started using the cloud code plug in this set up a nice work space for a sakes at our file system up. So

that we had all of the pieces that we needed to start building our actual service that were interested in. We took that initial starting point and we use it to create a nice restful service using spring Boot and then once we were satisfied at, that was running locally the way that we wanted. We can figure the IDE to deploy that into Cloud on. Once I was there, we saw that the deployment work successfully and now we have our service up and running exactly as we hoped it would, And so clearly this is what our cloud and since looks like we have a single customer API

that's running and Cloud run. And if we wanted to, we could have a client make calls directly to this this service. And if all we had was a single service in a single client, this is not such a bad option. We could create a service account we could give that service account before they can make calls and everything would work you know pretty pretty good. The problem this going to happen is that as we start adding more and more services, we're putting more of a burden on our client. They're going to have to remember which service is responsible for which piece of functionality. They're

going to have to route to the right place each time and that can be inconvenient. It can also be inconvenient for us as the API providers because now we have to think about who we're going to break whenever we make a change, what would be better is if we could put a single API facade in front of the services. So that for our clients, we can give them one consistent interface. If they can use, and we can insulate ourselves from their clients. We have flexibility to scale on deploy and make changes to our back in services without wearing that. Clients are going to need to change. So let's jump

into my next demo and take a look at how we can use service DeSoto deployed on to call run, put an API Gateway in front of those to create one consistent API facade for our clients. Let's jump back into the cloud console here in. Navigate to Cloud, run on the presentation, we want to be able to have an API Gateway. This going to sit in front of multiple services so that our API clients don't have to worry about which service to Route. Which request do we just want them to have one nice API facade that they can call into and we want API Gateway to handle? Both, the

security on that API is what was the routing so that we send those requests to the right service on the backend to configure API. Gateway, we need to have an open API specifications file, and it needs to have all of the resources in our API. So in this case, you can see that we have a customer is resource and accounts resource and an orders resource. Once we have that set up, we need to configure the value for host. Now, this may be a little bit surprising. If you're, if you're used to using an open API, the value that we're going to put here in the host field, is going to be a

combination. Of the identifier that we want to use for the API here, in this field called a PID, as well as our project. And this is going to conform to the standards service naming structure that's used within Google. So for right now, just think about this, as this is just a format that you have to follow. Don't think too much about why this format is the way it is, this is just the way that API Gateway gets configured. And then, here on the title field, we want to put in that same a PID and we'll see. And later steps that we're going to the Des value that we put in

for title is going to show up when we go to create an API key. And when we go to restrict that key to only be able to call certain services, Once we have hosting title, configure, the next thing to do is to add in routing instructions for API Gateway. So for each of these resources, were going to use the X Google back in the sea here, and we're going to put in an address to correspond to the correct service. That's running and Cloud runs over example for the customers resource, we want to go out to the customer service. So how do we do that? First thing that we have to know? Is the address

for each of our services on cloud run. And so, to find the address, we want to route to, we can navigate back to Cloud console and find the service that were interested in. And if we click on the service is going to bring us to a more detailed you, and you can see that right up here, we have the address where the service is accessible and we can copy this to our board. And then we will jump back to the IDE and back to our open API specification. And then here on the address field will just simply paste this in. So here's our our address for the customer

service is currently running on cloud Run. Next will do that. Exact same thing. For the account Epi we will grab its yarel from cloud, run will come back to the ID and place that value in the address field here. Then we'll go back to the clock out. So again this time grabbing our orders API, copy the application for the service, And just like, before will paste that into the address field here. At this point are open API, specifications is ready to go and we can use this to create a new API inside of API Gateway to do that. We're going to go to Cloud console. We're

going to get navigate down to the API Gateway option. Ever going to click on create API, Here, we're going to give our API display name will call it eCommerce EPI, and we need to use the same API ID here that we used in our open API specifications. So we called an e-commerce there. We need to make sure we call it Ecommerce here, as well as this stuff takes a little while to complete at usually one to two minutes or so for it to get done and then, once it does wrap up, already been to upload are open API specifications. We just created so quick on browse will

find the file in our file system. And once we do, will select that open avi file, and then we'll give our configuration here at display name. This will just show up on the list when we go to the UI and then we're going to Selective Service account that we want to use to connect to that back in to the cloud run services that we are routing to. Turkey and the stuff is going to take you know, around 30 seconds or so to complete. And then once this wraps up will be able to deploy our new API config to an API Gateway.

So, just like before, we're going to give our API Gateway at this plane in and call it the Commerce API Gateway and pick a location will use you as Central. That's where all of our Cloud run services, are deployed, quickly, 8. And there we go, it's created. I can now click on this API and if I do, I'll see that. I have a Gateway associated with us. It's a Floyd, and this Gateway is accepting traffic at the u r l e, c e, listed under Gateway. You are out here. Now, I can take this URL, I can go to my browser and I could just simply issue a request and I'll call the Gateway URL, / customers

and Wallah. There we go. We get our data back from our customers API. So now, let's jump back into slides and let's recap what we saw in this demo, All right, so what are we seeing that demo? Well, we started off with our open API specification and we started off by defining all the resources that are apis been exposed to the clients, and then, we can figure the API Gateway with the parameters that API Gateway needs. And that was really are a p. I d r title and our project ID. And then finally, we updated, each other's resources to point to the correct service on cloud run. So that when an API

call comes in, as going to be routed to the right place. Once we had our open API spec. All ready to go. We went back into Pantheon and we can figure out API Gateway. Now he's all that there were a few steps that we went through. And one. Says, we uploaded are open API specification and we created an API config. And in the demo, we just created one and we took that one API configuration and we deployed it directly to the Gateway, but a plist actually have multiple configurations associated with them. In this could be pretty useful for a number of use cases, if

you're doing something like API, versioning, or your building on St. I'll see you, maybe you're going to have a different configuration and your test versus dad versus Pradhan, but maybe I can figs can help you to solve these cases. And right now after our demo, this is what our environment looks like. We have three different services that are running on South run. We have an API Gateway Now with an API called e-commerce, that's running those services. And then our clients will now have a consistent interface that they can call into to access any pieces of those services that are

running In Crowd rotten. I was just one problem that that if he Eyes Wide Open to the Internet. So anyone at this point can make a call to wear API and it's going to respond with data. And what we'd like to do is we'd like to put in place of security so that not just anybody can call and or API but only plans that we authorize. And so why don't we jump back in the demo? And look at how we can use API Gateway to add API, key security to provide a more secure API for appliance The configure API security. We're going to come back to our open API specifications. As you can see, I

have a new security definition that I've already added. It has a type of API key and has a name of key, and it hasn't in value of query. So what this means is that I'm going to look for an API key. I'm going to look for a query parameter called key, and that's what I'm going to interpret as the API key. Now, I need to then go to each individual resource and I need to add in a security definition and I'm going to just simply reference that API key that I had in the security definition of above. And what this is going to do is it going to then require any incoming API calls to either

provide a valid API key, that's been authorized to use this resource or else is going to reject the call. Now that we can figure security within our open API specifications, we can come back here to the cloud console and we can find the same e-commerce API in the same API. Gateway that we created in the previous day and we need to create a new API configuration. So to do that, let's go to the config tab that you see here and we're going to click on upload config just like we did in the last time I were going to cook on brown house. We're going to find that open API specifications.

That we just created with our security definitions in it. We're going to select that file and upload it. Now will give it a new display name here as well. We'll call this one eCommerce, secure config, and then just like before, we're going to select the service account that we're going to use to authenticate the calls to Cloud run. We'll take the same Gateway. We could have created a new Gateway here as well, but we're going to just override the config that was deployed to that existing Gateway. And we will wait for around 30 seconds or so, while our configuration is uploaded

and deploy to that new Gateway. And after patiently waiting for a few seconds here, we will see that this step will complete successfully as soon as the step wraps up, our configuration is live and just a ploy to our API Gateway. So just like we did in the last until we can come back over here to our browser window and we can issue a request for Gateway URL, / customers. But this time, we're going to get a different response. Last time, we got back data, we got that customer data. This time, we're getting back an error message saying, hey, this apis expecting you to provide an

API key, but you didn't provide one. So now is take a look at what we need to do, to get Bali credentials that we can call this a p. I If you recall, when we are very first setting up our open API specifications. I said we're going to use this API ID and we're going to put that idea into the title field. So let me show you exactly how that title value. Is going to be important to API consumers. Before we can get a valid key to color API. We need to enable this API within our project. And we were going to do that for going to come here to the apis and services dashboard click

on enable, apis and services in that title, that e-commerce titles over going to search for. And that's the API that were going to find right here. And once this pops up, we can click on enable. Going to take a few seconds going to say, this is not a Google API and give you a little warning there, but after a few seconds it's going to then be enabled on our project. And once it is, we can then navigate over to the apis and services credential section. And we can create a new credential, on this case, it's going to be an API key

that he's created. And then we're going to want to restrict it. Otherwise, it's going to give us access to everything. Once we click on restrict key, we're going to see a list of services. We can select from now because we enabled the e-commerce API, we're going to see e-commerce and that list. And now this key that were generating is only going to be good for making calls to our e-commerce API. Now, we can quick here and we can copy your key to a clipboard, and then we'll jump back to the browser where we had the air before, it was put in a query parameter, called T, equals API

key. And there we go. Now, we're getting back data. Instead of the air, rapi secured, we have a way to get credentials in a way to get access to our API. Cinepolis jump back into slides and let's recap what we did, and what we saw in this dinner, All right, so great. We've set up our API Gateway. We have configured it to point to our Cloud around services and now we've added Security on top of it. So we're done right? Well in a sense. Yes. But if this were real production API is, you know, we're going to have to actually operate and maintain and manage this thing in a big part of that is

going to be monitoring our API to make sure that it's working the way we expect. So why don't we jump into an external now? And take a look at how we can use cloud login file monitoring to set up an alert. So there's something's going wrong with her. A PR, it will get alerted about it. Or I'll ask him, but we're going to take a look at how we might monitor apis. So to do that, we're going to come down here to the operation section of the cloud console menu pick monitoring and then alerting underneath the monitoring menu. Just got off, work going to create a new policy and let's talk a little

bit about what types of things we might want to monitor. We might want to look at things like air rates that are creeping up too high. We might want to look at the amount of traffic that's coming through our API or in this case, we're going to show is how we can monitor the back and latency and get alerted. If all of a sudden are back in for API, is taking longer to respond in a specific threshold. Let's start by giving our alerting policy a name. We're going to call it slow back ends and then we're going to add a condition. First thing we need to do is to find the rate resource

that we want to monitor. Now for API Gateway, all of the resources and metrics that we're going to report are going to be underneath that produced API resource. So that's what we're going to select here for our first condition. Once we've selected that resource, we can pick from a number of metrics. In this case, we're going to pick request back in latency from here. We need to select the aggregator how we can look at things here. Like the 50th percentile 95th percentile. In this case, I'm going to pick the 99th percentile because I want to understand what the worst latency. The consumers are

experiencing And then the last and they're going to need to do under configuration is to set up threshold. I'm going to set up pretty low just to 10 milliseconds just to make sure it's going to be easy for us to trigger this alert and we can verify that it's working. And then the very last thing we'll do is we'll just click on ADD and then that will bring us back to our main create alerting policy form here. And the next thing we're going to need to do is to set up a notification Channel. We have different types that we can choose from. I'm just going to do a very simple, notification

panel here to email and I'm going to enter my own email address in here. Put on ad and then that's going to be it. We could have documentation if we want but I'm just going to click on Save and now at this point, our alert is created and our next step is going to be to start generating some traffic to see if we can trigger this alert and make sure that we're getting an email if our latency start to creep up. So all we have to do to generate load, let's just come back over to the browser we were using before and we're just going to start hitting

our back end, was just a whole bunch of API calls will just keep smashing, the refresh button and send me those API calls and hopefully that will be enough to trigger an alert here before too long. If we go back to the monitoring you I now and refresh we should see a new alert that's popped up and we do if we click on this will be able to get some details about the alert. Exactly what happened. What was the latency that we were seeing verify that it did exceed the threshold and then if I go to my inbox I'll also see that I did get notified about this alert being triggered. And now, if

I were the person responsible for monitoring this API and operating the safety, I, I can go dig into this and figure out what's going on. And we could take corrective action to make sure that we correct any problems that are occurring. Hopefully, this gives you a good idea for how you can set up monitoring and alerting for apis that are managed by API Gateway. And without, let's jump back into slide and recap. What we saw out here in this demo. All right, so now we've seen how to build apis. We've seen how to secure those apis. And now we've seen how to monitor those apis and make sure

that we're going to get an alert if anything's not working correctly. So, we hope that through this tunnel in the presentation. You got a taste for what you can do, with our new API Gateway products, which you can we just recently announced in beta. I wanted to spend a little bit of time, talking to you about the things that we have on our road map. And where we see this product coming over the coming months. So, the first thing to talk about is API Gateway and how we see the surveying Giuseppe customers, if you are, someone who's building web apps, your building mobile apps are multi

experience apps that are using apis on gcp. We really want to make that process a lot easier for you. I'm not only just routing to things like server list but also help you compose apis. So if you have data that big boiler, you have data that is running on serverless Or Nah, Cerberus compute, maybe even date of this in your data centers. Do you want to connect to be a VPC? We want to make that process is extremely Easy for you, if you're building out apps that need us indication, if you want to use things like Google class identity platform, we're working closely with those teams to bring you

some Lucien. That's going to make it much, much easier to build this applications on top of Google Cloud. Now, it's specifically in our short-term, we have a few enhancements, I'd like to make you aware of. We had an overwhelming amount of demand for open API, V3 support and we've heard you loud and clear. Our team is working hard to implement open API, V3 for API Gateway. We're stuck in the house. Something out for you in the very, very first part of 2021. We're also working to integrate with a Google Cloud load balancer and that's going to do a couple things that's going to give you the

ability to configure integration with products such as Cloud armor. So if you need DDOS protection, you need. 10, protection. IP filtering and so forth. Going to be a great solution for you as well as integration with our Cloud. CDN 444 cashing his responses, For those of you that are more interested in full lifecycle API management, we're working really closely with the apogee team as well to bring you any gratien with Ava G features such as API products and apple juice developer portals. So, on behalf of the entire team here at gcp, especially the serverless team, the apogee team

and the API Gateway team. We are so thankful for you taking the time to watch our session here today. And we really look forward to getting your feedback on the product. Thank you so much.

Cackle comments for the website

Buy this talk

Access to the talk “Building and managing APIs for serverless with Google Cloud”
Available
In cart
Free
Free
Free
Free
Free
Free
Free
Free

Ticket

Get access to all videos “Google Cloud Next 2020”
Available
In cart
Free
Free
Free
Free
Free
Free
Free
Free
Ticket

Similar talks

Seth Vargo
Senior Staff Engineer at Google
Available
In cart
Free
Free
Free
Free
Free
Free
Free
Free
Sarah D'Angelo
UX Researcher at Google
+ 1 speaker
Ivan Portyankin
Software Engineer at Google
+ 1 speaker
Available
In cart
Free
Free
Free
Free
Free
Free
Free
Free
Dino Chiesa
Solutions Architect at Google
+ 1 speaker
Terry Wang
Principal Engineer at T-Mobile
+ 1 speaker
Available
In cart
Free
Free
Free
Free
Free
Free
Free
Free

Buy this video

Video

Access to the talk “Building and managing APIs for serverless with Google Cloud”
Available
In cart
Free
Free
Free
Free
Free
Free
Free
Free

Conference Cast

With ConferenceCast.tv, you get access to our library of the world's best conference talks.

Conference Cast
635 conferences
26170 speakers
9693 hours of content