Alternatives to Azure Functions logo

Alternatives to Azure Functions

AWS Lambda, Serverless, Cloud Functions for Firebase, Google Cloud Functions, and Apex are the most popular alternatives and competitors to Azure Functions.
177
145
+ 1
23

What is Azure Functions and what are its top alternatives?

Azure Functions is an event driven, compute-on-demand experience that extends the existing Azure application platform with capabilities to implement code triggered by events occurring in virtually any Azure or 3rd party service as well as on-premises systems.
Azure Functions is a tool in the Serverless / Task Processing category of a tech stack.

Azure Functions alternatives & related posts

AWS Lambda logo

AWS Lambda

4.9K
3.4K
383
4.9K
3.4K
+ 1
383
Automatically run code in response to modifications to objects in Amazon S3 buckets, messages in Kinesis streams, or...
AWS Lambda logo
AWS Lambda
VS
Azure Functions logo
Azure Functions

related AWS Lambda posts

Jeyabalaji Subramanian
Jeyabalaji Subramanian
CTO at FundsCorner | 24 upvotes 281.7K views
atFundsCornerFundsCorner
Zappa
Zappa
AWS Lambda
AWS Lambda
SQLAlchemy
SQLAlchemy
Python
Python
Amazon SQS
Amazon SQS
Node.js
Node.js
MongoDB Stitch
MongoDB Stitch
PostgreSQL
PostgreSQL
MongoDB
MongoDB

Recently we were looking at a few robust and cost-effective ways of replicating the data that resides in our production MongoDB to a PostgreSQL database for data warehousing and business intelligence.

We set ourselves the following criteria for the optimal tool that would do this job: - The data replication must be near real-time, yet it should NOT impact the production database - The data replication must be horizontally scalable (based on the load), asynchronous & crash-resilient

Based on the above criteria, we selected the following tools to perform the end to end data replication:

We chose MongoDB Stitch for picking up the changes in the source database. It is the serverless platform from MongoDB. One of the services offered by MongoDB Stitch is Stitch Triggers. Using stitch triggers, you can execute a serverless function (in Node.js) in real time in response to changes in the database. When there are a lot of database changes, Stitch automatically "feeds forward" these changes through an asynchronous queue.

We chose Amazon SQS as the pipe / message backbone for communicating the changes from MongoDB to our own replication service. Interestingly enough, MongoDB stitch offers integration with AWS services.

In the Node.js function, we wrote minimal functionality to communicate the database changes (insert / update / delete / replace) to Amazon SQS.

Next we wrote a minimal micro-service in Python to listen to the message events on SQS, pickup the data payload & mirror the DB changes on to the target Data warehouse. We implemented source data to target data translation by modelling target table structures through SQLAlchemy . We deployed this micro-service as AWS Lambda with Zappa. With Zappa, deploying your services as event-driven & horizontally scalable Lambda service is dumb-easy.

In the end, we got to implement a highly scalable near realtime Change Data Replication service that "works" and deployed to production in a matter of few days!

See more
Julien DeFrance
Julien DeFrance
Principal Software Engineer at Tophatter | 16 upvotes 388K views
atSmartZipSmartZip
Amazon DynamoDB
Amazon DynamoDB
Ruby
Ruby
Node.js
Node.js
AWS Lambda
AWS Lambda
New Relic
New Relic
Amazon Elasticsearch Service
Amazon Elasticsearch Service
Elasticsearch
Elasticsearch
Superset
Superset
Amazon Quicksight
Amazon Quicksight
Amazon Redshift
Amazon Redshift
Zapier
Zapier
Segment
Segment
Amazon CloudFront
Amazon CloudFront
Memcached
Memcached
Amazon ElastiCache
Amazon ElastiCache
Amazon RDS for Aurora
Amazon RDS for Aurora
MySQL
MySQL
Amazon RDS
Amazon RDS
Amazon S3
Amazon S3
Docker
Docker
Capistrano
Capistrano
AWS Elastic Beanstalk
AWS Elastic Beanstalk
Rails API
Rails API
Rails
Rails
Algolia
Algolia

Back in 2014, I was given an opportunity to re-architect SmartZip Analytics platform, and flagship product: SmartTargeting. This is a SaaS software helping real estate professionals keeping up with their prospects and leads in a given neighborhood/territory, finding out (thanks to predictive analytics) who's the most likely to list/sell their home, and running cross-channel marketing automation against them: direct mail, online ads, email... The company also does provide Data APIs to Enterprise customers.

