Hey, everyone. Thanks for coming. I'm Dustin. DICodes on Twitter. I work at Google. I'm a developer advocate. So I lead all of our Python advocacy across all of Google Cloud and all of our products.

And everyone that touches Python, which is kind of all of our products. So really, for me, this Venn diagram between Google Cloud and Python actually kind of looks like this. There's a lot of overlap. Quick disclaimer. This is a sponsored talk. So Google is the sponsor of this conference. And in exchange for that, we got this talk slot. Sub-disclaimer, I'm not here to sell you anything.

Kind of the point of advocacy is that I want to understand what you, the users, or potential users, want out of Google Cloud. If you're not already using Google Cloud, I actually don't really care. I am not trying to make you buy it or convince you that you should. But I do want you to know what we have, what's available.

And then if you are a user, I want you to know, hey, maybe we just added this new thing. It's really cool in Python. Or I just want to hear from you. So the timeline for this talk is going to kind of look like this. I'm going to talk a little bit about our serverless runtime. So these are the kind of the places where you can take Python code and run it on Google Cloud. Usually these are web applications and things like that.

I'm going to talk a little bit about our services and client libraries. So these are all of our PIP installable libraries and APIs that you can interact with from Python. And then I'm going to leave a chunk of time for Q&A too. So a lot of people have sort of questions about maybe if you've not used Google Cloud before, what you might do to get started

or what you can do with Python there. And if I haven't answered that in the first two things, then you can ask me questions afterwards. So first let's talk about serverless runtimes. And before I talk about serverless runtimes, I want to talk a little bit about what serverless actually is. So we'll talk about the very first serverless Python platform. We'll just sort of try to define serverless.

I'll talk about our new and shiny runtimes on Cloud Platform. And I'll talk about what I think the future of serverless is. So the first serverless Python platform. Does anyone recognize this logo? App Engine, yes. So this is the original App Engine logo, Google App Engine. And it was released in 2008.

This was the blog post that announced it. And it was very exciting at the time because there wasn't really an existing environment where you could deploy Python code. This is sort of the first place where you could take Python. So App Engine in 2008 kind of looked like this. It had dynamic web serving, persistent storage, automatic scaling and load bouncing,

which is kind of one of the things we think of as serverless today. And it had all these very special Google APIs for doing things like authenticating your users, sending email and stuff like that. And it had a fully featured local development environment. People were really excited about App Engine. So I like to go back in time and look at the tweets of people talking about stuff like this.

So this person, they said it's easy to start, easy to scale. I was very excited about it. This is from 2008. This person, they asked what their opinion is on App Engine. They said, cloud computing is like a huge smoothie with many straws. The smoothie is Google App Engine and I'm drinking that shit. This person said, depending on how long will be the only supported language for App Engine,

Python might finally get its day in the mainstream sun. So this is kind of funny looking back from 2008 or from now at 2008 saying, oh yeah, of course, like Python now is one of our most mainstream languages and especially on a cloud platform, it's one of our highest priority languages. At the time, Python was like not mainstream. It was kind of a funny choice for App Engine to pick Python.

And I don't know if it was really a gamble, but it was a good bet. It ended up being a good choice. And so it was a good thing for App Engine, it was a good thing for Python as well. Not the reason why Python's successful obviously, but it didn't hurt. So here's the question, was this actually serverless?

So let's see what serverless is. This person thinks serverless is server as a service. So you don't have to think about your server, you just get it when you need it. Serverless is serverless in the same way that a beef burger is vegetarian because you didn't personally see the cow being killed. So you don't have to think about managing provisioning physical hardware, right? This is a serverless, so it's kind of like,

you're abstracted away from it. Serverless is someone else's responsible for these computers going down, right? If something goes down in a serverless environment, it's not your problem, it's Google's problem, right? Or it's Azure's problem or it's AWS's problem. Serverless is one too many layers of extraction from where I sit for me to actually understand it other than as a gateway drug to the cloud.

And that's definitely true too. Serverless has been, I think for most users, a lot easier to get started with and helps them scale up from nothing to something significant pretty easily and quickly as well. So at Google, we have sort of some principles that we think of as representing serverless. And this is when we build what we call a serverless product, they have these things generally.

So zero server management, if you don't want to configure your instances, you don't have to. There's no upfront provisioning. Generally, you get auto scaling to meet demands and this means potentially even down to zero. So if your web app isn't getting any traffic, you're not paying for anything because it's not doing anything because you don't have any instances. That's great because it makes it really cheap.

