Rails in the Cloud: The Pocket-Friendly Choice

When presented with the possibility to migrate their Rails app to Lambda, clients usually have similar set of questions. Most of them revolve around the exact pricing and following savings that one can expect.

The truth is - no one can give you a specific number when working with Lambda because there are many moving parts that must go into that kind of calculation. It's hard to know for sure how long each action in your controller will take and when you add warm up times, priorities, and few more unknowns you are pretty much guessing. This is by design and it's not an accident that all cloud providers are trying to make you move your eye from the price ticker of various services they provide.

In this blog post, we'll explore some case studies that highlight the potential cost savings of migrating your Rails apps to AWS Lambda, walk you through the numbers and try to make sense of what you can expect if you go down that path.
We'll also discuss scenarios where the serverless architecture might not be the best fit, providing you with a holistic view of migrating possibilities.

Rails App: A Case Study

Let's take a real-world example to put things in perspective. Meet Hummingbird, a beautiful Rails app with a robust user base of 10,000 daily visits. Hummingbird is currently comfortably housed on Heroku, but the rent isn't cheap.

Now, how much does it cost to run Ruby on Heroku? Let's break it down:

• - Dynos: Hummingbird needs 10 standard-2x dynos for the web process, and 5 worker dynos for background jobs. Each of these dynos costs $50/month, so in total, we're looking at (10 + 5) * $50 = $750/month.
• - Database: Hummingbird uses the Heroku Postgres service on the Standard-0 plan, which costs an additional $200/month.
• - Add-ons: Hummingbird also uses several add-ons for things like data stores, logging, and monitoring services. We might allocate an additional $100/month for these.
• - Data Transfer: Let's add another $100/month for data transfer costs.

Adding all of these up, the cost of hosting Hummingbird on Heroku comes to a grand total of $1,150 per month.

But what about the cost of manpower? We have a DevOps team dedicated to maintaining Hummingbird. With an estimate of 10 hours per week (assuming an hourly rate of $50), the monthly cost for the team amounts to $2,000. That brings our grand total to $3,150 per month. And remember, this is a conservative estimate.

Let's see what would happen if we were to move Hummingbird to AWS Lambda. For a Rails app with 10,000 daily visits and an average execution time of 200ms per visit, we'll need a total of 2,000,000ms of execution time per day. Assuming we allocate 512MB of memory to each function and the price of $0.0000000083, the cost of AWS Lambda per month would be approximately $170.

Reducing DevOps involvement by 50%, which is a realistic presumption, would be an important part of lowering our monthly costs. Total expenses could amount to approximately $1,170, which is just over 1/3 of what we were previously spending on Heroku. While the actual cost savings may vary based on the level of optimization achieved, it is evident that even better results are within the reach.

Case Study 2: The Petite Powerhouse

In the vibrant world of apps, we often find that size isn't a measure of potential. Let's turn our attention to our petite powerhouse, "Doodle", a lightweight Rails app with a fervent daily user base of 1,000 visits.
The monthly expenditure for Doodle on Heroku looked something like this:

• - Dynos: With a lighter load, Doodle needed just two standard-1x dynos for the web process and one for background jobs. At $25/month each, that's a total of $75.
• - Database: A Hobby Basic Postgres service sufficed for Doodle's database needs at $9/month.
• - Add-ons: For add-ons, a further $20/month was spent.
• - Data Transfer: For such a lightweight app data transfer costs were relatively low, coming in at around $10/month.

So, Doodle's monthly living costs on Heroku summed up to $114.

To run Doodle smoothly, a DevOps engineer spent roughly 5 hours per week, translating to a monthly cost of $1,000 (assuming a $50 hourly rate).

In total, our petite powerhouse Doodle was costing $1,114 a month to operate on Heroku.

We then migrated Doodle to AWS Lambda. For 1,000 daily visits with an average execution time of 200ms per visit, we needed around 200 seconds of execution time per day. With 256MB of memory allocated to each function, the AWS Lambda cost came down to a modest $28 per month.

With the migration, the DevOps hours were halved, bringing down the manpower cost to $500. The total expenditure for running Doodle on AWS Lambda was now a much more affordable $528 per month.

The result? Doodle continued to perform flawlessly on AWS Lambda, with the added bonus of reduced costs and better scalability. The lesson from Doodle is clear: small size and big savings can go hand in hand on the cloud!

Case Study 3: The Heavy Hitter

Let's move to the heavyweights. Enter "Juggernaut," a behemoth Rails app, flexing a muscle of 100,000 daily visits.
Here's a glimpse into Juggernaut's Heroku expenditure:

