Great to hear it! Let us know how it goes :)
68 karma · joined March 13, 2019
Spent the last 10 years building cloud service providers in the infrastructure space from scratch.
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
We're planning to release instance types with dedicated CPUs for applications that need them.
It seems we need to do some work on the pricing page.
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...
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.
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.
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.
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.
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.
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!
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?
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.
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.
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 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.
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!
# 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. :)
First of all, thanks a lot for your feedbacks, we greatly appreciate you taking time to provide details about your experience with our platform!
I would make sure to understand the problems you are describing as most of the issue you faced seems to be related to our first generation of platforms.
I will try to provide a factual update of the situation: 1 - Are you speaking of SMTP? We have suffered a lot from fraudster in the past (~2017) but we have now more strict process toward SMTP opening and a complete team dedicated to fighting abuse. 2 - That's totally true for all generations prior to the General Purpose range. We do not guarantee local data and our users are responsible of doing backups. The new General Purpose Range is backed by replicated local storage but this doesn’t mean we can 100% guarantee the storage as simultaneous SSD failure do happen. We now have a backup feature and support hot snapshots, which means backup can be performed with no downtime. 3 - The answer you’ve got to your issue is inappropriate and abnormal as we provide refund toward outages and a power failure is of course an outage. I would like to further investigate if you can share more information in private. 4 - I’m not sure to follow you here. If you archive your server, we will indeed save your server to long term storage. You are only billed for the storage when your server is archived, not for the machine itself. A new server starts in about a minute but servers with large volumes might indeed take longer as we do copy your data locally on the hypervisor to reduce 5 - Our C1 and C2 BareMetal server indeed have a network served kernel. On all new server range, including our START, GPU and General Purpose instances, the kernel is locally installed and is the distribution provided kernel. 6 - There is no firewall NAT but a stateless NAT system which lets us transparently migrate IPs between servers in one API call. We have no offer providing less than 100Mbit/s with one of the largest network backbone capacity in Europe. Our network map is available online (http://netmap.scaleway.com/), we have an open peering policy and over 5Tb/s of network capacity. If you have specific destination with bandwidth issue, I would be happy to let our network team investigate as I’m pretty sure we have no internal congestion.
Source : I'm managing the Compute Scaleway business since 2014, so I'm aware of the issue we faced in the past and which one are now resolved.
I’m available on twitter (@yann_eu) if you’re available to discuss the issue you faced as I truly believe our last platform generations solve the issue you encountered.