Live data from Hacker News

Uncloud - Tool for deploying containerised apps across servers without k8s

uncloud.run

91–100 of 189 posts

Re: Uncloud - Tool for deploying containerised apps across servers without k8s

#91

Hey, creator here. Thanks for sharing this! Uncloud[0] is a container orchestrator without a control plane. Think multi-machine Docker Compose with automatic WireGuard mesh, service discovery, and HTTPS via Caddy. Each machine just keeps a p2p-synced copy of cluster state (using Fly.io's Corrosion), so there's no quorum to maintain. I’m building Uncloud after years of managing Kubernetes in small envs and at a unicor…

> - uses the familiar Docker Compose spec, no new DSL to learn

But this goes with assumption that one already know docker compose spec. For exact same reason I'm in love for `podman kube play` to just use k8s manifests to quickly test run on local machine - and not bother with some "legacy" compose.

(I never liked Docker Inc. so I never learned THEIR tooling, it's not needed to build/run containers)

Re: Uncloud - Tool for deploying containerised apps across servers without k8s

#93

Hey, creator here. Thanks for sharing this! Uncloud[0] is a container orchestrator without a control plane. Think multi-machine Docker Compose with automatic WireGuard mesh, service discovery, and HTTPS via Caddy. Each machine just keeps a p2p-synced copy of cluster state (using Fly.io's Corrosion), so there's no quorum to maintain. I’m building Uncloud after years of managing Kubernetes in small envs and at a unicor…

> - uses the familiar Docker Compose spec, no new DSL to learn But this goes with assumption that one already know docker compose spec. For exact same reason I'm in love for `podman kube play` to just use k8s manifests to quickly test run on local machine - and not bother with some "legacy" compose. (I never liked Docker Inc. so I never learned THEIR tooling, it's not needed to build/run containers)

podman-compose works fine. It’s a very simple format.

Re: Uncloud - Tool for deploying containerised apps across servers without k8s

#95
really need to disclose the status of this application. It's ridiculous to pipe curl | bash in the actual code.

Gonna burn bridges with this lack of transparency. I love the intent but the implementation is so bad that I probably wont look back.

Re: Uncloud - Tool for deploying containerised apps across servers without k8s

#96

Very cool, so sort of like Dokku but simpler/easier to use? Looks like the docs assume the management of a single cluster. What if you want to manage multiple/distinct clusters from the same uc client/management env?

> What if you want to manage multiple/distinct clusters

Uncloud supports having multiple contexts (think - clusters) in the same configuration file, or you can also use separate config files (via --uncloud-config attribute).

https://uncloud.run/docs/cli-reference/uc_ctx

Re: Uncloud - Tool for deploying containerised apps across servers without k8s

#97

I know just enough about Kubernetes to not sound like an idiot when I’m in the room and mostly I deploy Docker containers to various managed services on AWS - Lambda, ECS, etc. But, as a lead for implementations, I just couldn’t in good conscience permit something that is not an industry standard and not supported by my cloud provider. First from a self interested standpoint, it looks a lot better on their resume to…

Fair points on the career and onboarding angle. It’s hard to argue against "everyone knows it". But with that mentality, we'd never challenge anything. COBOL was the industry standard once. So were bare metal servers or fat VMs without containers. Someone had to say "this is more painful than it needs to be and I want to try something different because I can".

I know how to use k8s but I really don't enjoy it. It feels so distasteful to me that it triggered me to make an attempt at designing a nicer experience, because why not. I remember how much fun I had trying Docker when it first came out. That inspires me to at least try. It doesn't seem like the k8s community is even trying unfortunately.

Re: Uncloud - Tool for deploying containerised apps across servers without k8s

#98

I know just enough about Kubernetes to not sound like an idiot when I’m in the room and mostly I deploy Docker containers to various managed services on AWS - Lambda, ECS, etc. But, as a lead for implementations, I just couldn’t in good conscience permit something that is not an industry standard and not supported by my cloud provider. First from a self interested standpoint, it looks a lot better on their resume to…

Fair points on the career and onboarding angle. It’s hard to argue against "everyone knows it". But with that mentality, we'd never challenge anything. COBOL was the industry standard once. So were bare metal servers or fat VMs without containers. Someone had to say "this is more painful than it needs to be and I want to try something different because I can". I know how to use k8s but I really don't enjoy it. It fee…

The enterprise equivalent of COBOL today is Java and to a much lesser extent C#. Those were both championed by large corporations - Sun and Microsoft.

The move to VMs at first and then to the cloud were also marketed by existing companies with huge budgets where people who made decisions had the “No one ever got fired for choosing $LargeWellknownCompany that is in the upper right corner of Gartner’s Magic Square”.

I love Docker. I think everyone going to EKS before they need to is dumb. There are dozens of services out there that let you give it a Docker container and just run it.

And I think that spending energy avoiding “cloud lock-in” is dumb. Choose your infrastructure and build. Migrations are going to be a pain at any decent scale anyway and you are optimizing for the wrong thing if you are worried about lock in.

As an individual especially in today’s market, it’s foolish (not referring to you - any developer or adjacent) not to always be thinking of what keeps you the most employable if the rug gets pulled from under you.

As a decision maker who is held accountable for architecture and when things go wrong they look at or when the next person has to come along to maintain it, they are going to look at me like I am crazy if I choose a non industry standard solution just because I was too lazy to choose the industry standard.

Again I don’t mean that you are being “lazy”. That’s how people think.

But if I were hiring someone - and I’m often interviewing people for cloudy/devOps type roles. Why would I hire someone with experience with a Docker orchestration framework I never heard of over someone who knew K8s?

And the final question you should ask yourself is why are you really doing this?

Is it to scratch an itch out of passion and it’s something that you feel the world should have? If so in all sincerity, I wish you luck on your endeavor. You might get lucky like Bun just did. I had effusive praise for them doing something out of passion instead of as VC bait.

Are you doing it for financial gain? If so, you have to come up with a strategy to overcome resistance from people like Ive outlined.

Re: Uncloud - Tool for deploying containerised apps across servers without k8s

#99

Hey, creator here. Thanks for sharing this! Uncloud[0] is a container orchestrator without a control plane. Think multi-machine Docker Compose with automatic WireGuard mesh, service discovery, and HTTPS via Caddy. Each machine just keeps a p2p-synced copy of cluster state (using Fly.io's Corrosion), so there's no quorum to maintain. I’m building Uncloud after years of managing Kubernetes in small envs and at a unicor…

I really like what is on offer here - thank you for building it. Re the private network it builds with Wireguard, how are services running within this private network supposed to access AWS services such as RDS securely? Tailscale has this: https://tailscale.com/kb/1141/aws-rds

Re: Uncloud - Tool for deploying containerised apps across servers without k8s

#100
post #18
post #4

Earlier quoted context omitted.

"I keep seeing teams reach for K8s when they really just need to run a bunch of containers across a few machines" Since k8s is very effective at running a bunch of containers across a few machines, it would appear to be exactly the correct thing to reach for. At this point, running a small k8s operation, with k3s or similar, has become so easy that I can't find a rational reason to look elsewhere for container "orche…

I can only speak for myself, but I considered a few options, including "simple k8s" like [Skate]( https://skateco.github.io/ ), and ultimately decided to build on uncloud. It was as much personal "taste" than anything, and I would describe the choice as similar to preferring JSON over XML. For whatever reason, kubernetes just irritates me. I find it unpleasant to use. And I don't think I'm unique in that regard.

> For whatever reason, kubernetes just irritates me. I find it unpleasant to use. And I don't think I'm unique in that regard.

I feel the same. I feel like it's a me problem. I was able to build and run massive systems at scale and never used kubernetes. Then, all of a sudden, around 2020, any time I wanted to build or run or do anything at scale, everywhere said I should just use kubernetes. And then when I wanted to do anything with docker in production, not even at scale, everywhere said I should just use kubernetes.

Then there was a brief period around 2021 where everyone - even kubernetes fans - realised it was being used everywhere, even when it didn't need to be. "You don't need k8s" became a meme.

And now, here we are, again, lots of people saying "just use k8s for everything".

I've learned it enough to know how to use it and what I can do with it. I still prefer to use literally anything else apart from k8s when building, and the only time I've ever felt k8s has been really needed to solve a problem is when the business has said "we're using k8s, deal with it".

It's like the Javascript or WordPress of the infrastructure engineering world - it became the lazy answer, IMO. Or the me problem angle: I'm just an aged engineer moaning at having to learn new solutions to old problems.

Post reply on HN