Extensions | Ideas/feedback requested

Fresh Produce
1

Greetings from the Fly.io Extensions team!
We just launched Sentry.io as our default error tracking extension.
Next, we’re working on bringing you managed Postgres and MySQL (more on that soon).

Now we want feedback from you.
Which integrated 3rd party service would improve your Fly.io experience?
Is something missing, preventing you from migrating workloads over?
Some example areas are:

  • CI/CD pipelines
  • Metrics consumption and visualisation
  • Log aggregation
  • DNS
  • WAF, Bot management
  • CDN
  • …

Thank you for sharing your ideas.

6 Likes
2

For my personal projects and side hustles, nope your awesome.

But for the enterprise I work for, I can see a few gaps. Some thoughts -

CI/CD for me is normally handled at enterprise level by something like Jenkins. So I don’t think this is a big concern, since you can just run the job.

I can really see the need for something like APM. If you can get integrations with NewRelic and DataDog that would be a big win. Personally love DataDog. I am unclear if Sentry is competing in this space as much as it has slight overlap.

Log aggregation is 100% needed for enterprise in any place where they are auditing usage logs, and traffic logs for bad actors and bad behaviors. Splunk would probably be the best integration with the most surface area.

I can’t speak much to DNS, I know my enterprise hosts there own, but I don’t interact with it much.

WAF and Bot Management is becoming a huge deal. With credible threats a DDoS attacks, having control here makes a lot of sense. I know you have services higher up, but the lack of visibility and rule set control is a big deal.

CDN is a lowest on my list personally, because of the fact that your at edge already. Though I can think of features on a CDN personally, I would love to have and use other services for. These are less drop dead needs, as much as they are nice to haves that make development easier.

  1. Location based headers
  2. Image manipulation functions (path/to/image.jpg?size=100x100&zoom=1.2&shape=circle)
  3. Cache control (time, purge, routes, file types, etc)

Outside of this, for new ideas for startups I would add -

A status page partner. With your proxy routing and control of the network, it would be interesting to do two things.

  1. Have a partner you can work with so you have better capability to push capabilities or websockets, so they don’t have to rely on pings. I can see this being at the proxy layer when apps are healthy, so it never travels to the actual app.

  2. Integrations where apps can sign up to report, for SaaS businesses that other depend on.

I would love a BackBlaze integration as a alternative to S3.

Lastly I could see paging services, which shortcut the need for APM or Status Pages (for internal). For example a webhook integration to report to PagerDuty that a service name (app-name-here) is down, would be pretty great.

I imagine this would be in stalled states, like unable to start, user has no high-availability, or all instances are bad (bad deploy). I can see this one being dangerous for you all to own, as it could be hard to split the difference of your internal issues, vs the apps specific problems?

Last thing I can think of is cloud scanning software for compliance. For example I have to use Prisma (palo-alto) to scan configurations for SOC2 issues based on controls. Would be interesting to give at a organization (not app) level, access to a 3rd party that build that integration.

Intrusion Detection and Security scanning in general would be helpful.

I don’t know that for my use cases on fly.io currently, any of this is needed. But working for a fortune 12 company in healthcare, I could not even suggest fly.io for hosting right now. Not because I don’t believe it in and think it would be a cost savings and ease a lot of our burden with AWS. But because we have too many outsized requests from other verticals that put requirements on what we do in the form of governance, where they already choose the tool we have to integrate with. Or at a minimum set a baseline we have to meet related to log drains, security scans, monitoring, reporting, cost optimization, and meeting “pre determined best practice patterns”.

To be clear, I work for the most risk adverse and conservative company you can imagine. The innovative ideas that Fly has, will take another 5-10 years to even enter there vocabulary as a pattern/consideration, and another 3-5 to become reality as a use case.

Hope that all makes sense, and happy to contribute more.

5 Likes
3

Zane: thank you very much for your time & ideas. Especially appreciate your inputs on APM, Logs & S3. We will take all that feedback and start working on the list and keep the community update as we execute on more integrations.

2 Likes
4

Let me know if I can help speed that up!

1 Like
5

Hi, I’m the founder of FlyCD, a git-based, continuous deployment platform for people that deploy on Fly. I already have some Fly customers using FlyCD. As a service/platform provider, I think it’ll be nice to have some way to integrate with Fly similar to how GitHub Apps work. This could help with performing actions on behalf of a user/org using short-lived tokens, as well as better integration into the platform.

Also, I’m open to discussing with you if there’s a better way to integrate with Fly and give people a good automated deployment experience without them needing to master YAML or specific CI/CD tools, or struggling to maintain the pipeline code across multiple repos and projects. Some developers want to focus on shipping and not bother about YAML.

