Serverless computing has revolutionized cloud development, enabling developers to build and deploy applications without managing infrastructure. The Serverless Framework has been a popular choice for deploying serverless applications, but its current shift towards a more commercial model has left many developers searching for an open-source alternative.

Enter OSS-Serverless — a fully open-source alternative that ensures continuity, transparency, and freedom from vendor lock-in. In this guide, we’ll explore how to migrate your existing projects from the Serverless Framework to OSS-Serverless. We will create a project from a serverless template and generate a starter project.

The complete project for this article can be found on Github https://github.com/cyberworkz/examples in the online-library-oss folder.

What is oss-serverless?

OSS-Serverless is a maintained alternative to Serverless Framework v3. It exists for those that cannot upgrade to Serverless Framework v4 and is a drop-in replacement for v3. The repository has been created and is maintained by Bref maintainers and contributors.

Why switch to oss-serverless?

The Serverless Framework was once a go-to tool for serverless development, but recent shifts, such as increased reliance on paid plans, have pushed developers towards open alternatives. OSS-Serverless offers:

✅ 100% Open Source — No hidden fees, subscriptions, or commercial restrictions.
✅ Continuity & Community-Driven — Developed and maintained by the community, ensuring long-term stability.
✅ Compatible with AWS — Similar syntax to Serverless Framework, making migration easy.
✅ No Vendor Lock-In — Deploy anywhere without being tied to a proprietary service.

Plugins

Testing oss-serverless with the following plugins worked just fine:

• serverless-plugin-typescript
• serverless-plugin-optimize
• serverless-offline
• serverless-stage-manager

This gives the impression that the serverless plugins also work out-of-the-box with oss-serverless.

Installing OSS-Serverless

Getting started with OSS-Serverless is simple. First, remove the Serverless Framework and then install oss-serverless globally using npm:

npm remove -g serverless
npm install -g osls

serverless --version

That's it!

Creating a project

To create your project we are going to use an opinionated template from the following repository: https://github.com/cyberworkz/serverless-templates

Use the following command to create your Serverless project:

sls create --template-url https://github.com/cyberworkz/serverless-templates/tree/main/aws-nodejs-typescript-restapi-nest --path online-library-oss

When you navigate into the project folder you would see the following structure.

Open a terminal window in the project folder and run first ‘npm install’ to install the necessary packages. Then in the same terminal run the following command:

npm run start

This will run your project using the serverless-offline plugin locally. This will start a REST API Serverless function locally. Navigate in a browser window to the following URL: http://localhost:3000/dev/hello and you are greeted with the well-known ‘Hello World’ ;-)

You successfully switched to oss-serverless and can create serverless projects without worrying about commercial stuff.

So, this wraps it up. I hope this helps you in your Serverless journeys. Again, the code for this project can be found on Github 👇 https://github.com/cyberworkz/examples in the online-library-oss folder.

Haiko van der Schaaf

• Be sure to clap and follow the writer ️👏
• Follow me on Bluesky 🦋 for my latest content about serverless technology!

DynamoDB is a great serverless option for persisting data. However, the AWS SDK for DynamoDB is a low-level API that unfortunately forces you to scatter information about your entities across your code. It is a maintenance nightmare. But looking a bit further than the AWS SDK, things are better.

The migration of code from AWS SDK v2 for DynamoDB to the rather unimpressive new version V3 gave me the motivation to investigate alternatives. Such an alternative should allow for writing cleaner code while not hiding all the features of DynamoDB. Long story short, I ended up with the DynamoDB Entity Store. This library embraces the 'Single Table Design' approach, offers a clean interface for read operations, and has sensible defaults to protect you from unintentional costly operations such as scanning your table.

In this story, I would like to introduce the 'DynamoDB Entity Store' library and show how it can give you cleaner code and simplify things so you can decide whether it adds value for you. To demonstrate the concepts of the library, I will use the example of an online library service used in my previous stories. The code for this project can be found on Github👇 https://github.com/cyberworkz/examples in the ddb-entity-storefolder.

💡DynamoDB Entity Store concepts

The main concept of the library is ‘Entities’. An entity corresponds to a domain type of your application. Each entity object is responsible for:

• Defining the name of the entity type
• Expressing how to convert a DynamoDB record to a well-typed object (“parsing”)
• Creating partition key and sort key values

Let’s demonstrate this with an example by creating an entity object for the AuthorBook type, expanding on a previous post creating an online library service.

We will use the ‘Single Table Design’ approach, where we select the primary- and sort key so that we can fetch a collection of books from a specific author. For example, you could have the following records in DynamoDB for George Orwell's 1984 and Animal Farm:

DynamoDB Entity Store uses default names for the primary (PK) and sort key (SK) adhering to the ‘Single Table Design’ approach. This can be configured in the setup. This will be covered more in-depth in the section below.

To enable operations on AuthorBook type you need to create an 'Entity'. This entity describes how to construct the 'PK' and 'SK' attributes in the DynamoDB record. Also, a type predicate function must be added, so TypeScript unequivocally can determine the type of the object. The following code shows how you can create an entity for type AuthorBook:

The code shows how the isAuthorBook function helps determine whether the DynamoDB record is an AuthhorBook. This function is part of the arguments for the createEntity function.

The ‘createEntity’ function creates an entity object with the following arguments:

• type name
• type predicate
• function to generate PK value
• function to generate SK value

You only need to create this object once per type of entity in your application, and usually can be stateless so that you can define them as a global constant.

⚙️Setup and Query operations

Now that we have our entity object defined, we turn to configuring and executing querying operations.

To set up the client for DynamoDB operations, you create a 'store' object. In the code fragment below, we use an ‘AllEntitiesStore’, which aligns with the ‘Single Table Design’ approach. An example of how the store object is created can be seen in the constructor of the BooksReposisory class in the code fragment.

The store uses the DynamoDB Document Client underneath. The store configures the client with an AWS account and region from environment variables and default marshalling/unmarshalling. You can override this behavior and provide your own Document Client object when creating a store context object with the function ‘createStoreContext’.

You can also configure a logger using the store context. This is a great help in developing as it shows how the actual DynamoDB query will be executed. In the above code fragment a ‘consoleLogger’ is created in the constructor. Other loggers are also possible. See an example of logging a DynamoDB query below.

To create the store object you also need to give your table configuration as an argument in the ‘createStore’ function. This can be easily done with the ‘createStandardSingleTableConfig’ function, creating a TableConfig object following ‘Single Table design’ conventions.

let tableConfig: TableConfig = createStandardSingleTableConfig(this.tableName);

When writing entities to DynamoDB, the DynamoDB Entity Store adds two extra attributes to the DynamoDB record:

• _et - the value of entity type
• _lastUpdated - the current date-time

In my case, I prefer to call the type attribute 'TYPE'. Luckily, DynamoDB Entity Store lets you overwrite this config so you can adjust it to your preferences.

tableConfig.metaAttributeNames.entityType = 'TYPE';

Adding a type attribute to your DynamoDB records in a table with multiple entities helps you to discriminate between them in several use cases. One such use case is for example DynamoDB Streams.

⚡Standard Single Entity Operations

DynamoDB Entity Store offers a handle for entity operations making your life easier. It can be obtained from the store object in the following way:

authorBookOps: SingleEntityOperations = this.store.for(AUTHOR_BOOK_ENTITY);

This operations object has a number of methods, but to summarize they are:

• put()
• get..() (two different flavors)
• update()
• delete()
• query...() (multiple flavors)
• scan...() (multiple flavors)

See the documentation of DynamoDB Entity Store for more info.

DynamoDB Entity Store makes executing queries using the operations object very simple. Where you used to type out everything as a string for a query with AWS SDK, you can use functions with DynamoDB Entity Store. For example, to get all the books of a particular author you can do the following:

books = await this.authorBookOps.queryOnePageByPkAndSk({firstName, lastName},
            rangeWhereSkBeginsWith(this.bookPrefix), {scanIndexForward: false});

The operations objects knows how the AuthorBook entity is designed and uses that to construct the DynamoDB query. Together with helper functions such as ‘rangeWhereSkBeginsWith’ it allows for very concise code.

Compared with AWS SDK code (below), DynamoDB Entity Store is far more readable and maintainable.

//AWS SDK
const result = await this.db 
.query({
            TableName: this.tableName,
            KeyConditionExpression: '#PK=:PK AND begins_with(#SK, :SK)',
            ExpressionAttributeNames: {
                '#PK': 'PK',
                '#SK': 'SK'
            },
            ExpressionAttributeValues: {
                ':PK': this.authorPrefix.concat(lastName.toUpperCase()).concat("_").concat(firstName.toUpperCase()),
                ':SK': this.bookPrefix
            },
            ScanIndexForward: false,
            Limit: 100
        })

The shown functionality is just the tip of the iceberg. DynamoDB Entity Store offers far more. For example, it also offers handles for pagination and transactions. Learn more about it in the documentation of the library.

🙏 Conclusion

Working with AWS SDK for DynamoDB is not that optimal. It is a low-level API that will create hard-to-maintain code. The new AWS SDK v3 version makes it even harder. Fortunately, there are alternatives for the AWS SDK as DynamoDB Entity Store. DynamoDB Entity Store abstracts all this plumbing away and allows you to write concise code that is readable and maintainable.