And again, you only pay for the resources you use, so you're not paying for a VM that's up and running constantly to handle the peak load that you only experience once a day. And the focus is generally just on writing code and not having to write long YAML files or configuration files or anything like that. So App Engine is probably like our obviously

first serverless language and probably it still exists and has gone through a couple iterations since then and is fully serverless today, right? So we have a bunch of more languages besides Python now. So we have JavaScript and Go and Ruby and all those. And the focus is just code.

You only pay for what you use. It's in a bunch of regions all across the world. And yeah, that's pretty much it for App Engine. And I'll show a little bit of demo of each of these later as we go through too. Cloud Functions is somewhat similar to App Engine, also serverless, but the idea is to build small composable functions. And you're probably familiar with AWS Lambda, et cetera.

So these are generally event driven. So they're gonna respond to either an HTTP request or some action that's happening, like you put an image in a cloud storage bucket. And so it lets you write like a little Python function that responds to those events. Cloud Functions are also around the world. And actually the thing I like to say

about the availability zones, even though you can only launch them in certain zones, if you're interested in latency, when you hit a Cloud Function, you're actually getting on the Google network as quickly as you can and traveling internally. So it's actually like, zones are not quite as important if you're concerned yourself with latency.

Cloud Functions has a free tier, which is awesome. You get to do 2 million function invocations per month. You can run a million seconds per month of compute time. And you can do up to five gigabytes of egress traffic. All right, let's talk about some new and shiny runtimes for these serverless products. So in Cloud Functions, we have a Python 3.7 runtime.

It is the only Python runtime available for Cloud Functions. And it's really exciting because the way that we built it allows us to add more Python runtimes as new versions of Python are released. So when 3.8 comes out in October, pretty soon afterwards, we should have a Python 3.8 runtime. So you can really easily, you're not forced into a certain version of Python

if you, well, besides 3.7 and 3.8, you can't go older. But yeah, you have some flexibility there and it happens pretty quickly in relation to what the community is doing. This is sort of a rough timeline. So it gives you an idea of how quickly we went from the release of 3.7 to the 3.7 runtime in Cloud Functions. And yeah, it's generally available now,

which means, you know, please go ahead and use it in production. And so this is what a Cloud Function looks like. It looks just like a regular Python function. There's really actually no difference here. Totally valid Python function. The thing that makes it a Cloud Function is that it has a single parameter called request. So this is a HTTP function. So it's gonna receive a request from the web

and that's all you have to write. Like this, it deployed to Cloud Functions, will give you an endpoint that you can hit and it will respond with this value. That's it. There's nothing else you have to do, which is pretty awesome. And it's pretty powerful when you want it to do more than this as well. You can just continue writing your function. If you want, you can also include dependencies.

So the original App Engine was a little bit weird with the way it handled dependencies. With Cloud Functions, it's totally idiomatic. If you've used requirements.txt file before, it's the exact same thing, exact same syntax. It actually just gets installed with pip anyway. So you can specify all your dependencies, pin them to versions and all that stuff as well.

So we also have a Python 3.7 runtime for App Engine. And that's really exciting as well because in the same way for Cloud Functions, we have a 3.7 runtime and we plan to have a 3.8 runtime, we'll do the same for App Engine as well. So timeline kind of looks like this. So way back when we first launched with the 2.7 runtime, that was the original App Engine was Python 2.

Now we have a 3.0 runtime in 2018. We're moving pretty quickly with the new betas. And it's also generally available. So you can use it now in production. And this is what an App Engine app looks like. This is just a Flask app. If you've used Flask before, you can just write a Flask app, as long as it uses WSGI, which Flask, Django,

all of Pyramid, all those other ones do, all those web frameworks. You can use any of them and just deploy it to App Engine. So yeah, this is Flask. And it does the same thing our Cloud Function does, but allows us to define the app and have a little more control over what's happening there and have multiple endpoints if we need it as well. So there is one thing you have to configure

with App Engine. Like I said, the original runtime was Python 2. And that's the default, unfortunately, right now. If you want to use Python 3, you have to tell us you want to use the Python 3 runtime. So there's one line, app.em, only to say runtime Python 3.7. If you want, you can do more customization. So if you didn't want to use G Unicorn,

which is what we use by default for the HTTP server, you can use anything you want. So really, actually, any command that you want, you can kick off and run Azure Entry Point into your web application. And again, just like Cloud Functions, idiomatic requirements. So you can specify these the same way that you do on Heroku or anywhere else.

