Skip to content

Serverless

  • BP: choosing right-product
    • App type?
      • Cloud/Firebase events -> Cloud Functions
      • Stateless HTTP ->
        • Need Kubernetes or configurable hardware -> Cloud Run for Anthos
        • Custom languages / system libraries -> Cloud Run
        • Deployment? Application -> App Engine, Function -> Cloud Function
  • Use cases
  • Compare
Use Case Cloud Run Cloud Function App Engine
Web App Yes
HTTP Service Yes
API for Mobile/Web Yes Yes
Internal API Yes Yes
Data Processing Yes
Workflow & Orchestration Yes Yes
Cloud Event Triggered Yes
Connecting Cloud Services Yes
Feature Cloud Run Cloud Function App Engine
Containers Yes
Traffic splitting Yes Yes
Custom Domain Yes Yes
Setup authentication? Yes
Requests Per Instance Many One Many
Timeout (Min) 15 9 1

Cloud Function

  • automatically authenticated to APIs, without the need the create service account, permissions etc
  • BP: To control auto-scaling when using pubsub, set max_instances to queue calls
  • Concurrent request: Cloud functions are 1 request per instance and hence do not ramp up as quickly as App Engine or Cloud Run

Cloud run

  • runs (gcloud run deploy <app> --image=<image> --platform=managed) applications in containerized applications (gcloud builds) and has an endpoint(gcloud run services describe) on kubernetes managed by Google
  • applications need to be stateless
  • application can be invoked by POSTing to the service URL
  • 3 ways to deploy, specify using --platform : managed, gke or kubernetes (KNative compatible cluster)
  • The calling service/user (--member=xxx) must have roles/run.invoker. Where xxx is
    • allUsers for public, user:<user-email> for users, serviceAccount:<svc-email> for service accounts
    • use self-signed JWT token for calling from outside GCP
  • BP:
    • only allow authenticated (--no-allow-unauthenticated) requests
      • gcloud run services add-iam-policy-binding <app> --member=serviceAccount:<svc-id> --role=roles/run.invoker
    • use gcloud run deploy --service-account <svc-id> a service account instead of defaulting to the Compute Engine default service account which has Editor IAM role (RW access to all GCP resources)
    • Managed applications are limited to 15 minutes, not ideal for long running jobs
    • v/s App Engine (?): app engine: doesn't require container, easy integration with google Authentication and Authorization
  • BP to reduce cold-start time: (for dynamic languages) reduce number of dependencies, or use lazy evaluation or global variables
  • Large container image size has no affect cold start or request processing times and does not count towards available memory

App Engine

  • suitable for microservices architecture
    • consists of one Application, 1+ Services, 1+ versions for each service
  • standard environment supports limited runtimes
    • cannot exceed 60 seconds
  • supports versioning for A/B testing
  • allows traffic splitting by version
  • develop and test locally using SDK
  • creating an app:
    • create app.yaml in project directory
    • optionally create index.yaml to create additional indexes, upload using gcloud datastore indexes create index.yaml
    • set up app engine: gcloud app create --region=us-central Note: region cannot be changed
    • deploy app gcloud app deploy (--no-prompt to update, but not activate the new version)
    • browse: gcloud app browse
  • application is stored in Cloud Storage
  • Use import googlecloudprofiler in Python apps for monitoring
  • Q: How do you rollout a risky deployment? A: Deploy as a new version, but not as default, and then split traffic for testing
  • Apps can help reduce code-start latency on a new instance by configuring warmup request handling
Features Standard Env Flex Env
runtime Python3, Java, PHP, Go, Node.js, Ruby containers
Network/API Most GCP API + External Same as compute engine
startup time milliseconds minutes
ssh access No Optional
scale to zero? Yes min. 1 instance
Free tier? Yes No
Websockets? No Yes

Cloud Endpoints

  • Managed NGINX based, Extensible Service Proxy ESP
  • uses either OpenAPI spec or one of Google API framework
  • Control access and validate calls using JWT, Google API Keys
  • Runtime environments: Kubernetes, App and Compute engines
  • can use GCP APIs and authentication

apigee edge is a proxy service that provides frontend to APIs

  • rate-limiting
  • security
  • quota
  • analytics
  • not specific to GCP
  • Q: Which service to use to retire legacy app engine piece-by-piece A: apigee (because cloud endpoint uses GCP services/authentication)