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.
2.1K
1.8K
+ 1
241

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

AWS Elastic Beanstalk is a platform as a service (PaaS) offering from Amazon Web Services that simplifies the process of deploying and managing applications. Key features include scalable infrastructure, automatic load balancing, monitoring, and the ability to support multiple programming languages and frameworks. However, it has limitations such as limited customization options and higher costs compared to other alternatives.

  1. Heroku: Heroku is a fully managed platform as a service that allows developers to build, run, and scale applications with ease. Key features include seamless integration with Git, a robust ecosystem of add-ons, and support for multiple programming languages. Pros: Easy to use, quick deployment, scalable infrastructure. Cons: Limited customization options, can be expensive for larger applications.
  2. Google App Engine: Google App Engine is a platform as a service offering from Google Cloud that provides auto-scaling, fully managed infrastructure for applications. Key features include support for multiple programming languages, built-in security, and low latency. Pros: Integrated with other Google Cloud services, easy to use, automatic scaling. Cons: Limited control over infrastructure, limited support for certain programming languages.
  3. Microsoft Azure App Service: Azure App Service is a fully managed platform as a service offering from Microsoft Azure that supports multiple programming languages and frameworks. Key features include seamless integration with Azure services, auto-scaling, and built-in CI/CD capabilities. Pros: Integrated with other Azure services, easy deployment, continuous monitoring. Cons: Limited customization options, can be costly for large applications.
  4. DigitalOcean App Platform: DigitalOcean App Platform is a platform as a service offering from DigitalOcean that simplifies the deployment and management of applications. Key features include support for multiple programming languages, automatic scaling, and built-in monitoring. Pros: Easy to use, cost-effective, flexible pricing options. Cons: Limited add-on support, fewer features compared to other platforms.
  5. IBM Cloud Foundry: IBM Cloud Foundry is a platform as a service offering from IBM Cloud that provides developers with a cloud-native environment to deploy and manage applications. Key features include support for multiple programming languages, containerization support, and built-in logging and monitoring. Pros: Scalable infrastructure, strong security features, multi-cloud support. Cons: Complex setup process, higher learning curve compared to other platforms.
  6. Red Hat OpenShift: Red Hat OpenShift is a Kubernetes-based platform as a service offering that simplifies the process of deploying and managing containerized applications. Key features include support for DevOps practices, automated scaling, and integration with various tools and services. Pros: Highly customizable, integrated CI/CD pipeline, strong community support. Cons: Higher cost compared to other platforms, complex configuration options.
  7. Platform.sh: Platform.sh is a platform as a service offering that focuses on providing a complete cloud hosting solution for web applications. Key features include support for multiple programming languages, Git integration, and auto-scaling capabilities. Pros: Easy workflow management, built-in monitoring, high availability architecture. Cons: Limited customization options, can be expensive for larger applications.
  8. Render: Render is a fully managed platform as a service that simplifies the deployment and scaling of web applications. Key features include support for multiple programming languages, automatic scaling, and built-in CI/CD capabilities. Pros: Easy to use, cost-effective pricing, seamless deployment process. Cons: Limited add-on support, fewer advanced features compared to other platforms.
  9. Vercel: Vercel is a platform as a service offering that specializes in optimizing the deployment and hosting of web applications. Key features include support for static and serverless applications, built-in edge networking, and Git integration. Pros: Fast deployment times, automatic scaling, global CDN. Cons: Limited support for backend services, higher pricing for larger applications.
  10. Pivotal Cloud Foundry: Pivotal Cloud Foundry is a platform as a service offering that provides developers with a cloud-native environment to deploy and manage applications. Key features include support for multiple programming languages, automated scaling, and built-in security features. Pros: Flexible infrastructure, easy integration with external services, strong support for microservices architecture. Cons: Complex setup process, higher cost compared to other platforms.