All right, let's talk a little bit about the future of serverless. So where are we gonna go from what we have right now? And I'm not just talking about Google Cloud, but all the other serverless providers as well. More tweets. Serverless is really only useful in niche areas. That's true if you accept that one of those niches is called the future and includes pretty much all of it.

That's definitely true. One trend that we see a lot at Google is that more and more and more of our customers want to shift from VMs and physical hardware into more serverless runtimes. Kelsey says, final thought. Serverless is dope. Let's eliminate language runtime restrictions so more people can benefit. Container images might help. So Kelsey said this in 2017,

and he had the benefit of kind of knowing that we were about to launch a product that basically did exactly this. So if the Python runtime is not enough for you, if you need to be able to install some special Debian package or some special platform library or something like that that isn't available in the runtime that we provide,

up until this point, you couldn't do anything about that. But with our latest product, which is called Cloud Run, you can. The Cloud Run is very simple. All it is is hosted Docker containers. So you define a Docker file, you build a Docker container, or we could build it for you, and then you deploy it. And as long as it listens on the port

that we ask it to listen on and sets up a web server that can respond to traffic, you can do anything you want. You can install anything you want. Anything that is a valid Docker container can be deployed to Cloud Run. And it's really powerful because it really lets you do anything, and you can inherit from any image on Docker Hub, anything that you want to do.

Yeah, totally stateless HTTP containers. So this is like the simplest possible Docker file. We're gonna just inherit from Python 3.7. We define a directory for our application, we install some requirements, and then we start pythonapp.py, we just start it up. And that's it, that's all you have to do to define the Docker container which runs a Python app.

The contract is kinda like this. All you have to do is listen for requests on localhost, on the port defined by the environmental variable port, start an HTTP server in four minutes, that's all the time you have, and that's it. That's all you have to do. And the entirety of everything else that happens in the container is up to you.

Cloud Run also has a free tier. So again, two million invocations or requests per month. You get 180,000 seconds of compute time. And right now, because it's actually in beta, you have infinite gigabytes of egress traffic. So if you wanna go do something crazy on Cloud Run right now, send a lot of traffic somewhere, you can go nuts.

There will be eventually a free tier limit on that, but right now it's just figuring it out. So to sort of summarize Cloud Run, this is what it says in the docs. Your container image can run code written in the programming language of your choice and use any base image, provided that it respects the constraints listed on this page. And so when I first saw this,

when I first saw Cloud Run and I read this, I didn't see this as like the container contract. I saw this as a challenge. I was like, really? You can run any programming language. You can do any base image that you want. Like what's the most ridiculous thing that I could run on Cloud Run? And so I thought, what if I got like a really super old version

of Python working and created like the first serverless Python runtime? Maybe I could do this. So I went to python.org. I went to the download section. I scrolled to the bottom of all the releases and I went to view older releases. I went back in time even more and went on even older source releases.

I went to this page, which is at legacy.python.org, which is extra old, scrolled to the bottom of that and found the original source for Python 1.0.1. I created a Docker container, which compiled it. And amazingly, Python 1.0.1, which was released in 1994, compiles on a modern version of Ubuntu

with a small patch. So I had to change a couple lines to get it to work. And then I had a Docker container that had Python 1.0.1 installed on it. So I could, I couldn't run Python double dash version because that didn't exist yet. But I could run Python and I got a REPL. And you can see that it was copyright 1991, 1994.

But unfortunately, Python 1.0.1, there wasn't an HTTP service or server container or a module, sorry. So I decided that I needed to go forward just a little bit in time to Python, where is it? One point, yeah, 1.3. Did the same thing, made a Docker container, compiled Python 1.3 inside of it.

Again, just a small patch to get it to work. And then again, I had a Docker container. Still couldn't run Python double dash version, but when I ran the REPL, I could import HTTP server. So then I wrote this, which if you kind of squint at it, it looks like that flask app I showed before, but this is like an HTTP server that says hello world from Python plus the current version of Python

in like the oldest possible HTTP server that was available in Python. And then it kicks off the server. So I created a Docker image. So these exist on Docker Hub, vintage Python. You can run Python 0.1, 1.1, 1.2, 1.3. So I inherited from that.

I started my app. This is the same Docker file I showed before. That's it, just those two files. Built the Docker container, did some stuff, deployed it with gcloud beta run deploy. And then I had this, hello from Python 1.3. So I handled my web request through Cloud Run,

no problem at all. So this is, and then I tweeted about it because this is very silly and why would anyone actually ever want to use Python 1.3 in a serverless runtime? But it kind of shows the power of Cloud Run. Like you actually, anything that you want to do, you can build a container. As long as you can build a container, you can do it. And it's funny because after I did this, a bunch of people were like, well, I can do one better.

