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?
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.
I don’t know if the author intended to be “local first- adjacent” with this project, but I am seeing a lot of wasm-target projects lately, including replicated databases, and I wonder if this project isn’t a peek at what a truly distributed (browser-to-browser) workload might look like. This project persists the system config in GitHub, but if the components are wasm then there’s at a chance that they can use that provision themselves in every browser.
Imagine a workload where a client does their own compute, by provisioning worker components locally and retrieving only shared data from your systems - how much cheaper would your hosting costs be?!
Thanks for articulating that. I was groping around for something along those lines — going beyond easy self-hosted to local-first deployment. Considering the web3 origins, I wonder if the project founders had that in mind as well.
There was a different, recent HN post about scoped propogators, which I find to have a lot of good potential for people to write and apply local customizations for their own apps.
I don’t know if those are the killer use case for this, but I think ideas along these lines takes it further out of alignment with incentives for business models.
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.
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.
If it works as well as described (ie as well as can be expected with IPFS as a storage layer), it doesn't work.
We used to call those “turn-key solutions”.
"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.
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.
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.
Maybe they’ll become consultants helping big customers use the platform to fund its development.
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.
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.
Amazon and the hyperscalers will eventually pick something like this up and offer it for free.
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).
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.
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...)
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.
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.
Replying just to “isn't a coherent mental model”:
I just took a deep dive into the documentation- which is comprehensive - and I feel the complete opposite; the author has a very well refined mental model of a PaaS and has created a modularized source-code expression of that model that I found very interesting. The CI module is called “patrick”, which gave me a chuckle.
You have some good feedback in your post, but I feel like the author may not be trying to replace hosted PaaS; they are essentially using tiny-go to build small distributable wasm modules that can interoperate in a distributed network, which aligns very closely with the localfirst ethos that brings compute and storage out of the datacenter. Does it feel a bit silly to even SAY “client-side CI”? Objectively, yes, but if a future architecture might need to safely deliver code to clients in a mesh this is a really interesting way to experiment with solutions.
Yes, so that one doesn't need to learn those helly AWS config.
Exactly. If one has to self-host actually, it's best to deal with the direct infrastructure (IAAS) layers and get its efficiency instead of going through additional layer overhead.
I don't know much about NodeJS/React world but to compare with PHP, this is the equivalent of self-hosting an open source CPanel instead of creating a LAMP setup on VPS and working with Linux and PHP directly?
When you have an infrastructure team at your company - that is basically what they do - changing IaaS or your bare metal into PaaS. But yes that is only useful at certain scale of operations.
Maybe with such tooling as original post it will be useful in smaller scale.
Not sure of Tau's exact features but one nice thing about the Vercels and Netlifys is the integration with Github and easy CI /CD setup.
Having CI taken care of by just installing a single package on your own server is compelling.
The main think that they take care of that this probably can't on bare metal is redundancy and uptime and scaling.
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.
Nah, this is just Dokku 2 and I love Dokku. I think you’re mistaking a software component “service” and a business model “service”
Self hosted gmail P2P netflix server Bank account + bank combo Mortgage Hertz DIY concierge service Fast food from scratch Bootcamp taking bootcamp Oxygen Farm