App vs. Service Installs

Installing a program on a computer isn't overly hard these days. OSX (... MacOS, sorry) made it fairly simple more than a decade ago: just drop an app bundle into the "Applications" folder... but even for Windows apps, it's "next next finish" mostly, something that a lot of moderately computer-savvy users can accomplish.

Not to speak of app stores and phones. (... the main reason I avoided them is that it's somewhat debatable whether the "computer" they're installing apps onto is actually theirs. 2000s era Windows computers had no such problems.)

Meanwhile... what if you're trying to install a photo gallery server instead? Or an RSS reader webapp? Well, suddenly, it's TLS certs and database accounts and usernames and proxying and similarly obscure things. Definitely not for the average user. There have been some efforts for making this easier: Synology has an "OS" with an app store that can help with some of it, and there is also Sandstorm, with a similar app-store like model... but True Sysadmins are still expected to tinker with configs, which says something about how deep these solutions go (hint: not very).

Why is this & how do we fix it?

Platform issues

For webapps, the Web is essentially a glorified remote desktop service. You have your actual data on the server, with the UI rendered on the client. For some value of "render", at least. Some apps send out HTML and browsers show that, some apps send out JSON and have some client-side JS generate something that the browsers display. In the end, if we used Windows Remote Desktop and forwarded Win32 apps pixel by pixel, it wouldn't change a whole lot to most users.

Except... it's a fairly messed up remote desktop protocol. (... as you would expect from something that was designed to download hypertext documents.)

First of all, everything needs to go through the same server port, because we forgot to start using DNS SRV records. Which... we solve with hacks like virtualhosts and proxy servers (... which, of course, need configuration). Not to mention rules on which apps can talk to which other apps, based on which domain they are on (... also thanks to the fact that it was a system for hypertext documents). Plus, since we had originally-static HTTP document servers around anyway, some webapps don't even serve HTTP requests directly but expect the web (frontend) server to launch / connect to them in various ways (... CGI, FastCGI, uWSGI, PHP modules, Java application servers, ... etc.)

Meanwhile, there is the question of user authentication. For a reasonable remote desktop service, you authenticate first and talk to apps second. For web apps: it's... sometimes the opposite, sometimes it isn't, and it's not OS users anyway, since there might be too many of them, and it's not like they're users on your actual server. (Unless you're self-hosting something, of course. Or unless you're on Windows and your users are from Active Directory. Which... sometimes makes sense.) As for where your users and passwords are coming from: more configuration! Maybe you could get the app to talk to your database. Maybe you can't.

Also, if you don't want to keep logging in to your own single-user server 5 times for different apps with different passwords... that's a whole another level.

(... if only we went with Windows Remote Desktop all the way.)

Data

For apps / programs, the story is simple: you save your data / files / etc. somewhere on your hard drive / storage / etc. Maybe you have a per-user database. Hopefully it keeps working even if you have multiple users on the same machine.

For web apps... well, there are two cases. You either want your users to know about each other, or you don't.

If they do interact... well, you'll need a database. Which is its own thing. Shared by multiple apps. Which then create their own tables. Etc. (The fact that apps use logins for databases that are neither the webapp users nor the server OS users is quite an impressive level of messiness.) We're sharing the database server, we'll need more configuration. Which... you might attempt to automate, but... it's going to be different for every one of them.

... actually, why don't apps launch their own DB server instances? (... or are we just in the process of reinventing containers?)

If they do not interact... well, then things are even more weird. We could have little per-user database instances instead. (This is what Sandstorm does I think.)

Overall though... yet again, we're in quite a distance from "just install the app with a few clicks". We can't even blame "The Web" for this; it's mostly just that we couldn't really agree on how to store data for services that are potentially used by multiple users. (Even if it happens to be a single user.)

Security

Meanwhile, even if you somehow manage to get things almost right, you'll still be doomed. Want to actually connect to your neat little service? Well, you shouldn't just open ports to the Open Internet; it's dangerous! At least that's what infosec people will tell you. (They're... not wrong.)

At least, you definitely don't do plain HTTP. So you go and set up certs. And by this I mean you set up this neat script that runs on your web server (which, for the aforementioned reasons, will have to sit in front of your actual service anyway) that refreshes a Let's Encrypt cert every few months. It works with NGINX and Apache (unless your config is weird). Is it harder though than next-next-finish? Most definitely yes.

And then you'll need to login to each of your services from each machine you're using them from, ... see "above" for reasons. But... optimally, you'd connect to a VPN first, so that you don't expose your potentially-broken login forms to the Evilness of the Internets. Remembering the LAN from apenwarr is a neat summary of what happened to Actually Running Things.

Solutions?

Well, I don't particularly have many of those.

For the analogous problem of "installing DOS programs is sometimes hard" (Extended memory! EMS! HIMEM.SYS! MSCDEX.EXE!), I wouldn't have had a lot of immediate ones either. Except... in that case, people recognized that you can sell more computers to people if they can actually install stuff on them, even if they aren't experts.

For our case, the same people came to the conclusion that you can sell your webapps as services, so there is absolutely no need for making anything easier. Thus, while many people do use a bunch of webapps, most users host exactly zero of them.

Actually, even companies who used to host things are giving this up (this being sold as "cloud computing"), in the name of simplicity and cost-effectiveness. Because hosting these yourself is legitimately hard. (... just as described above.) Of course, this produces little motivation for making things simpler.

In terms of thinking though... it might help imagining your app as a Win32 GUI app, via Remote Desktop. For example, consider your fancy photo gallery webapp, with a database, the proxy in front, HTTPS, etc etc. How hard would it be to install this, if the only thing you had to care about is one single machine (that you can log into via remote desktop)? Well... um... so... now it's just the builtin Windows file browser, maybe with some indexing. Or just some image browser GUI. Authentication is solved already; file access rights are solved already; even thumbnailing is built into the OS.

Of course, this is harder to do with something like a forum; having a thick client does help though with deciding what really needs to go into your server part. Maybe you would want to design a protocol instead?

But... overall, it doesn't have to be this hard. We just have to remember that it could be simple.

... comments welcome, either in email or on the (eventual) Mastodon post on Fosstodon.