[HN Gopher] Tau: Open-source PaaS - A self-hosted Vercel / Netli...
___________________________________________________________________
Tau: Open-source PaaS - A self-hosted Vercel / Netlify / Cloudflare
alternative
Author : thunderbong
Score : 265 points
Date : 2024-07-12 14:41 UTC (8 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| yayr wrote:
| very interesting... here is a comparison of the community and
| enterprise offering
|
| https://taubyte.com/pricing/
|
| who is actually behind this?
| KomoD wrote:
| > who is actually behind this?
|
| "Samy Fodil"
|
| https://github.com/samyfodil
| bitpush wrote:
| First coolify[1] and now Tau. More competition the better for
| users.
|
| From the quick look it seems like coolify is more fully featured?
|
| [1]: https://coolify.io/
| TechDebtDevin wrote:
| Coolify needs a lot of work imho.
| andruby wrote:
| Do you mean it's missing features or that it requires lots of
| maintenance and handholding?
|
| I'm evaluating some of the options for toy projects so I'm
| curious to read people's experiences.
| pif_ wrote:
| It's still in beta (under active development), so for
| fairly serious projects it's not yet viable in production
| in my opinion. But I'm using it for two personal sites, and
| it works perfectly. It's exactly the kind of tool I was
| looking for: open source, self-hosting, easy to install,
| easy to use and well maintained.
| ffsm8 wrote:
| Before Coolify came CapRover and dokku.
|
| My toy server (64ram, ryzen 5600G 60tb HDD, 4tb NVMe) is
| currently running fedora/caprover, though I've been considering
| just putting truenas scale on it, as it added custom
| deployments as well...
| udev4096 wrote:
| That's a beast server. What are you using it for?
| ffsm8 wrote:
| It sounds bigger then it is, raid 10 cuts it in half after
| all (30tb HDD, 2tb NVMe)
|
| It's mostly just for the *arr stack, various self hosted
| services like vaultwarden, seafile etc and my personal toy
| projects. I.e. a pwa book reader along with the occasional
| dev tool I wanna experiment with.
| satvikpendem wrote:
| I found CapRover and dokku to have some limitations such as
| lack of a GUI or long setup process. In contrast with
| Coolify, it Just Worked(tm). I'll have to check out Tau as
| well.
| bibstha wrote:
| Love Caprover. Using this on production to host many docker
| containers.
| hosh wrote:
| There are some neat ideas here -- building a PAAS off of p2p
| technologies to enable network autodiscovery, automated load-
| balancing, distributed storage, Webassembly-native, etc.
|
| Having put stuff through production though, I'm a bit skeptical
| about how well it works out in the wild, though I am interested
| in learning how well it does and what its failure modes are. If
| it works well-enough, it has the potential for democratizing
| production apps.
|
| I'm not sure how they are going to make money with their
| enterprise offering though.
| alfonsodev wrote:
| Would this be a good combo to combine with Hetzner server
| auctions, or just too much trouble ? or even with todays
| connections having a server at home ? any success stories ?
| winrid wrote:
| They only auction servers in one region
| joshmanders wrote:
| What's with the vilification of kubernetes? 99% of this document
| (https://tau.how/99-Misc/kubernetes/01-k8s-cons/) boils down to
| "You have to understand what a pod, deployment, container, etc
| is" once you remove every line that discusses the cons of
| managing a cluster yourself, because nobody actually does that
| except extremely large orgs. All of these problems go away when
| you utilize a managed offering like DOKS, EKS, AKS or GKE.
| mynameisvlad wrote:
| If your goal is to self-host your own PaaS, why would you use a
| managed k8s offering?
| joshmanders wrote:
| Why wouldn't you? If you decide to not use a PaaS and self
| host your own servers would you reach for a VPS or would you
| manage your own rack in a colocated data center?
| jpgvm wrote:
| Precisely, it's just about which abstraction and
| responsibility level you want to engage with. Managed k8s
| (from good vendors) means the scheduler is as far as you
| need to go which is enough to do a great many "self hosted"
| things.
| abound wrote:
| "Self-hosting" doesn't necessarily mean you own the hardware.
| Many people self-host on cloud providers at different levels
| (Fly, Digital Ocean/Hetzner, GCP/Azure/AWS), and most of
| those have some managed K8s offering.
| zerkten wrote:
| I found it interesting that this was the focus when users of
| Vercel etc. have probably decided against k8s already. For me,
| a k8s comparison would make sense if this was a platform for
| running containers/VMs in a more traditional server model.
| thinkxl wrote:
| > What's with the vilification of kubernetes?
|
| because a well-configured k8s cluster nullifies the need for
| this project. also hi!
| tln wrote:
| There's a fair amount of friction to going from 0 to a well-
| configured k8s cluster with gitops and a local dev story....
| jpgvm wrote:
| Gitops and a local dev story are more about your
| application than your deployment environment. Especially
| because along the way you need to consider building,
| testing, CI, etc.
|
| It's really hard to fault k8s these days, all the original
| problems are solved and all that remains is necessary
| complexity that can't be abstracted without lowering power.
|
| That doesn't mean you can't abstract over it, you can and
| should but you should do so in the scope of your team or
| organisation where you already know which pieces of power
| you need/want or otherwise know the way you which you want
| to leak those capabilities.
| llama052 wrote:
| 100% this.. There's also exciting projects like Talos, Rancher,
| and the like for self-hosting Kubernetes that makes it entirely
| more manageable.
|
| So much saturation in this space of people trying to create one
| off solutions, which on some level I admire. However the
| further off the main path you go the more you lock yourself
| into problems you can't troubleshoot or edge cases that aren't
| supported.
|
| Abstraction these days is alluring, and it's cool! However you
| want something well known, well supported, (from multiple
| companies ideally) and documented. The hate for understanding
| kubernetes is just hate for having to understand layers of
| orchestration, or worse the layers behind the application.
|
| If it's too complicated then you might not need it. Any
| platform you use will have those same layers, it just depends
| on how much is assumed or exposed to you. If you don't want to
| see any dials or options then use a managed solution, not a
| roll your own platform tool. That's of course assuming a few
| virtual machines managed by hand doesn't satisfy your needs,
| but if that's the case you don't need a platform solution (and
| hopefully it's not production).
| p-o wrote:
| I like your take on this. I think K8s offers a _lot_ and it has
| a bad reputation because of its early days. Kubernetes has room
| to improve, like everything else, but the API now are becoming
| a lot easier to work with and the Custom Resources allows folks
| to extend Kubernetes.
|
| I still think that projects like this one come from necessity.
| Folks want to have an alternative for vendor lock-in.
|
| I'm building something like that too (https://github.com/pier-
| oliviert/sequencer) for Kubernetes, and it's also out of
| necessity.
|
| Vercel, Heroku and others have a lot of helpful tools that are
| empower developers, and I think people want to have those
| without being locked-in.
|
| It goes without saying that I'm totally bias :)
| aduwah wrote:
| I disagree hard with this. I love kubernetes to bits, but
| managing complex networking issues, having proper security, or
| just simply rightsizing the nodes is definitely not going away
| with having a managed control plane.
| akvadrako wrote:
| Google's autopilot takes care of that stuff for average use
| cases. You just point a few yaml files at it any your app is
| running.
|
| It's not like netlify does better in terms of rightizing
| nodes.
| philippemnoel wrote:
| "What's with the vilification of kubernetes?" I ask myself that
| question every day
| memset wrote:
| This is really neat! I'm working a message queue in go (drop-in
| replacement for SQS) and also thinking about autoscaling. I've
| been playing with raft vs using a central store (ie, postgres) to
| coordinate.
|
| Can you tell me more about IPFS - I've never used it before. How
| has that been working, and can you tell me what you've observed
| when you have many nodes which need to coordinate?
| sneak wrote:
| IPFS is slow and impractical. The design of the content
| addresssble system is cool, but having tried approximately
| annually to run it for production usage since it was released,
| I can say that it is still firmly in the "research project"
| category, a decade later.
| AgentME wrote:
| The weakest part of IPFS in my experience is how long it
| takes one node to find another with the requested data across
| the internet through the public DHTs. I imagine it might work
| much better in this system if they're limiting it to only do
| lookups and fetches within your own network of nodes.
| pdimitar wrote:
| Lately I've stumbled upon https://www.goqite.com/ but haven't
| had a good use case for it yet.
| taraparo wrote:
| Wouldn't using talos be better than having to run this on custom
| managed ubuntu servers?
| pdimitar wrote:
| Which Talos, can you send a link?
| taraparo wrote:
| https://www.talos.dev/
| llama052 wrote:
| I assume https://www.talos.dev/
|
| Basically a small OS that will prop itself up and allow you
| to create/adopt into a Kubernetes cluster. Seems to work well
| from my experience and pretty easy to get set up on.
| Ambroos wrote:
| I've been reading through the docs and skipping through the one
| recentish YouTube tutorial trying to make sense of what this
| actually is. While it seems like an impressive thing for what
| appears to be a one-man-project, the almost complete lack of
| documentation makes it feel like a bit of a hard no in the
| current state. There seems to be a history of it being heavily
| linked to Web3 things that also feels weird.
|
| Some suggestions for this to be able to succeed:
|
| - Documentation, documentation, documentation, the only place
| where I could that the three supported ways to write a serverless
| function are with Go, Rust and AssemblyScript is somewhere hidden
| in a tutorial. It all has to compile to WebAssembly so I guess
| that's the limiting factor.
|
| - Examples?
|
| - Using git as source of truth for the configuration/state of a
| system is cool. Please link to sample repos so I can see what a
| system with a website, some functions that touch DB and files,
| and the configuration etc looks like.
|
| - How does the database part work? Client SDKs?
|
| - There are lots of protocols with unclear names that are only
| briefly mentioned here but then seen in random places in
| configuration: https://tau.how/01-getting-started/01-local-
| cloud/#protocols
|
| - The Concepts part of the documentation is buzzword soup, it's
| impossible to derive any meaning from it other than that the
| author dislikes Kubernetes and probably used some generative AI
| for the content.
|
| - Roadmap, plans, versioning, plans on how Tau version upgrades
| should go, ...
| breck wrote:
| I love the verbiage. When I see a folder in the source named
| "dream", then files named "Universe" and "multiverse", it pulls
| me in :).
|
| I also love the single binary in Go. That's on my todo list for a
| few things.
|
| Well done!
| VyseofArcadia wrote:
| I've been out of web dev for a few years, but my understanding of
| the appeal of serverless is that it is theoretically pay only for
| what you use. But if you're hosting Tau to do serverless via Tau,
| well, it's not really serverless anymore. You are now definitely
| paying for the server running the serverless infra.
|
| Why would anyone target Tau serverless, then? What am I missing?
| cal85 wrote:
| That's not the only appeal of serverless. In fact it's not even
| really true - I pay Vercel a flat rate every month whether I'm
| heavily using it or not.
|
| The appeal of serverless for me is simplicity. It abstracts the
| server away. Less to think about, more brain capacity focused
| on unique business logic.
| joshmanders wrote:
| > The appeal of serverless for me is simplicity.
|
| That's interesting, because serverless is far from simple and
| Vercel is about the same distance from simplicity as the sun
| is from the edge of the observable universe.
| sqeaky wrote:
| Self-hosted platform as a service?!
|
| Isn't the whole point of platforms as a service (from the
| customer perspective) that you don't need to do the hassle of
| self hosting.
|
| There are pros and cons to using an external service and to self
| hosting. And just throwing all these words at me together makes
| me feel like there isn't a coherent mental model of what this is
| trying to be, or if there is it isn't clearly communicated.
|
| If this is some sort of CDN software or attempt at running
| Lambda-like code Snippets on your own distributed cluster that's
| cool. But a description of that would be nice.
|
| The GitHub read me jump straight into how this is just a single
| binary and how deploying it is easy, but not what the hell it is.
| CloudFlare can do like a million things, which features from
| cloudflare is this competing with? I just really want to know
| what the pros and cons of this are compared to other ways of
| rolling my own servers or renting out someone else's platform?
| Kinrany wrote:
| "Self-hostable as a service" is a common pattern because it
| provides the benefits of as-a-service without the threat of
| vendor lock-in. Plus you can run the same software in temporary
| or test environments.
| st3fan wrote:
| Where Vendor can also be an open source project. The cost of
| moving away from a project like Tau can be equally high as a
| closed source PaaS of course.
| rrix2 wrote:
| and if that cost of moving away is high enough, a team or
| org "locked in" to a FOSS solution can continue to pay
| humans to support it internally while evaluating off-ramps
| instead of being told they need to re-arch their cloud
| stack in three months' time.
| makestuff wrote:
| It will be interesting to see how these companies evolve
| their business strategy once PE/VCs are pressuring them to
| IPO/get bought out. It seems like any customer that is large
| enough to have significant billing would just bring the
| platform in house instead of paying for the hosted version. I
| guess they could take the docker desktop approach with their
| licensing that >X million in revenue still requires a license
| of some sort.
| hosh wrote:
| They are using technologies such that the system can self-
| heal, and self-deploy (with auto discovery) ... so there's
| a misalignment of incentives for the product and a hosting
| business.
|
| I like the ideas they are trying, so I wish the best of
| luck to them. Hopefully, they'll find a business model that
| is better aligned with the product.
| godzillabrennus wrote:
| Maybe they'll become consultants helping big customers
| use the platform to fund its development.
| hosh wrote:
| Further down on the README, it explains how it uses libp2p for
| network autodiscovery, IPFS for distributed storage, and how it
| can distribute and share routes and assets and automating load-
| balancing. It is Webassembly-native, so you don't have to mess
| with compiling dependencies or execution environments.
|
| If it works as well as described, then the underlying
| technology (and the constraints they have) allows it to be
| self-hosted while having some of the benefits for a managed
| platform.
| sqeaky wrote:
| Thanks for digging in.
|
| Would be nice if READMEs opened up with what the thing was
| and maybe a one or two sentence problem and solution
| description.
| hosh wrote:
| Sometimes, it's hard to tell how significant something is,
| and the creators may not even know until hindsight, let
| alone articulate it in a concise, accessible way.
|
| The initial marketing word usage such as "amazing" put me
| off at first ("Show me, don't tell me"), as well as how the
| author(s) poo-poo'ed on Kubernetes. (I've worked on both
| good and bad usage of K8S, so it isn't always a fairy tale,
| nor with a bad ending). However, it also read like someone
| who seemed to have a deeper understanding of infra writing
| about this, not just a vapid reinvention by someone who
| works mostly on the front-end, so I kept going with the
| README.
|
| Having said that, while I am a big fan of IPFS, I know
| there are performance issues with it. (Maybe Tau set up a
| private IPFS that is only used within the cluster, which
| may help it work faster). It also sounds like they are
| working on general container support, not just Webassembly.
| Overall, if they keep iterating and improving things based
| on how things work in production, then they'll end up with
| a fairly robust system.
| jauntywundrkind wrote:
| The point of platform isn't just that someone else hosts it.
| It's that it's a consistent target for your teams & different
| projects, with a well defined set of capabilities.
|
| Having patterns to deploy & ship software, that also can bring
| up & manage other resources along the way (databases, load
| balancers, geo-reicatikn, etc etc).
| seangrogg wrote:
| While I think this is a valid take for the term "platform" I
| do think that "Platform as a Service" implies that someone
| else is running the platform and I don't have to deal with
| the headache of managing it, I just use it.
| phendrenad2 wrote:
| Yes, from the developer's perspective, someone else is
| running the platform (the platform team). (At least, as
| long as the developers can avoid assuming ownership of the
| platform by managing terraform files or something, which in
| practice I've yet to see anyone avoid...)
| sqeaky wrote:
| And this is true even if you're not using a product that
| bills itself "as a service", get somehow we never called
| the next machines that programmers never touched running
| a LAMP stack "platform as a service". It's almost as if
| the "as a service" part meant as a service to your
| organization.
| mlaretallack wrote:
| In a company, there may me multiple teams, each doing there
| own projects, PaaS can be within the same company and
| provide a common way to do stuff without each team having
| to start from scratch each time.
| revskill wrote:
| Yes, so that one doesn't need to learn those helly AWS config.
| kgeist wrote:
| Two large marketplaces in my country I know of have their own
| self-hosted PaaS (I know some of their devs personally).
| They're microservice-driven and have many small teams. One of
| their devs showcased me their platform where a small team can
| launch a new microservice with a few simple configs/CLI
| commands without having to know anything about infrastructure
| (it has built-in monitoring, logging, scalability options,
| discovery etc., full package). I guess it lowers costs because
| they have a lot of traffic. And they made it super easy to use
| for small teams with no cloud expertise. Faster deployments
| because each small team manages their microservices on their
| own. Plus, no vendor lock-in. I can imagine the pain of
| migrating 3000 microservices off a vendor. However, I think for
| small companies self-hosted PaaS is an overkill. Those
| companies have dedicated teams who work solely on PaaS.
| turtlebits wrote:
| Looks compelling, but the docs are extremely vague and full of
| fluff. The "Why One Binary" is hilariously bad. Almost feels like
| content to impress managers/recruiters.
|
| https://tau.how/02-concepts/03-one-binary/#the-genesis-of-ta...
| Ambroos wrote:
| Pretty much all of the docs are very clearly the output of what
| the typical LLM produces. It's just words, no meaning.
| mplewis wrote:
| Nothing like "docs by LLM" to warn you about the quality of
| the code you're about to trust your entire infrastructure to.
| teruakohatu wrote:
| I thought you were probably exaggerating... you were not.
| warkdarrior wrote:
| But, but,...
|
| "By emphasizing ease and simplification, Taubyte aspires to
| transform cloud computing into a catalyst for creativity and
| innovation"
| WD-42 wrote:
| Ouch. This is llm output.
| klabb3 wrote:
| Wow, this is the most shameless piece of garbage I've seen.
| Using an LLM to clean up and polish? Fine. But this? It's like
| two words of content that's been expanded to a wall of
| gobbledygook.
| lbltavares wrote:
| "Taubyte's single binary philosophy advocates for a future
| where the full potential of cloud computing is unlocked through
| its accessibility and efficiency"
| KomoD wrote:
| Don't call this a Cloudflare alternative because it simply isn't.
| OJFord wrote:
| Cloudflare _Pages_ I assumed, from the title, since it already
| didn 't make sense to compare Cloudflare (overall) to 'Vercel /
| Netlify'
| sandGorgon wrote:
| how is this achieving scale-up and scale-to-zero ? from my
| (rudimentary) investigation only knative k8s had scale-to-zero
| implemented well enough.
|
| and if you dont have scale-to-zero, you cant claim a vercel
| alternative.
| TheAnkurTyagi wrote:
| What key features make Tau a compelling self-hosted PaaS
| alternative?
| localfirst wrote:
| how does this compare to coolify and caprover already established
| and mature PaaS ? this is a welcome addition
| trollied wrote:
| Am I wrong, or all this ends up doing is round-robin DNS, which
| is no good for a geographic CDN?
___________________________________________________________________
(page generated 2024-07-12 23:00 UTC)