• - Dynos: Juggernaut required 20 standard-2x dynos for the web process and 10 worker dynos for background jobs. At $50/month each, the dyno cost came to a hefty $1,500.
• - Database: Utilizing a more demanding Standard-4 Postgres service, the database cost was $750/month.
• - Add-ons: A variety of add-ons for different services amounted to an additional $200/month.
• - Data Transfer: Given the heavier traffic, data transfer costs were significant, adding another $200/month.

The monthly cost for hosting Juggernaut on Heroku was thus $2,650.

On the DevOps front, keeping Juggernaut running smoothly required a team of two engineers, each dedicating 20 hours per week. With an assumed hourly rate of $50, this led to a monthly DevOps cost of $8,000.

So, the grand total for running Juggernaut on Heroku was a whopping $10,650 per month.

When we transitioned Juggernaut to AWS Lambda, the scenery changed dramatically. With 100,000 daily visits and an average execution time of 200ms per visit, we needed about 20,000 seconds of execution time per day. With 1024MB of memory for each function, AWS Lambda cost came to around $700 per month.

Following the migration, we could reduce the DevOps hours by half, cutting the manpower cost down to $4,000, locking expenditure at impressively leaner $4,700 per month. Math was there even for the heaviest of hitters.

Not Everything is a Nail

Now that we've celebrated the victorious tales of Hummingbird, Doodle, and Juggernaut, let's take a slight detour to explore a different kind of narrative. Enter "Sisyphus", a monolithic Rails app with unique characteristics that paint a different picture.

Sisyphus is a heavyweight champion, boasting a healthy 80,000 daily visits. Originally housed on Heroku, its infrastructure costs were similar to Juggernaut's, ringing up a bill of $2,400 monthly. DevOps hours were also on par, at 30 hours per week, which amounted to a monthly cost of $6,000. The grand total? A substantial $8,400 per month.

However, Sisyphus is not your typical Rails app. It has an intricate, CPU-intensive background job system that executes millions of tasks daily. These tasks involve large file processing and database-intensive operations that would require much more memory and execution time on AWS Lambda.

If we were to migrate Sisyphus to AWS Lambda, the Lambda costs for execution time and memory allocation would skyrocket due to these intensive background jobs. In our calculations, it would amount to roughly $7,000 per month. After halving the DevOps hours post-migration (amounting to $3,000), the total costs of running Sisyphus on AWS Lambda would round up to about $10,000 per month - a shocking $1,600 more than the cost of Heroku.

In Sisyphus's case, the promise of serverless doesn't quite hold up and its example serves as a cautionary tale that highlights the importance of evaluating an app's specific requirements before leaping towards serverless. It's a reminder that while the allure of serverless is powerful, it's not a one-size-fits-all solution.

Hands-on approach

With all those managed options, let's not forget there is always possibility to go with bare metal servers, which can indeed seem like an attractive proposition when viewed purely from an infrastructure cost perspective. After all, having a server dedicated entirely to your application can offer superior performance.

Let's imagine for a moment that we're considering migrating our app, Hummingbird, to a bare metal server. To match the performance we're getting from Heroku, we might need a server with a powerful processor, ample RAM, and a large SSD for storage. This could potentially set us back around $200 per month - a figure that might seem competitive when compared to Heroku or even AWS Lambda.

But, as they say, the devil is in the details. While the upfront server cost might appear appealing, it's the associated costs that can catch you off guard. The management of a bare metal server is no small task; it demands an increase in DevOps involvement. Think of tasks like configuring the server, setting up the deployment processes, managing backups, and keeping the system secure and updated. All these tasks add up to significant man-hours.

In our case, let's say the DevOps team has to dedicate an additional 20 hours per week which translates to an additional cost of $4,000 per month and suddenly the seemingly affordable bare metal option doesn't look quite as economical. This doesn't even factor in the potential costs associated with downtime, server failures, and lack of scalability.

Some might benefit from taking this road but most are not equipped for it.

The Cloud Advantage

While our journey has focused on AWS Lambda, it's important to note that the cloud sky is vast, and AWS isn't the only game in town. Other providers such as Google Cloud Functions and Azure Functions also offer serverless computing capabilities, each with their unique strengths and offerings.

Google Cloud Functions excel in data analytics and machine learning services, while Azure Functions provide excellent integration with other Microsoft services. So, depending on your application's specific requirements and your affinity for a particular ecosystem, your serverless solution could very well reside outside of AWS.

The key is to thoroughly evaluate your needs, performance requirements and budget to identify what will work best for your Rails app. If you need some help analyzing your unique situation and exploring possible outcomes, our team of dedicated experts is here to help.