Alternatives to AWS Lambda logo
Serverless, AWS Elastic Beanstalk, Azure Functions, AWS Step Functions, and Google App Engine are the most popular alternatives and competitors to AWS Lambda.
4.6K
3.2K
+ 1
377

What is AWS Lambda?

AWS Lambda is a compute service that runs your code in response to events and automatically manages the underlying compute resources for you. You can use AWS Lambda to extend other AWS services with custom logic, or create your own back-end services that operate at AWS scale, performance, and security.
AWS Lambda is a tool in the Serverless / Task Processing category of a tech stack.

AWS Lambda alternatives & related posts

Serverless logo

Serverless

431
340
17
431
340
+ 1
17
The most widely-adopted toolkit for building serverless applications
Serverless logo
VS
AWS Lambda logo
Compare Serverless vs AWS Lambda
Serverless logo
Serverless
VS
AWS Lambda logo
AWS Lambda

related Serverless posts

Praveen Mooli
Praveen Mooli
Technical Leader at Taylor and Francis · | 11 upvotes · 36.7K 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 · | 10 upvotes · 86.3K 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

related AWS Elastic Beanstalk posts

Julien DeFrance
Julien DeFrance
Full Stack Engineering Manager at ValiMail · | 16 upvotes · 182.5K 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
Amazon ElastiCache
Amazon ElastiCache
Amazon Elasticsearch Service
Amazon Elasticsearch Service
AWS Elastic Load Balancing (ELB)
AWS Elastic Load Balancing (ELB)
Memcached
Memcached
Redis
Redis
Python
Python
AWS Lambda
AWS Lambda
Amazon RDS
Amazon RDS
Microsoft SQL Server
Microsoft SQL Server
MariaDB
MariaDB
Amazon RDS for PostgreSQL
Amazon RDS for PostgreSQL
Rails
Rails
Ruby
Ruby
Heroku
Heroku
AWS Elastic Beanstalk
AWS Elastic Beanstalk

We initially started out with Heroku as our PaaS provider due to a desire to use it by our original developer for our Ruby on Rails application/website at the time. We were finding response times slow, it was painfully slow, sometimes taking 10 seconds to start loading the main page. Moving up to the next "compute" level was going to be very expensive.

We moved our site over to AWS Elastic Beanstalk , not only did response times on the site practically become instant, our cloud bill for the application was cut in half.

In database world we are currently using Amazon RDS for PostgreSQL also, we have both MariaDB and Microsoft SQL Server both hosted on Amazon RDS. The plan is to migrate to AWS Aurora Serverless for all 3 of those database systems.

Additional services we use for our public applications: AWS Lambda, Python, Redis, Memcached, AWS Elastic Load Balancing (ELB), Amazon Elasticsearch Service, Amazon ElastiCache

See more

related Azure Functions posts

Kestas Barzdaitis
Kestas Barzdaitis
Entrepreneur & Engineer · | 12 upvotes · 31.9K 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
Michal Nowak
Michal Nowak
Co-founder at Evojam · | 6 upvotes · 38.2K views
atEvojamEvojam
Azure Functions
Azure Functions
Firebase
Firebase
AWS Lambda
AWS Lambda
Serverless
Serverless

In a couple of recent projects we had an opportunity to try out the new Serverless approach to building web applications. It wasn't necessarily a question if we should use any particular vendor but rather "if" we can consider serverless a viable option for building apps. Obviously our goal was also to get a feel for this technology and gain some hands-on experience.

We did consider AWS Lambda, Firebase from Google as well as Azure Functions. Eventually we went with AWS Lambdas.

PROS
  • No servers to manage (obviously!)
  • Limited fixed costs – you pay only for used time
  • Automated scaling and balancing
  • Automatic failover (or, at this level of abstraction, no failover problem at all)
  • Security easier to provide and audit
  • Low overhead at the start (with the certain level of knowledge)
  • Short time to market
  • Easy handover - deployment coupled with code
  • Perfect choice for lean startups with fast-paced iterations
  • Augmentation for the classic cloud, server(full) approach
