A small API is ready for users, but maintaining a server may be more work than the team needs. Serverless computing offers a way to ship it without managing that server directly. In a Function as a Service (FaaS) deployment, the releasable unit is a function that runs when invoked. Servers still exist; the platform hides much of their management. That makes FaaS useful for getting an early product in front of customers and learning from their feedback. section 4.4 section 1.3.3
The abstraction changes both code and cost. FaaS focuses deployment on an individual function rather than a long-running application. It can make development and deployment fast, but may restrict access to system-level features, such as libraries needed for image processing or video splitting. Managed infrastructure can also cost more as usage grows. Compare those costs with the developer time and operating work required by less abstract services; an early product need not start with dedicated servers. section 4.4 section 4.6
Table 4.1 “As a service” applications (view table figure)
Compare FaaS products with infrastructure, container, and platform services before choosing how much deployment responsibility to retain. section 4.4
Deploy a Go translation function
A Go translation API can keep its existing HTTP handler and add a root-level faas.go entry point. The exported Translate function accepts an http.ResponseWriter and *http.Request, then calls the existing translation handler. This placement matters for the shown Google Cloud Functions deployment: it looks for the function in the designated root folder, not a sub-package. A single function could also use an http.Mux to route more calls later. section 4.5
Listing 4.3 pipeline.yml
jobs:
...
deploy-function:
name: Deploy FaaS
runs-on: ubuntu-latest
needs: test
if: ${{ github.event_name == 'push' && github.ref == 'refs/heads/main' }}
steps:
- name: Check out code into the Go module directory
uses: actions/checkout@v2
with:
fetch-depth: 0
- name: Deploy function
id: deploy
uses: google-github-actions/deploy-cloud-functions@main
with:
name: translate #1
entry_point: Translate #2
runtime: go116
credentials: ${{ secrets.gcp_credentials }} #3
- id: test
run: curl "${{ steps.deploy.outputs.url }}/hello" #4
See the deployment job's test dependency, main-branch push condition, Go runtime, credentials secret, named entry point, and curl check of the resulting URL. section 4.5
For a small release, close the loop between a code change and a working endpoint:
- Run tests before deployment; deploy the function on a push to the main branch and check the URL returned by the deployment step. section 4.5
- If users need to call the endpoint, grant the Cloud function invoker role to allUsers in the Google Cloud console. Confirm the public-access warning, then try requests such as /translate/hello?language=german. section 4.5
- Make a small change, such as adding French translation, add its test, then commit and push to exercise the same delivery path. Remove trial deployments when finished to avoid possible charges. section 4.5
FaaS is not the only destination. A Platform as a Service (PaaS) accepts source code and builds and runs an application; a long-running service can expose a health-check endpoint so its platform can judge readiness. A function is normally invoked rather than kept in a long-running state, so that health check was not added to the FaaS deployment. If demand makes on-demand execution expensive, dedicated virtual machines or container orchestration become alternatives—but bring more operational work or learning. Choose the smallest deployment arrangement that lets the team ship, verify, and learn, then revisit it as usage changes. section 4.6 section 10.0