I had inherited years and years of technical debt and I knew things had to change radically. The first enabler to this was to make use of the cloud and go with AWS, so we would stop re-inventing the wheel, and build around managed/scalable services.

For the SaaS product, we kept on working with Rails as this was what my team had the most knowledge in. We've however broken up the monolith and decoupled the front-end application from the backend thanks to the use of Rails API so we'd get independently scalable micro-services from now on.

Our various applications could now be deployed using AWS Elastic Beanstalk so we wouldn't waste any more efforts writing time-consuming Capistrano deployment scripts for instance. Combined with Docker so our application would run within its own container, independently from the underlying host configuration.

Storage-wise, we went with Amazon S3 and ditched any pre-existing local or network storage people used to deal with in our legacy systems. On the database side: Amazon RDS / MySQL initially. Ultimately migrated to Amazon RDS for Aurora / MySQL when it got released. Once again, here you need a managed service your cloud provider handles for you.

Future improvements / technology decisions included:

Caching: Amazon ElastiCache / Memcached CDN: Amazon CloudFront Systems Integration: Segment / Zapier Data-warehousing: Amazon Redshift BI: Amazon Quicksight / Superset Search: Elasticsearch / Amazon Elasticsearch Service / Algolia Monitoring: New Relic

As our usage grows, patterns changed, and/or our business needs evolved, my role as Engineering Manager then Director of Engineering was also to ensure my team kept on learning and innovating, while delivering on business value.

One of these innovations was to get ourselves into Serverless : Adopting AWS Lambda was a big step forward. At the time, only available for Node.js (Not Ruby ) but a great way to handle cost efficiency, unpredictable traffic, sudden bursts of traffic... Ultimately you want the whole chain of services involved in a call to be serverless, and that's when we've started leveraging Amazon DynamoDB on these projects so they'd be fully scalable.

See more
Serverless logo

Serverless

460
367
17
460
367
+ 1
17
The most widely-adopted toolkit for building serverless applications
Serverless logo
Serverless
VS
Azure Functions logo
Azure Functions

related Serverless posts

Praveen Mooli
Praveen Mooli
Technical Leader at Taylor and Francis | 11 upvotes 164K views
MongoDB Atlas
MongoDB Atlas
Amazon S3
Amazon S3
Amazon DynamoDB
Amazon DynamoDB
Amazon RDS
Amazon RDS
Serverless
Serverless
Docker
Docker
Terraform
Terraform
Travis CI
Travis CI
GitHub
GitHub
RxJS
RxJS
Angular 2
Angular 2
AWS Lambda
AWS Lambda
Amazon SQS
Amazon SQS
Amazon SNS
Amazon SNS
Amazon Kinesis Firehose
Amazon Kinesis Firehose
Amazon Kinesis
Amazon Kinesis
Flask
Flask
Python
Python
ExpressJS
ExpressJS
Node.js
Node.js
Spring Boot
Spring Boot
Java
Java
#Data
#Devops
#Webapps
#Eventsourcingframework
#Microservices
#Backend

We are in the process of building a modern content platform to deliver our content through various channels. We decided to go with Microservices architecture as we wanted scale. Microservice architecture style is an approach to developing an application as a suite of small independently deployable services built around specific business capabilities. You can gain modularity, extensive parallelism and cost-effective scaling by deploying services across many distributed servers. Microservices modularity facilitates independent updates/deployments, and helps to avoid single point of failure, which can help prevent large-scale outages. We also decided to use Event Driven Architecture pattern which is a popular distributed asynchronous architecture pattern used to produce highly scalable applications. The event-driven architecture is made up of highly decoupled, single-purpose event processing components that asynchronously receive and process events.

To build our #Backend capabilities we decided to use the following: 1. #Microservices - Java with Spring Boot , Node.js with ExpressJS and Python with Flask 2. #Eventsourcingframework - Amazon Kinesis , Amazon Kinesis Firehose , Amazon SNS , Amazon SQS, AWS Lambda 3. #Data - Amazon RDS , Amazon DynamoDB , Amazon S3 , MongoDB Atlas

To build #Webapps we decided to use Angular 2 with RxJS

#Devops - GitHub , Travis CI , Terraform , Docker , Serverless

