Tomasz Hamerla

Tomasz Hamerla

at the intersection of software & data engineering

The dangers of serverless solutions

Lessons learned from the auth0 outage

Tomasz Hamerla

2-Minute Read

auth0 outage

auth0 had terrible outage. As a result, I was kicked in the middle of learning on LinuxAcademy and could not have accessed it for almost 2 hours. As I was frustrated trying to access the platform, I was also discussing the dangers of those-so called ‘serverless solutions’ like auth0 with fellow LinuxAcademy students. I showed to them my old article about cloud and promised to write a new one with my current conclusions after gaining experience with all main platforms - AWS / Azure / GCP.

Serverless is a myth

First of all, I would like to point out that the word “serverless” is one of the biggest misunderstandings in IT. Why? Oh, well - here we go:

  • “serverless” is a “buzz word” that in my opinion doesn’t have a precise meaning - doesn’t even define the type of services we are talking about - FaaS (Function as a Service), SaaS (Software as a Service), Database as a Service (DaaS) and so on
  • “serverless” promises salvation throught “no-ops” while in reality it adds a new learning curve and a whole new strange ecosystem to follow; furthermore learning curve is longer and harder as there are not so many well-architected solutions to follow up
  • “serverless” adds a new problem - namely vendor lock-in; while it is obviously not a problem specific to “serverless” and can happen in different types of architectures, it does very often happen in “serverless” due to the nature of this architecture
  • “serverless” promises cost reduction while in reality it completely depends on the solution design; as mentioned above, it is harder to design a well-architected solution due to the “freshness” of “serverless” solutions
  • “serverless” is said to be the new religion while it is simply a new type of architecture that is immature and often hard to design properly

Solution

So how to address those problems? Here are my thoughts in bullet points:

  • treat “serverless” like any other architecture to follow up, not a new kind of religion - spend most of the time with your team considering different trade-offs that it offers
  • be careful about the costs and prepare a solid migration plan
  • implement for “serverless” high availability and fault tolerance - for example use multiple authentcation providers as a backup if the main one fails; this also increases RTO and RPO

Recent Posts

Categories