Alternatives to AWS Elastic Beanstalk logo

Alternatives to AWS Elastic Beanstalk

Google App Engine, AWS CodeDeploy, Docker, AWS CloudFormation, and Azure App Service are the most popular alternatives and competitors to AWS Elastic Beanstalk.
1.3K
747
+ 1
230

What is AWS Elastic Beanstalk and what are its top alternatives?

Once you upload your application, Elastic Beanstalk automatically handles the deployment details of capacity provisioning, load balancing, auto-scaling, and application health monitoring.
AWS Elastic Beanstalk is a tool in the Platform as a Service category of a tech stack.

AWS Elastic Beanstalk alternatives & related posts

related Google App Engine posts

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

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

AWS CodeDeploy

173
96
36
173
96
+ 1
36
Coordinate application deployments to Amazon EC2 instances
AWS CodeDeploy logo
AWS CodeDeploy
VS
AWS Elastic Beanstalk logo
AWS Elastic Beanstalk

related AWS CodeDeploy posts

Chris McFadden
Chris McFadden
VP, Engineering at SparkPost · | 9 upvotes · 36.3K views
atSparkPostSparkPost
AWS CodeBuild
AWS CodeBuild
AWS CodeDeploy
AWS CodeDeploy
Amazon EC2 Container Service
Amazon EC2 Container Service
AWS Lambda
AWS Lambda
GitHub
GitHub

The recent move of our CI/CD tooling to AWS CodeBuild / AWS CodeDeploy (with GitHub ) as well as moving to Amazon EC2 Container Service / AWS Lambda for our deployment architecture for most of our services has helped us significantly reduce our deployment times while improving both feature velocity and overall reliability. In one extreme case, we got one service down from 90 minutes to a very reasonable 15 minutes. Container-based build and deployments have made so many things simpler and easier and the integration between the tools has been helpful. There is still some work to do on our service mesh & API proxy approach to further simplify our environment.

See more
Sathish Raju
Sathish Raju
Founder/CTO at Kloudio · | 5 upvotes · 13.6K views
atKloudioKloudio
Node.js
Node.js
Angular 2
Angular 2
React
React
TypeScript
TypeScript
Docker
Docker
AWS CodePipeline
AWS CodePipeline
AWS CodeDeploy
AWS CodeDeploy
AWS Lambda
AWS Lambda
#Kloudio.
#AWS

At Kloud.io we use Node.js for our backend Microservices and Angular 2 for the frontend. We also use React for a couple of our internal applications. Writing services in Node.js in TypeScript improved developer productivity and we could capture bugs way before they can occur in the production. The use of Angular 2 in our production environment reduced the time to release any new features. At the same time, we are also exploring React by using it in our internal tools. So far we enjoyed what React has to offer. We are an enterprise SAAS product and also offer an on-premise or hybrid cloud version of #kloudio. We heavily use Docker for shipping our on-premise version. We also use Docker internally for automated testing. Using Docker reduced the install time errors in customer environments. Our cloud version is deployed in #AWS. We use AWS CodePipeline and AWS CodeDeploy for our CI/CD. We also use AWS Lambda for automation jobs.

See more

related Docker posts

Tim Nolet
Tim Nolet
Founder, Engineer & Dishwasher at Checkly · | 19 upvotes · 267.3K views
atChecklyHQChecklyHQ
Heroku
Heroku
Docker
Docker
GitHub
GitHub
Node.js
Node.js
hapi
hapi
Vue.js
Vue.js
AWS Lambda
AWS Lambda
Amazon S3
Amazon S3
PostgreSQL
PostgreSQL
Knex.js
Knex.js
vuex
vuex

Heroku Docker GitHub Node.js hapi Vue.js AWS Lambda Amazon S3 PostgreSQL Knex.js Checkly is a fairly young company and we're still working hard to find the correct mix of product features, price and audience.

We are focussed on tech B2B, but I always wanted to serve solo developers too. So I decided to make a $7 plan.

Why $7? Simply put, it seems to be a sweet spot for tech companies: Heroku, Docker, Github, Appoptics (Librato) all offer $7 plans. They must have done a ton of research into this, so why not piggy back that and try it out.

