We're Leaving Kubernetes

• template-typescript-monorepo

  6 89 8.4 TypeScript

  Template repo with the latest tech working together

  > How does the orchestration work?

  Github Actions CI. Take this and make a few more dependencies and a matrix strategy and you are good to go: https://github.com/bhouston/template-typescript-monorepo/blo... For dev environments, you can add post-fixes to the services based on branches.

  > How do you share storage?

  I use managed DBs and Cloud Storage for shared storage. I think that provisioning your own SSDs/HDs to the cloud is indicative of an anti-pattern in your architecture.

  > How do the docker containers know how to find each other?

  I try to avoid too much communication between services directly, rather try to go through pub-sub or similar. But you can set up each service with a domain name and access them that way. With https://web3dsurvey.com, I have an api on https://api.web3dsurvey.com and then a review environment (connected to the main branch) with https://preview.web3dsurvey.com / https://api.preview.web3dsurvey.com.

  > How does security work?

  You can configure Cloud Run services to be internal only and not to accept outside connections. Otherwise one can just use JWT or whatever is normal on your routes in your web server.

• SaaSHub

  www.saashub.com featured

  SaaSHub - Software Alternatives and Reviews. SaaSHub helps you find the best software and product alternatives

  

• serving

  7 5,586 9.7 Go

  Kubernetes-based, scale-to-zero, request-driven compute (by knative)

  

  > You know that Cloud Run is a Kubernetes PaaS, right?

  Yup. Isn't it Knative Serving or a home grown Google alternative to it? https://knative.dev/docs/serving/

  The key is I am not managing Kubernetes and I am not paying for it - it is a fool's errand, and incredibly rarely needed. Who cares what is underneath the simple Cloud Run developer UX? What matters for me is cost, simplify and understandability. You get that with Cloud Run, and you don't with Kubernetes.

• devpod

  33 9,562 9.7 Go

  Codespaces but open-source, client-only and unopinionated: Works with any IDE and lets you use any cloud, kubernetes or just localhost docker.

  

  In my experience, the case where this becomes really valuable is if your team needs access to either different kinds of hardware or really expensive hardware that changes relatively quickly (i.e. GPUs). At a previous small startup I setup https://devpod.sh/ (similar to gitpod) for our MLE/Data team. It was a big pro to leverage our existing k8s setup w/ little configuration needed to get these developer envs up and running as-needed, and we could piggyback off of our existing cost tracking tooling to measure usage.

  The rest of our eng team just did dev on their laptops though. I do think there was a level of batteries-included-ness that came with the ephemeral dev envs which our less technical data scientists appreciated, but the rest of our developers did not. Just my 2c

• sst

  185 22,177 10.0 TypeScript

  Build full-stack apps on your own infrastructure.

  

  wow very very interesting. I think we can discuss about it on hours.

  1.) What would you think of things like hetzner / linode / digitalocean (if stable work exists)

  2.) What do you think of https://sst.dev/ or https://encore.dev/ ? (They support rather easier migration)

  3.) Could you please indicate the split of that 1 million $ in devops time and google cloud costs unnecessarily & were there some outliers (like oh our intern didn't add this specific variable and this misconfigured cloud and wasted 10k on gcloud oops! or was it , that bandwidth causes this much more in gcloud (I don't think latter to be the case though))

  Looking forward to chatting with you!

• sidekick

  4 5,973 9.0 Go

  Bare metal to production ready in mins; your own fly server on your VPS.

  yeh I have same thoughts , also if possible , bun can also reduce memory usage in very very basic scenarios https://www.youtube.com/watch?v=yJmyYosyDDM

  Or just https://github.com/mightymoud/sidekick or coolify or dokku or dockify , like there are million of such things , oh just remembered kamala deploy from DHH and docker swarm IIRC (though people have seemed to forget docker swarm !)

  I like this idea very much !

• distrobox

  405 10,178 9.4 Shell

  Use any linux distribution inside your terminal. Enable both backward and forward compatibility with software and freedom to use whatever distribution you’re more comfortable with. Mirror available at: https://gitlab.com/89luca89/distrobox

  I strongly recommend just switching the Dev environment over to Linux and taking advantage of tools like "distrobox" and "toolbx".

  https://github.com/89luca89/distrobox

  https://containertoolbx.org/

  It is sorta like Vagrant, but instead of using virtualbox virtual machines you use podman containers. This way you get to use OCI images for your "dev environment" that integrates directly into your desktop.

  https://podman.io/

  There is some challenges related to usermode networking for non-root-managed controllers and desktop integration has some additional complications. But besides that it has almost no overhead and you can have unfettered access to things like GPUs.

  Also it is usually pretty easy to convert your normal docker or kubernetes containers over to something you can run on your desktop.

  Also it is possible to use things like Kubernetes pods definitions to deploy sets of containers with podman and manage it with systemd and such things. So you can have "clouds of containers" that your dev container needs access to locally.

  If there is a corporate need for window-specific applications then running Windows VMs or doing remote applications over RDP is a possible work around.

  If everything you are targeting as a deployment is going to be Linux anything then it doesn't make a lot of sense to jump through a bunch of hoops and cause a bunch of headaches just to avoid having it as workstation OS.

