We at ChiselStrike are building a backend-as-a-service product and run most of our infrastructure on AWS using tools like Kubernetes and Terraform, which are arguably the industry standard for infrastructure. Although everybody talks about how Kubernetes, for example, is complex and hard, most companies out there use it. It’s hardly surprising to folks like me who lived the pre-cloud computing days. You literally had to file an infrastructure ticket to get anything done and sometimes it take multiple weeks to get it done. So being able to fire up instances on the cloud with automated cluster management and provisioning, it feels pretty darn amazing knowing the history.

However, infrastructure is still hard, and you need expert infrastructure engineers to work on it. As a developer, I still often resort to just asking our infrastructure folks to do things for me. Instead of filing a an infrastructure change request ticket, I ping them on Slack and wait for an hour or maximum a day, instead of waiting for weeks. Don’t get me wrong, I would like to contribute more, but whenever people start to talk about EKS storage classes or Helm charts, I want to run away screaming. And I think I should know some of this stuff because if you want to talk about Linux kernel namespaces or cgroups, I feel right at home. There’s something about infrastructure tooling that’s just foreign to us developers.

Developer friendly infrastructure?

Fly.io has made a big splash recently on no-nonsense infrastructure. When I first heard about them, I was sceptical. Infrastructure is tons and tons of hard work, so how could anyone actually compete with industry giants like AWS, Kubernetes or Terraform? But the more I read about their architecture the more it made sense. To put my money where my mouth is, I decided to give it a go and see how I could deploy ChiselStrike applications on Fly.io.

The first thing I did was go to the Fly.io web site and sign up. The experience was actually bit confusing on the pricing. I am on a “Hobby Plan”, but still they asked for my credit card (which I entered). I have so far not been charged with anything, but am unable to find pricing information to confirm that’s the case. After signing up, I installed the flyctlcommand line tool, which lets users provision and control deployments.

From a developer perspective, there are two main abstractions on Fly.io: applications and machines. Applications are the high-level unit of deployment whereas machines are a lower-level interface for provisioning micro-VMs. For my own use case, I decided to just focus on applications, although I did play around a bit wit the machine interface too.

For deployments, Fly.io uses Firecracker-based micro-VMs, which supposedly boot in some hundreds of milliseconds and are automatically suspended when inactive, which reduces cost. The way you deploy an application to Fly.io infrastructure is via a Dockerfile, which is internally consumed by Fly.io.

Deploying ChiselStrike apps on Fly.io

The first thing I needed to do was to make it easy to build a Docker image of a ChiselStrike applications. After some trial and error, this turned out to be pretty easy. As ChiselStrike can already be consumed via npm, I just needed to make sure I copy all the project contents to the image and then run npm install in the container, and launch npm run dev:

FROM node:18-slim
COPY . /opt/app
WORKDIR /opt/app
RUN npm install
EXPOSE 8080/tcp
CMD npm run dev -- -- --api-listen-addr 0.0.0.0:8080

The resulting image is slightly bigger than I had hoped for, but part of the reason is that ChiselStrike uses npx internally so the final image needs Node.js. However, I consider that to be a bug and once that’s fixed, the final image only needs an OS and ChiselStrike, and the OS part can be also shrunk with Alpine Linux, for example.

So how does the deploying a ChiselStrike application to Fly.io look like in practice?

You first create a ChiselStrike app with:

npx create-chiselstrike-app my-backend

The command creates a project template with a “hello world” endpoint.

Once you have signed up to Fly.io, deploying is as simple as:

fly launch --generate-name --region fra --now

That’s it! No additional configuration or setup needed. As long as you have a working Dockerfile, Fly.io deals with the rest. As a developer, that’s a pretty magical experience!

Summary

Although I absolutely fell in love with Fly.io, the APIs and documentation are still bit rough around the edges. As I was trying to get gRPC working, I had to consult random discussion forum posts and the age-old procedure of trial-and-error to get things working. I did hit random DNS errors when attempting to ssh to the Fly.io machines and OpenSSL failures while testing. I also hit a really weird error when lauching an app on macOS that didn’t happen on Linux.

That said, Fly.io really does feel like it’s going to make infrastructure easy for us developers. It’s very easy to get started and the interfaces are very discoverable. I am personally looking forward to playing around with Fly.io more in the future, and maybe doing a more complete proof-of-concept for deploying ChiselStrike applications.

#Fly.io

Fly.io makes infrastructure easy for developers