So what is serverless? Server in someone’s datacenter, magical animal or easier to use services? Some of the answers are yes. Let’s dive into Google Cloud Run service to see how easy it is to be“cloud native” with a secure and simple deployment solution.
What is serverless
Often serverless services mean that they are in pay as you go “subscription” allowing you, as a user, to reduce costs. If you don’t have 24/7 traffic, you are probably overspending money. Often with serverless comes other benefits such as:
- increased security
- less infrastructure maintenance
- ease of deployments
First serverless service on Google Cloud Platform was App Engine which is still available as a product. It was announced and released in preview in 2008 then released in GA in 2011.
Serverless options on GCP
Google Cloud Platform has a broad offer of serverless services such as Firestore, Workflows or DataFlow but today we’ll talk only about so-called Compute services.
Appengine
First serverless offer on GCP. Right now it can be used in two modes: Standard and Flexible.
Standard mode allows you to use only a set of languages but also can scale to 0 instances when there is no traffic.
Flexible mode allows you to use a more broad set of languages and libraries but there is always one active instance.
When you once create an App Engine service you are not able to change regions and for example scale your solution globally. But in one selected region this will work flawlessly and will be able to handle huge traffic.
Cloud Functions
Functions(FaaS) was released as a solution for event-driven architectures. V1 offers support only for a selected set of programming languages. Functions are often small code portions running independently which also allow easier scalability.
With V2 generation which are based on Cloud Run you’ll be able to overcome V1 limitations and use more languages, connect to more GCP services and get better performance.
Cloud Run
Cloud Run is the latest serverless product of GCP which we’ll focus on today. It may feel like it’s connecting the best parts of two previous, easy deployment in any available region, scaling to 0 when no traffic and good performance with even up to 4vcpu and up to 16GB of RAM (in preview).
What is Cloud Run
Cloud Run is a service where you deploy your code in a Docker container using any language you want (there are examples of running Cobol on Cloud Run!).
All containers running on Cloud Run are in a secure gVisor sandbox so not all syscalls might be accessible, but from my experience I didn’t have any problems. Recently published second generation of Cloud Run has full Linux compatibility and should support all syscalls.
Your deployed container has one public port and by default gets an https url endpoint which can be additionally secured excluding external traffic or requiring service-to-service authentication. So no need to worry about setting up Let’s Encrypt certbot and any other complicated stuff.
Cloud Run is connected to GCP Operations so you get Logging + Tracing in a box which makes it easier to track and measure performance of your application.
Easy deployment and security
Deployment
As mentioned before, you need to have a Docker container to deploy it on Cloud Run Service as new Revision.
Images need to be stored on GCR in any available region (Global, Europe, Asia). To push it there you can use commands like docker build and docker push but there are also easier ways to do it with GCP CLI.
When you go to your project directory and type gcloud run deploy --source=./ it will trigger the build of the container using Buildpack. When done, it will be pushed to GCR and then deployed to Cloud Run. So using just one command you can make your app live.
From what I saw this often works well but generated containers tend to be quite big. This may have changed in recent times but if you don’t want to spend time creating the best Dockerfile you can, just use it.
Security
When deployment finishes you’ll get an individual URL with SSL and blocked public access to it. This might look like https://gateway-<hash>-lm.a.run.app and when you try to open it you’ll see error
Error: Forbidden
Your client does not have permission to get URL / from this server.This is because by default group allUsers doesn’t have access to invoke your service. You can change this behaviour in tab Triggers or Permissions and add allUsers to the IAM list with permission Cloud Run Invoker. From my experience it’s better to manage it in Permissions as changing in tab Triggers might remove previously added users, groups or service accounts.
Thanks to these IAM rules you can access your application from other GCP services (not only Cloud Run) without making it accessible to everyone. This is called service-to-service authentication.
Next
In future posts I’ll cover more features of Cloud Run like network access control, connecting to GCP Load Balancer, streaming data with gRPC, different CPU allocations or how to keep Cloud Run always in hot state.