HN is almost perfect as it is. I really hope it does not change.
I love that it barely has any styling. Just enough to make it work. The fact that it doesn't use any design patterns is actually one of the reasons I visit HN.
The only thing I would change is the font sizes on mobile. I find it hard to tap the `Comments` link or the upvote buttons. I sometimes end up fat fingering those. Maybe a little bigger or a bit more padding?
I love that this is funded by the French&German government. Go Europe! Wonderful to see. My only wish is that other EU governments (my own included) would invest even more into projects like this.
In retrospect, I should've been more aggressive and risk taking with life decisions in my early teens and early twenties. Now with two small kids and a mortgage, I no longer have the flexibility to take massive risks.
All the risky moves that I made so far in life ended up being ok. Stressful, terrifying, but I always came out ok somehow.
Couple of examples:
- Moved to a lesser developed country at 19 to be with a girl.
- Bought two homes at the same time, was broke for a while.
- Moved back to my home country & bought a house in a crazy market.
Everyone here arguing that most people have no practical use for higher speeds at home have never experienced 1 GBit up+down. Once you have it, you'll never settle for less.
I have 1 GBit up+down at home, I cabled the whole house with CAT7 cables and set up the best access points money can buy for mobile devices. Everything else is wired. It's an amazing experience and internet everywhere sucks compared to home.
When I lived in Romania this costed me €10, now that I am back in the Netherlands it's a bit more pricey at €52, but it's 100% worth it.
I think that people also say that they have no practical use for it because they don't have access to it, so they don't realize all the practical uses. For instance, I've worked with a lot of engineering companies that collect a lot of lidar data. Having reasonable speeds (1Gbps up/down) would have a huge impact on how and where we can transmit and process the data.
I did the same, hoping that someday I will finally get FTTH.
Currently still on the only real option here which is Comcast 1G/20M. Sometimes LTE has better upload speed (but not latency, obviously).
Netherlands. Almost every major super market chain uses them and dynamically adjusts the prices. Here's an article from 2019 about a major chain intending to change all the price tags that year (Dutch): https://www.emerce.nl/nieuws/albert-heijn-digitaliseert-prij...
If there's anyone reading this that is planning on deploying Keycloak in a high availability environment, I would highly recommend that you persist all sessions in the database as offline sessions.
At work, I ran 9 Keycloak clusters in production, handling tens of millions of sessions where the cost of losing sessions was high. The amount of time we wasted on getting it to work reliably with its default configuration of storing the sessions in its distributed, in-memory cache (Infinispan) is insane. It just isn't designed to handle such a work load reliably. Unless you're willing to spent months tuning it for every possible scenario, you WILL lose sessions.
If you are in this situation, shoot me an email. I have been through this pain and it took a lot of painstaking work to get to a highly reliable set up at scale.
Hi,
You might want to take a look at the new storage in keycloak[1].
Newer keycloak versions (19 and up) have a configurable storage for the auth sessions (see storage-area-auth-session and storage-area-user-session). I haven't checked them but the documentation is promising.
For older session (last time I checked keycloak 15) you might want to use offline sessions but they don't allow SSO after the auth session was evicted from infinispan.
We were wondering about Redis in a similar IAM use-case (PingFederate) but it wasn't officially supported, so we decided to just go with persistent Postgres. I wonder if we saved ourselves a bunch of heartache.
We often experienced cascading failure, especially during rolling restarts. A node would start shutting down and Infinispan would start to try to rebalance. Due to the large volume of sessions, other nodes would start to become unresponsive and stop replying. Eventually, you'd end up in a situation where it would give give up trying to shut the node down cleanly and just kill itself. That wouldn't be a big deal if you weren't doing a rolling restart. When the first node doesn't shut down cleanly, the data should be "safe" since it is replicated to at least N owners. In practice, the other nodes also get restarted, also shut down uncleanly and sessions are lost. Secondly, as the cluster became unresponsive, requests to refresh sessions would start to time out, which would also cause those sessions to be "lost" since they would eventually hit the maximum idle time.
As long as we wouldn't do any restarts, it would sort of work. Problems would pop up when due to high load, one or more nodes would become unresponsive and liveness probes would restart nodes. That would often cause the kind of cascading failure described above.
Most of these problems are also the result of running it in Kubernetes. We very quickly learned to remove the liveness probes and to massively increase the grace period. This helped, but only so much. We still had rather frequent failures similar to the one I just described.
Maybe if we wouldn't have run it in Kubernetes and we would be more knowledgeable about Infinispan, we could've gotten a stable set up. For us, as a small team without that specialized knowledge, we struggled to get a stable set up.
Ah, the infinite fun of managing distrubuted systems, I've seen similar failure modes in pretty much anything distributed. While in one node systems the spike of traffic just causes it to sorta work slow, cascading failures caused by latency plague most of the distributed ones.
Whether it's process management or just say node having too little memory and spinning in GC too much.
Mixing app and DB (which is I guess happening here) also can be fun, as now app being overloaded can cause DB being overloaded. You'd probably be just fine if infinispan was used as a remote database instead of embedded one.
This article gets pretty close, but it misses a very critical piece. If you're running Keycloak 16 or older, you'll explicitly want to enable lazy offline session loading [0]. Otherwise, Keycloak will attempt to load ALL offline sessions in memory during startup.
Keycloak 17 made offline sessions lazily loaded by default.
It's all fiber. You can't really get non-fiber around here. It's blazing fast and pretty stable. There are no real restrictions. They have a fair use policy, but I never heard of anyone being slapped on the wrist for using too much.
I'll probably drive it into the ground because I drive like a maniac. A new car is wasted on me.
Con: I pay my ass of in taxes because its a diesel. Pro: I imported it for free.