Top Alternatives to AWS Elastic Beanstalk

  • Google App Engine
    Google App Engine

    Google has a reputation for highly reliable, high performance infrastructure. With App Engine you can take advantage of the 10 years of knowledge Google has in running massively scalable, performance driven systems. App Engine applications are easy to build, easy to maintain, and easy to scale as your traffic and data storage needs grow. ...

  • AWS CodeDeploy
    AWS CodeDeploy

    AWS CodeDeploy is a service that automates code deployments to Amazon EC2 instances. AWS CodeDeploy makes it easier for you to rapidly release new features, helps you avoid downtime during deployment, and handles the complexity of updating your applications. ...

  • Docker
    Docker

    The Docker Platform is the industry-leading container platform for continuous, high-velocity innovation, enabling organizations to seamlessly build and share any application — from legacy to what comes next — and securely run them anywhere ...

  • AWS CloudFormation
    AWS CloudFormation

    You can use AWS CloudFormation’s sample templates or create your own templates to describe the AWS resources, and any associated dependencies or runtime parameters, required to run your application. You don’t need to figure out the order in which AWS services need to be provisioned or the subtleties of how to make those dependencies work. ...

  • Azure App Service
    Azure App Service

    Quickly build, deploy, and scale web apps created with popular frameworks .NET, .NET Core, Node.js, Java, PHP, Ruby, or Python, in containers or running on any operating system. Meet rigorous, enterprise-grade performance, security, and compliance requirements by using the fully managed platform for your operational and monitoring tasks. ...

  • Heroku
    Heroku

    Heroku is a cloud application platform – a new way of building and deploying web apps. Heroku lets app developers spend 100% of their time on their application code, not managing servers, deployment, ongoing operations, or scaling. ...

  • Kubernetes
    Kubernetes

    Kubernetes is an open source orchestration system for Docker containers. It handles scheduling onto nodes in a compute cluster and actively manages workloads to ensure that their state matches the users declared intentions. ...

  • JavaScript
    JavaScript

    JavaScript is most known as the scripting language for Web pages, but used in many non-browser environments as well such as node.js or Apache CouchDB. It is a prototype-based, multi-paradigm scripting language that is dynamic,and supports object-oriented, imperative, and functional programming styles. ...

AWS Elastic Beanstalk alternatives & related posts

Google App Engine logo

Google App Engine

10.1K
7.9K
610
Build web applications on the same scalable systems that power Google applications
10.1K
7.9K
+ 1
610
PROS OF GOOGLE APP ENGINE
  • 145
    Easy to deploy
  • 106
    Auto scaling
  • 80
    Good free plan
  • 62
    Easy management
  • 56
    Scalability
  • 35
    Low cost
  • 32
    Comprehensive set of features
  • 28
    All services in one place
  • 22
    Simple scaling
  • 19
    Quick and reliable cloud servers
  • 6
    Granular Billing
  • 5
    Easy to develop and unit test
  • 4
    Monitoring gives comprehensive set of key indicators
  • 3
    Really easy to quickly bring up a full stack
  • 3
    Create APIs quickly with cloud endpoints
  • 2
    Mostly up
  • 2
    No Ops
