Please enable JavaScript.
Coggle requires JavaScript to display documents.
GCP-Cloud Function V1/V2 and Cloud RUN - Coggle Diagram
GCP-Cloud Function V1/V2 and Cloud RUN
Events are triggered from
http invocation
firestore
pubs event
firebase
event in logs
....
file uploaded to CS
Idea - run code in response for some trigger
automatically scale
no worries for services in background
pay - how long it run * numbers of invocation + RAM and CPU provisioned
there are two versions
old - first gen
second ver - new, build on Cloud Run and Eventarc
It is recommended to use V2. V1 vs V2
Concurrency: up to 1000 concurrent request per Functional Instance. (V1 - 1 req per instance)
Multifunction revision and traffic split across revisions (it is based on Cloud Run)
Larget instance size: 2X from V1 (16 RAM and 4 CPU now available in V2)
support 90 triggers (V1 support only 7)
Longer Request Timeout - up to 60m for HTTP
Based on Cloud Run - behind V2 we have a Cloud Run service
V1 uses typical Servless Architecture when V2 is mostly deployed APP from Image
create:
can use different language
need to deploy
we need to define region
we can create from code: provide code, -> Cloud Build create the Image -> Cloud Run deploy it. That's why we see Function V2 in Cloud Run as a new Service
Scaling and Concurrency
in V1: 1 functional instance = 1 req
in V2: 1 fun. inst - up 1000 req. But it should be safe ti run Concurently
Cold start relevant here
Autoscalling - new functional instance can be started for new request
Best Practise
if we need to support different versions - need to go to Cloud Endpoints, API Gateway or Apigee
Split traffic per revision for testing and then increase traffic
configure max amount of instances - to avoid ab-normally high traffic
Use Secret Manager if we have smth specific to protect
minimize dependency - to decrease time of start
To avoid Cold Start - set 1 instance as minimum
Use separate Service Account per each function
Qualities and features
time bounded: 1 min(defoult) to 60 minutes
can write in a lot of languages: Java, Node, Python, Go
Important concepts
Trigger
Function
Event
Create Function
chose version - v1 or v2
add name
choose new function
Enable Function API
set Trigger
setup how to auth request
setup runtime, connection and security settings - memory and autoscaling is here
Cloud Build API is also required - we need it to deploy function
Press - "deploy"
There is also page - `"Function Details" for created run
CLOUD RUN
Create new:
chose region
chose autoscalling (1 node required to avoid cold start)
chose name
chose CPU per req or always run
Chose container or build from repo
Choose to allow traffic from the Internet
Terminology:
Inside we have reviossons - ruined application
we can configure memory and CPU numbers, timeouts, etc
we can split traffic between revisions
we also have metrics - counts, latency, etc
We create a service
Triggers - can allow https, etc
Idea and concepts
based on Knative - (Serverless Containers in Kubernetes environments.),
https://knative.dev/docs/
Fully managed - zero infra and "Pay-per-use". But we can controll CPU per request/allways and autoscaling - basic points when create
Container to prod in seconds
All benefits from container: no limit for code language, easy portable, etc
Widely integrated: Cloud Code, Cloud Build(CI/CD), Loggs, etc, Anthos
support YAML config
If we don't want to pay attention for Infra- we can use serves Cloud Run
controlling access for Cloud Functions
Identity-based
Evaluating credentials (Authentication)
Allowing that entity to access your resources based on what permissions (Authorization)
Network-based
limit access by specifying network settings for individual functions
allows for fine-tuned control over the network ingress and egress
Authenticating function to function calls
each function can only send requests to a specific subset of your other functions.
need to add the calling function's service account as a member on the receiving function and grant that member the Cloud Functions Invoker (roles/cloudfunctions.invoker) role.