Enough biz talk, onto tech. The challenges were:

  • Slice of a portion of the functionality so a $7 plan is still profitable. We call this the "plan limits"
  • Update API and back end services to handle and enforce plan limits.
  • Update the UI to kindly state plan limits are in effect on some part of the UI.
  • Update the pricing page to reflect all changes.
  • Keep the actual processing backend, storage and API's as untouched as possible.

In essence, we went from strictly volume based pricing to value based pricing. Here come the technical steps & decisions we made to get there.

  1. We updated our PostgreSQL schema so plans now have an array of "features". These are string constants that represent feature toggles.
  2. The Vue.js frontend reads these from the vuex store on login.
  3. Based on these values, the UI has simple v-if statements to either just show the feature or show a friendly "please upgrade" button.
  4. The hapi API has a hook on each relevant API endpoint that checks whether a user's plan has the feature enabled, or not.

Side note: We offer 10 SMS messages per month on the developer plan. However, we were not actually counting how many people were sending. We had to update our alerting daemon (that runs on Heroku and triggers SMS messages via AWS SNS) to actually bump a counter.

What we build is basically feature-toggling based on plan features. It is very extensible for future additions. Our scheduling and storage backend that actually runs users' monitoring requests (AWS Lambda) and stores the results (S3 and Postgres) has no knowledge of all of this and remained unchanged.

Hope this helps anyone building out their SaaS and is in a similar situation.

See more
Ganesa Vijayakumar
Ganesa Vijayakumar
Full Stack Coder | Module Lead · | 15 upvotes · 477.5K views
Codacy
Codacy
SonarQube
SonarQube
React
React
React Router
React Router
React Native
React Native
JavaScript
JavaScript
jQuery
jQuery
jQuery UI
jQuery UI
jQuery Mobile
jQuery Mobile
Bootstrap
Bootstrap
Java
Java
Node.js
Node.js
MySQL
MySQL
Hibernate
Hibernate
Heroku
Heroku
Amazon S3
Amazon S3
Amazon RDS
Amazon RDS
Solr
Solr
Elasticsearch
Elasticsearch
Amazon Route 53
Amazon Route 53
Microsoft Azure
Microsoft Azure
Amazon EC2 Container Service
Amazon EC2 Container Service
Apache Maven
Apache Maven
Git
Git
Docker
Docker

I'm planning to create a web application and also a mobile application to provide a very good shopping experience to the end customers. Shortly, my application will be aggregate the product details from difference sources and giving a clear picture to the user that when and where to buy that product with best in Quality and cost.

I have planned to develop this in many milestones for adding N number of features and I have picked my first part to complete the core part (aggregate the product details from different sources).

As per my work experience and knowledge, I have chosen the followings stacks to this mission.

UI: I would like to develop this application using React, React Router and React Native since I'm a little bit familiar on this and also most importantly these will help on developing both web and mobile apps. In addition, I'm gonna use the stacks JavaScript, jQuery, jQuery UI, jQuery Mobile, Bootstrap wherever required.

Service: I have planned to use Java as the main business layer language as I have 7+ years of experience on this I believe I can do better work using Java than other languages. In addition, I'm thinking to use the stacks Node.js.

Database and ORM: I'm gonna pick MySQL as DB and Hibernate as ORM since I have a piece of good knowledge and also work experience on this combination.

Search Engine: I need to deal with a large amount of product data and it's in-detailed info to provide enough details to end user at the same time I need to focus on the performance area too. so I have decided to use Solr as a search engine for product search and suggestions. In addition, I'm thinking to replace Solr by Elasticsearch once explored/reviewed enough about Elasticsearch.

Host: As of now, my plan to complete the application with decent features first and deploy it in a free hosting environment like Docker and Heroku and then once it is stable then I have planned to use the AWS products Amazon S3, EC2, Amazon RDS and Amazon Route 53. I'm not sure about Microsoft Azure that what is the specialty in it than Heroku and Amazon EC2 Container Service. Anyhow, I will do explore these once again and pick the best suite one for my requirement once I reached this level.

Build and Repositories: I have decided to choose Apache Maven and Git as these are my favorites and also so popular on respectively build and repositories.

Additional Utilities :) - I would like to choose Codacy for code review as their Startup plan will be very helpful to this application. I'm already experienced with Google CheckStyle and SonarQube even I'm looking something on Codacy.