See more
Nitzan Shapira
Nitzan Shapira
at Epsagon | 11 upvotes 107.1K views
atEpsagonEpsagon
AWS Lambda
AWS Lambda
GitHub
GitHub
Java
Java
Go
Go
Node.js
Node.js
npm
npm
Serverless
Serverless
Python
Python

At Epsagon, we use hundreds of AWS Lambda functions, most of them are written in Python, and the Serverless Framework to pack and deploy them. One of the issues we've encountered is the difficulty to package external libraries into the Lambda environment using the Serverless Framework. This limitation is probably by design since the external code your Lambda needs can be usually included with a package manager.

In order to overcome this issue, we've developed a tool, which we also published as open-source (see link below), which automatically packs these libraries using a simple npm package and a YAML configuration file. Support for Node.js, Go, and Java will be available soon.

The GitHub respoitory: https://github.com/epsagon/serverless-package-external

See more
Cloud Functions for Firebase logo

Cloud Functions for Firebase

239
195
1
239
195
+ 1
1
Run your mobile backend code without managing servers
Cloud Functions for Firebase logo
Cloud Functions for Firebase
VS
Azure Functions logo
Azure Functions

related Cloud Functions for Firebase posts

Aliadoc Team
Aliadoc Team
at aliadoc.com | 5 upvotes 88.3K views
atAliadocAliadoc
Bitbucket
Bitbucket
Visual Studio Code
Visual Studio Code
Serverless
Serverless
Google Cloud Storage
Google Cloud Storage
Google App Engine
Google App Engine
Cloud Functions for Firebase
Cloud Functions for Firebase
Firebase
Firebase
CloudFlare
CloudFlare
Create React App
Create React App
React
React
#Aliadoc

In #Aliadoc, we're exploring the crowdfunding option to get traction before launch. We are building a SaaS platform for website design customization.

For the Admin UI and website editor we use React and we're currently transitioning from a Create React App setup to a custom one because our needs have become more specific. We use CloudFlare as much as possible, it's a great service.

For routing dynamic resources and proxy tasks to feed websites to the editor we leverage CloudFlare Workers for improved responsiveness. We use Firebase for our hosting needs and user authentication while also using several Cloud Functions for Firebase to interact with other services along with Google App Engine and Google Cloud Storage, but also the Real Time Database is on the radar for collaborative website editing.

We generally hate configuration but honestly because of the stage of our project we lack resources for doing heavy sysops work. So we are basically just relying on Serverless technologies as much as we can to do all server side processing.

Visual Studio Code definitively makes programming a much easier and enjoyable task, we just love it. We combine it with Bitbucket for our source code control needs.

See more
Google Cloud Functions logo

Google Cloud Functions

186
130
8
186
130
+ 1
8
A serverless environment to build and connect cloud services
Google Cloud Functions logo
Google Cloud Functions
VS
Azure Functions logo
Azure Functions

related Google Cloud Functions posts

Kestas Barzdaitis
Kestas Barzdaitis
Entrepreneur & Engineer | 12 upvotes 62K views
atCodeFactorCodeFactor
Google Cloud Functions
Google Cloud Functions
Azure Functions
Azure Functions
AWS Lambda
AWS Lambda
Docker
Docker
Google Compute Engine
Google Compute Engine
Microsoft Azure
Microsoft Azure
Amazon EC2
Amazon EC2
CodeFactor.io
CodeFactor.io
Kubernetes
Kubernetes
#SAAS
#IAAS
#Containerization
#Autoscale
#Startup
#Automation
#Machinelearning
#AI
#Devops

CodeFactor being a #SAAS product, our goal was to run on a cloud-native infrastructure since day one. We wanted to stay product focused, rather than having to work on the infrastructure that supports the application. We needed a cloud-hosting provider that would be reliable, economical and most efficient for our product.

CodeFactor.io aims to provide an automated and frictionless code review service for software developers. That requires agility, instant provisioning, autoscaling, security, availability and compliance management features. We looked at the top three #IAAS providers that take up the majority of market share: Amazon's Amazon EC2 , Microsoft's Microsoft Azure, and Google Compute Engine.

AWS has been available since 2006 and has developed the most extensive services ant tools variety at a massive scale. Azure and GCP are about half the AWS age, but also satisfied our technical requirements.

