yann_eu

Great to hear it! Let us know how it goes :)

There are similarities, one key difference is that we're running on top of high-performance BareMetal servers with high-end CPUs.

For now, the vcpus are shared for all types of MicroVMs with a constant ratio for each GB of RAM.

We're planning to release instance types with dedicated CPUs for applications that need them.

The starter plan is actually a pay-per-use plan, so you're starting at $0 and spending depending on your usage. You don't need to move directly to $79. Does that make sense?

It seems we need to do some work on the pricing page.

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.

Thanks! Hope you’ll like it :)

We have similarities with fly.io (Firecracker MicroVMs on top of BareMetal) and also some key differences:

- we directly integrate with GitHub to automatically build your application on push. We support building native code with Builpacks or from Dockerfile in addition to pre-built containers.

- we put a CDN in front of all your services to provide caching and edge TLS termination

- technically, our internal network is a service mesh built with Kuma and Envoy

- overall, we aim to be a bit higher in the stack, instead of looking at providing low-level virtual machines, we want to focus on productivity features like preview environments

We actually thought zero infrastructure configuration. At this stage, there is some basic setup to do for a multi-service app. You need to configure the HTTP routes. We aim to add as much automatic discovery of the codebase as possible.

Thanks for the feedback on the pricing. $0 is actually the price of the plan and we provide $5.5 of free credit in the plan. It seems the “Up to” was somehow skipped in the “16GB & 16 vCPU per service”, this is indeed confusing.

We focused on estimating the minimum/entry-level cost of Kubernetes here.

If you have a data intensive service, it surely would add up, but it's not specific to Kubernetes. If you go with VMs or a Serverless deployment, you'll have to pay it too.

If you're speaking about the storage and data transfers related to the Kubernetes control plane itself, I don't believe it represents a significant cost, even with a large cluster.

You're right, having only one person on call for a managed cluster doesn't make a lot of sense. We should probably have planned with at least 2 people for a managed cluster too to cover 24/7/365 operations.

I think our thought process here is that developers are also involved in on call support for the service availability and the k8s cluster availability is mostly managed by the provider, but the cluster can still fail even if the control plane is managed.

Hi!

Yann, co-founder at Koyeb, here.

Yes, we considered Consul as a service mesh but found that it was too strongly coupled with the network and task layer of Nomad. We were looking for something highly customizable which wouldn't get into the way.

Also, the multi-tenancy features are paid features, which might have been difficult to sustain economically for us.