Happy Coding! Suggestions are welcome! :)

Thanks, Ganesa

See more

related AWS CloudFormation posts

Joseph Kunzler
Joseph Kunzler
DevOps Engineer at Tillable · | 9 upvotes · 36.5K views
atTillableTillable
Amazon S3
Amazon S3
Amazon EC2
Amazon EC2
AWS Elastic Load Balancing (ELB)
AWS Elastic Load Balancing (ELB)
AWS CloudFormation
AWS CloudFormation
Terraform
Terraform

We use Terraform because we needed a way to automate the process of building and deploying feature branches. We wanted to hide the complexity such that when a dev creates a PR, it triggers a build and deployment without the dev having to worry about any of the 'plumbing' going on behind the scenes. Terraform allows us to automate the process of provisioning DNS records, Amazon S3 buckets, Amazon EC2 instances and AWS Elastic Load Balancing (ELB)'s. It also makes it easy to tear it all down when finished. We also like that it supports multiple clouds, which is why we chose to use it over AWS CloudFormation.

See more
Terraform
Terraform
Google Cloud Deployment Manager
Google Cloud Deployment Manager
AWS CloudFormation
AWS CloudFormation

I use Terraform because it hits the level of abstraction pocket of being high-level and flexible, and is agnostic to cloud platforms. Creating complex infrastructure components for a solution with a UI console is tedious to repeat. Using low-level APIs are usually specific to cloud platforms, and you still have to build your own tooling for deploying, state management, and destroying infrastructure.

However, Terraform is usually slower to implement new services compared to cloud-specific APIs. It's worth the trade-off though, especially if you're multi-cloud. I heard someone say, "We want to preference a cloud, not lock in to one." Terraform builds on that claim.

Terraform Google Cloud Deployment Manager AWS CloudFormation

See more
Azure App Service logo

Azure App Service