It is worth noting that even though all three providers support Docker containerization services, GCP has the most robust offering due to their investments in Kubernetes. Also, if you are a Microsoft shop, and develop in .NET - Visual Studio Azure shines at integration there and all your existing .NET code works seamlessly on Azure. All three providers have serverless computing offerings (AWS Lambda, Azure Functions, and Google Cloud Functions). Additionally, all three providers have machine learning tools, but GCP appears to be the most developer-friendly, intuitive and complete when it comes to #Machinelearning and #AI.

The prices between providers are competitive across the board. For our requirements, AWS would have been the most expensive, GCP the least expensive and Azure was in the middle. Plus, if you #Autoscale frequently with large deltas, note that Azure and GCP have per minute billing, where AWS bills you per hour. We also applied for the #Startup programs with all three providers, and this is where Azure shined. While AWS and GCP for startups would have covered us for about one year of infrastructure costs, Azure Sponsorship would cover about two years of CodeFactor's hosting costs. Moreover, Azure Team was terrific - I felt that they wanted to work with us where for AWS and GCP we were just another startup.

In summary, we were leaning towards GCP. GCP's advantages in containerization, automation toolset, #Devops mindset, and pricing were the driving factors there. Nevertheless, we could not say no to Azure's financial incentives and a strong sense of partnership and support throughout the process.

Bottom line is, IAAS offerings with AWS, Azure, and GCP are evolving fast. At CodeFactor, we aim to be platform agnostic where it is practical and retain the flexibility to cherry-pick the best products across providers.

See more
Tim Nolet
Tim Nolet
Founder, Engineer & Dishwasher at Checkly | 5 upvotes 20.8K views
atChecklyHQChecklyHQ
Node.js
Node.js
Google Cloud Functions
Google Cloud Functions
Azure Functions
Azure Functions
Amazon CloudWatch
Amazon CloudWatch
Serverless
Serverless
AWS Lambda
AWS Lambda

AWS Lambda Serverless Amazon CloudWatch Azure Functions Google Cloud Functions Node.js

In the last year or so, I moved all Checkly monitoring workloads to AWS Lambda. Here are some stats:

  • We run three core functions in all AWS regions. They handle API checks, browser checks and setup / teardown scripts. Check our docs to find out what that means.
  • All functions are hooked up to SNS topics but can also be triggered directly through AWS SDK calls.
  • The busiest function is a plumbing function that forwards data to our database. It is invoked anywhere between 7000 and 10.000 times per hour with an average duration of about 179 ms.
  • We run separate dev and test versions of each function in each region.

Moving all this to AWS Lambda took some work and considerations. The blog post linked below goes into the following topics:

  • Why Lambda is an almost perfect match for SaaS. Especially when you're small.
  • Why I don't use a "big" framework around it.
  • Why distributed background jobs triggered by queues are Lambda's raison d'锚tre.
  • Why monitoring & logging is still an issue.

https://blog.checklyhq.com/how-i-made-aws-lambda-work-for-my-saas/

See more
Apex logo

Apex

