Follow

Seeing an argument that Mastodon instances are hard to deploy (true of any web application) and that the solution is to focus on making something "serverless" that can be deployed to AWS or other clouds that provide proprietary "serverless" frameworks. Making applications that only run on giant cloud hosting providers is absolutely *not* the path toward technological autonomy. I think we need to better communicate free software principles here.

@dthompson FWIW, I'm considering hacking on a serverless mini-mastodon. But, you *can* wrap a set of node-based AWS lambda functions (for example) with an express server to run it independently. Lots of escape hatches that I'd plan to build in if I got around to actually doing it.

@dthompson Personally, I'd want to try something serverless not so much because it's easier to deploy - but because it might be cheaper and scale *down* more easily for many very small instances (i.e. my own single-user instance or a small low-traffic group instance) Admittedly, I might be wrong about that being handy though

@lmorchard I think those are valid reasons, but I think we need to look beyond Amazon and Google's cloud and do something that doesn't rely upon proprietary software as a service.

@lmorchard so this is kind of like free software that primarily supports proprietary operating systems, and secondarily free ones. it's nice that it works, but when the proprietary system is the default and best experience, it's not helping people escape proprietary platforms.

@dthompson I haven't used it, but there are also things like OpenWhisk - that could help reduce lock-in I guess?

Main thing I'm thinking about is that if I can host a thing for $1 vs $10-$70 per month - that's a huge win. And probably engineer it such that it could live elsewhere

@lmorchard reducing cost and server maintenance burden are both good goals. let's just keep our eyes on the prize while pursuing that. free software web apps need to be a lot easier to deploy.

@dthompson That's true, but it also seems like a chicken/egg thing. Or a maturity-of-serverless-tech thing.

If I can get a cheap & accessible thing running now, getting more hosting providers running fully OSS serverless stacks may have more demand when I want to move away in the future.

In the meantime, I'm not going to start a hosting company myself.

@lmorchard @dthompson I had a similar realization lately: it's absurdly hard to deploy a server-application.

It's expensive too. Most are intended to run by themselves on a machine, so if you have a few of these, the cost gets high even wth containers and cheap vms.

And that's if you're good with tech. If you're not, forget it. Which is a shame, because it's not hard to install an app on your phone or laptop or even a NAS. So what gives?

@lmorchard @dthompson So I am working on an "application runner" platform that would make it very easy to install and run apps.

Not any arbitrary app, they would have to be written for that platform (🥚/🐔). But the platform would handle a lot of the difficult stuff like users and auth.

I was thinking that a single-user version of Mastodon could be such an app. But I'm a long ways away from that!

@teleclimber @lmorchard @dthompson I agree with this: I've got some cheap VPSes running, but several things I've gone to (experimentally) deploy recently assume they get the whole machine. No go. Another road-block is Let's Encrypt assuming one cert per IP (which is typically "per VPS instance" at best)

@dthompson @lmorchard

I'm afraid nodejs plays a role in making the deployment difficult

I'm afraid the web is lost

We should get back to native desktops (or shells or whatever they are called today)

And yes, we should install them as a framework on every android device

Maybe I'm too apodiptic

@catonano @lmorchard I think there needs to be a reunification between language package managers and distro package managers. I think the root of the great divide lies there. if we can resolve that (maybe not possible) then we can get things back on track.

@dthompson not trying to derail, but deploying pleroma here was like a 5 commands + nginx setup done in maybe less than 20, maybe even 15 minutes? I have like 3 commands to maintain the instance, for updates.

@ng0 even that is admittedly a lot to ask of a lot of people. I think the effort to make things easier to deploy is good, and the people that make the serverless argument mean well, but I think they are missing the big picture when they advocate for it. the solution isn't easy deploys of free software to proprietary systems, it's easy deploys of free software to free systems!

@dthompson I did not disagree with your view.
In fact I'm slowly working on getting this into Guix and my system, so that it can be as "easy" as adding it as a system service.
We only need to decrease computing consumption of guix itself (pull), and it could run on a raspberry pi or other small computers (what pleroma can do already today).

@dthompson why does "serverless" always just mean AWS

@garbados I guess because they popularized it and are ahead of the other cloud providers in their implementation. setting aside my feelings for the name, I think the basic idea of abstracting away server details is good (I guess Heroku is really one of the first big services for this). we need a free "serverless" protocol or something so that there isn't lock-in.

@dthompson but it's still just "someone else's server". why not use neutral coordinators like torrents do to allow peers to act as servers for each other? the alternative is a bunch of siloing bs imo

@garbados moving to true P2P is a completely valid solution. this is kind of where my knowledge ends. ultimately I am for whatever reduces the number of silos.

@dthompson @garbados anyone who uses "serverless" to mean something other than P2P immediately loses their credibility in my eyes

building software that is actually serverless is so much cooler than "using a specific AWS service"

@technomancy @garbados I mean, Lambda does make certain jobs much easier for me at work, but... it's just not a thing that could ever benefit the free software world.

re: serverless 

@technomancy @dthompson even p2p isn't serverless. who coordinates peers? it's still servers. the term "serverless" just feels like unrepresentative hype for a generic ease of deployment. Dat uses public torrent infra to coordinate peers, as does IPFS; SSB has its own "pub" system that is basically a private tracker that seeds everything it coordinates, and it's still a server.

