31–40 of 57 posts
"Microservices perform better, especially when written in Go." Nonsense.
Sort of agree, that's a very noisy and broad statement. I'd argue that the underlying I/O and event loop implementation matters more. At the end of the day it's all about highly available systems. Am I wrong?
Am I missing something, or does this really have no support for TOTP/HOTP? An authentication system without 2FA or U2F support in 2017 seems... lacking (or unfinished).
"Microservices perform better, especially when written in Go." Nonsense.
Sort of agree, that's a very noisy and broad statement. I'd argue that the underlying I/O and event loop implementation matters more. At the end of the day it's all about highly available systems. Am I wrong?
Here are a few references that leap to mind (I keep the first printed out and pinned right next to my monitor).
https://gist.github.com/jboner/2841832
https://www.quora.com/What-are-some-mind-blowing-facts-about...
"Microservices perform better, especially when written in Go." Nonsense.
Sort of agree, that's a very noisy and broad statement. I'd argue that the underlying I/O and event loop implementation matters more. At the end of the day it's all about highly available systems. Am I wrong?
One point of context I'd like to inject here is that chatter between AuthN and a host app is pretty minimal. Aside from executing admin actions like locking an account, the main dependency is fetching a public key to verify JWTs. This public key can be cached using a standard key fingerprint, which means it only needs to happen once per process.
Architecture does matter, and I've been pretty happy with how AuthN's boundary has played out.
This looks pretty reasonable! I would love to see a Cloud Storage backend. A minor quibble is that I think that managing your own metrics in Redis is probably not the simplest or most flexible approach - instead, you should consider exposing a /metrics endpoint that can be ingested by the user's monitoring tool of choice (Prometheus/InfluxDB/etc).
Have you seen the /stats endpoint? It exposes the metrics as JSON, which may be a good match for your suggestion. I'd also like to export the key events to a STATSD-compatible sink so a sophisticated user can manage metrics in their own system.
Redis is already on hand because of other features though, and HLL is a pretty cheap integration. I figure it's a decent starting point for many people.
Earlier quoted context omitted.
Sort of agree, that's a very noisy and broad statement. I'd argue that the underlying I/O and event loop implementation matters more. At the end of the day it's all about highly available systems. Am I wrong?
Microservices need to be divided up very carefully, with full knowledge of the latency trade-off of moving functionality across a network gap. A same-datacenter round-trip takes 5,000 times longer than a main memory access, and 1,000,000 times longer than an L1 cache access. There's no silver bullet in performance or scalability. Each solution will require trading off advantages that matter less to achieve business g…
This looks pretty reasonable! I would love to see a Cloud Storage backend. A minor quibble is that I think that managing your own metrics in Redis is probably not the simplest or most flexible approach - instead, you should consider exposing a /metrics endpoint that can be ingested by the user's monitoring tool of choice (Prometheus/InfluxDB/etc).
Thanks! Have you seen the /stats endpoint? It exposes the metrics as JSON, which may be a good match for your suggestion. I'd also like to export the key events to a STATSD-compatible sink so a sophisticated user can manage metrics in their own system. Redis is already on hand because of other features though, and HLL is a pretty cheap integration. I figure it's a decent starting point for many people.
Being tied to Redis is also not great. For instance, it looks like everything apart from the metrics could comfortably live in Google Cloud Storage if you had a backend for it. Cloud Storage really isn't an appropriate place to put frequently updated counters, though. So if I deployed AuthN, I would want to be able to ditch Redis.
I should stress, though, that these are quibbles. I think AuthN looks very nice, and the quibbles are cropping up because I'm trying to figure out if I can use it. :)
/keratin/authn-server/docs/config.md
which is a 404 presumably instead of
/keratin/authn-server/blob/master/docs/config.md
Earlier quoted context omitted.
Thanks! Have you seen the /stats endpoint? It exposes the metrics as JSON, which may be a good match for your suggestion. I'd also like to export the key events to a STATSD-compatible sink so a sophisticated user can manage metrics in their own system. Redis is already on hand because of other features though, and HLL is a pretty cheap integration. I figure it's a decent starting point for many people.
It looks like the /stats endpoint consults the Redis database and returns processed data. If we're aggregating metrics externally, it would be more idiomatic for this to be totally stateless and just expose hot metrics - it's the aggregator's job to store and process the data. This can be quite painless using something like the Go Prometheus library. Being tied to Redis is also not great. For instance, it looks like…
* Google Cloud Storage implementations for data interfaces
* Metrics interface with a Prometheus implementation (STATSD to follow)
* Redis-backed HLL metrics are optional
Feel free to open issues in the tracker if you reach that point!