What's wrong with edge functions and how do run code as close as possible to your users?

The idea of running code in a data center located as close as possible to the user sounds not bad. If we add there Anycast DNS (when a request to resolve a domain to the IP address of a server is handled by a nearest to the user DNS server) and geo-based load balancers, we can reduce latency for requests to 20-50ms for most users around the world. But this is on paper only. In this post, I'll show you why edge functions don't work well in many cases and how we at LocalCloud plan to solve that.

Let's start with a few details about how edge functions work:

• You upload code with your functions to a cloud provider that has edge functions
• The cloud provider clones your code to servers in different data centers
• When a new request is received by the cloud provider's DNS or load balancers (depending on the cloud provider), your domain is resolved to the IP address nearest to the user data center with your code, and a request is forwarded to a server located at that data center with your code
• Your code is executed and a response is sent to the user

Agree, that it looks very simple but there is one big issue. Edge functions are stateless and you cannot store any data between calls. To store data you need an external database. Let's assume, that you have a database in Frankfurt and this means that an edge function from any region will send a request to Frankfurt from all locations to get/save data. Even if your function makes one call to a database, the latency will be around the same as if you just use one cloud server in the same data center where you have a database. If your function makes a few calls to DB, you'll get even bigger latency than when you run your code only in Frankfurt - the same data center where your DB is located. You can tell - well, let's use a distributed database. That could be an option but even projects funded by millions of dollars cannot afford to keep managed databases in, let's say, 20 or even 10 data centers. What does it mean? It means that it doesn't matter how many locations your edge function will be replicated because only locations with your data matter. You can tell that there are a few providers with edge functions and distributed databases - yes, they are but in this case you are locked in by a vendor and you're very limited in what you can use for your project. The main problem with such limits is that you should follow ideas of proprietary frameworks that will add complexity to your project. A simple example, you develop something and suddenly you find that you need real-time updates over WebSockets but a cloud provider where you host your edge functions doesn't provide that and you can rewrite most of the code, migrate data, etc. or you find, that you need to run long-time processing like media file processing and again, edge functions have limits that don't allow you to develop forward your project and adds complexity. All this means that edge functions not only limit you on what frameworks and runtimes to use but also take your time studying those proprietary frameworks and make it tricky to migrate when you find that you cannot use edge functions anymore.

How do we solve all those problems with edge functions?

The solution is simple - don't limit users to what they can run on edge machines, and keep code and data in the same data center to have only 5-10 ms latency for DB requests. Like when you want to deploy an open-source project (for example, Ghost CMS) with Docker, everything will be deployed on one cloud or bare metal server. Then we should deploy containers and databases in 10+ data centers across the globe, connect all servers by cloud-agnostic Virtual Private Network to encrypt and save traffic between servers from different data centers and different cloud providers, and distribute requests between different locations based on a user location on the DNS level. It's how ideal edge containers should work and what we plan to implement at LocalCloud this year. The great news is that you already can create distributed infrastructure with LocalCloud with the community edition or managed cloud version. LocalCloud doesn't use heavy Kubernetes under the hood and it's very lightweight that's why resource usage by the LocalCloud agent is very very small (less than 100MB of RAM and near zero CPU). The only thing that is still missing to start calling LocalCloud  "an edge container provider" is distributing requests on the DNS level that we have on our summer roadmap. And the best thing for you will be fixed costs without any pay for usage, and you will never get unpredictable bills.

Main ideas behind LocalCloud edge containers?

• Edge containers are just standard Docker containers while edge functions can be used with very limited frameworks. You shouldn't use any special frameworks and adopt your code like with edge functions and serverless. If you don't want to use containers you can deploy without any containers as usually we do on local machines - run services and databases on different ports without containers (in this case "edge containers" will be "edge servers" that are almost the same but with another name). You decide how to deploy
• You select where your code should be located. For example, you have many users in the EU and USA but around zero users in Asia. Of course, there is no need to deploy your code to Asia, waste resources, and pay for servers with near-zero load
• We balance traffic on the DNS level which helps to save huge amounts of resources by not using traditional load balancers which should handle all traffic before forwarding it to servers
• Cost-effective - you pay for servers like with VPS or bare metal servers. For example, if you deploy your service to 2 locations (for example, for users from the EU and the USA) to servers with 2vCPU and 8GB memory, you will pay for those 2 servers only - currently, it will be 18 EUR/month. Depending on your app/service, you'll be able to handle up to a few thousand active users with those 2 servers
• Zero vendor lock-in. Yes, no vendor lock-in is our main idea for all our services. You can migrate to the community edition or even stop using LocalCloud at any time and still keep the whole infrastructure working.
• Usage should be as simple as possible without overengineering
• Cloud agnostic - you can run edge containers on cloud servers by any cloud provider including LocalCloud servers, old laptops, and even single-board computers

The beta version of LocalCloud Edge Containers (Edge Servers if you don't want to use containers) will be available this summer, follow us and subscribe to our newsletter to be notified when we start the beta. As usual, we're waiting for your feedback and ideas at hey@localcloud.sh