Guide to Creating a Serverless Application
Serverless functions should work well and only be available on request from an inactive state. We give you a guide on how to create a serverless application – and what else you should know around this topic.
Understanding Serverless Architecture
Serverless architecture allows you to deploy backend web services on demand. Instead of maintaining your own server configuration, you can design your software for serverless providers to minimise the overhead involved. Serverless applications are typically deployed from a Git repository to an environment that can scale as needed.
This means that serverless functions can effectively scale “to zero” – a function or endpoint should not consume any resources until it is invoked. However, this also means that serverless functions must behave well and should only be available from an idle state to provide custom responses to input requests. These responses can be as computationally intensive as required, but must be invoked and terminated in a predictable manner.
Requirements for Serverless Applications
To follow this guide you will need:
- a local shell environment with a serverless deployment tool installed.
- the version control tool Git available in your development environment.
Step 1 – Create a Serverless App Repository
A complete serverless app may be limited to just two files: the configuration file, which is usually in .yml syntax and declares the required metadata for your app to the serverless provider, and a file containing the code itself, such as my_app.py, my_app.js or my_app.go. If your application has language dependencies, they are usually declared using standard language conventions as well, e.g. a package.json file for Node.js.
To initialise a serverless application, you can use doctl sandbox init with the name of a new directory:
ctctl sandbox init myServerlessProject
By default, this will create a project with the following directory structure:
myServerlessProject/
├── packages
│ └── sample
│ └── hello
│ └── hello.js
└── project.yml
The project.yml file is located in the top directory. It declares metadata for hello.js, which contains a single function. All serverless applications follow this essential structure. You can find more examples with other serverless frameworks in the official Serverless Framework GitHub repository. You can also create these directory structures from scratch without relying on an initialisation function, but note that the requirements of each serverless provider will vary slightly.
Step 2 – Architecture of a Serverless Application
A serverless application can consist of a single function written in a language interpreted by your serverless computing provider (usually Go, Python and JavaScript) as long as it can return output. Your function may call other functions or load other language libraries, but there should always be a single main function defined in your project configuration file that communicates with the endpoint itself.
Running doctl sandbox init in the last step automatically generated a sample project for your serverless application, including a file called hello.js. You can open this file with nano or your favourite text editor:
nano myServerlessProject/packages/sample/hello/hello.js
Step 3 – Deploy a Serverless Function
The doctl sandbox command line tools allow you to deploy and test your application without promotion to production, and other serverless implementations provide similar functionality. However, in almost all deployment workflows for serverless functions, you need to upload your application to a source code repository such as GitHub and connect the GitHub repository to your serverless provider.
When you are ready for a production deployment, you should be able to visit your serverless provider’s console and identify your source code repository as part of an application. Your application may have other components, such as a static website, or it may only provide the one endpoint.
For now, you can deploy directly to a test sandbox using doctl sandbox:
ctctl sandbox deploy myServerlessProject
This returns information about your deployment, including another command you can run to request your live test URL:
Output
Deployed '~/Desktop/myServerlessProject'
to namespace 'f8572f2a-swev6f2t3bs'
on host 'https://faas-nyc1-78edc.ctserverless.io'
Deployment status recorded 'myServerlessProject\.nimbella'
Deployed functions ('ctctl sbx fn get <funcName> --url' for URL):
- sample/hello
Running this command returns the current endpoint of your serverless function:
ctctl sbx fn get sample/hello –url
The paths returned are automatically generated, but should end with /sample/hello based on the function names.
Note: You can check the functionality of the doctl sandbox deployment in the source repository.
After you have deployed to the test or production environment, you can use cURL to send HTTP requests to your endpoint. For the sample application sample/hello developed in this tutorial, you should be able to send a curl request to your /sample/hello endpoint:
curl https://faas-nyc1-78edc.ctserverless.io/api/v1/web/f8572f2a-swev6f2t3bs/sample/hello
The output is returned as the body of a standard HTTP request:
Output
“Hello stranger!”
You can also specify the name argument for your function as described above by coding it as an additional URL parameter:
curl https://faas-nyc1-78edc.ctserverless.io/api/v1/web/f8572f2a-swev6f2t3bs/sample/hello?name=sammy
The output will be:
Output
“Hello sammy!”
After testing and confirming that your app returns the expected responses, you should ensure that sending unexpected output to your endpoint causes it to fail gracefully. You can review best practices for error handling to ensure input is parsed correctly, but most importantly, make sure your app never hangs unexpectedly, as this can cause availability issues for serverless apps, as well as unexpected per-use billing.
Finally, you want to deploy your app to GitHub or another source code repository for production. If you decide to use Git or GitHub, you can read about how to use Git effectively for an introduction to working with Git repositories.
Once you have connected your source code repository to your serverless provider, you can take further steps to restrict access to the endpoints of your feature or group them together as part of a larger, tagged app.
Conclusion
In this tutorial we have initialised, verified and deployed a sample serverless function. Although each serverless computing platform is essentially proprietary, the different vendors follow very similar architectural principles, and the principles in this tutorial are broadly applicable. Like any other web stack, serverless architectures can vary significantly in scope, but ensuring that individual components are self-contained helps keep your overall stack more maintainable. Guide to Creating a Serverless Application