2 Likes
6

Of course! Happy to participate more in any way possible. You’re my favorite cloud. =)

1 Like
7

WAF would be amazing to have, though it would need to happen transparently and without a massive cost increase (for us we’d expect roughly $100 - $150 / month for our usage).

I don’t want to be managing another layer of networking and paying for double or triple the bandwidth just to have everything pass through a WAF.

I want to be able to select a default ruleset, fiddle with some rules needed for our service, hit update and suddenly we have WAF on our apps.

8

Thanks for soliciting feedback about this!

  1. A caching HTTP proxy that supports purging by tags (surrogate keys) and with a pricing model that scales down to free or nearly free for low traffic apps. Cloudflare only offers cache tags on their enterprise plans and Fastly has a $50/mo starting price. However, https://www.quic.cloud/ has a generous free plan that supports cache tags. They’re marketed as for WordPress only, but I think that’s more about marketing than a technical limitation. They just use HTTP response headers for tagging and purging.

  2. A service that auto-deploys my app when a base layer in my Docker image is updated. For example, if my Docker image has an Ubuntu base layer and Ubuntu releases a security fix, I want that deployed even if/when I’m off-grid. I could probably figure out how to do this with a GitHub action, but it would be nice to not have one more thing to have to setup myself.

  3. Sorry, this one might be a bit off-topic, since it’s more of a Fly.io feature request than an integration, but adding VM snapshotting (like Lambda SnapStart) in order to reduce app bootup latency when scaling up from 0 would be awesome!

By the way, Fly.io is great! Keep up all your awesome innovative work!

1 Like
9

Hey there!

Would be nice to have

  1. logs aggregation
  2. alerting
  3. better metrics
  4. postgres backup management

I’m using Cloudflare over Fly, so not much interested in CDN and WAF.

One thing I miss after using AWS Beanstalk - is extended blue/green deployment. The new version is deployed under a different URL, you can manually test it and then swap URLs with main deployment. It’s zero downtime blue/green with a manual switch

2 Likes
10

CDN and DDOS protection became one of the issues that affected whether I deployed on fly. There are currently some conflicts between fly and cloudflare’s automatic ssl, which is documented here: Custom Domains and SSL Certificates · Fly Docs

I’m not sure which is better: fixing compatibility issues with cloudflare so I can take advantage of cloudflare’s services, or building fly’s own CDN and DDOS protection so I can rely on one less service.

3 Likes
11

Open Telemetry

Metrics and log aggregation sound great, but if those are each separate solutions, and sentry is another separate solution, then we have to go to a lot of unrelated services to try and cobble together a complete view. An OpenTelemetry initiative would be awesome. You’ve already got grafana and prometheus, so some of the usual suspects are already in place.

GitOps

The other one would be to come up with a clear solution for gitops. Right now, you have a terraform provider that doesn’t offer enough platform coverage. For example, I can deploy an app w/ an existing docker image, but I can’t deploy one where the image is built at deploy time. Also, once I use terraform, I can’t use flyctl. So deploying updates once the infrastructure is in place doesn’t work either. There are others limitations. As side projects go, it’s phenomenal. But side project is what it looks like at the moment. (fly.toml is unnecessary for app deployment?)

Flyctl is slick, but it’s procedural, and isn’t what’s powering the terraform provider. So it’s… really only suited to small projects with 1 environment, or folks who aren’t doing gitops. You have to have fly.tomls, which are a pain because they’re targeted at specific environments and would be in conflict w/ terraform anyway.

Most concerning is the announcement that flyctl is where you were planning to move all of the “brains” of your deployment was concerning. (Flyctl Versions, Autoupdating, and the CLI Apocalypse) Because unless this becomes the brains of your terraform provider, you’re working on numerous, seemingly independent deployment strategies. (terraform provider → graphql, flyctl → graphql, and graphql directly). And a gitops story will be left out here.

So at the moment, I’ve used terraform for 3rd party things, like rabbit. But I have to stick w/ flyctl for my code, and to have a CD solution

Managed Postgres

I just read the barman post which sounds like a great step. Will look into that. But again, its baked it into flyctl, not the api. Regardless, something fully managed there would be phenomenal.

12

The Sentry extension turns out is a pretty bad example of extensions and I hope the future extensions are much better.

It doesn’t have any integrated billing, so billing still happens with the 3rd party. You lose the “free tier” if you want to go over the included limit and want to pay for the overage. It pretty much does nothing more than create an account for you and set a secret.

I would expect extensions to be worthwhile integrations with billing happening through fly and not being a glorified signup process.

1 Like
13

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.