DynamoDB Entity Store embraces the ‘Single Table Design’ approach and lets you easily create entities and execute queries. It has sensible defaults that offer protection against costly operations with DynamoDB. The library is flexible enough to let you adjust it to your needs.

Give it a try and let me know if it gives you the same advantages as I have experienced.

So, this wraps it up. I hope this helps you in your Serverless journeys. The code for this project can be found on Github👇 https://github.com/cyberworkz/examples in the ddb-entity-storefolder.

Haiko van der Schaaf

• If you enjoyed this, please follow Serverlesscorner.com on Medium.
• Follow me on Bluesky 🟦 for my latest content about serverless technology!

Related stories

• How to Build a Serverless REST API with NestJS and DynamoDB
• How to do Single-table design with DynamoDB?
• How to filter Serverless events from DynamoDB streams
• How to use DynamoDB streams to feed Algolia search

We all know that adding some extra things can give excellent results. A layer of cheese to your burger, some wasabi to your sushi, and an extra layer code to your Lambda function. Yes, that’s right, you can add Lambda layers to your Lambda function. Lambda layers allow you to manage your Lambda functions more efficiently.

Lambda layer

Lambda layers is a .zip file archive that contains supplementary code or data. Layers usually contain library dependencies, a custom runtime, or configuration files. You can include up to five layers per function. Also, you can use layers only with Lambda functions deployed as a .zip file archive. An example of such a Lambda layer is Powertools for AWS Lambda. See the following article on how to incorporate a Lambda layer with the Serverless Framework.

Why should you use Lambda layers?

Lambda layers give you some extra flexibility and ways to manage your code. It gives you the following options:

• Reduce package size — Move some code, organized in a cohesive way, to a layer reducing the size of your package which gives faster deployments and development speed. This allows you to extend a Lambda function from 50MB to a maximum of 250MB. But, smaller is better with AWS Lambda.
• Separate concerns — In a large ecosystem with a lot of services and multiple teams, platform or cross-cutting functionality can be offered in a layer to higher services to enforce a common architecture and give a clear separation between teams. Teams responsible for the code in the layer can update the layer in the function separately from teams producing the higher services.
• Share code — Often you have a domain model or utility code that is shared by multiple services. Lambda layers offers an efficient way to share it across multiple Lambda functions and maintain it in an easy manner.

Drawbacks

As with any tool, there are some areas you should pay attention to when using Lambda layers.

• Local dev environment — Setting up local dev environment takes some extra effort. The layer must also be offered as a package that can be used locally.
• Security — Beware of using external layers. Make sure that when using external layers it is from a trustworthy source. You can use AWS Inspector to scan for any irregularities.

Conclusion

Lambda layers is an option to reduce the size of your Lambda function and organize code. Specifically in a big enterprise environment with multiple teams, Lambda layers can help in separating concerns and organizing code.

There are some drawbacks that you should address, but they are easily mitigated.

In the upcoming article, we will look at how we can create a layer inside your AWS account.

Have fun coding!

Haiko van der Schaaf

If you enjoyed this, please follow Serverlesscorner.com on Medium.

Add some layers to your AWS Lambda was originally published in Level Up Coding on Medium, where people are continuing the conversation by highlighting and responding to this story.

The latest Thoughtworks radar of April 2023 warns of using serverless technology for it increases the complexity and risks ending up with a Lambda pinball architecture.

Boris Tane on Twitter: "what's the worst lambda pinball architecture you've seen in the wild? pic.twitter.com/CEsq0x3HF8 / Twitter"

what's the worst lambda pinball architecture you've seen in the wild? pic.twitter.com/CEsq0x3HF8

The problem originates from the fact that when execution and data flows across multiple interdependent Lambdas, at a code level, simple mapping between domain concepts and the multiple Lambdas involved is practically impossible, making any changes and additions challenging. In short, when you don’t properly design your lambda’s you end up with a distributed spaghetti-code jungle, the previously used GOTOs are here replaced with events between the interdependent Lambdas.

Spaghetti Code’ is a phrase, an antipattern for unstructured, difficult-to-maintain code that is every developer’s nightmare. The word ‘spaghetti’ here refers to the flow of the program being tangled like ‘spaghetti’. It is also called ‘code that is difficult to follow by a human’.

As the reference indicates, this is not a new problem. The term already appears in the 1970s. However, the impact is more significant now as we are exposing public interfaces to other services. Luckily, this problem is already solved for us. We only have to know how to apply this to Lambda architecture.

What should we put in a Lambda function?

There are two questions here. How much code fits in a Lambda and which code should go into the Lambda?

