Show HN: Run globally distributed full-stack apps on high-performance MicroVMs

Hi HN! We’re Yann, Edouard, and Bastien from Koyeb (https://www.koyeb.com/). We’re building a platform to let you deploy full-stack apps on high-performance hardware around the world, with zero configuration. We provide a “global serverless feeling”, without the hassle of re-writing all your apps or managing k8s complexity [1].

We built Scaleway, a cloud service provider where we designed ARM servers and provided them as cloud servers. During our time there, we saw customers struggle with the same issues while trying to deploy full-stack applications and APIs resiliently. As it turns out, deploying applications and managing networking across a multi-data center fleet of machines (virtual or physical) requires an overwhelming amount of orchestration and configuration. At the time, that complexity meant that multi-region deployments were simply out-of-reach for most businesses.

When thinking about how we wanted to solve those problems, we tried several solutions. We briefly explored offering a FaaS experience [2], but from our first steps, user feedback made us reconsider whether it was the correct abstraction. In most cases, it seemed that functions simply added complexity and required learning how to engineer using provider-specific primitives. In many ways, developing with functions felt like abandoning all of the benefits of frameworks.

Another popular option these days is to go with Kubernetes. From an engineering perspective, Kubernetes is extremely powerful, but it also involves massive amounts of overhead. Building software, managing networking, and deploying across regions involves integrating many different components and maintaining them over time. It can be tough to justify the level of effort and investment it takes to keep it all running rather than work on building out your product.

We believe you should be able to write your apps and run them without modification with simple scaling, global distribution transparently managed by the provider, and no infrastructure or orchestration management.

Koyeb is a cloud platform where you come with a git repository or a Docker image, we build the code into a container (when needed), run the container inside of Firecracker microVMs, and deploy it to multiple regions on top of bare metal servers. There is an edge network in front to accelerate delivery and a global networking layer for inter-service communication (service mesh/discovery) [3].

We took a few steps to get the Koyeb platform to where it is today: we built our own serverless engine [4]. We use Nomad and Firecracker for orchestration, and Kuma for the networking layer. In the last year, we spawned six regions in Washington, DC, San Francisco, Singapore, Paris, Frankfurt and Tokyo, added support for native workers, gRPC, HTTP/2 [5], WebSockets, and custom health checks. We are working next on autoscaling, databases, and preview environments.

We’re super excited to show you Koyeb today and we’d love to hear your thoughts on the platform and what we are building in the comments. To make getting started easy, we provide $5.50 in free credits every month so you can run up to two services for free.

P.S. A payment method is required to access the platform to prevent abuse (we had hard months last year dealing with that). If you’d like to try the platform without adding a card, reach out at support@koyeb.com or @gokoyeb on Twitter.

[1] https://www.koyeb.com/blog/the-true-cost-of-kubernetes-peopl...

[2] https://www.koyeb.com/blog/the-koyeb-serverless-engine-docke...

[3] https://www.koyeb.com/blog/building-a-multi-region-service-m...

[4] https://www.koyeb.com/blog/the-koyeb-serverless-engine-from-...

[5] https://www.koyeb.com/blog/enabling-grpc-and-http2-support-a...

Show HN: Run globally distributed full-stack apps on high-performance MicroVMs
koyeb.com

My understanding is that Fly.io also started using Nomad but ended up running into big reliability issues at scale across many regions. I'm curious if you all are using it differently or haven't gotten to that scale yet.

Source: https://fly.io/blog/carving-the-scheduler-out-of-our-orchest...

I’d say we don’t use it exactly the same way: we don’t have a single global nomad cluster, which is a critical difference.

We have one Nomad cluster per region, which we “federated” ourselves using our own orchestrator. This basically reduces the latencies between agents and each cluster, reduces the failure domains, and also avoids encoding all the constraints in one single Nomad job definition.

I'm not so much worried about scaling with our setup but the performance of the autoscaler might be a concern in the future.

How did you get so many great company logos onto your website? Did each one have to go through a legal approval? Was a struggle for us at my old startup.