AWS Elastic Load Balancing (ELB)

AWS Elastic Load Balancing (ELB)

DevOps / Build, Test, Deploy / Load Balancer / Reverse Proxy

Decision at Uploadcare about AWS Elastic Load Balancing (ELB), Amazon EC2, Python, Tornado

Avatar of dmitry-mukhin

The 350M API requests we handle daily include many processing tasks such as image enhancements, resizing, filtering, face recognition, and GIF to video conversions.

Tornado is the one we currently use and aiohttp is the one we intend to implement in production in the near future. Both tools support handling huge amounts of requests but aiohttp is preferable as it uses asyncio which is Python-native. Since Python is in the heart of our service, we initially used PIL followed by Pillow. We kind of still do. When we figured resizing was the most taxing processing operation, Alex, our engineer, created the fork named Pillow-SIMD and implemented a good number of optimizations into it to make it 15 times faster than ImageMagick

Thanks to the optimizations, Uploadcare now needs six times fewer servers to process images. Here, by servers I also mean separate Amazon EC2 instances handling processing and the first layer of caching. The processing instances are also paired with AWS Elastic Load Balancing (ELB) which helps ingest files to the CDN.

20 upvotes2.7K views

Decision at Raygun about AWS Elastic Load Balancing (ELB), Amazon EC2, nginx, Amazon RDS, Amazon S3, LoadBalancerReverseProxy, CloudStorage, WebServers, CloudHosting

Avatar of CmdrKeen
Co-founder & CEO at Raygun
AWS Elastic Load Balancing (ELB)AWS Elastic Load Balancing (ELB)Amazon EC2Amazon EC2nginxnginxAmazon RDSAmazon RDSAmazon S3Amazon S3

We chose AWS because, at the time, it was really the only cloud provider to choose from.

We tend to use their basic building blocks (EC2, ELB, Amazon S3, Amazon RDS) rather than vendor specific components like databases and queuing. We deliberately decided to do this to ensure we could provide multi-cloud support or potentially move to another cloud provider if the offering was better for our customers.

We鈥檝e utilized c3.large nodes for both the Node.js deployment and then for the .NET Core deployment. Both sit as backends behind an nginx instance and are managed using scaling groups in Amazon EC2 sitting behind a standard AWS Elastic Load Balancing (ELB).

While we鈥檙e satisfied with AWS, we do review our decision each year and have looked at Azure and Google Cloud offerings.

#CloudHosting #WebServers #CloudStorage #LoadBalancerReverseProxy

19 upvotes5.2K views

Decision at Tillable about AWS CloudFormation, AWS Elastic Load Balancing (ELB), Amazon EC2, Amazon S3, Terraform

Avatar of 1jkunz1
DevOps Engineer at Tillable

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.

9 upvotes3.1K views

Decision about Amazon ElastiCache, Amazon Elasticsearch Service, AWS Elastic Load Balancing (ELB), Memcached, Redis, Python, AWS Lambda, Amazon RDS, Microsoft SQL Server, MariaDB, Amazon RDS for PostgreSQL, Rails, Ruby, Heroku, AWS Elastic Beanstalk

Avatar of bpr-admin

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

8 upvotes1 comment12.9K views

Decision at MachineShop about AWS Elastic Load Balancing (ELB), Kubernetes, nginx

Avatar of dambrisco
Senior Software Engineer at MachineShop

nginx became part of our stack largely by virtue of the ingress-nginx plugin for Kubernetes. It's proved reliable and easy to work with and helped us bring down our costs by moving from AWS Elastic Load Balancing (ELB)-backed services to Kubernetes ingresses.

1 upvote28 views

Decision about AWS Elastic Load Balancing (ELB)

Avatar of thanhbn87
Platform leader at Altplus Vietnam
  • Application type
  • SSL free
  • forwarding by rules.
  • multiple target groups with only one ALB AWS Elastic Load Balancing (ELB)
1 upvote5 views

Decision at Hevelop about AWS Elastic Load Balancing (ELB)

Avatar of marcatos

We're progressively migrating from classic ELB to newer ALB for ssl offloading and NLB for internal load balancing. AWS Elastic Load Balancing (ELB)

1 upvote4 views