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.

Agree, data location is indeed a central challenge when building globally distributed apps.

We picked the largest peering points in Europe and the US for the two first locations aka Washington / US-East and Frankfurt in Europe. For the following 4 locations which we announced last week in early access [1], we tried to pick the next best-interconnected locations on the world map: SFO / the valley, Singapore, Paris, and Tokyo.

We definitely need to do a better job in the doc [2], we can definitely provide some mapping matrix and will be working on some latency measurements/speedtest/iperf servers.

In this direction, did you look at PolyScale [3]? They do the job of database caching at Edge.

What do you have in mind regarding lower-level access to compute? We're looking at providing block storage and direct TCP/IP support if that's what you have in mind.

[1] https://community.koyeb.com/t/changelog-25-san-francisco-sin...

[2] https://www.koyeb.com/docs/reference/regions

[3] https://www.koyeb.com/docs/integrations/databases/polyscale

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.

Thanks for all the questions!

We're headquartered in Europe, you'll find the legal in our terms :) https://www.koyeb.com/docs/legal/terms

There is a difference between edge and non-edge locations (we call them core): edge locations terminate the TLS connection, do caching, and route traffic to the nearest core location. We explained how this works in this post [1] and this talk [2]. The TLDR is: If this core location is set up to run an instance of your service, it will send it to the right machine in the location. Otherwise, it's going to be routed to the core location where an instance is running.

Data storage can be tied to a location as you're deciding where you're application is running: if you ask us to run an application in Frankfurt, Germany we're not going to move it to the US nor to any other location.

The build engine is tied to GitHub but you can deploy a pre-built Docker container. GitLab has been highly demanded [3], so this is definitely on the list of things we're considering implementing.

Databases should land on the platform in September in early access [4], we're actively working on it.

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

[2] https://www.youtube.com/watch?v=IB93WCoroL8

[3] https://feedback.koyeb.com/feature-requests/p/git-driven-dep...

[4] https://feedback.koyeb.com/feature-requests/p/managed-postgr...

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.

Koyeb (https://www.koyeb.com/) | Paris/Lyon (France) | REMOTE | FULL-TIME | 3x Senior Software Engineers

Want to be part of a small team building the future of the Cloud? We’re expanding the Koyeb team and hiring 3 senior software engineers! https://www.koyeb.com/careers

Join us on our mission to provide the fastest way to deploy apps globally! We’re building our engineering team to develop and operate our distributed system orchestrating serverless workloads across clouds.

We are literally at the edge of both technology and the cloud, building a global platform with the latest technologies: golang, containers, serverless, nomad, firecracker, kubernetes, envoy, baremetal, and more.

We’re remote-friendly and have staff based in Paris and Lyon, France, check it out!

I’m really surprised that you call our bandwidth price “ludicrously high”. I might not have been clear in my previous comment, currently we’re providing 5TB/mo of free transfer and will always maintain a significant free tier for the bandwidth. We intend to maintain a forever free plan.

As far as I know, our bandwidth price is one of the lowest in the cloud/hosting market. We’re charging for bandwidth because our own providers do charge for it. We do not earn any money out of it, we’re simply covering our own hosting costs.

There is two models to charge bandwidth in the hosting/cloud market: with a limited bandwidth (e.g. 1Gb/s) and per GB. Most cloud providers are charging by GB, AWS, Azure and GCP are charging between $0.05 and $0.23, so between 5x and 23x more. DigitalOcean, Vultr and Linode charge $0.01, so the same price. European providers like OVH and Scaleway cap the bandwidth. Do you have any example of providers with a significantly lower price?

Ahah! Reminds me of what we're building at Koyeb. (https://www.koyeb.com/blog/the-koyeb-serverless-engine-docke...)

It should be as easy to deploy and deal with containers as it is to deploy serverless functions.

Disclaimer : I'm one of the co-founders of Koyeb.

I'm Yann, one of the co-founder of Koyeb. Thanks for your interest!

To give you an idea, we charge $1 per 10 hours of compute, accounted by 100ms. Each function or container has 1GB of RAM available. We also charge $0.01/GB of bandwidth.

The business plans include multi-user, longer log retention, custom S3 supports (on-premise) and advanced SLA.

I would be happy to further discuss that with you, you can contact me through the website or on slack.koyeb.com.

Hi Eric,

Yann, co-founder of Koyeb here.

You can actually deploy both: * docker containers, in this case you build your own container and we deploy/host it for you with native autoscaling. It's really useful if you have system dependencies or want to control the build process. * Python/Node functions, similar to lambda in the principle, but in this case we also take of all the build process, you simply connect your GitHub repository, we deploy and scale for you.

Don't hesitate to ask if you have other questions.

We target a release of the docker containers support by the end of the summer, could be even earlier for the early access :)

