Expected Behavior has more than a decade of experience hosting complex, high availability, high traffic software products in AWS. We've used AWS services from Kinesis to Lambda and built an impressive set of internal tools to manage complex deployments with relative ease. We've also worked in Azure, DigitalOcean, Linode, and Heroku.

And yet we've decided to use Render, a zero-devops cloud service, to host our new project management tool Burndown. Why?

Start Fast, No Ops

We want to use Burndown for our internal project management ASAP, so there's no time to waste. Any time spent spinning up servers, setting up services or otherwise managing an AWS deployment just gets in the way of shipping useful software. And it's not just the up front time we're looking to avoid: any time spent on ops over the coming weeks will just distract us from building a tool we love to use. Or worse, distract our teammates with ops work when they already have full plates.

It only took a few minutes to get a basic Rails app up and running in Render and we're not spending any time managing servers going forward.

Move Fast

We want to start fast AND move fast. Render's preview environments and GitHub integration mean we can see a pull requests in action by just clicking a link. While not necessarily ground breaking, we didn't have to do anything (or pay extra) to set this up. It's baked in!

Some other features that help us move fast:

• The built in job system and cron runner are must haves and look quick to set up
• The fast shell access is a time saver

Some room to grow

While Render is quick to get started, it also has enough of the creature comforts that we think we'll be able to live there for some time. Specifically:

• Built-in log access
• Some basic metrics built-in (CPU, memory, bandwidth)
• Easy autoscaling if we need it
• Persistent disks if we need them
• Database backups
• Internal services, if we need them

An important caveat: the limitations of Render are no problem for a business process product like Burndown. But there are certainly limits. For example, we won't be porting our application monitoring product Instrumental to Render, as it's complex infrastructure requires more than Render can offer.

Small and Scrappy

All things being equal, we like to support small companies. As a bootstrapped team of 6, it'd be a bit hypocritical if we didn't. That's not to say that Render matches our bootstrapped model - they've recently raised a $20m Series A and are growing quickly. Still, we'd rather give them a try than stick with the giant tech company products we're used it.

Bonus: The CEO answers user questions on Reddit. A good sign!

Low cost

While cost isn't a primary concern, it's going to cost us less than $20/mo to run Burndown for the foreseeable future. This might be a bit more than if we hand-rolled something tiny on AWS, but it's about half what we'd pay for a similar setup in, say, Heroku.

Honorable Mention: Infrastructure-as-code

We really like Render's blueprints as a way to define the stack and environment in code. That means PRs and the standard code review process to change infrastructure, and it means spinning up a new service or process without clicking around in an interface. :chefs_kiss:

Some Alternatives

In our review of the landscape, we also looked at:

• Heroku. Everyone on the team is familiar with it and it has many of the same benefits. But Render is tighter, cleaner, cheaper and scrappy. We also really liked the shape of Render's native environments compared to Heroku's buildpacks. See also: Render vs Heroku.
• DigitalOcean's App Platform. We like DigitalOcean and strongly considered them. Really it came down to this: Render was faster and a bit easier to get up and running.
• Rolling our own PaaS with Dokku. While it would be fun to set something like this up, it doesn't meet our primary requirements of Start Fast and No Ops.
• All of these seem good and have benefits over Render, but Render was the best overall fit for our requirements on Burndown.

On Avoiding AWS' Managed Services

In our experience, software becomes more complex to operate over time. When you're hosted within AWS, it's very tempting to use their many managed services to offload that complexity. That's often a very rational and reasonable choice, but it comes with a big downside: you're likely married to AWS for the life of the product. We don't want to be so married to one provider that it's cost prohibitive to switch when something better comes along.

While Render might actually be hosted within AWS, and may even use their managed services under the hood, the Burndown codebase doesn't have those decisions baked in. This gives us maximum flexibility moving forward.

tl;dr: With Render we can start fast and move fast at low cost with room to grow, while avoiding ongoing ops and vendor lock in.