• podman

  376 24,008 10.0 Go

  Podman: A tool for managing OCI containers and pods.

  

  I strongly recommend just switching the Dev environment over to Linux and taking advantage of tools like "distrobox" and "toolbx".

  https://github.com/89luca89/distrobox

  https://containertoolbx.org/

  It is sorta like Vagrant, but instead of using virtualbox virtual machines you use podman containers. This way you get to use OCI images for your "dev environment" that integrates directly into your desktop.

  https://podman.io/

  There is some challenges related to usermode networking for non-root-managed controllers and desktop integration has some additional complications. But besides that it has almost no overhead and you can have unfettered access to things like GPUs.

  Also it is usually pretty easy to convert your normal docker or kubernetes containers over to something you can run on your desktop.

  Also it is possible to use things like Kubernetes pods definitions to deploy sets of containers with podman and manage it with systemd and such things. So you can have "clouds of containers" that your dev container needs access to locally.

  If there is a corporate need for window-specific applications then running Windows VMs or doing remote applications over RDP is a possible work around.

  If everything you are targeting as a deployment is going to be Linux anything then it doesn't make a lot of sense to jump through a bunch of hoops and cause a bunch of headaches just to avoid having it as workstation OS.

• toolbox

  110 2,601 9.4 Shell

  Tool for interactive command line environments on Linux (by containers)

  

  I strongly recommend just switching the Dev environment over to Linux and taking advantage of tools like "distrobox" and "toolbx".

  https://github.com/89luca89/distrobox

  https://containertoolbx.org/

  It is sorta like Vagrant, but instead of using virtualbox virtual machines you use podman containers. This way you get to use OCI images for your "dev environment" that integrates directly into your desktop.

  https://podman.io/

  There is some challenges related to usermode networking for non-root-managed controllers and desktop integration has some additional complications. But besides that it has almost no overhead and you can have unfettered access to things like GPUs.

  Also it is usually pretty easy to convert your normal docker or kubernetes containers over to something you can run on your desktop.

  Also it is possible to use things like Kubernetes pods definitions to deploy sets of containers with podman and manage it with systemd and such things. So you can have "clouds of containers" that your dev container needs access to locally.

  If there is a corporate need for window-specific applications then running Windows VMs or doing remote applications over RDP is a possible work around.

  If everything you are targeting as a deployment is going to be Linux anything then it doesn't make a lot of sense to jump through a bunch of hoops and cause a bunch of headaches just to avoid having it as workstation OS.

• direnv

  169 12,649 8.0 Go

  unclutter your .profile

  

  We've been using Nix flakes and direnv (https://direnv.net/) for developer environments and NixOS with https://github.com/serokell/deploy-rs for prod/deploys - takes serious digging and time to set up, but excellent experience with it so far.

• deploy-rs

  18 1,421 5.5 Rust

  A simple multi-profile Nix-flake deploy tool.

  

  We've been using Nix flakes and direnv (https://direnv.net/) for developer environments and NixOS with https://github.com/serokell/deploy-rs for prod/deploys - takes serious digging and time to set up, but excellent experience with it so far.

• dstack

  21 1,595 9.9 Python

  dstack is a lightweight, open-source alternative to Kubernetes & Slurm, simplifying AI container orchestration with multi-cloud & on-prem support. It natively supports NVIDIA, AMD, & TPU.

  

  I can completely relate to anyone abandoning K8s. I'm working with dstack, an open-source alternative to K8s for AI infra [1]. We talk to many people who are frustrated with K8s, especially for GPU and AI workloads.

  [1] https://github.com/dstackai/dstack

• cri-dockerd

  12 1,131 6.5 Go

  dockerd as a compliant Container Runtime Interface for Kubernetes

  

• microvm.nix

  9 1,443 9.2 Nix

  NixOS MicroVMs

• incus-compose

  2 48 8.6 Go

  the missing equivalent for `docker-compose` in the Incus ecosystem

  I too am rallying quickly to the Incus way of doing things. Also of note, there's an effort to build a utility to write Compose manifests for Incus workloads that I'm following very closely. https://github.com/bketelsen/incus-compose

Suggest a related project