[ $davids.sh ] — david shekunts blog

😡 Haven't figured out what Serverless is, and then Edge Functions come along

# [ $davids.sh ] · message #159

😡 Haven't figured out what Serverless is, and then Edge Functions come along

I've been wanting to write about the differences between self-hosted, serverless containers, serverless functions, and now Edge Functions have arrived, so it's time:

  • Self-hosted – you rent servers, deploy docker-compose / nomad / kubernetes, and have fun as you can

  • Serverless containers – you create a Docker image, deploy it to a platform, and it runs, scales, and so on.

Yandex Serveless Containers, Google Cloud Run, AWS Faragate By the way, my favorite way when there's no DevOps.

  • Serverless functions – you create an application with 1 entry point (90% of the time it's an HTTP request) and write almost anything in the request processing.

AWS Lambda, Google Cloud Functions, Netlify Functions

Features: (1) each request creates a "mini virtual machine" (which takes time, called "cold start"), where your code is launched, and then, if there's no traffic, it shuts down, (2) you bind their launch to a specific region, (3) memory, execution time, and native API hardware limitations.

  • Edge functions – same as serverless functions, BUT instead of a mini virtual machine, your code runs (conditionally) within an already running application (like using eval).

Features: (1) almost no startup time, (2) currently limited to making HTTP requests (+ WS) on JS, (3) more like a CDN, so it CAN run on the nearest available server to the client.

Vercel Edge Functions, Netlify Edge Functions I'll break it down in more detail in the next posts, but I'll say right away: I wrote "CAN" in capital letters because the main speed problem for most applications is the speed of requests to a non-distributed database, so Edge Functions currently have a significant advantage over Serverless Functions when you specify their launch region near your database, not near clients.

I've just started playing with Edge Functions, but I have some experience with the other types, so I'll continue to share info and some interesting thoughts.

Teaser: all options are crap in one context or another, there's no "optimal" solution, and it all depends incredibly strongly on the context. The only universal advice is: "at least learn to do self-hosted" – and everything else will be strong optimizations on top of that, depending on the context.

If you have more specific questions, write them in the comments to this post

Everyone, powerful pumping 💪

  • @ Ivan ITK 🚫 · # 308

    Cloudflare Workers also learned to support node.js

    All serverless and edge platforms share one issue not highlighted in the post—limitations on execution time, allocated resources, and, depending on the platform, triggers.

  • @ [ $davids.sh ] · # 309

    Well, why didn't you highlight: "(3) limitations on memory, execution time, and native hardware APIs."

    But I didn't understand the part about "triggers."

  • @ Ivan ITK 🚫 · # 310

    "Sorry, I skimmed through the text—careless reader)
    Triggers for calling functions are mostly webhooks as a universal solution. But for example, in AWS Lambda, you can also use SQS or MSK, and there's even an option for an external Kafka consumer, which allows for more interesting implementations without vendor lock-in."

  • @ Ivan ITK 🚫 · # 321

  • @ [ $davids.sh ] · # 323

    Haha, I was just planning to write about this topic!)

    As I understood, the guys ended up creating a bunch of microservices and lambdas to solve a simple problem and were surprised why they had network latency issues.)

    So they rewrote it as a microservice (because only a part of the functionality was needed there)

    Well, I mean, good job, but for such cases, I use modular/distributed monoliths (I’ll probably lead the article to this point))

  • @ Ivan ITK 🚫 · # 324

    Yes, the original article raises many questions about the architecture, such as why lambda + step functions were initially chosen. Costs could have been estimated before development, frames are a measurable quantity, the number of stages is static, and the approximate video volume was also known.
    And yes, the main question in this scheme is "why"—what they were trying to scale with this approach is unclear.