Talks

Lightning Talk: Turning Web Servers into Workers

Ruby Unconf 2019

00:00:02.590 Hello, everyone! My name is Janusz Mordarski, and I am currently a freelancer at Sync. I split my time between Hamburg and Krakow, which I highly recommend for weekend trips. It’s a beautiful city.
00:00:14.289 Today, I want to share some insights on quickly launching web applications. Typically, I would recommend using platforms like Heroku or AWS. For those who find themselves tied to the Amazon platform, Elastic Beanstalk is a great alternative. It serves as a Heroku-like solution for AWS, allowing you to pick some pre-configured images from the internet.
00:01:11.710 Elastic Beanstalk works seamlessly with various AWS components, including Elastic Load Balancers, EC2 instances, RDS databases, and SQS. The setup is straightforward; with the click of a button, you can integrate RDS databases or Elastic Cache, making it easily scalable. I recommend using Elastic Load Balancer, which comes with additional scalability to handle any number of users.
00:02:05.020 It works with Ruby on Rails right out of the box, utilizing pre-configured Docker images. This makes management effortless using the Elastic Beanstalk CLI. Deployments and debugging in production can be handled with ease using EB SSH, where you can manage files for cron jobs, for example.
00:02:30.430 The focus of my talk is on transitioning web servers into workers that can execute background jobs quickly. I make use of the Elastic Beanstalk extension to set up cron jobs for both staging and production environments. Scalability is essential, so I advise considering load balancers from the start of your project.
00:03:38.170 Many people ask me how to best set up cron jobs in Elastic Beanstalk. There is a solution that has existed for a while called Mutex. This is a distributed mutex that can be implemented with Redis using a gem like Redis Mutex. This allows you to wrap your job code in a lock to prevent conflicts across multiple servers.
00:04:43.160 By specifying how long this lock should live, the job will run on one server while preventing it from executing on others simultaneously. This ensures that you don’t face issues with jobs overlapping or failing due to multiple executions. That’s all from me today. Thank you!