And then people were making Fortran runtimes and COBOL runtimes and all sorts of ridiculous things. So if you want to read more about that, here's some links there. So there are a few things I didn't cover right now. So some of them are Compute Engine, App Engine Flex. So these are more sort of VM-based runtimes

that aren't serverless. And I didn't cover them here because they've been around for a while and you might have already heard of them. I didn't cover App Engine first generation necessarily because that's Python 2.7 and it's gonna go away soon. Not App Engine itself, but Python 2.7 is quickly coming to end of life.

And I didn't cover Kubernetes Engine or Cloud Run on GKE. So you can also run Cloud Run on Kubernetes Engine. And if you're interested, Kubernetes Engine and GKE could also talk about that with me afterwards. But since they don't really offer a Python runtime, I just, I didn't really bring them up here. All right, services and client libraries. So I'm gonna just run through these real quick. These are some sort of the fun and interesting things

you can do from Python using our APIs and services. So we have a lot of Python client libraries. They're all on PyPI, so you can install all of them. And so they sort of fall into a couple categories like compute, storage, big data, machine learning, et cetera. Yeah, so storage and databases, these are some of the products

that fall under that category. Big data is like BigQuery. Machine learning, this is all of our translation, text-to-speech, speech-to-text, et cetera. Management is kind of boring billing and deployment manager and stuff like that. Identity and security, and yeah. So I'm talking about storage, machine learning, big data and management.

So some of the storage types that you can deploy on Google Cloud. You can either deploy a file, a whole database, or sort of something that we consider big data, which is lots of like semi-structured data. Not quite a database, not quite a file. So Cloud Storage is our solution for file storage. It's kind of like S3. So you can just upload basically any binary blob from Python

and put it in a storage bucket. It also has triggers for Cloud Functions. So when you put something in a bucket, you can make something happen in Cloud Functions, and all of that can just be done in Python. And so here's an example where you put an image in a bucket and it automatically will create a thumbnail with a wand. For machine learning,

we have the Cloud Natural Language API. So this lets you do things like analyze sentiment and find entities in text. So this takes a sentence, Mona said that jogging is very fun, and determine that it has positive sentiment and that entities in are Mona and jogging. So you can use this to sort of break apart what natural language is talking about.

We also have Cloud Vision. This one's pretty fun. So you can send it an image. So here I sent an image of a cat, wakeupcat.jpg, and it correctly told me that it's a cat, photo caption, all that fun stuff. It'll do automatic analysis of what is in the image and the likelihood of each of those things. There's also translation. Same thing that we use for Google Translate.

You can take a language, this is not a pipe, and get to see this awesome pipe. Translate to any language that you want that's supported by the API. All from Python. Big data. So again, BigQuery's the big one here. BigQuery has a great UI and you can directly operate on BigQuery

with the syntax there. But you can also do it from Python. So you can write a query in Python and submit it and iterate over the rows that you get back. Super easy to use. Also, fun fact, if you're into Python, all of the PyPI download statistics are on a public data set on BigQuery. So you can go and determine, you can track which libraries have been installed,

which ones have the most downloads, and things like that. Which versions of Python have downloaded which libraries. And the last thing is under services and client libraries, which is management, but for some reason, Cloud Build is under this category. And Cloud Build is also kind of an interesting product that I wanted to highlight really quickly. It is sort of the sidekick to Cloud Run.

So this is Cloud Build, lets you take source and a Docker file and turn it into a Docker container. So this is something you can do locally on your machine as well, but if you need to do this at scale, you need to build a lot of containers for CI or something like that, Cloud Build is a great product to do that because you do it all on our infrastructure.

All right, how much time do I have? I have about 10 minutes, perfect. So I want to ask you all to stick around real quick. I have a little bit of feedback at the end. If you want to give me feedback and stick your name in, I will immediately after this talk raffle off this Google Home Mini

for anyone that has given feedback. But right now I wanted to give you all a chance to ask some questions about Google Cloud or Python or really anything that I talked about if anyone has any questions.

Yeah, over there. It's very interesting. I just wondered, to use those services, are they free? So the question was to use those services, like you mean the serverless products or the APIs?

Both. Okay, both, yeah, sure. To use them, are they free? So most of our products have a free tier. So like BigQuery, Cloud Functions, Cloud Run, they all have a free tier. They do require that you put in a credit card because we're trying to avoid fraud, basically. But you're not charged for the free tier.

