00:00:18
Welcome to "Terms of Deployment: The Process of Evaluating Hatchbox, Fly.io, and Render for Developers." I have a confession to make; despite the title, which is inspired by both the novel and the movie "Terms of Endearment," there is no connection between those media and this talk at all. So if you're a Deborah Winger or Shirley MacLaine fan, if you leave, I won't be mad.
00:00:27
Today, we're going to talk about some of the new app hosting platforms that have come online for Rails developers recently. I'll introduce myself, discuss how we evaluated some options, and talk about the different factors you can use to help make decisions for yourself, whether you work for an agency, a digital product studio, or are a freelancer.
00:00:40
We hope to provide you with the tools necessary to help you decide which platform to use. At the end, we'll summarize and give you additional tools to help you move forward.
00:00:54
So, first of all, who am I? My name is Jordan Burke, and I'm a senior software developer at Headway, a digital product studio based in Green Bay. You can tell it's me because I'm wearing the same jacket in the picture. I actually only have one jacket and a couple of hoodies.
00:01:04
I'm a recovering technical founder who has learned many things the hard way. My first startup was a healthcare IT startup, so I learned how to build a HIPAA-compliant infrastructure on AWS in 2013. Not fun! I have helped run Rails Girls events, Rails Bridge events, and taught some introductory Rails courses. I heavily relied on Heroku's free tier to teach people how to put their Rails apps online.
00:01:27
I love to build things, whether it's Legos, my garden, software, or what have you. This is just a small part of my collection; don't even get me started on my Star Wars tabletop miniature collection. But let's talk a little bit about why we're here.
00:01:42
First off, how many of you work with clients and recommend hosting solutions, or are on small teams responsible for these decisions? Okay, a few of you should get something out of this. At Headway, we work with larger clients that have their own infrastructure teams, and this talk isn't necessarily for them. So if you're watching, you can tune out.
00:02:04
The smaller clients we work with are just getting started or don't have a lot of tactical expertise in-house, so this talk is definitely for them. What really spurred the genesis of this talk is that, as you may have heard, in late August of 2022, Heroku announced that they were discontinuing their free tier.
00:02:26
Like you, I'm sure this threatened the livelihood of many apps that you had put on Heroku and completely forgot about for five to seven years. I mean, how dare they! I'm kidding, of course, but it shook a lot of things up. Even though nothing was really changing for our clients, we still use Heroku for a couple of our clients.
00:02:45
It prompted us to explore alternatives. Many alternatives were popping up, and it made us question whether we were serving our clients' best interests. Therefore, we decided to explore some new options with internal products and some client projects that the clients trusted us to steward their resources, budget, and time.
00:03:09
We have deployed some client projects to Hatchbox, Fly.io, and Render. We wanted to determine the quirks and eccentricities of each platform so that we could make informed decisions in the future. You might ask, 'Why not Elastic Beanstalk, why not MRK, why not X?' These were the three platforms that we felt closely matched our needs and our clients' needs at the time.
00:03:42
Evil Martians just released a blog post last night about MRK, so if I go to Rubyconf in November, I'll probably add that to the list. There are many platforms out there that can serve your clients' needs; these are just the three that really worked for us.
00:04:09
So let's talk about the contenders we brought to this discussion. How many of you have used Hatchbox? I expected that. How many of you have used Fly? Okay, a couple of hands. How many of you have used Render? A few more hands.
00:04:46
We have used all three platforms in some fashion at Headway and I've tried to remain objective in this overview, but we're all human. I have my favorites, but I appreciate all of them.
00:05:01
Let's start with Hatchbox. Disclaimer: this is all my interpretation.
00:05:05
Chris, who's sitting right here, has nothing to do with what I'm about to say. Hatchbox is by Rails devs for Rails devs and lives by the principle of convention over configuration. You can bring your own back-end servers from the usual suspects: AWS, DigitalOcean, Linode, Vulture. So you have some options there.
00:05:15
We work with many startup companies, so we recommend they sign up for AWS Activate and get $1,000 in free credits from AWS, and then back that up with Hatchbox. This gives them a bit of a head start.
00:05:37
Clearly, Hatchbox is from the folks that created GoRails, so you know they're scratching their own itch with it. Some considerations: it's opinionated and currently only for Rails. If you're trying to do something outside the conventions, you can, but you'll have to do it yourself.
00:05:48
Nothing on Hatchbox prevents you from doing whatever you want on your servers. Moving on to Fly, it's really nifty because it scales where your users are. There is a free tier, but if your app goes viral in South America, it can scale instances there. If you have lots of worldwide traffic at specific times of the day, Fly helps you keep up with the ebb and flow of your users.
00:06:17
Fly's instances are bare-metal machines, so you can configure them with whatever your deploy process is using the toggle configuration files. You can deploy Docker files with it, and if you run into issues, posting on either their community board or on Reddit gets you a response super fast, sometimes even from their CEO.
00:06:41
Fly tends to soft-launch features into their CLI, so you might have to dig around to figure out how to do certain things. While they offer database instances, they specifically and almost gleefully maintain that they are an app platform. So you might want to host your databases elsewhere if you want better management tools.
00:07:07
I respect their line in the sand; it's a consideration for you.
00:07:16
Render is the platform I have experimented with the least, but I think there's a lot of upside. It has probably the fastest setup I’ve ever seen. I took one of the jumpstart free template Rails apps and put it on Render in about five minutes, from getting it to git push.
00:07:31
It's also the cheapest option I found. I completely forgot about a setup for about a month and got a bill for just $14, which is great. Render wants to become a one-stop shop for all app needs: static sites, web apps, databases, Redis, cron jobs, all of it. It's clearly aimed at replacing Heroku as the app hosting multi-tool.
00:08:03
They have a significant free tier to back up their intent, and it will get your Rails app up and running. So, which one do I choose? The answer might surprise you.
00:08:31
How many of you walked in here not expecting it to be 'oh, it depends'? No? Now we're going to start some fights—kidding, it all depends! That was a misdirection; obviously, that's why you're here.
00:08:49
You're looking to learn about the platforms and figure out how to make that decision yourself. So, we're going to talk a little bit about what you can do and how we at Headway use certain criteria to make those decisions.
00:09:05
So, why not choose one? There's nothing wrong with sticking with one platform depending on your clients, customers, and your team. That might be the best option for you. Stability is paramount when it comes to delivering good products to customers and clients. If you feel most comfortable with one particular platform, just go with it.
00:09:38
However, you may still need to choose now or in the future which one to stick with or whether to diversify. At Headway, we consider several criteria when deciding which platform to use for a new client or whether to migrate an existing client to a new host.
00:10:09
We look at the knowledge costs, which involve our team's experience with the platform, the technical costs, which encompass how we spend our clients' budget and time to deploy the project, and finally, the monetary cost, which is quite straightforward.
00:10:24
Let's dig into these criteria. With knowledge costs, we assess how much experience we have with the platform for the specific type of build. At Headway, we're not just a Rails shop; we also develop Phoenix apps, React Native, and React Web, and we often create custom solutions based on what the client needs.
00:10:57
Is this platform the best solution for the project? Have we ever deployed a Phoenix app to Render before? Sometimes the answer is no, but we take all of that into consideration. Additionally, we evaluate if that knowledge is localized—have we shared it within the team? How easy is it for someone else on the team to step in if the current developers win the lottery?
00:11:29
There are tricks and pitfalls we've learned along the way, and if we don't document those carefully, they could trip up anyone coming onto the project or when we hand it over to the client. We also consider how easily that knowledge can be transferred. How much DevOps and infrastructure knowledge do we need to get up to speed on it? Is it just a 'git push,' or is it going to require multiple CLI commands to get into the console to deploy?
00:12:12
Technical costs encompass both the budget for the project and the trust in the team to complete the objectives we're setting. These are finite resources, and we need to ensure that we’re good stewards of those resources with our decisions.
00:12:53
We ask ourselves whether our predisposition to tinker with new things is running wild. We need to be clear about that with ourselves and our clients. If an update needs to be made, such as upgrading Postgres or Ruby versions, how much work does that involve? Is it easy enough for the client to do themselves, or do they need to find time with us or someone else?
00:13:12
This also involves considering the expertise of their team. A lot of the time they might only have a single developer or head of technology who handles most of their needs. We must determine how easy or difficult it will be for them to perform these tasks.
00:13:44
A significant factor to consider is how easily the product can scale. If the product gets noticed on platforms like Product Hunt, how easy will it be to manage potential 502 errors? If it doesn't scale as needed, is it our fault or the platform's fault? Let's be real—who here hasn't written code that leads to some 502 errors when users try to access the app?
00:14:12
Now, let's talk about monetary costs. This is one aspect you definitely need to discuss with the client, but only after covering the earlier two costs internally. Monthly costs are a concrete number that the client can see, and it impacts their burn rate. If your previous explorations led you to not use the cheapest option, make sure you have valid reasons for that choice.
00:14:46
Make sure you're prepared to explain the trade-offs clearly. For instance, while one platform may charge $5 a month, it might require 20 man-hours to change things, ultimately costing more in the long run.
00:15:23
These are all considerations to weigh when working with clients and determining the best solutions, because this is not a decision you should make unilaterally. You need to discuss options with your clients or customers; otherwise, you might end up going with what you prefer and not necessarily what best serves them.
00:15:50
We've given you tools and taken you to the dance-off; now we'll provide you with additional resources to help plan your journey. You know your capabilities; you know your team, and you know the clients you're working with.
00:16:17
If you're a small technical co-founder or the person tasked with maintaining infrastructure on a small team, first of all, I see you and I appreciate you. You know what smart moves to make with your resources. Trust your gut and be willing to reach out for help, even on client projects.
00:16:43
When we've run into challenges, we've reached out on Discord or hopped into forums for Fly, and we instantly got answers or were pointed in the right direction. You don’t have to know everything; it’s about being willing to ask for help.
00:17:12
All three platforms I discussed today have very active communities on Discord, Reddit, and their community boards. You're likely not the first person to encounter an issue, and help is just a question away.
00:17:39
As for tools, I will post these slides in the Slack channel, and you'll be able to see all my silly speaker notes as well. You can either laugh or make fun of me—either way, it’s fine.
00:18:04
This talk actually evolved from a blog post I'm writing about a detailed comparison between these three platforms and Heroku, which is getting longer each day. We plan to add MRK to that comparison, and who knows what else will come up next week.
00:18:30
In that blog post, we will also have a public checklist on Notion that you can use to duplicate and customize. We have one internally that we use as a gut check while starting new client projects and determining which host to utilize.
00:18:56
As always, I’ve broken many things, both hearts and software, so feel free to reach out about mistakes I’ve made; maybe I can help you avoid them.
00:19:31
We have time for questions. You may direct them to my dog, Arthur Pendragon, or me directly. My email is on the last slide, and I’m happy to take them.
00:19:57
Thank you!
00:20:06
That's a very good question. The inquiry was whether you get managed databases on Fly, like you do on Heroku.
00:20:15
The answer is no. They just rolled out Postgres clusters on Fly, but those are still unmanaged. One of the apps we have on Fly still uses the managed databases from Heroku because that's one of the recommendations they make.
00:20:35
They recommend RDS or Heroku, which adds more complexity, but it works. Regarding the discontinuation of the free tier on Heroku, it shocked my perception about the platform.
00:20:55
For a long time, we relied on Heroku for Rails Girls, Rails Bridge classes, and now we find ourselves looking for alternatives. However, Heroku still has not raised prices, and they continue to serve clients well, including those still on paid plans.
00:21:25
I believe that Heroku's discontinuation of their free tier reflects a lack of reinvestment in the community, while platforms like Fly and Render are keen to grow their user base.
00:21:50
As for moving clients to alternatives based on geographical scaling potential, we haven't made that decision yet for any specific clients.
00:22:04
However, one client we did move over to Fly could benefit from future geographical scaling as their needs grow. We're working holistically to make this decision based on each specific case.
00:22:31
We consider how comfortable our clients are with managed versus unmanaged databases when evaluating hosting options. A significant aspect of our work involves assessing our client's technical expertise and their ability to self-manage.
00:22:50
If clients are slow to change their DNS settings, it indicates their capability to manage an unmanaged database solution effectively.
00:23:13
Finally, if I had to choose a platform for another introductory Rails class without a client involvement, I would choose Render due to their expansive free options.
00:23:30
In conclusion, I would go with the easiest setup possible, likely sending the app without Dockerizing it first. However, if I plan to share it as an example, I might include a Dockerfile configuration.
00:23:52
With tools like Render and Hatchbox, deployments typically occur through GitHub or webhooks, so user management is largely in your control.
00:24:07
Fly uses CLI commands for deployment, which gives everyone access unless specific integrations with GitHub actions limit deployments to particular users.
00:24:25
In summary, the question surrounds leading indicators for moving from managed to unmanaged databases. This varies based on case specifics, and I appreciate hearing various opinions on the topic.
00:24:45
If you're considering transitioning to an unmanaged database, having a dedicated ops team and the ability to perform backups can be crucial.
00:25:09
Thank you all for attending and for your questions!