{
"$type": "site.standard.document",
"canonicalUrl": "https://unnecessary.tech/posts/flyio",
"path": "/posts/flyio",
"publishedAt": "2023-01-17T18:06:44.000Z",
"site": "at://did:plc:jx54v4rmscfwzit7fmgz24ba/site.standard.publication/3mnrsqmzz3w2e",
"tags": [
"programming",
"cloud"
],
"textContent": "A while ago I deployed this blog to [Fly.io][fly] as a small exercise to gain\nsome experience with the platform, but this is just a static blog that can be\ndeployed on any static hosting site. In order to learn more, I decided to\ndeploy a small project, PostNewsRSS, to [Fly.io][fly] to get a better idea of how well it performs and how\neasy it is to use.\n\nWhat is Fly.io and what does it cost?\n\n[Fly.io][fly] is a PaaS service with servers in 26 locations around the world.\nTheir service is based in building and deploying a docker container, but rather\nthat deploy it as a container in a host operating system, they deploy each\ncontainer as a separate [firecracker microVM][firecracker]. This creates additional\nisolation between adjacent services as no two deployed apps use the same kernel.\n[Fly][fly] also deploys their own hardware to datacenters, which allows them to\npotentially charge cheaper compute, storage, and bandwidth rates than they\ncould if they also relied on cloud services such\nas [AWS][aws], [GCP][gcp], or [Azure][azure]. Compute does seem to be fairly\ncompetitively priced with a single shared CPU with 1 Gigabyte of RAM costing\n$5.70 a month on [Fly][fly]. Similar VMs at GCP would run around $6.03 for\n[GCP][gcp] (e2-micro VM), and $6.05 on [AWS][aws] (t4g.micro). Dedicated\ncompute at [Fly][fly] is a much higher price with a 2 CPU with 4 Gigabytes of RAM\nsolution running $62 a month versus $24.12 for [GCP][gcp] (e2-medium) and\n$24.19 on [AWS][aws] (t4g.medium).\n\nVolume storage runs $0.15 per Gigabyte per Month which compares favorably to\n[GCP][gcp]'s SSD price of $0.17 per Gigabyte per Month, but is higher than\n[Amazon][aws]'s $0.125 per Gigabyte per Month io2 provisioned SSDs. Overall\nthese prices are fairly similar. Outbound data transfer runs from $0.02 per GB\nto $0.12 per GB depending on region, compared to between $0.12 per GB and $0.23\nper GB for [Google][gcp] and $0.09 per GB for [Amazon][aws]. [Fly][fly] also\noffers a generous free tier which includes up to 3 shared 1 CPU VMs with 256\nMegabytes of RAM, 3 Gigabytes of volume storage, and 160 Gigabytes of outbound\ndata transfer, which is definitely enough to get started.\n\nIn addition to basic compute, they also offer a\nsemi-managed\nPostgres database service. I have not taken advantage of this service yet, and\nwould recommend keeping an eye on the work they are doing with distributed\nsqlite. They also offer managed redis\nthrough [upstash]. I have not tried any of these services, so I cannot evaluate\nthem right now.\n\nOne interesting approach [Fly.io][fly] has to pricing is that they offer in\naddition to the \"Hobby\" (pay-as-you-go) pricing. [Fly][fly] has support tiers with\nfixed monthly rates, however they also come with an equivalent amount of usage\nincluded. So for example if you were to reliably use over $29 a month in resources,\nit would behoove you to buy the \"Launch\" plan which costs $29 a month, and\nincludes $29 a month in usage. This would give you access to email support at\nno additional cost. At the $199 a month level is the \"Scale\" plan which includes\n$199 a month in usage, priority email support, and some compliance assistance. \nThis includes signing a BAA under HIPAA as well as filling out the security\ncontrols they are responsible for in a NIST 800-53 type form. There is also\nan \"Enterprise\" level which includes additional compliance and support levels\nincluding an SLA. If you need this level, you know it, and have to negotiate for\nthe price.\n\nWhat is the developer experience?\n\nFor my blog, I deployed a simple Docker container running [nginx] using the\n[flyctl] command line client. Running flyctl launch will do an analysis of\nthe project and create a fly.toml configuration file you can edit. Then\nflyctl deploy will deploy your project. It will be sent to a free build\ninstance which will do the docker build and send the image to a private fly\ndocker image repository. Then the project will be deployed as microVMs in one or\nmore regions depending on how you scale the project. This is a relatively fast\nand smooth process for my blog.\n\nThe [PostNewsRSS][postnewsrss] project is written in [Go] and will generate an RSS\nfeed on the fly by querying the [post.news][postnews] API. For this project I\ndecided to use [paketo buildpacks][paketo] which are the default for many programming\nlanguages detected by [flyctl]. I deployed this service to two regions to allow\nfor some geographic diversity and to potentially have no downtime should one\nregion go down. When I first deployed I thought I had a problem, because the build\nseemed to hang for several minutes after downloading the paketo build images.\nEventually the compilation phase starts, but for several minutes it appears there\nis little or no progress. I am not sure why there is\nthis delay, but it seems pretty consistent for me, even after I destroyed and\nredeployed my build server. It is not a showstopper at all, but it is something\nto be aware of. During a build the old version of the application remains up, so\nit does not cause any downtime, but it does mean that a deployment will take up\nto 10 minutes.\n\nYou can review the logs of the application using the flyctl CLI as well as on\nthe [Fly.io][fly] dashboard, but one of the major benefits of the platform is\nthat a wide variety of [metrics] are available and can be queried using [PromQL].\nThis means it is trivial to attach a Grafana dashboard to an application for\nmonitoring. [Fly.io][fly] will also gather custom metrics from your application\nevery 15 seconds and save those metrics for approximately 3 days. For my application\nI set up metrics to monitor the count of the number of times queries were throttled\nfrom individual IP addresses as well as metrics to measure the success and \nresponse codes from queries made by my application to the upstream [post.news][postnews]\nservers. The metrics can be served on a separate port from the web service to\nkeep them private, and if you want to save them for a longer time period, [Fly][fly]\nexposes the prometheus federation endpoint allowing you to copy the data into a\nprivate prometheus or influxdb database. This custom metrics service allows for\na lot of flexibility in monitoring and is a major benefit to the platform.\n\nFinal thoughts\n\nI really enjoy using [Fly.io][fly] and I will keep it in mind for future projects.\nI agree with this post that\n[Fly.io][fly] is a very good successor to Heroku and encourage anyone looking for\na PaaS platform to give it a try. I am also happy to count it among several moderate\nsize companies creating deployment platforms that can compete with the big cloud\nproviders by offering a tremendous developer experience in a specific cloud\ntechnology, rather than offering a catalog of generalized cloud services. \n\n[fly]: https://fly.io/\n[firecracker]: https://firecracker-microvm.github.io/\n[aws]: https://aws.amazon.com/\n[gcp]: https://cloud.google.com/\n[azure]: https://azure.microsoft.com/\n[nginx]: https://www.nginx.com/\n[flyctl]: https://fly.io/docs/hands-on/\n[postnewsrss]: https://postnewsrss.unnecessary.tech/\n[postnews]: https://post.news/\n[upstash]: https://upstash.com/\n[Go]: https://go.dev/\n[paketo]: https://paketo.io/\n[metrics]: https://fly.io/docs/reference/metrics/\n[PromQL]: https://prometheus.io/docs/prometheus/latest/querying/basics/",
"title": "Deploying on Fly.io"
}