10 things developers should know about serverless architecture

Increasingly in use by large enterprises and smaller start-ups alike, serverless offers a new approach to software solution development. For developers and software engineers, taking a serverless approach means they don’t have to understand or manage the infrastructure that runs the software. Instead, they can focus just on the business logic.

Major cloud providers like Amazon Web Services, Google Cloud and Microsoft Azure provide and manage the infrastructure for serverless architectures , abstracting every layer from the bare metal to the software environment.

[caption id="attachment_300010714" align="alignnone" width="550"]

Serverless architecture[/caption]



The above image (source: Specify.io ) shows which layers are managed by the Cloud Provider and which ones are under the developer responsibility. Take, for example, the “IaaS” and “Serverless” stacks: in the former, the developer should take care of managing the Operating System, yet has more freedom to host multiple services on the same machine (e.g. serve a web application and host a database); in the latter, the developer does not even need to think about installing Node.js into the environment, and basically can just run code.

While the idea of zero infrastructure management can seem ideal, there are a few considerations developers should consider before going serverless. Most of these refer to generic “cloud functions”, such as AWS Lambda, Azure Functions or Google Cloud Functions. However, serverless services are not only functions, though that may be the most representative definition. AWS, for example, provides a wide range of tools that run according to the serverless approach , including API Gateway, DynamoDB, SQS, SNS, etc. Basically, any service where:

- You pay for the service as you go (i.e. no fixed fees) - You have direct access to the service (no underlying infrastructure installations or configurations) - The service auto-scales its resources.

Regardless of your experience with the cloud or the main providers, some key aspects of serverless architecture should factor into your decision. Here are the top 10 things developers need to know about serverless.

Using a serverless architecture does not mean your code is running on thin air. Regardless of which cloud service provider you choose, somewhere, a host machine is running your code. The advantage of serverless is that you don’t have to worry about it. Forget about hardware failures, software updates, reboots, security and so on — your service will be up as long as the infrastructure is maintained by the provider (which is, in the end, their main business).

While developers have plenty of choices when it comes to working in a specific language, it’s important to know that not all programming languages are supported by cloud functions. Here is a summary of the languages supported directly by each provider:

You’ll need to note that the languages may have different runtimes, like Node.js 8, Node.js 10, Node.js 12, Python 2, Python 3 and so on. And some environments will support custom runtimes, e.g. Custom AWS Lambda runtimes. Before starting a project with a serverless architecture, take the time to plan for languages, runtimes and other factors — including the possibility that you or your colleagues may need to learn a new language to move your code to the cloud.

Serverless functions are not suitable for long-term tasks. For example, after 15 minutes, AWS will kill your Lambda, no matter what.

Keep this in mind during your development phase: you may create beautiful code that crunches your 2MB log file correctly, but you may encounter timeouts in production where the log file may be 200MB. If you don’t know beforehand what size of data you are going to ingest, you may encounter headaches.

As a side note, a watchdog timer can be invaluable when it comes to handling timeouts.

Serverless functions tend to be served on nano-containers with limited amounts of resources. This setup means that serverless architectures are not suitable for tasks that are hungry for CPU and/or memory.

By default, AWS Lambdas have 128MB of memory available (it can be increased on deploy though). Coming from a world in which hardware resources seem infinite, a developer working with a serverless architecture should take these resource limits into careful consideration. Optimize your code, reduce your dependencies and, if it’s not enough, look into optimising your Lambda configuration.

When working in a serverless architecture, you shouldn’t read/save data on the local filesystem. Serverless functions are ephemeral, and everything will be destroyed after the function is completed. Instead, you can get your data from external sources (databases, S3 storage, etc.) and process in your Lambda.

AWS has made it possible to mount Amazon Elastic File System (EFS) in your Lambda, and Azure supports a similar feature . Google Cloud Functions, however, runs on a read-only filesystem and provides a /tmp directory where the function can write files (but then is destroyed after the function ends).

Also unique to serverless, and building on the previous point, is the fact that a Lambda function is decorated by environment variables that are defined by the user when creating the resource, but the environment is stateless.

If you need to keep track of state, your function should call an external storage or cache service to persist the data.

Monitoring a Lambda function in a serverless architecture is hard. You can access your provider console and a dashboard with detailed information of each function, but monitoring a more complex system, or a pipeline, requires additional effort and, sometimes, the use of tracing services like Zipkin .

After execution, your function runtime will be destroyed with no record kept. Don’t log everything though, as large workloads could cause the log storage and processing costs to go beyond the cost of the lambda execution itself. Carefully decide what is important and make sure you preserve that information by logging it. You can always parse your logs to create reports, maybe with a cloud function!

You can rent a Virtual Private Server (VPS) on most cloud providers, but usually you pay for them even when they are idle. If your business is active only in specific time zones, you’ll probably notice zero traffic during the night. Yet, you are billed for those sleepy hours.

The primary benefit of serverless architecture is that this does not happen. Instead, you pay for each execution. So if your Lambda is not called, you won’t be charged. 

On the other hand, if you have high traffic, you may experience spikes on your bill. Consider that a function running with many concurrent executions 100% of the time may be more expensive than a VPS that you pay for by the hour.

Because each cloud vendor handles serverless functions in a different way, when you write code it is hard to be cloud-agnostic. If you need to take advantage of cloud SDKs or cloud-specific services then you keep the majority of your code cloud-agnostic by employing techniques such as Hexagonal Architecture. To make the most of your time and ensure the success of your project, you should decide in advance where the code will run. Moreover, you can’t move your C# code from AWS to Google Cloud (it’s not supported), so keep that in mind in advance or be prepared to refactor.

Switching to a serverless architecture won’t necessarily solve all problems. In fact, following the latest trends and buzzwords can be costly if you haven’t properly scoped your needs and weighed the options.

You may not want to choose serverless cloud functions if you are running a stateful application. Similarly, if you want to avoid vendor lock-in, serverless architecture may not be the route for you. On the other hand, if you need real-time data processing then you should consider dedicated serverless platforms, such as AWS Managed Service for Kafka.

Whatever the requirements, you should definitely consider serverless if you want to manage infrastructure and scaling in an easy way — letting the details of that become your provider’s problem, not yours. For your consideration Depending on your project needs, choosing a serverless architecture could yield significant savings both in cost and time. Serverless can also enable greater scalability and even help to lower deployment risks.

For developers, in particular, serverless offers the opportunity to really focus on the purpose and logic of their code, rather than think about managing or maintaining infrastructure. For that reason and others, the potential of serverless deserves thorough consideration for any project — as long as you remember the ten things discussed here.