57
23
0
57
23
+ 1
0
Build, deploy, and scale web apps on a fully managed platform
    Be the first to leave a pro
    Azure App Service logo
    Azure App Service
    VS
    AWS Elastic Beanstalk logo
    AWS Elastic Beanstalk
    Heroku logo

    Heroku

    8.1K
    5.7K
    3.1K
    8.1K
    5.7K
    + 1
    3.1K
    Build, deliver, monitor and scale web apps and APIs with a trail blazing developer experience.
    Heroku logo
    Heroku
    VS
    AWS Elastic Beanstalk logo
    AWS Elastic Beanstalk

    related Heroku posts

    Tim Nolet
    Tim Nolet
    Founder, Engineer & Dishwasher at Checkly · | 19 upvotes · 267.3K views
    atChecklyHQChecklyHQ
    Heroku
    Heroku
    Docker
    Docker
    GitHub
    GitHub
    Node.js
    Node.js
    hapi
    hapi
    Vue.js
    Vue.js
    AWS Lambda
    AWS Lambda
    Amazon S3
    Amazon S3
    PostgreSQL
    PostgreSQL
    Knex.js
    Knex.js
    vuex
    vuex

    Heroku Docker GitHub Node.js hapi Vue.js AWS Lambda Amazon S3 PostgreSQL Knex.js Checkly is a fairly young company and we're still working hard to find the correct mix of product features, price and audience.

    We are focussed on tech B2B, but I always wanted to serve solo developers too. So I decided to make a $7 plan.

    Why $7? Simply put, it seems to be a sweet spot for tech companies: Heroku, Docker, Github, Appoptics (Librato) all offer $7 plans. They must have done a ton of research into this, so why not piggy back that and try it out.

    Enough biz talk, onto tech. The challenges were:

    • Slice of a portion of the functionality so a $7 plan is still profitable. We call this the "plan limits"
    • Update API and back end services to handle and enforce plan limits.
    • Update the UI to kindly state plan limits are in effect on some part of the UI.
    • Update the pricing page to reflect all changes.
    • Keep the actual processing backend, storage and API's as untouched as possible.

    In essence, we went from strictly volume based pricing to value based pricing. Here come the technical steps & decisions we made to get there.

    1. We updated our PostgreSQL schema so plans now have an array of "features". These are string constants that represent feature toggles.
    2. The Vue.js frontend reads these from the vuex store on login.
    3. Based on these values, the UI has simple v-if statements to either just show the feature or show a friendly "please upgrade" button.
    4. The hapi API has a hook on each relevant API endpoint that checks whether a user's plan has the feature enabled, or not.

    Side note: We offer 10 SMS messages per month on the developer plan. However, we were not actually counting how many people were sending. We had to update our alerting daemon (that runs on Heroku and triggers SMS messages via AWS SNS) to actually bump a counter.

    What we build is basically feature-toggling based on plan features. It is very extensible for future additions. Our scheduling and storage backend that actually runs users' monitoring requests (AWS Lambda) and stores the results (S3 and Postgres) has no knowledge of all of this and remained unchanged.

    Hope this helps anyone building out their SaaS and is in a similar situation.

    See more
    Russel Werner
    Russel Werner
    Lead Engineer at StackShare · | 19 upvotes · 236.7K views
    atStackShareStackShare
    React
    React
    Glamorous
    Glamorous
    Apollo
    Apollo
    Node.js
    Node.js
    Rails
    Rails
    Heroku
    Heroku
    GitHub
    GitHub
    Amazon S3
    Amazon S3
    Amazon CloudFront
    Amazon CloudFront
    Webpack
    Webpack
    CircleCI
    CircleCI
    Redis
    Redis
    #StackDecisionsLaunch
    #SSR
    #Microservices
    #FrontEndRepoSplit

    StackShare Feed is built entirely with React, Glamorous, and Apollo. One of our objectives with the public launch of the Feed was to enable a Server-side rendered (SSR) experience for our organic search traffic. When you visit the StackShare Feed, and you aren't logged in, you are delivered the Trending feed experience. We use an in-house Node.js rendering microservice to generate this HTML. This microservice needs to run and serve requests independent of our Rails web app. Up until recently, we had a mono-repo with our Rails and React code living happily together and all served from the same web process. In order to deploy our SSR app into a Heroku environment, we needed to split out our front-end application into a separate repo in GitHub. The driving factor in this decision was mostly due to limitations imposed by Heroku specifically with how processes can't communicate with each other. A new SSR app was created in Heroku and linked directly to the frontend repo so it stays in-sync with changes.

    Related to this, we need a way to "deploy" our frontend changes to various server environments without building & releasing the entire Ruby application. We built a hybrid Amazon S3 Amazon CloudFront solution to host our Webpack bundles. A new CircleCI script builds the bundles and uploads them to S3. The final step in our rollout is to update some keys in Redis so our Rails app knows which bundles to serve. The result of these efforts were significant. Our frontend team now moves independently of our backend team, our build & release process takes only a few minutes, we are now using an edge CDN to serve JS assets, and we have pre-rendered React pages!

    #StackDecisionsLaunch #SSR #Microservices #FrontEndRepoSplit

    See more
    Apollo logo

    Apollo

    849
    600
    9
    849
    600
    + 1
    9
    GraphQL server for Express, Connect, Hapi, Koa and more
    Apollo logo
    Apollo
    VS
    AWS Elastic Beanstalk logo
    AWS Elastic Beanstalk

    related Apollo posts

    Nick Rockwell
    Nick Rockwell
    CTO at NY Times · | 27 upvotes · 380.8K views
    atThe New York TimesThe New York Times
    MySQL
    MySQL
    PHP
    PHP
    React
    React
    Apollo
    Apollo
    GraphQL
    GraphQL
    Node.js
    Node.js
    Kafka
    Kafka
    Apache HTTP Server
    Apache HTTP Server

    When I joined NYT there was already broad dissatisfaction with the LAMP (Linux Apache HTTP Server MySQL PHP) Stack and the front end framework, in particular. So, I wasn't passing judgment on it. I mean, LAMP's fine, you can do good work in LAMP. It's a little dated at this point, but it's not ... I didn't want to rip it out for its own sake, but everyone else was like, "We don't like this, it's really inflexible." And I remember from being outside the company when that was called MIT FIVE when it had launched. And been observing it from the outside, and I was like, you guys took so long to do that and you did it so carefully, and yet you're not happy with your decisions. Why is that? That was more the impetus. If we're going to do this again, how are we going to do it in a way that we're gonna get a better result?

    So we're moving quickly away from LAMP, I would say. So, right now, the new front end is React based and using Apollo. And we've been in a long, protracted, gradual rollout of the core experiences.

    React is now talking to GraphQL as a primary API. There's a Node.js back end, to the front end, which is mainly for server-side rendering, as well.

    Behind there, the main repository for the GraphQL server is a big table repository, that we call Bodega because it's a convenience store. And that reads off of a Kafka pipeline.

    See more
    Adam Neary
    Adam Neary
    Engineer at Airbnb · | 26 upvotes · 377.3K views
    atAirbnbAirbnb
    GraphQL
    GraphQL
    GraphQL Playground
    GraphQL Playground
    Apollo
    Apollo
    #BackendDrivenUI
    #Prisma

    At Airbnb we use GraphQL Unions for a "Backend-Driven UI." We have built a system where a very dynamic page is constructed based on a query that will return an array of some set of possible “sections.” These sections are responsive and define the UI completely.

    The central file that manages this would be a generated file. Since the list of possible sections is quite large (~50 sections today for Search), it also presumes we have a sane mechanism for lazy-loading components with server rendering, which is a topic for another post. Suffice it to say, we do not need to package all possible sections in a massive bundle to account for everything up front.

    Each section component defines its own query fragment, colocated with the section’s component code. This is the general idea of Backend-Driven UI at Airbnb. It’s used in a number of places, including Search, Trip Planner, Host tools, and various landing pages. We use this as our starting point, and then in the demo show how to (1) make and update to an existing section, and (2) add a new section.

    While building your product, you want to be able to explore your schema, discovering field names and testing out potential queries on live development data. We achieve that today with GraphQL Playground, the work of our friends at #Prisma. The tools come standard with Apollo Server.

    #BackendDrivenUI

    See more

    related OpenShift posts

    Conor Myhrvold
    Conor Myhrvold
    Tech Brand Mgr, Office of CTO at Uber · | 16 upvotes · 837.2K views
    atUber TechnologiesUber Technologies
    Jaeger
    Jaeger
    Python
    Python
    Java
    Java
    Node.js
    Node.js
    Go
    Go
    C++
    C++
    Kubernetes
    Kubernetes
    JavaScript
    JavaScript
    OpenShift
    OpenShift
    C#
    C#
    Apache Spark
    Apache Spark

    How Uber developed the open source, end-to-end distributed tracing Jaeger , now a CNCF project:

    Distributed tracing is quickly becoming a must-have component in the tools that organizations use to monitor their complex, microservice-based architectures. At Uber, our open source distributed tracing system Jaeger saw large-scale internal adoption throughout 2016, integrated into hundreds of microservices and now recording thousands of traces every second.

    Here is the story of how we got here, from investigating off-the-shelf solutions like Zipkin, to why we switched from pull to push architecture, and how distributed tracing will continue to evolve:

    https://eng.uber.com/distributed-tracing/

    (GitHub Pages : https://www.jaegertracing.io/, GitHub: https://github.com/jaegertracing/jaeger)

    Bindings/Operator: Python Java Node.js Go C++ Kubernetes JavaScript OpenShift C# Apache Spark

    See more
    Michael Ionita
    Michael Ionita
    CTO at Walls.io GmbH · | 6 upvotes · 44.3K views
    atWalls.ioWalls.io
    Kubernetes
    Kubernetes
    OpenShift
    OpenShift

    We use Kubernetes because we decided to migrate to a hosted cluster (not AWS) and still be able to scale our clusters up and down depending on load. By wrapping it with OpenShift we are now able to easily adapt to demand but also able to separate concerns into separate Pods depending on use-cases we have.

    See more
    Azure Websites logo

    Azure Websites

    300
    238
    21
    300
    238
    + 1
    21
    Deploy and scale modern websites and web apps in seconds
    Azure Websites logo
    Azure Websites
    VS
    AWS Elastic Beanstalk logo
    AWS Elastic Beanstalk
    Dokku logo

    Dokku

    101
    91
    58
    101
    91
    + 1
    58
    Docker powered mini-Heroku in around 100 lines of Bash