CONS OF GOOGLE APP ENGINE
    Be the first to leave a con

    related Google App Engine posts

    Dmitry Mukhin
    Engineer at Uploadcare · | 15 upvotes · 205K views

    Uploadcare has built an infinitely scalable infrastructure by leveraging AWS. Building on top of AWS allows us to process 350M daily requests for file uploads, manipulations, and deliveries. When we started in 2011 the only cloud alternative to AWS was Google App Engine which was a no-go for a rather complex solution we wanted to build. We also didn’t want to buy any hardware or use co-locations.

    Our stack handles receiving files, communicating with external file sources, managing file storage, managing user and file data, processing files, file caching and delivery, and managing user interface dashboards.

    At its core, Uploadcare runs on Python. The Europython 2011 conference in Florence really inspired us, coupled with the fact that it was general enough to solve all of our challenges informed this decision. Additionally we had prior experience working in Python.

    We chose to build the main application with Django because of its feature completeness and large footprint within the Python ecosystem.

    All the communications within our ecosystem occur via several HTTP APIs, Redis, Amazon S3, and Amazon DynamoDB. We decided on this architecture so that our our system could be scalable in terms of storage and database throughput. This way we only need Django running on top of our database cluster. We use PostgreSQL as our database because it is considered an industry standard when it comes to clustering and scaling.

    See more
    Nick Rockwell
    SVP, Engineering at Fastly · | 12 upvotes · 426.1K views

    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

    393
    620
    38
    Coordinate application deployments to Amazon EC2 instances
    393
    620
    + 1
    38
    PROS OF AWS CODEDEPLOY
    • 17
      Automates code deployments
    • 9
      Backed by Amazon
    • 7
      Adds autoscaling lifecycle hooks
    • 5
      Git integration
    CONS OF AWS CODEDEPLOY
      Be the first to leave a con

      related AWS CodeDeploy posts

      Chris McFadden
      VP, Engineering at SparkPost · | 9 upvotes · 156.9K views

      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
      Founder/CTO at Kloudio · | 5 upvotes · 80.2K views

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

      Docker

      171.4K
      137.7K
      3.9K
      Enterprise Container Platform for High-Velocity Innovation.
      171.4K
      137.7K
      + 1
      3.9K
      PROS OF DOCKER
      • 823
        Rapid integration and build up
      • 691
        Isolation
      • 521
        Open source
      • 505
        Testa­bil­i­ty and re­pro­ducibil­i­ty
      • 460
        Lightweight
      • 218
        Standardization
      • 185
        Scalable
      • 106
        Upgrading / down­grad­ing / ap­pli­ca­tion versions
      • 88
        Security
      • 85
        Private paas environments
      • 34
        Portability
      • 26
        Limit resource usage
      • 17
        Game changer
      • 16
        I love the way docker has changed virtualization
      • 14
        Fast
      • 12
        Concurrency
      • 8
        Docker's Compose tools
      • 6
        Easy setup
      • 6
        Fast and Portable
      • 5
        Because its fun
      • 4
        Makes shipping to production very simple
      • 3
        Highly useful
      • 3
        It's dope
      • 2
        Very easy to setup integrate and build
      • 2
        HIgh Throughput
      • 2
        Package the environment with the application
      • 2
        Does a nice job hogging memory
      • 2
        Open source and highly configurable
      • 2
        Simplicity, isolation, resource effective
      • 2
        MacOS support FAKE
      • 2
        Its cool
      • 2
        Docker hub for the FTW
      • 2
        Super
      • 0
        Asdfd
      CONS OF DOCKER
      • 8
        New versions == broken features
      • 6
        Unreliable networking
      • 6
        Documentation not always in sync
      • 4
        Moves quickly
      • 3
        Not Secure

      related Docker posts

      Simon Reymann
      Senior Fullstack Developer at QUANTUSflow Software GmbH · | 30 upvotes · 9.7M views

      Our whole DevOps stack consists of the following tools:

      • GitHub (incl. GitHub Pages/Markdown for Documentation, GettingStarted and HowTo's) for collaborative review and code management tool
      • Respectively Git as revision control system
      • SourceTree as Git GUI
      • Visual Studio Code as IDE
      • CircleCI for continuous integration (automatize development process)
      • Prettier / TSLint / ESLint as code linter
      • SonarQube as quality gate
      • Docker as container management (incl. Docker Compose for multi-container application management)
      • VirtualBox for operating system simulation tests
      • Kubernetes as cluster management for docker containers
      • Heroku for deploying in test environments
      • nginx as web server (preferably used as facade server in production environment)
      • SSLMate (using OpenSSL) for certificate management
      • Amazon EC2 (incl. Amazon S3) for deploying in stage (production-like) and production environments
      • PostgreSQL as preferred database system
      • Redis as preferred in-memory database/store (great for caching)

      The main reason we have chosen Kubernetes over Docker Swarm is related to the following artifacts:

      • Key features: Easy and flexible installation, Clear dashboard, Great scaling operations, Monitoring is an integral part, Great load balancing concepts, Monitors the condition and ensures compensation in the event of failure.
      • Applications: An application can be deployed using a combination of pods, deployments, and services (or micro-services).
      • Functionality: Kubernetes as a complex installation and setup process, but it not as limited as Docker Swarm.
      • Monitoring: It supports multiple versions of logging and monitoring when the services are deployed within the cluster (Elasticsearch/Kibana (ELK), Heapster/Grafana, Sysdig cloud integration).
      • Scalability: All-in-one framework for distributed systems.
      • Other Benefits: Kubernetes is backed by the Cloud Native Computing Foundation (CNCF), huge community among container orchestration tools, it is an open source and modular tool that works with any OS.
      See more
      Tymoteusz Paul
      Devops guy at X20X Development LTD · | 23 upvotes · 8.7M views

      Often enough I have to explain my way of going about setting up a CI/CD pipeline with multiple deployment platforms. Since I am a bit tired of yapping the same every single time, I've decided to write it up and share with the world this way, and send people to read it instead ;). I will explain it on "live-example" of how the Rome got built, basing that current methodology exists only of readme.md and wishes of good luck (as it usually is ;)).

      It always starts with an app, whatever it may be and reading the readmes available while Vagrant and VirtualBox is installing and updating. Following that is the first hurdle to go over - convert all the instruction/scripts into Ansible playbook(s), and only stopping when doing a clear vagrant up or vagrant reload we will have a fully working environment. As our Vagrant environment is now functional, it's time to break it! This is the moment to look for how things can be done better (too rigid/too lose versioning? Sloppy environment setup?) and replace them with the right way to do stuff, one that won't bite us in the backside. This is the point, and the best opportunity, to upcycle the existing way of doing dev environment to produce a proper, production-grade product.

      I should probably digress here for a moment and explain why. I firmly believe that the way you deploy production is the same way you should deploy develop, shy of few debugging-friendly setting. This way you avoid the discrepancy between how production work vs how development works, which almost always causes major pains in the back of the neck, and with use of proper tools should mean no more work for the developers. That's why we start with Vagrant as developer boxes should be as easy as vagrant up, but the meat of our product lies in Ansible which will do meat of the work and can be applied to almost anything: AWS, bare metal, docker, LXC, in open net, behind vpn - you name it.

      We must also give proper consideration to monitoring and logging hoovering at this point. My generic answer here is to grab Elasticsearch, Kibana, and Logstash. While for different use cases there may be better solutions, this one is well battle-tested, performs reasonably and is very easy to scale both vertically (within some limits) and horizontally. Logstash rules are easy to write and are well supported in maintenance through Ansible, which as I've mentioned earlier, are at the very core of things, and creating triggers/reports and alerts based on Elastic and Kibana is generally a breeze, including some quite complex aggregations.

      If we are happy with the state of the Ansible it's time to move on and put all those roles and playbooks to work. Namely, we need something to manage our CI/CD pipelines. For me, the choice is obvious: TeamCity. It's modern, robust and unlike most of the light-weight alternatives, it's transparent. What I mean by that is that it doesn't tell you how to do things, doesn't limit your ways to deploy, or test, or package for that matter. Instead, it provides a developer-friendly and rich playground for your pipelines. You can do most the same with Jenkins, but it has a quite dated look and feel to it, while also missing some key functionality that must be brought in via plugins (like quality REST API which comes built-in with TeamCity). It also comes with all the common-handy plugins like Slack or Apache Maven integration.

      The exact flow between CI and CD varies too greatly from one application to another to describe, so I will outline a few rules that guide me in it: 1. Make build steps as small as possible. This way when something breaks, we know exactly where, without needing to dig and root around. 2. All security credentials besides development environment must be sources from individual Vault instances. Keys to those containers should exist only on the CI/CD box and accessible by a few people (the less the better). This is pretty self-explanatory, as anything besides dev may contain sensitive data and, at times, be public-facing. Because of that appropriate security must be present. TeamCity shines in this department with excellent secrets-management. 3. Every part of the build chain shall consume and produce artifacts. If it creates nothing, it likely shouldn't be its own build. This way if any issue shows up with any environment or version, all developer has to do it is grab appropriate artifacts to reproduce the issue locally. 4. Deployment builds should be directly tied to specific Git branches/tags. This enables much easier tracking of what caused an issue, including automated identifying and tagging the author (nothing like automated regression testing!).

      Speaking of deployments, I generally try to keep it simple but also with a close eye on the wallet. Because of that, I am more than happy with AWS or another cloud provider, but also constantly peeking at the loads and do we get the value of what we are paying for. Often enough the pattern of use is not constantly erratic, but rather has a firm baseline which could be migrated away from the cloud and into bare metal boxes. That is another part where this approach strongly triumphs over the common Docker and CircleCI setup, where you are very much tied in to use cloud providers and getting out is expensive. Here to embrace bare-metal hosting all you need is a help of some container-based self-hosting software, my personal preference is with Proxmox and LXC. Following that all you must write are ansible scripts to manage hardware of Proxmox, similar way as you do for Amazon EC2 (ansible supports both greatly) and you are good to go. One does not exclude another, quite the opposite, as they can live in great synergy and cut your costs dramatically (the heavier your base load, the bigger the savings) while providing production-grade resiliency.

      See more
      AWS CloudFormation logo

      AWS CloudFormation

      1.5K
      1.3K
      88
      Create and manage a collection of related AWS resources
      1.5K
      1.3K
      + 1
      88
      PROS OF AWS CLOUDFORMATION
      • 43
        Automates infrastructure deployments
      • 21
        Declarative infrastructure and deployment
      • 13
        No more clicking around
      • 3
        Any Operative System you want
      • 3
        Atomic
      • 3
        Infrastructure as code
      • 1
        CDK makes it truly infrastructure-as-code
      • 1
        Automates Infrastructure Deployment
      • 0
        K8s
      CONS OF AWS CLOUDFORMATION
      • 4
        Brittle
      • 2
        No RBAC and policies in templates

      related AWS CloudFormation posts

      Joseph Kunzler
      DevOps Engineer at Tillable · | 9 upvotes · 202.1K views

      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
      Bram Verdonck

      Yesterday we moved away from using CloudFlare towards Amazon Route 53 for a few reasons. Although CloudFlare is a great platform, once you reach almost a 100% AWS Service integration, it makes it hard to still use CloudFlare in the stack. Also being able to use Aliases for DNS makes it faster because instead of doing a CNAME and an A record lookup, you will be able to receive the A records from the end services directly. We always loved working with CloudFlare , especially for DNS as we already used Amazon CloudFront for CDN. But having everything within AWS makes it "cleaner" when deploying automatically using AWS CloudFormation. All that aside, the main reason for moving towards Amazon Route 53 for DNS is the ability to do geolocation and latency based DNS responses. Doing this outside the AWS console would increase the complexity.

      See more
      Azure App Service logo

      Azure App Service

      296
      372
      11
      Build, deploy, and scale web apps on a fully managed platform
      296
      372
      + 1
      11
      PROS OF AZURE APP SERVICE
      • 6
        .Net Framework
      • 5
        Visual studio
      CONS OF AZURE APP SERVICE
        Be the first to leave a con

        related Azure App Service posts

        Mehdi Baaboura
        Managing Director at Gigadrive · | 2 upvotes · 20.3K views

        Easier setup and integration for PHP based applications. Azure App Service requires a lot of extra configuration, while AWS Elastic Beanstalk has most things set-up out of the box. On top of this, Azure is much more expensive.

        See more
        Heroku logo

        Heroku

        25.3K
        20.2K
        3.2K
        Build, deliver, monitor and scale web apps and APIs with a trail blazing developer experience.
        25.3K
        20.2K
        + 1
        3.2K
        PROS OF HEROKU
        • 703
          Easy deployment
        • 459
          Free for side projects
        • 374
          Huge time-saver
        • 348
          Simple scaling
        • 261
          Low devops skills required
        • 190
          Easy setup
        • 174
          Add-ons for almost everything
        • 153
          Beginner friendly
        • 150
          Better for startups
        • 133
          Low learning curve
        • 48
          Postgres hosting
        • 41
          Easy to add collaborators
        • 30
          Faster development
        • 24
          Awesome documentation
        • 19
          Simple rollback
        • 19
          Focus on product, not deployment
        • 15
          Natural companion for rails development
        • 15
          Easy integration
        • 12
          Great customer support
        • 8
          GitHub integration
        • 6
          Painless & well documented
        • 6
          No-ops
        • 4
          I love that they make it free to launch a side project
        • 4
          Free
        • 3
          Great UI
        • 3
          Just works
        • 2
          PostgreSQL forking and following
        • 2
          MySQL extension
        • 1
          Security
        • 1
          Able to host stuff good like Discord Bot
        • 0
          Sec
        CONS OF HEROKU
        • 27
          Super expensive
        • 9
          Not a whole lot of flexibility
        • 7
          No usable MySQL option
        • 7
          Storage
        • 5
          Low performance on free tier
        • 2
          24/7 support is $1,000 per month

        related Heroku posts

        Russel Werner
        Lead Engineer at StackShare · | 32 upvotes · 2.5M views

        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
        Simon Reymann
        Senior Fullstack Developer at QUANTUSflow Software GmbH · | 30 upvotes · 9.7M views

        Our whole DevOps stack consists of the following tools:

        • GitHub (incl. GitHub Pages/Markdown for Documentation, GettingStarted and HowTo's) for collaborative review and code management tool
        • Respectively Git as revision control system
        • SourceTree as Git GUI
        • Visual Studio Code as IDE
        • CircleCI for continuous integration (automatize development process)
        • Prettier / TSLint / ESLint as code linter
        • SonarQube as quality gate
        • Docker as container management (incl. Docker Compose for multi-container application management)
        • VirtualBox for operating system simulation tests
        • Kubernetes as cluster management for docker containers
        • Heroku for deploying in test environments
        • nginx as web server (preferably used as facade server in production environment)
        • SSLMate (using OpenSSL) for certificate management
        • Amazon EC2 (incl. Amazon S3) for deploying in stage (production-like) and production environments
        • PostgreSQL as preferred database system
        • Redis as preferred in-memory database/store (great for caching)

        The main reason we have chosen Kubernetes over Docker Swarm is related to the following artifacts:

        • Key features: Easy and flexible installation, Clear dashboard, Great scaling operations, Monitoring is an integral part, Great load balancing concepts, Monitors the condition and ensures compensation in the event of failure.
        • Applications: An application can be deployed using a combination of pods, deployments, and services (or micro-services).
        • Functionality: Kubernetes as a complex installation and setup process, but it not as limited as Docker Swarm.
        • Monitoring: It supports multiple versions of logging and monitoring when the services are deployed within the cluster (Elasticsearch/Kibana (ELK), Heapster/Grafana, Sysdig cloud integration).
        • Scalability: All-in-one framework for distributed systems.
        • Other Benefits: Kubernetes is backed by the Cloud Native Computing Foundation (CNCF), huge community among container orchestration tools, it is an open source and modular tool that works with any OS.
        See more
        Kubernetes logo

        Kubernetes

        58.9K
        51K
        677
        Manage a cluster of Linux containers as a single system to accelerate Dev and simplify Ops
        58.9K
        51K
        + 1
        677
        PROS OF KUBERNETES
        • 164
          Leading docker container management solution
        • 128
          Simple and powerful
        • 106
          Open source
        • 76
          Backed by google
        • 58
          The right abstractions
        • 25
          Scale services
        • 20
          Replication controller
        • 11
          Permission managment
        • 9
          Supports autoscaling
        • 8
          Cheap
        • 8
          Simple
        • 6
          Self-healing
        • 5
          No cloud platform lock-in
        • 5
          Promotes modern/good infrascture practice
        • 5
          Open, powerful, stable
        • 5
          Reliable
        • 4
          Scalable
        • 4
          Quick cloud setup
        • 3
          Cloud Agnostic
        • 3
          Captain of Container Ship
        • 3
          A self healing environment with rich metadata
        • 3
          Runs on azure
        • 3
          Backed by Red Hat
        • 3
          Custom and extensibility
        • 2
          Sfg
        • 2
          Gke
        • 2
          Everything of CaaS
        • 2
          Golang
        • 2
          Easy setup
        • 2
          Expandable
        CONS OF KUBERNETES
        • 16
          Steep learning curve
        • 15
          Poor workflow for development
        • 8
          Orchestrates only infrastructure
        • 4
          High resource requirements for on-prem clusters
        • 2
          Too heavy for simple systems
        • 1
          Additional vendor lock-in (Docker)
        • 1
          More moving parts to secure
        • 1
          Additional Technology Overhead

        related Kubernetes posts

        Conor Myhrvold
        Tech Brand Mgr, Office of CTO at Uber · | 44 upvotes · 10.9M views

        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
        Ashish Singh
        Tech Lead, Big Data Platform at Pinterest · | 38 upvotes · 3M views

        To provide employees with the critical need of interactive querying, we’ve worked with Presto, an open-source distributed SQL query engine, over the years. Operating Presto at Pinterest’s scale has involved resolving quite a few challenges like, supporting deeply nested and huge thrift schemas, slow/ bad worker detection and remediation, auto-scaling cluster, graceful cluster shutdown and impersonation support for ldap authenticator.

        Our infrastructure is built on top of Amazon EC2 and we leverage Amazon S3 for storing our data. This separates compute and storage layers, and allows multiple compute clusters to share the S3 data.

        We have hundreds of petabytes of data and tens of thousands of Apache Hive tables. Our Presto clusters are comprised of a fleet of 450 r4.8xl EC2 instances. Presto clusters together have over 100 TBs of memory and 14K vcpu cores. Within Pinterest, we have close to more than 1,000 monthly active users (out of total 1,600+ Pinterest employees) using Presto, who run about 400K queries on these clusters per month.

        Each query submitted to Presto cluster is logged to a Kafka topic via Singer. Singer is a logging agent built at Pinterest and we talked about it in a previous post. Each query is logged when it is submitted and when it finishes. When a Presto cluster crashes, we will have query submitted events without corresponding query finished events. These events enable us to capture the effect of cluster crashes over time.

        Each Presto cluster at Pinterest has workers on a mix of dedicated AWS EC2 instances and Kubernetes pods. Kubernetes platform provides us with the capability to add and remove workers from a Presto cluster very quickly. The best-case latency on bringing up a new worker on Kubernetes is less than a minute. However, when the Kubernetes cluster itself is out of resources and needs to scale up, it can take up to ten minutes. Some other advantages of deploying on Kubernetes platform is that our Presto deployment becomes agnostic of cloud vendor, instance types, OS, etc.

        #BigData #AWS #DataScience #DataEngineering

        See more
        JavaScript logo

        JavaScript

        352.5K
        268.3K
        8.1K
        Lightweight, interpreted, object-oriented language with first-class functions
        352.5K
        268.3K
        + 1
        8.1K
        PROS OF JAVASCRIPT
        • 1.7K
          Can be used on frontend/backend
        • 1.5K
          It's everywhere
        • 1.2K
          Lots of great frameworks
        • 897
          Fast
        • 745
          Light weight
        • 425
          Flexible
        • 392
          You can't get a device today that doesn't run js
        • 286
          Non-blocking i/o
        • 237
          Ubiquitousness
        • 191
          Expressive
        • 55
          Extended functionality to web pages
        • 49
          Relatively easy language
        • 46
          Executed on the client side
        • 30
          Relatively fast to the end user
        • 25
          Pure Javascript
        • 21
          Functional programming
        • 15
          Async
        • 13
          Full-stack
        • 12
          Setup is easy
        • 12
          Future Language of The Web
        • 12
          Its everywhere
        • 11
          Because I love functions
        • 11
          JavaScript is the New PHP
        • 10
          Like it or not, JS is part of the web standard
        • 9
          Expansive community
        • 9
          Everyone use it
        • 9
          Can be used in backend, frontend and DB
        • 9
          Easy
        • 8
          Most Popular Language in the World
        • 8
          Powerful
        • 8
          Can be used both as frontend and backend as well
        • 8
          For the good parts
        • 8
          No need to use PHP
        • 8
          Easy to hire developers
        • 7
          Agile, packages simple to use
        • 7
          Love-hate relationship
        • 7
          Photoshop has 3 JS runtimes built in
        • 7
          Evolution of C
        • 7
          It's fun
        • 7
          Hard not to use
        • 7
          Versitile
        • 7
          Its fun and fast
        • 7
          Nice
        • 7
          Popularized Class-Less Architecture & Lambdas
        • 7
          Supports lambdas and closures
        • 6
          It let's me use Babel & Typescript
        • 6
          Can be used on frontend/backend/Mobile/create PRO Ui
        • 6
          1.6K Can be used on frontend/backend
        • 6
          Client side JS uses the visitors CPU to save Server Res
        • 6
          Easy to make something
        • 5
          Clojurescript
        • 5
          Promise relationship
        • 5
          Stockholm Syndrome
        • 5
          Function expressions are useful for callbacks
        • 5
          Scope manipulation
        • 5
          Everywhere
        • 5
          Client processing
        • 5
          What to add
        • 4
          Because it is so simple and lightweight
        • 4
          Only Programming language on browser
        • 1
          Test
        • 1
          Hard to learn
        • 1
          Test2
        • 1
          Not the best
        • 1
          Easy to understand
        • 1
          Subskill #4
        • 1
          Easy to learn
        • 0
          Hard 彤
        CONS OF JAVASCRIPT
        • 22
          A constant moving target, too much churn
        • 20
          Horribly inconsistent
        • 15
          Javascript is the New PHP
        • 9
          No ability to monitor memory utilitization
        • 8
          Shows Zero output in case of ANY error
        • 7
          Thinks strange results are better than errors
        • 6
          Can be ugly
        • 3
          No GitHub
        • 2
          Slow

        related JavaScript posts

        Zach Holman

        Oof. I have truly hated JavaScript for a long time. Like, for over twenty years now. Like, since the Clinton administration. It's always been a nightmare to deal with all of the aspects of that silly language.

        But wowza, things have changed. Tooling is just way, way better. I'm primarily web-oriented, and using React and Apollo together the past few years really opened my eyes to building rich apps. And I deeply apologize for using the phrase rich apps; I don't think I've ever said such Enterprisey words before.

        But yeah, things are different now. I still love Rails, and still use it for a lot of apps I build. But it's that silly rich apps phrase that's the problem. Users have way more comprehensive expectations than they did even five years ago, and the JS community does a good job at building tools and tech that tackle the problems of making heavy, complicated UI and frontend work.

        Obviously there's a lot of things happening here, so just saying "JavaScript isn't terrible" might encompass a huge amount of libraries and frameworks. But if you're like me, yeah, give things another shot- I'm somehow not hating on JavaScript anymore and... gulp... I kinda love it.

        See more
        Conor Myhrvold
        Tech Brand Mgr, Office of CTO at Uber · | 44 upvotes · 10.9M views

        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