re: serverless 

@garbados @dthompson sure; I didn't mean any existing systems; more that building a P2P system that didn't have the problem of needing servers to coordinate *would* be ten times cooler than hyping up some tired old AWS product

re: serverless 

@garbados @technomancy @dthompson no such thing as serverless. No matter how P2P. Each of the peers are servers, because they serve stuff!

re: serverless 

@kelly_clowers @garbados @dthompson kinda agree, but if you start going down that road it's not much of a leap to "any client which can perform uploads is also a server" and the term loses its meaning pretty quickly

"privileged frame of reference-less" might be a better term but I have a feeling it's not going to catch on

re: serverless 

@technomancy @kelly_clowers @dthompson someone used the term « leaderless systems » which isn’t without precedent and still feels largely appropriate to what p2p meshes represent, but not something like AWS. it also includes some distributed databases like couchdb, as an added bonus

re: serverless 

@garbados @technomancy @kelly_clowers @dthompson what happens when all the p2p nodes of a network eventually end up on AWS! 😭 I guess the latency would be good.

re: serverless 

@U_1F306 @garbados @technomancy @kelly_clowers put all the p2p nodes in us-east-1a for lowest latency

@dthompson totally. the tooling for p2p meshes is still in demoware hell but we're getting there; the interest and the labor is all at hand. there's some resistance to interop with server-based tech but IMO we'll get over it

@dthompson I'm not an expert in this but it could be nice to have a way to deploy apps in a self-hosted environment easily. Like that but in our own metal with no proprietary code in the middle.

@TheGibson there's no discussion. just something I saw. don't want to point out anything in particular. I don't know this person but they mean well. I just think it's a bit misguided.

@dthompson It's easier said than done, but I really like gitlab approach of deploying their application (it runs on a very similar stack) -- using omnibus package that creates its own environment under its own directory.

docs.gitlab.com/omnibus/

@avolkov I am 100% opposed to omnibus packages, and app bundling that circumvents the system package manager in general. it's a security nightmare.

@dthompson
This is a good argument, and the difference is that gitlab instances can run on their own somewhere deep within an intranet, and mastodon instances have to be connected.

Still, there's definitely a value in streamlining the installation so if someone wants to do everything securely, they know what's involved, this would especially help people running their own instances with just a few users.

@avolkov I think omnibus packages happen when people make applications that are too hard to build and just punt on the problem completely.

@dthompson But mastodon is a genuinely complex web application, and complex web applications inherently involve a lot of setting up.

I can set up Mastodon from scratch, I can use ansible to do that as well, I'm fine, but for someone who doesn't now this thing and just wants a space for their art project -- it's either going to be installing Mastodon or not.

Omnibus lowers barriers of entry for the newcomers.

@avolkov it lowers the barrier to entry at the expense of a lot of other things. I think we can do better.

@dthompson Web applications don't have to be inherently hard to run, Rails is hard to run, and Mastodon's confusing docs aren't helping the matter. Pleroma is much better about this, and what I point people to who don't have beefy hardware and sysadmin experience.

Serverless hosting absolutely isn't the answer - better documentation, turnkey solutions on Heroku and the like are. We as open source developers have a tendency to assume everyone knows what we know.

@embr I think more high-level deployment tools are good, provided that we don't forget about the principles of user freedom along the way. writing something that can only be reasonably deployed in heroku isn't helping the greater cause. we need to control the entire stack, even if we only interact with it at a very high level.

@embr @dthompson Yah I have heard you can run a small instance of pleroma on a raspberry pi and that it requires way less work to setup. I am very interested.

@dthompson Fediverse home appliances (with user-serviceable parts) FTW.

@jaycie i installed mastodon on my smart fridge and now all I see are pictures of sexy dragons when I try to get milk.

@jaycie but seriously I like the idea of "plug and play" home appliances that have distributed services already setup... provided that the whole security updates thing can be handled in a reasonable way so people's homes don't become part of a botnet.

@dthompson Agreed.

At some level, I think that social media servers are like table saws: There's a point of automation and attempted safety after which they paradoxically become more dangerous because people feel like they can be lax novices around them.

@jaycie this analogy makes me wonder if I'm one of those people because I use a SawStop table saw...

@dthompson I'm also reminded of how noise-making hardware gets installed on electric vehicles so that people don't walk right in front of silent cars.

@dthompson

seems like ages since I learned of the (now defunct) flyweb effort at Mozilla and thought "finally, here we go".

Alas.

@jaycie

@dthompson @jaycie ssshh. don't spoil our secret guix agenda of taking over the world in a giant botnet run on lisp.

@dthompson

I think there are values of "technical autonomy" that translate into "you can't make me care about the stack of dependencies below my competence level".

@dthompson

which bifurcates into those of us excited by, say, every piece of RISC-V news on the one hand and those who, say, consider thoughtless typeface selection a war crime.

Not *totally* orthogonal, but you get it: We have to pick which details to take for granted.

Sign in to participate in the conversation
Toot.Cat

The social network of the future: No ads, no corporate surveillance, ethical design, and decentralization! Own your data with Mastodon!