Kind of, completely managed with Docker containers support and multi-cloud storage :)

We deal with both multi-cloud processing and storage with a managed platform when the Serverless framework simply allows you to configure and deploy functions on main cloud service providers.

We allow you to build, deploy and run (i.e. we operate the infrastructure) processing workflows using ready-to-use integrations, containers, or custom functions. We also provide a multi-cloud storage layer, you can use and push data stored on multiple cloud storage providers with a simple S3 interface instead of having to deal with each object provider implementation.

We also plan to be compatible with the serverless framework for the custom functions part.

I'm Yann, one of the founders of Koyeb. Koyeb is a platform for developers and businesses to run serverless data processing apps in minutes.

We provide an easy to use platform to build production-grade workflows for all your data, including image, video, audio, or document processing.

To provide a little bit of context, we previously developed Scaleway (https://scaleway.com/), a European Cloud Service Provider, and started Koyeb initially around multi-cloud object storage (https://news.ycombinator.com/item?id=21005524) We are now going a step further: we are trying to also provide an easy way to process data and to orchestrate distributed processing from various sources.

Currently, we provide an S3 compliant API to push your data, you can implement processing workflows using ready-to-use integrations (https://www.koyeb.com/catalog) and store results on the cloud storage provider of your choice (i.e. GCP, Azure Blob, AWS S3, Vultr, DigitalOcean, Wasabi, Scaleway, or even Minio servers).

We're working on adding support for Docker containers and custom functions to let our users combine catalog integrations with their own code in workflows. We will also add support for new data sources to send, ingest, and import data from different services.

We of course take care of all the infrastructure management and scaling of the platform.

The platform is in early access phase and I'd love to hear what you think, your impressions and feedback.

Thanks a lot!

Thanks :) Pretty weird for the pricing page, thanks for the feedback!

# Is this just BLOB object storage? Yes, we're focused on blob/object storage for now. We believe there is a huge lack of simple solutions to automate data movements between cloud providers and that's the first thing we're looking to tackle.

# Do you have a maximum file size for storage? We have no limit on file size for transfers, actually the limiting factor is going to be the providers as S3 is for instance limited to 5TB. For data processing, we will have some limitations depending on wether the processing can be done by chunks or not.

# What is the bandwidth between clouds for transfer? For the bandwidth, it actually not only depends of us but also of the source and destinations Providers but we can easily scale to 10s of Gb/s.

# Do you provide DNS for CDN scenarios? What is your use case with DNS and CDN? We don't do that yet.

# If data is replicated across clouds, what is the update protocol? We deal with all S3 compliant providers at the moment and plan to support all main object storage providers.

We will fuel our documentation with your questions, thanks! If you have a use case in mind, I would be happy to further discuss it with you, I'm reachable on twitter on the same nickname. :)

Hi there! I'm Yann, Co-Founder of Koyeb, feel free to ask me anything. We're looking for feedback :)

We were basically thinking about routing /64 blocks over the /127 interconnection to provide routed /64 ;)