[HN Gopher] Fly's Prometheus Metrics
___________________________________________________________________
Fly's Prometheus Metrics
Author : elithrar
Score : 59 points
Date : 2021-05-13 21:07 UTC (1 hours ago)
(HTM) web link (fly.io)
(TXT) w3m dump (fly.io)
| yannoninator wrote:
| I'm not quite sure if fly is production ready for our usecase
| yet, but it does look awesome though.
| mrkurt wrote:
| It depends entirely on your stack + use case! If you feel like
| emailing I can give you an honest take. :)
| hstaab wrote:
| Does anyone here have experience using Fly? I've seen a few of
| their posts and it seems quite nice.
| mtlynch wrote:
| I discovered fly a month or two ago, and I've been incredibly
| impressed. The dev experience is really nice, and the team is
| super responsive.
| mrkurt wrote:
| You can get a reasonable idea of the problems people run into
| on our community forum. I use Fly for everything but that may
| not be the best signal for you: https://community.fly.io/
| wferrell wrote:
| I recently setup my own http://logpaste.com to give them a try.
| Fly was quite easy to use.
| krono wrote:
| First time I've heard of Fly, went to check out their docs and
| found this awesome little mention:
|
| > We use Lets Encrypt to issue certificates, and donate half of
| our SSL fees to them at the end of each calendar year.
| tptacek wrote:
| We wrote a similarly tedious piece about how our certificate
| system works, if you're interested: https://fly.io/blog/how-
| cdns-generate-certificates/
| ryanschneider wrote:
| How big is the fly eng team at this point? You all seem to be
| doing a ton, I'm always kind of surprised these posts don't end
| with the usual "we're hiring" blurb that's become the norm on
| these sorts of tech posts.
| mrkurt wrote:
| We're small, only 7 people. That's on purpose (so far). The
| magic 8 ball says we'll grow in the next few months though.
| dexen wrote:
| Not to pick on Fly (seems nice), but on the trend for containers:
|
| _> if you've got a Docker container, it can be running on Fly in
| single-digit minutes._
|
| I used to laugh at the old Plan 9 fortune, "... Forking an
| allegro process requires only seconds... -V. Kelly". Guess I'm
| not laughing anymore?
|
| FWIW, performance of components is _the_ barrier to composition
| in system design and development. You can 't compose modules that
| take _seconds_ to act, and still have something that is usable
| real-time.
| maxmcd wrote:
| Fly runs the contents of the container in a VM. Bring your own
| runtime in that VM, use kernel sandboxing features, do whatever
| you want (in linux).
|
| I'm all for the "k8s is not erlang" position, but in fly's case
| it seems like the right tool for the job. Fly is much faster
| than a new EC2 instance.
| n3mes1s wrote:
| More info about this in the blogpost Docker without Docker[0]
|
| [0] https://fly.io/blog/docker-without-docker/
| tptacek wrote:
| You're remarking on a development time number. Like, the amount
| of time it'll take to create your account.
| simonw wrote:
| I can see how someone would misunderstand that claim though:
| the idea of getting up and running on a new hosting provider
| that quickly seems so unlikely that thinking "well they must
| be talking about container launch times here instead" is an
| understandable mistake.
| vhodges wrote:
| fwiw, I moved my prod env from a VPS (at linode) to fly.io
| twice in one week. Once to try it out and get a feel for
| what I was getting into and the second time for real. Took
| about 90 minutes each (plus some thinking time and doc
| reading). It's a small app without a ton of data to move
| nor a lot of traffic at this point, so take my experience
| with a grain of salt.
| tptacek wrote:
| Oh, you're right; I'm just clarifying. The perils of trying
| to fit your whole project into a tiny lead paragraph. :)
| lsb wrote:
| "Create your first project in minutes. Create your next
| project in under 25 seconds."
| throwaway894345 wrote:
| Container launch times are frequently in minutes if we
| include pulling the images from a repo, which we reasonably
| should.
|
| In whichever case, that doesn't mean we can't compose them
| into a performant product as the OP suggests, it just means
| you run them as daemons so you can amortize the startup
| cost across many invocations. This isn't specific to
| containers--we do the same thing for web servers,
| databases, virtual machines, _physical machines_ etc.
| Anything with a startup cost that you don 't want to pay
| each time.
| Sytten wrote:
| They mentionned that they decided against thanos for the storage
| of metrics, but would be curious to hear if other TSDB were
| considered. It is a hot space, I know about M3BD, Clickhouse,
| Timescale, influx, QuestDB, opentsdb, etc.
___________________________________________________________________
(page generated 2021-05-13 23:00 UTC)