And also I think you get like a certain amount of credit as well for when you open the account. So you do have the ability to test out a lot of these things and not pay anything at all. I am not sure. Some of the services also have free tier. They sort of vary from one to another. It's not sort of a broad layer across all of them. But yeah, most of them have the ability to test it out and use it for free.

Thanks, yeah. Hi, thanks. And as you show, we can do everything in Cloud Run, but is it possible to, for example, use Poetry in App Engine or serverless? Yeah, great question. So the question was, I showed that you can do a lot of stuff in Cloud Run,

but is it possible to use alternative package managers like Poetry in App Engine, Cloud Functions and things like that? The answer is no. So if you want to use an alternative package manager, you need to use Cloud Run. Most of the serverless products, also like App Engine, Cloud Functions, but also like Heroku and everything else.

Actually, I might be speaking out here. I don't fully know if Heroku supports Poetry or not. But anyway, we don't. So yeah, if you wanted to use Poetry, if you wanted to use pipfile.lock, that kind of thing, you would need to use Cloud Run. But it would work perfectly on Cloud Run. Thanks. Thanks. Any other questions?

All right, cool. So one other thing, like I said before, my job is not to sell you Google Cloud. I am really interested in our users, people that have experimented with it, especially if you've experimented with it

and determined it's not for you. I want to hear why. So I spent a lot of time talking to customers and then taking that feedback and going back to our product teams and making our products better as a result. So if you wanted to talk to me about Google Cloud, you could bring me to your organization. We can sit down and talk if you're a customer or if you're not a customer or if you're considering Google Cloud,

or if you just want to talk about Python stuff, you can reach out to me. That's my email address. But there's also, I'm going to ask to fill out some feedback. So at the end of the feedback form, if you did want to get in touch with me or bring me to your organization, you can check a box at the end and give me some more contact information. But yeah, so if you go to di.codes.europython,

there's just like a very quick Google form. I'd really appreciate your feedback. It helps me make the talks better, helps me focus more on what people want to hear. And then yeah, if you enter your name or nickname or just any unique identifier that you want, I'll give this like two minutes and then I'll raffle this off right now.

And if there's any other questions in the meantime too, feel free to shout them out. We get to see as people finish the feedback form,

their names will pop in here. Oh, sorry, I should put the link back up.

Has anyone gotten any crazy ideas about what they want to run on Cloud Run as a result? I was really impressed. It was not long after I posted the tweet about the 1.3 runtime that it was like almost immediately someone had a Fortran runtime. It took them no time at all. I was like, I don't know how you do that. It took me like a day to get that running.

Maybe I have a quick question. So just for like smaller web pages, whatever for a client, do you have the option in Cloud Run to use certificates and stuff like that, HTTPS, and it's all in there or? Yeah. It's, you don't have to,

well, with the normal virtual machine, I guess with the local answers, you don't have the HTTPS in there if you don't pay. So you would have to use, a Firebase account or something like that. That's what I read. Let's say that way I didn't try it. So with Cloud Run, you can generate your own certificates

and then, or use one of the free services and you integrate it. Yeah, so the question was about Cloud Run HTTP certificates. So by default, when you create a Cloud Run app and you deploy it the first time, you get like a URL, whatever at cloud.run and it's HTTPS by default.

So you don't have to, you can get HTTPS out of the box without having to configure or do anything at all. We give that to you. You can also use custom domain if you want. And at that point, yeah, the configuration is up to you. You provide the certificate if you want. Kind of, I think what you'd probably expect is what it does.

And the other nice thing, you mentioned Firebase. So Firebase is really nice because it's basically a glorified router in a way. And so if you wanted to, if you have an existing Firebase app and you want to start using Cloud Run, you could set up a Cloud Run instance behind a route in Firebase. So you can just route all the traffic

for this one endpoint to Cloud Run and have that Cloud Run app respond to the traffic for just part of your Firebase app, which is pretty nice. All right, I'm gonna, oh, we've got a lot of names, this is great. Okay, so anyone still finishing the survey real quick? All right, clock's ticking.

This is a fun little app that one of my coworkers has made to make it bigger. It is, yeah, I think it's Firebase actually. All right, anybody else still pending? Ready, okay.

So I'll click it once and it'll spin and whoever it is, come up afterwards and get your mini. All right, I already did the random number and figured it out, but this is for show. All right, T-B-U-M-I, who's that?

Yeah, awesome, all right, cool. So that's all I got for y'all. I really appreciate you coming for the talk and yeah.