Serverless runtime for applications

The Serverless Essentials

I know many of my friends who are not developers but they still need to know Serverless Functions. They may be providing services to developers, solution architects or leading a team that works with developers. This article is intended for those who work with applications but don’t design or develop them.

Use of serverless functions have grown exponentially over the past few years and the benefits and scalability advantages are well known.

Basics First

• Serverless does not just mean serverless functions, there are several serverless services including AI/ML which run on cloud platforms. But I will focus just on functions in this article.
• While AWS serverless Lambda is probably the most widely used, other cloud service providers also offer similar serverless functions and serverless services
• Serverless Functions introduce so many new possibilities but we need to understand its limitations to make proper use of them. Serverless functions run for a short time, so the task assigned to a function must be short
• Serverless functions have versatile use, you can use them for once in a day file transfer to running sentiment analysis for a busy call center or for a busy consumer app that needs to scale to a million events

Popular Use Cases

• It is entirely possible to create an end to end application with an assembly of cloud services and with business logic in serverless function. In this case, serverless function becomes the glue for delivering your entire functionality. A well written Serverless Function with application tasks divided at an atomic level can very well replace a monolith with microservice-like architecture
• Event driven architecture, this covers a wide range of use cases. Third party integration, simply taking an action based on monitoring alert, real time file processing, real time stream processing.
• Serverless Functions are also a popular choice for applications doing sentiment analysis, video and image analysis, IOT events, smart home devices and virtual assistant calls

The AWS reference architecture image shows payment processing use case

Serverless Functions Architecture — What do you need to know

Code

• First of all when we say, I want to use Lambda, it means we are writing new code or we are re-writing, re-architecting existing applications. There is no lift and shift into Lambda for on-premise applications.
• Serverless Functions and architecture are not portable across CSP platforms. If you write Lambda, you are on AWS. Lambda will integrate easily with other AWS services, same way other CSPs have their own Function services
• Serverless Functions are quite language friendly, you can use Java, Python, Node.js, Go but this is not a web application on JVMs where you can have long startup routine, consider one task one function practice and consider performance at run time.
• Your CSP will clean up your function after it runs once, so the next time your function may take longer to come to life. You need to keep them warm or available if you need better performance. Yes I am referring to Cold Starts. Find a way to avoid this at run time. Consider using a lightweight framework or a language other than Java and even provisioned concurrency in AWS
• As general best practice, use the 12 factor app methodology. While everything is important, the “state” and CI/CD are very important. Your stateless function will need state to be stored outside of the code (elasticache/redis)

Security, permissions, network

• Cloud security uses a layered approach, you need to think through how will you ensure your function is able to unlock all layers as required. If you want your Lambda to write to an S3 bucket, you need to make sure Lambda gets proper permission for S3
• Talking about Lambda again, it is important to understand Environment variables and what should NOT be stored and what to encrypt with KMS/Keyvault. Any secrets, passwords should be stored in Secrets Manager or Parameter Store
• Also, make sure to identify where your serverless function will run and where it will communicate. Network security is equally important. If your serverless going to run within a VPC you need to ensure VPCs/Network are configured to allow Functions to communicate where it needs to outside of VPCs

Monitoring

• Tracking the execution(lifecycle) of the serverless function may provide useful insight in it’s efficiencies or inefficiencies. Serverless functions have a short life, there is a short window to capture useful data to understand errors or efficiency of our function.
• It is good to ensure appropriate logs of errors and activities are getting generated using tools like CloudWatch, X-Ray, azure app .
• Having Serverless Functions interact with assembly of services will mean, you have many network calls. This may introduce latency and to troubleshoot, you may need logs from more than one service.

Data

• What type of data do you have, will answer if we need to store that data and where? Are you getting your data as a stream? Kinesis in AWS and Kafka in general are popular choices which handle streaming data. Your business logic will decide what needs to be done with the data stream.
• Serverless architecture can also include a database and an object storage, based on what the function intends to do. S3 object storage has evolved as a robust, central component for all types of architectural patterns in AWS
• A high intensity serverless environment can overwhelm databases, consider inserting a message queue in front of a database as needed.

• Also consider event based architecture requirements for databases. What type of database do you need, should be decided

Well, if this was helpful then don’t wait. You can build it too. Start your first function today :-).