The final application platform we'll explore in this section of the course is Cloud Run; a managed compute platform that lets you run stateless Containers via web requests or Pub/Sub events. Cloud Run is serverless. That means it removes all infrastructure management tasks so you can focus on developing applications. It's built on Knative, an open API and runtime environment built on Kubernetes that gives you freedom to move your workloads across different environments and platforms. It can be fully managed and Google Cloud and Google Kubernetes Engine or anywhere Knative runs. Cloud Run is fast. It can automatically scale up and down from zero almost instantaneously. It charges you only for the resources you use, calculated it down to the nearest 100 milliseconds. You'll never pay for your over-provisioning resources. The Cloud Run developer workflow is a straightforward three step process. First, you write your application using your favorite programming language. This application should start a server that listens for web requests. Second, you build and package your application into a container image. Third, the container image is pushed to Artifact Registry where Cloud Run, will deploy it. Note that Cloud Run can only deploy images that are stored in Artifact Registry. You can build, push, and deploy your own code from your local source if you have the required permissions. You can also deploy an image that already exists in Artifact Registry. Once you've deployed your container image, you'll get a unique HTTPS URL back. Cloud Run then starts your container on demand to handle requests, and ensures that all incoming requests are handled by dynamically adding and removing containers. Because Cloud Run is serverless, it means that you as a developer, can focus on building your application and not on building and maintaining the infrastructure that powers it. For some use cases, a container-based workflow is great because it gives you a great amount of transparency and flexibility. If you build the container image, you have the power to decide exactly what file ends up in your container image and how it gets there. However, building an application is hard enough already, let alone having to think about containerization and the responsibilities that come with that. Sometimes you're just looking for a way to turn source code into an HTTPS endpoint, and you want your vendor to make sure your container image is secure, well configured, and built in a consistent way. With Cloud Run, you can do both. You can use a container-based workflow as well as a source-based workflow. If you use the source-based approach, you'll deploy your source code instead of a container image. Cloud Run then builds your source and packages the application into a container image for you. Cloud Run does this using buildpacks, an open source project. Cloud Run handles HTTPS serving for you. This means you only have to worry about handling web requests and you can let Cloud Run take care of adding the encryption. By default, your application is exposed on a unique sub domain of the globalrun.appdomain. You can also use your own custom domain. Cloud Run manages everything else; generating a valid SSL certificate, configuring SSL termination correctly with secure settings, and handling incoming requests, decrypting them, and forwarding them to your application. The pricing model on Cloud Run is unique as you only pay for the system resources you use while a container is handling web requests with a granularity of 100 milliseconds and when it's starting or shutting down. You don't pay for anything if your container doesn't handle requests. Additionally, there was a small fee for every one million requests you serve. The price of container time increases with CPU and memory. A container with more vCPU and memory is more expensive. Today, cloud can allocate up to four vCPUs and eight gigabytes of memory. Most of the other compute products, such as Compute Engine, charged for servers as long as they're running, even if you're not using them. This means you're often paying for idle server capacity. You can use Cloud Run to run any binary as long as it's compiled for Linux 64 bit. Now, this means you can use Cloud Run to run web applications written using popular languages such as Java, Python, Node.js, PHP, Go and C plus plus. You can also run code written in less popular languages, such as Cobol, Haskell, and Perl. As long as your app handles web requests, you're good to go.
