Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

The point that often these services advertise on basis of resiliency is a fair one and I agree with what I think I'm reading into your conclusion which, if correctly understood, is that by increasing the number of dependencies in our systems we're exposing ourself to a compounding amount of downtime. And I'd assume we'd agree that generally we should architect towards fewer points of failure?

My reaction was more against the performative "haha, foolish n00b developers didn't build their system to use both Lambdas and Google Cloud and then failover to a data center on the North Pole like me, the superior genius that I am" that oftentimes appears in threads about downtime.

We could all do with a bit more "there but for the grace of god" attitude during these incidents while still learning lessons from them.



> And I'd assume we'd agree that generally we should architect towards fewer points of failure?

Yes, and to me that generally means having less points in total. We can make stuff pretty resilient but it's very hard and requires huge resources, so it's usually easier and simpler to just not have as many points at all instead of trying to add "more resilient" points in the form of SaaS.

In this case, a lot of apps are useless if the auth is down, and the auth is useless if the app is down so moving auth to something more resilient (if we assume this was an isolated incident and auth0 is generally good) only adds a point of failure and does not gain anything in terms of uptime. Especially since in more traditional setups the auth is usually hosted on the same server, on the same database and within the same framework as the app itself.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: