Serverlessly allows you to write vendor-neutral cloud-native microservices which you can run on any FaaS (AWS Lambda, Azure Functions etc), CaaS (AWS Fargate, Google Cloud Run etc) or self-managed infrastructure (Auto-scaling EC2, Kubernetes etc) at scale.
What problem does Serverlessly solve?
When you write microservices for AWS Lambda, you get locked into the system because the same code can't run on Azure Functions or self-managed infrastructure. With Serverlessly, you can move around by just switching Platform Adapter.
In contrast, Containers (which seem to solve same problem) are heavy on cold boot (AWS Fargate cold boot time can go upto 20 seconds) & keeping containers warm in CaaS or Kubernetes cluster can be costly. Besides, Serverlessly microservices can also be deployed in Containers if the need arises.
Your CI/CD pipeline can change Platform Adapter on the fly to make you truly go multi-cloud (for increasing service availability, decreasing latency etc). Serverlessly will offer tooling to make that easy.
Middlewares may look outdated, but they aren't. Currently, countless mankind hours get wasted solving same common problems because big cloud providers didn't bother to think about building middleware ecosystems for their FaaS offerings. For example, if you look at security middleware Helmet for Express, it's useful even to microservices.
Step-through debugging a microservice involves bringing FaaS execution environment locally which isn't always piece of cake. With Serverlessly, you can change to a Platform Adapter for self-managed infrastructure & debug your code normally (For Typescript, if you want to avoid compilation, you can run node --inspect-brk -r ts-node/register your-microservice.ts or node --inspect -r ts-node/register your-microservice.ts before attaching your favorite debugging client over inspector protocol as usual).
A Serverlessly Protocol represents a network protocol like http, ws etc. It glues together multiple parts of Serverlessly system.
Official npm packages for protocols: @serverlessly/protocol-*
Third-party npm packages for protocols: serverlessly-protocol-*
Internal state of a Serverlessly Protocol.
Modular consumer code which can be shared across organization or the world.
A Middleware Engine is responsible to process middlewares. Here, by processing, it's meant that it initializes the middlewares (if required), glue them together, creates a new Protocol Context using the glued code (which has consumer code) & register the Protocol Context to Serverlessly Protocol.
Note: In the entire lifespan of a Serverlessly microservice, a Middleware Engine runs only once (only during cold boot on FaaS), so it isn't a performance overhead.
Official npm packages for middleware engines: @serverlessly/[protocol]-mengine-*
Third-party npm packages for middleware engines: serverlessly-[protocol]-mengine-*
A Platform represents a specific execution environment. AWS Lambda, Azure Function, Self-managed Node.js environment etc are all examples of Platform.
A Platform Adapter makes it possible to run a Serverlessly microservice on a specific platform like AWS Lambda, Azure Functions etc. It does the translation from the Platform to Serverlessly Protocol Context & vice versa.
Note: In the entire lifespan of a Serverlessly microservice, a Platform Adapter runs only once (on FaaS, only during cold boot), so it isn't a performance overhead.
Official npm packages for platform adapters: @serverlessly/[protocol]-platform-*
Third-party npm packages for platform adapters: serverlessly-[protocol]-platform-*