57
51
0
57
51
+ 1
0
Serverless Architecture with AWS Lambda
    Be the first to leave a pro
    Apex logo
    Apex
    VS
    Azure Functions logo
    Azure Functions
    Zappa logo

    Zappa

    29
    25
    0
    29
    25
    + 1
    0
    Deploy all Python WSGI applications on AWS Lambda + API Gateway.
      Be the first to leave a pro
      Zappa logo
      Zappa
      VS
      Azure Functions logo
      Azure Functions

      related Zappa posts

      Jeyabalaji Subramanian
      Jeyabalaji Subramanian
      CTO at FundsCorner | 24 upvotes 281.7K views
      atFundsCornerFundsCorner
      Zappa
      Zappa
      AWS Lambda
      AWS Lambda
      SQLAlchemy
      SQLAlchemy
      Python
      Python
      Amazon SQS
      Amazon SQS
      Node.js
      Node.js
      MongoDB Stitch
      MongoDB Stitch
      PostgreSQL
      PostgreSQL
      MongoDB
      MongoDB

      Recently we were looking at a few robust and cost-effective ways of replicating the data that resides in our production MongoDB to a PostgreSQL database for data warehousing and business intelligence.

      We set ourselves the following criteria for the optimal tool that would do this job: - The data replication must be near real-time, yet it should NOT impact the production database - The data replication must be horizontally scalable (based on the load), asynchronous & crash-resilient

      Based on the above criteria, we selected the following tools to perform the end to end data replication:

      We chose MongoDB Stitch for picking up the changes in the source database. It is the serverless platform from MongoDB. One of the services offered by MongoDB Stitch is Stitch Triggers. Using stitch triggers, you can execute a serverless function (in Node.js) in real time in response to changes in the database. When there are a lot of database changes, Stitch automatically "feeds forward" these changes through an asynchronous queue.

      We chose Amazon SQS as the pipe / message backbone for communicating the changes from MongoDB to our own replication service. Interestingly enough, MongoDB stitch offers integration with AWS services.

      In the Node.js function, we wrote minimal functionality to communicate the database changes (insert / update / delete / replace) to Amazon SQS.

      Next we wrote a minimal micro-service in Python to listen to the message events on SQS, pickup the data payload & mirror the DB changes on to the target Data warehouse. We implemented source data to target data translation by modelling target table structures through SQLAlchemy . We deployed this micro-service as AWS Lambda with Zappa. With Zappa, deploying your services as event-driven & horizontally scalable Lambda service is dumb-easy.

      In the end, we got to implement a highly scalable near realtime Change Data Replication service that "works" and deployed to production in a matter of few days!

      See more
      Jeyabalaji Subramanian
      Jeyabalaji Subramanian
      CTO at FundsCorner | 12 upvotes 336.8K views
      atFundsCornerFundsCorner
      Amazon SQS
      Amazon SQS
      Sentry
      Sentry
      GitLab CI
      GitLab CI
      Slack
      Slack
      Google Compute Engine
      Google Compute Engine
      Netlify
      Netlify
      AWS Lambda
      AWS Lambda
      Zappa
      Zappa
      vuex
      vuex
      Vuetify
      Vuetify
      Vue.js
      Vue.js
      Swagger UI
      Swagger UI
      MongoDB
      MongoDB
      Flask
      Flask
      Python
      Python

      At FundsCorner, we are on a mission to enable fast accessible credit to India鈥檚 Kirana Stores. We are an early stage startup with an ultra small Engineering team. All the tech decisions we have made until now are based on our core philosophy: "Build usable products fast".

      Based on the above fundamentals, we chose Python as our base language for all our APIs and micro-services. It is ultra easy to start with, yet provides great libraries even for the most complex of use cases. Our entire backend stack runs on Python and we cannot be more happy with it! If you are looking to deploy your API as server-less, Python provides one of the least cold start times.

      We build our APIs with Flask. For backend database, our natural choice was MongoDB. It frees up our time from complex database specifications - we instead use our time in doing sensible data modelling & once we finalize the data model, we integrate it into Flask using Swagger UI. Mongo supports complex queries to cull out difficult data through aggregation framework & we have even built an internal framework called "Poetry", for aggregation queries.

      Our web apps are built on Vue.js , Vuetify and vuex. Initially we debated a lot around choosing Vue.js or React , but finally settled with Vue.js, mainly because of the ease of use, fast development cycles & awesome set of libraries and utilities backing Vue.

      You simply cannot go wrong with Vue.js . Great documentation, the library is ultra compact & is blazing fast. Choosing Vue.js was one of the critical decisions made, which enabled us to launch our web app in under a month (which otherwise would have taken 3 months easily). For those folks who are looking for big names, Adobe, and Alibaba and Gitlab are using Vue.

      By choosing Vuetify, we saved thousands of person hours in designing the CSS files. Vuetify contains all key material components for designing a smooth User experience & it just works! It's an awesome framework. All of us at FundsCorner are now lifelong fanboys of Vue.js and Vuetify.

      On the infrastructure side, all our API services and backend services are deployed as server less micro-services through Zappa. Zappa makes your life super easy by packaging everything that is required to deploy your code as AWS Lambda. We are now addicted to the single - click deploys / updates through Zappa. Try it out & you will convert!

      Also, if you are using Zappa, you can greatly simplify your CI / CD pipelines. Do try it! It's just awesome! and... you will be astonished by the savings you have made on AWS bills at end of the month.

      Our CI / CD pipelines are built using GitLab CI. The documentation is very good & it enables you to go from from concept to production in minimal time frame.

      We use Sentry for all crash reporting and resolution. Pro tip, they do have handlers for AWS Lambda , which made our integration super easy.

      All our micro-services including APIs are event-driven. Our background micro-services are message oriented & we use Amazon SQS as our message pipe. We have our own in-house workflow manager to orchestrate across micro - services.

      We host our static websites on Netlify. One of the cool things about Netlify is the automated CI / CD on git push. You just do a git push to deploy! Again, it is super simple to use and it just works. We were dogmatic about going server less even on static web sites & you can go server less on Netlify in a few minutes. It's just a few clicks away.

      We use Google Compute Engine, especially Google Vision for our AI experiments.

      For Ops automation, we use Slack. Slack provides a super-rich API (through Slack App) through which you can weave magical automation on boring ops tasks.

      See more

      related Google Cloud Run posts

      Google Cloud Functions
      Google Cloud Functions
      Google Cloud Run
      Google Cloud Run

      I use Google Cloud Run because it's like bring your own docker image to Google Cloud Functions.

      I use it for building Dash Apps

      It creates a nice url for web apps, and I see it being the evolution of serverless if GCP can scale this up.

      My Real-Time Python App Example

      See more
      Knative logo

      Knative

      23
      31
      11
      23
      31
      + 1
      11
      Kubernetes-based platform for serverless workloads
      Knative logo
      Knative
      VS
      Azure Functions logo
      Azure Functions
      Chalice logo

      Chalice

      21
      24
      0
      21
      24
      + 1
      0
      Python Serverless Microframework for AWS (by Amazon)
        Be the first to leave a pro
        Chalice logo
        Chalice
        VS
        Azure Functions logo
        Azure Functions
        Kubeless logo

        Kubeless

        18
        32
        0
        18
        32
        + 1
        0
        Kubernetes Native Serverless Framework
          Be the first to leave a pro
          Kubeless logo
          Kubeless
          VS
          Azure Functions logo
          Azure Functions
          OpenFaaS logo

          OpenFaaS

          17
          26
          4
          17
          26
          + 1
          4
          Serverless Functions Made Simple for Kubernetes and Docker
          OpenFaaS logo
          OpenFaaS
          VS
          Azure Functions logo
          Azure Functions
          AWS Batch logo

          AWS Batch

          17
          4
          0
          17
          4
          + 1
          0
          Fully Managed Batch Processing at Any Scale
            Be the first to leave a pro
            AWS Batch logo
            AWS Batch
            VS
            Azure Functions logo
            Azure Functions
            Architect logo

            Architect

            15
            58
            0
            15
            58
            + 1
            0
            The simplest, most powerful way to build serverless applications
              Be the first to leave a pro
              Architect logo
              Architect
              VS
              Azure Functions logo
              Azure Functions
              Apache OpenWhisk logo

              Apache OpenWhisk

              14
              39
              1
              14
              39
              + 1
              1
              A serverless, open-source cloud platform
              Apache OpenWhisk logo
              Apache OpenWhisk
              VS
              Azure Functions logo
              Azure Functions
              Graphcool Framework logo

              Graphcool Framework

              13
              14
              1
              13
              14
              + 1
              1
              鈿★笍 Framework to develop & deploy serverless GraphQL backends
              Graphcool Framework logo
              Graphcool Framework
              VS
              Azure Functions logo
              Azure Functions
              Fission logo

              Fission

              11
              20
              0
              11
              20
              + 1
              0
              Serverless Functions as a Service for Kubernetes
                Be the first to leave a pro
                Fission logo
                Fission
                VS
                Azure Functions logo
                Azure Functions
                stdlib logo

                stdlib

                7
                2
                0
                7
                2
                + 1
                0
                The Standard Library for Functions as a Service
                  Be the first to leave a pro
                  stdlib logo
                  stdlib
                  VS
                  Azure Functions logo
                  Azure Functions
                  1backend logo

                  1backend

                  7
                  12
                  1
                  7
                  12
                  + 1
                  1
                  An open-source Github-like platform as an alternative for AWS Lambda
                  1backend logo
                  1backend
                  VS
                  Azure Functions logo
                  Azure Functions
                  Effe logo

                  Effe

                  7
                  4
                  0
                  7
                  4
                  + 1
                  0
                  A building block for an open source AWS lambda
                    Be the first to leave a pro
                    Effe logo
                    Effe
                    VS
                    Azure Functions logo
                    Azure Functions