CONS
  • Not much know-how and best practices available about structuring the code and projects on the market
  • Not suitable for complex business logic due to the risk of producing highly coupled code
  • Cost difficult to estimate (helpful tools: serverlesscalc.com)
  • Difficulty in migration to other platforms (Vendor lock⚠️)
  • Little engineers with experience in serverless on the job market
  • Steep learning curve for engineers without any cloud experience

More details are on our blog: https://evojam.com/blog/2018/12/5/should-you-go-serverless-meet-the-benefits-and-flaws-of-new-wave-of-cloud-solutions I hope it helps 🙌 & I'm curious of your experiences.

See more
AWS Step Functions logo

AWS Step Functions

56
37
0
56
37
+ 1
0
Build Distributed Applications Using Visual Workflows
    Be the first to leave a pro
    AWS Step Functions logo
    VS
    AWS Lambda logo
    Compare AWS Step Functions vs AWS Lambda
    AWS Step Functions logo
    AWS Step Functions
    VS
    AWS Lambda logo
    AWS Lambda

    related Google App Engine posts

    Nick Rockwell
    Nick Rockwell
    CTO at NY Times · | 9 upvotes · 9.8K views
    atThe New York TimesThe New York Times
    Kubernetes
    Kubernetes
    Google Kubernetes Engine
    Google Kubernetes Engine
    Google App Engine
    Google App Engine
    Amazon EC2
    Amazon EC2
    #Migration
    #Cloudmigration
    #AWStoGCPmigration
    #GCP
    #AWS

    So, the shift from Amazon EC2 to Google App Engine and generally #AWS to #GCP was a long decision and in the end, it's one that we've taken with eyes open and that we reserve the right to modify at any time. And to be clear, we continue to do a lot of stuff with AWS. But, by default, the content of the decision was, for our consumer-facing products, we're going to use GCP first. And if there's some reason why we don't think that's going to work out great, then we'll happily use AWS. In practice, that hasn't really happened. We've been able to meet almost 100% of our needs in GCP.

    So it's basically mostly Google Kubernetes Engine , we're mostly running stuff on Kubernetes right now.

    #AWStoGCPmigration #cloudmigration #migration

    See more
    AWS Batch logo

    AWS Batch

    16
    3
    0
    16
    3
    + 1
    0
    Fully Managed Batch Processing at Any Scale
      Be the first to leave a pro
      AWS Batch logo
      VS
      AWS Lambda logo
      Compare AWS Batch vs AWS Lambda
      AWS Batch logo
      AWS Batch
      VS
      AWS Lambda logo
      AWS Lambda
      AWS Fargate logo

      AWS Fargate

      94
      48
      0
      94
      48
      + 1
      0
      Run Containers Without Managing Infrastructure
        Be the first to leave a pro
        AWS Fargate logo
        VS
        AWS Lambda logo
        Compare AWS Fargate vs AWS Lambda
        AWS Fargate logo
        AWS Fargate
        VS
        AWS Lambda logo
        AWS Lambda
        Cloud Functions for Firebase logo

        Cloud Functions for Firebase

        213
        173
        0
        213
        173
        + 1
        0
        Run your mobile backend code without managing servers
          Be the first to leave a pro
          Cloud Functions for Firebase logo
          VS
          AWS Lambda logo
          Compare Cloud Functions for Firebase vs AWS Lambda
          Cloud Functions for Firebase logo
          Cloud Functions for Firebase
          VS
          AWS Lambda logo
          AWS Lambda

          related Cloud Functions for Firebase posts

          Aliadoc Team
          Aliadoc Team
          at aliadoc.com · | 5 upvotes · 32.2K 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

          170
          116
          8
          170
          116
          + 1
          8
          A serverless environment to build and connect cloud services
          Google Cloud Functions logo
          VS
          AWS Lambda logo
          Compare Google Cloud Functions vs AWS Lambda
          Google Cloud Functions logo
          Google Cloud Functions
          VS
          AWS Lambda logo
          AWS Lambda

          related Google Cloud Functions posts

          Kestas Barzdaitis
          Kestas Barzdaitis
          Entrepreneur & Engineer · | 12 upvotes · 31.9K 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 · 8.9K 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

          54
          47
          0
          54
          47
          + 1
          0
          Serverless Architecture with AWS Lambda
            Be the first to leave a pro
            Apex logo
            VS
            AWS Lambda logo
            Compare Apex vs AWS Lambda
            Apex logo
            Apex
            VS
            AWS Lambda logo
            AWS Lambda
            Zappa logo

            Zappa

            28
            24
            0
            28
            24
            + 1
            0
            Deploy all Python WSGI applications on AWS Lambda + API Gateway.
              Be the first to leave a pro
              Zappa logo
              VS
              AWS Lambda logo
              Compare Zappa vs AWS Lambda
              Zappa logo
              Zappa
              VS
              AWS Lambda logo
              AWS Lambda

              related Zappa posts

              Jeyabalaji Subramanian
              Jeyabalaji Subramanian
              CTO at FundsCorner · | 23 upvotes · 144.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 · 283K 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’s 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
              Knative logo

              Knative

              19
              20
              11
              19
              20
              + 1
              11
              Kubernetes-based platform for serverless workloads
              Knative logo
              VS
              AWS Lambda logo
              Compare Knative vs AWS Lambda
              Knative logo
              Knative
              VS
              AWS Lambda logo
              AWS Lambda

              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
              Chalice logo

              Chalice

              18
              21
              0
              18
              21
              + 1
              0
              Python Serverless Microframework for AWS (by Amazon)
                Be the first to leave a pro
                Chalice logo
                VS
                AWS Lambda logo
                Compare Chalice vs AWS Lambda
                Chalice logo
                Chalice
                VS
                AWS Lambda logo
                AWS Lambda
                Kubeless logo

                Kubeless

                17
                30
                0
                17
                30
                + 1
                0
                Kubernetes Native Serverless Framework
                  Be the first to leave a pro
                  Kubeless logo
                  VS
                  AWS Lambda logo
                  Compare Kubeless vs AWS Lambda
                  Kubeless logo
                  Kubeless
                  VS
                  AWS Lambda logo
                  AWS Lambda
                  Graphcool Framework logo

                  Graphcool Framework

                  12
                  13
                  1
                  12
                  13
                  + 1
                  1
                  ⚡️ Framework to develop & deploy serverless GraphQL backends
                  Graphcool Framework logo
                  VS
                  AWS Lambda logo
                  Compare Graphcool Framework vs AWS Lambda
                  Graphcool Framework logo
                  Graphcool Framework
                  VS
                  AWS Lambda logo
                  AWS Lambda
                  Architect logo

                  Architect

                  12
                  55
                  0
                  12
                  55
                  + 1
                  0
                  The simplest, most powerful way to build serverless applications
                    Be the first to leave a pro
                    Architect logo
                    VS
                    AWS Lambda logo
                    Compare Architect vs AWS Lambda
                    Architect logo
                    Architect
                    VS
                    AWS Lambda logo
                    AWS Lambda
                    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
                      VS
                      AWS Lambda logo
                      Compare Fission vs AWS Lambda
                      Fission logo
                      Fission
                      VS
                      AWS Lambda logo
                      AWS Lambda
                      OpenFaaS logo

                      OpenFaaS

                      11
                      19
                      0
                      11
                      19
                      + 1
                      0
                      Serverless Functions Made Simple for Kubernetes and Docker
                        Be the first to leave a pro
                        OpenFaaS logo
                        VS
                        AWS Lambda logo
                        Compare OpenFaaS vs AWS Lambda
                        OpenFaaS logo
                        OpenFaaS
                        VS
                        AWS Lambda logo
                        AWS Lambda
                        Apache OpenWhisk logo

                        Apache OpenWhisk

                        10
                        38
                        1
                        10
                        38
                        + 1
                        1
                        A serverless, open-source cloud platform
                        Apache OpenWhisk logo
                        VS
                        AWS Lambda logo
                        Compare Apache OpenWhisk vs AWS Lambda
                        Apache OpenWhisk logo
                        Apache OpenWhisk
                        VS
                        AWS Lambda logo
                        AWS Lambda