Efficient Backend Development with Serverless Technologies

With serverless technologies, robust and scalable backends can be built that can be operated extremely cost-effectively. At innFactory, we have increasingly relied on backends that are completely implemented as serverless architecture since 2022. We want to explain what exactly this means and how we implement the technologies in this article.

Serverless Functions

Serverless Functions are the central element of a serverless architecture. They represent a way to execute code without developers having to worry about the underlying infrastructure or servers. The term “serverless” doesn’t mean that no servers are actually used, but rather that developers no longer have to worry about managing and scaling these servers.

Here are some key characteristics of Serverless Functions:

1. Event-driven execution: Serverless Functions are typically activated based on events or requests. Examples of events include HTTP requests via API gateways, adding a file to a storage service, or triggering a schedule (CRON jobs).
2. Automatic scaling: The serverless platform automatically handles scaling the functions based on the number of incoming requests or events. This makes it possible to handle highly varying workloads without having to manually adjust resources.
3. Pay-per-use billing: Developers only pay for the resources actually consumed and the execution time of their functions. When a function is not active, no costs are incurred.
4. Isolation and security: Each function runs in an isolated environment, minimizing security risks. Functions typically have no direct access to the underlying infrastructure.
5. Diverse use cases: Serverless Functions can be used in a variety of use cases. Specific examples of tasks we use Serverless Functions for (also in “traditional” cloud projects):
   • PDF generation for financing concepts (Laura AI, VR-Bank)
   • Automatic invoice creation (internal, Clockodo + Easybill)
   • Saving form data from smartcity-rosenheim.de
   • CSV export of WiFi quality in stores (Rossmann)
   • Import of hotel master data (Familotel)

All major cloud providers offer Serverless Functions. At Google they’re called “Cloud Functions,” at AWS “Lambda Functions,” and at Azure “Azure Functions.” We usually use TypeScript/Node.js as the programming language for Serverless Functions. However, cloud providers now offer many alternatives. For very compute-intensive applications, for example, Go or Rust. But also established languages like Java or C# are available alongside the rising language Python.

Complexity with a Large Number of Serverless Functions

While using individual functions in projects is usually unproblematic, since in our experience they always handle “special tasks” that ran autonomously and fairly isolated from the rest, an entire backend based on Serverless Functions can bring various problems. We’ll see later how these problems can be solved with the help of SST:

• Architecture complexity: As the number of Serverless Functions increases, the overall architecture can become very confusing.
• Deployment: When a function is deployed, it’s typically deleted and recreated, which takes a lot of time with many functions. The overview of whether a function is deployed and how current it is is also very unclear with multiple environments.
• Other cloud resources: Functions often access other cloud resources, such as databases. Here, a function needs permission that specifically only grants access to the required resources. Additionally, the other resources must of course exist and be configured accordingly.
• Cold starts: Serverless Functions can take a few seconds the first time they’re called after a long time until they’re really loaded and executed.

Describing Infrastructure with SST (Serverless Stack Toolkit) or Serverless Framework

The solution for the problems mentioned above is provided by tools like SST or the Serverless Framework.

With these tools, the architecture of the functions can be described with TypeScript (SST) or YAML (Serverless Framework). These tools also handle deployment. For example, all functions are deployed with just one command, and it also ensures that only those that have changed are updated. Access permissions can be defined directly in the infrastructure description, and cold starts can be avoided by configuring “keep warm” for the functions.

SST vs. Serverless Framework

Basically, SST focuses more on the complete infrastructure description, while the Serverless Framework focuses on deploying Serverless Functions. Both tools would be suitable for implementing serverless backends. Here are more points where the tools differ:

Advantages of SST:

• With SST you describe the complete cloud infrastructure including frontend integration -> everything in one project
• SST offers an extremely good developer experience: For testing and debugging, the business logic of the function runs locally on your own machine. Communication with the deployed function is done via a websocket, thus also enabling access to the rest of the infrastructure. However, debugging is local, which enables faster and easier error analysis and also lets changes flow in instantly (live reloading).

Advantages of Serverless Framework:

• Serverless has more programming languages for functions to choose from (Node.js, Python, Java, Go, C#, Ruby, Swift, Kotlin, PHP, Scala, F#)
• Serverless is independent of the cloud provider, while SST only works with AWS

SST vs. CDK

Anyone who works a lot with AWS is now wondering what the difference is to the Cloud Development Kit (CDK) from AWS. So here we briefly list the decisive points:

• Builds on CDK
• CDK code can be freely added if necessary
• Simple deployment of different environments
• Environment per developer
• Testing of infrastructure and business logic
• Database migrations
• Type-safe and autocomplete thanks to TypeScript
• Automation of frontend deployment (creation of S3 bucket, CloudFront distribution, etc.)

Conclusion

We have now implemented several projects with SST. The greatest added value for the customer with serverless architectures comes in the form of very low operating costs. But implementation and maintenance is also almost on par with the classic microservice architecture, which we almost always implement with Scala and Akka, thanks to SST. In our experience, serverless architecture is best suited for applications that predominantly contain CRUD operations, while for more specialized use cases (e.g., running machine learning or other compute-intensive backends) we continue to firmly rely on Scala, Kubernetes, and Co.