I'm hoping that this is the start of a trend away from the overly complex, overly engineered, big ball of mud that is Kubernetes towards simpler and easier deployment/hosting/container runtimes that are easier for smaller and large teams alike to manage.<p>Don't get me started on how "devops" has become a meme. I want to deploy services and features. I wouldn't want to spend my full time dealing with Kubernetes and containers and all manner of complexity.<p>I think cloud providers have much better models generally (e.g. Azure App Service). Setup pipeline, deploy, done. Containers are an optional thing.<p>What I'm saying is, I don't think it's fair on anyone that essentially the only choices are 1) run servers and VM's yourself and manage deploying to them 2) kubernetes 3) cloud providers.<p>There needs to be an option between them.
Nice post, thanks for sharing it.<p>From personal experience I can only agree with their choice to pick Nomad. At the place where I work we have been running Nomad as our main container orchestrator for around 2.5 years now. It's rock solid, very easy to set-up and maintain and overall not too complex to understand in depth.
> Global and multi-zone deployments: User workloads on Koyeb need to be able to run in multiple zones. Kubernetes doesn't support multi-zone out of the box. Implementing multi-zone with Kubernetes requires deploying a full cluster per zone, with a dedicated control plane for each data center.<p>I’m having trouble understanding this. K8s worker nodes should be deployable across zones, regions etc. You can label the nodes with the zone id and use taints/tolerations to ensure workloads are deployed in specific zones/regions (if that’s what you want).
Seems similar to fly.io, but fly.io seems better: uses WireGuard instead of service mesh, supports custom domains, supports any TCP or UDP service, provides volumes, etc. But that’s great seeing more options in that market!
Great post and a great tech stack.<p>As far as I know Fly.io also went the same path of using the Nomad stack and tools.<p>We did something similar at appfleet.com and also decided against Kubernetes. We opted to write a lightweight manager of Firecracker VMs.
I’m waiting the day someone discovers a simpler alternative to k8s. It will be like that day in which we realized that http verbs >>> Corba/rmi for web services.
I'm curious - when a user deploys their new code to your product, does that kick off a new Nomad job, or is that managed internally, kicking off a koyeb-managed Firecracker with Kuma for service discovery?
(Off topic)<p>I maintain this small repo [1] and I have added our thread today to the section (#infrastructure). It's to learn "What/Why people move from this to that."<p>It's not an _awesome_-like repo but I've found it's useful to learn others' decisions. Feel free to keep them up-to-date (but if you know there is better place / resource, I'm happy to work with them too.) Thanks a lot.<p>[1] <a href="https://github.com/icy/w2w" rel="nofollow">https://github.com/icy/w2w</a>
Thanks for sharing! That's currently an uncommon change but I must admit you explained it well.<p>Quick question for the team: did you consider or try Consul as a service mesh ?