Let’s start with how much code fits in a Lambda. Traditionally, you would build an application that contains all the functionality. The application would contain multiple services (aka modules, packages, etc). Each service would contain one or multiple functions (aka methods). You would run the application on hardware, on a VM, or in a Docker container.

A lambda has its limitations regarding deployment size. AWS Lambda size limit is 50 MB when you upload the code directly. With Lambda layers you can have a maximum of 250MB for your package.

With these limitations in mind, we should scope what should fit into a Lambda to either a service or a function.

Which code should go into a Lambda?

Now we are arriving at the most important question to avoid the Lambda Pinball, how to decide which code should go into a Lambda?

The goal here is to organize code in such a way that changing the code somewhere will make the least ripple effect on other parts of your system. To do this you should guide your efforts in organizing your code by the ‘Single Responsibility Principle’.

The single-responsibility principle (SRP) is a computer programming principle that states that “A module should be responsible to one, and only one, actor.” It was coined by Robert C. Martin aka Uncle Bob.

Martin defines a responsibility as a reason to change, and concludes that a class or module should have one, and only one, reason to be changed (e.g. rewritten).

Domain Driven Design

A lambda function therefore should have a single responsibility. But at what granular level should we apply this? An effective way to organize responsibilities is to look at the concepts of a business domain as used in ‘Domain Driven Design’ (DDD)

Domain-driven design (DDD) is a major software design approach, focusing on modeling software to match a domain according to input from that domain’s experts.

DDD aims to group concepts and functionality into a single (business) domain. An e-commerce application could have for example an Inventory domain, Invoice domain, and Shipping domain.

These domains are too big for a single function. Therefore for using Lambda, we should match the concept of a Service with a Domain. The Service should contain all functions related to the particular domain.

Organizing code in this way will decrease dependence between Lambda’s and makes it easy to map domain concepts. Changing code for a single business domain will be easier and maintainability is increased. This will avoid tight coupling and cut down on unnecessary inter-lambda communication using events.

Conclusion

A naive approach to putting code into Lambda will result in a distributed spaghetti code jungle making any changes and additions challenging.

Using the ‘Single Responsibility Principle’ with Domain Driven Design concepts your code you can organize your code across Lambda functions in a maintainable way. Following this recipe to design your system allows you to experience pinball at the right venue, the arcade hall 🕹️👾.

Have fun coding!

Haiko van der Schaaf

• If you enjoyed this, please follow Serverlesscorner.com on Medium.
• Follow me on Bluesky 🟦 for my latest content about serverless technology!

Related stories

• Does AWS Lambda SnapStart make sense?
• Serverless vs CDK
• S3 trigger: Serverless CSV upload into DynamoDB

⭐ Welcome to the February ServerlessCorner newsletter.⭐

⚙️Event-driven programming got a lot of love during the recent AWS re:Invent, but too many loosely coupled events can feel like a pinball architecture. AWS Step functions is a serverless service to orchestrate workflows. The first story ‘What is AWS Step functions’ will give you insight how it can help to orchestrate your lambda microservices.

🔒The second story is from Airbnb security and shows how they leveraged serverless technology as AWS Lambda and AWS Step functions to automate end-to-end certificate rotations.

📈 Third, an article about metrics for asynchronous Lambdas. Where it was difficult to monitor the processing of asynchronous invocations, now there are new metrics that provide visibility for asynchronous Lambda function invocations.

🔍 And lastly, an introduction of AWS Inspector. AWS Inspector scans for vulnerabilities in your AWS Lambda functions and Lambda layers.

Have fun reading 🚀

If you like to receive more exciting stories about serverless technology and its use cases please sign up on Serverlesscorner newletters.

Subscribe

This month’s stories:

⚡️What is AWS Step Functions? How It Works & Use Cases

⚡️ Meet Ottr: A Serverless Public Key Infrastructure Framework

⚡️ Introducing new asynchronous invocation metrics for AWS Lambda

⚡️AWS Inspector for your Lambda’s

• What is AWS Step Functions? How It Works & Use Cases | Resmo
• Meet Ottr: A Serverless Public Key Infrastructure Framework
• Introducing new asynchronous invocation metrics for AWS Lambda | Amazon Web Services
• Amazon Inspector Now Scans AWS Lambda Functions for Vulnerabilities | Amazon Web Services

If you like to receive more exciting stories about serverless technology and its use cases please sign up on Serverlesscorner newletters.

Subscribe

PS. Love ❤️ reading my stories and other ones on Medium? Become a member if you ain’t already.

ServerlessCorner Monthly: February 2023 was originally published in serverlesscorner newsletter on Medium, where people are continuing the conversation by highlighting and responding to this story.