Meanwhile, over on Android, we are running dozens of apps of varying quality, all updating all the time, and phones have very high reliability anyway.
On Android you don't need all kinds of containerization nonsense with 100MB packages for even the tiniest things.
Nor do you get a nightmare of broken dependencies. The OS gives you one consistent API level, and it's consistent on any device.
Permissions and security are pretty much solved, or as close solved as they can possibly get right now, you can't stop people from giving location access to everything and still claim people own their devices.
On servers, we have a nightmare tangle of Microservices and crap.
On Android, we have a really nice design pattern where the OS pretty much provides everything, and stuff you might want to swap out can be done with a service provider app of some type.
It's not hard to imagine extending that model to cover things like databases. Why should we have a 50 step process to install every app, when the app can just say "Hey, I need to make a database, I can use postgres or SQLite, put my stuff in whatever provider is configured, and don't ask for a password, I already have the permission."?
It's just... so much more sane and structured. There's already lots of Linux userland on Android projects, no real blocking issue there in being able to migrate legacy stuff.
There's performance issues with complexity, except.... not really. Apps use things far slower than Dart and Kotlin and Android API calls all the time. And Android is efficient enough to run on a phone at just a few watts, while still rendering modern websites, so it seems like they're doing something right.
What gives? Why are we not managing our web apps by uploading a single APK file and a settings.ini with the permissions we want to give it? Why is the Steam Deck Linux based while Android hardly has any decent games?
None of those things you'd want in a server OS.
The phone apps don't use the exact same system for it, but essentially they're fully isolated in a similar way containers would be. The only difference is what is provided by the system and what by the app.
Flatpak can also shift the GUI into the base layer, so for example on Fedora Silverlight you can have a barebones system which uses a shared gui layer for most installed apps. (CoreOS is a similar idea, but for the server side)
> It's not hard to imagine extending that model to cover things like databases
Databases are not interchangeable beyond trivial examples. But a plugin system like that exists - odbc.
> when the app can just say "Hey, I need to make a database, I can use ...
This can be already solved with either full system configuration (Nixos) or containers (docker-compose does pretty much that). Those are sane and structured as well and they're available now.
If you want to go one layer higher (lower?), you can build a similar environment with AWS cloudformation - they can provide you with app containers or isolated functions, ready databases, all the connections in between.
> Apps use things far slower than Dart and Kotlin and Android API calls all the time.
Yes, but on the phone your app may just take slightly longer. On the server side a common case taking longer means everyone else waiting a bit longer and the whole thing translates to more money spent on infra. Those are different failure cases / requirements.
> Why are we not managing our web apps by uploading a single APK file and a settings.ini with the permissions we want to give it?
Many of us are doing basically that. The APKs are container images / static binaries / other kind of packages though. My whole server is one Nixos configuration file for many services and packages for example. Some older systems won't change overnight, but for new stuff you have all the possibilities you want, available right now.
Probably the closest to "just put some blocks together" you can get now are the iot fleet management services OSes like balena and others.
There were a few very early attempts at Android laptops, but as for tablets (only worse), w/o any support from Google (Playstore category, guidelines...) those floundered.
I blame mostly ChromeOS, preferred by Google because it fixed the NIH issue and because why build one good ecosystem when you can build an OK one AND a bad one ? I'm still making "Android desktops" from TV boxes for the elderly around me. Android's support for standard webcams and other USB devices is a boon. It only really needs an LTS version, and some devices/apps guidelines and vetting. Not sexy enough for Googleheads, I guess ?
Most of what you refer to is Android is the UI stuff built on top of a slimmed down Linux Kernel.
I'd like the opposite actually, a push to standardize Android into a proper Linux distribution and not the Frankenstein that it became.
What you are saying is so true. I don't understand why no standardization work is being done to make server deployments simpler with high reliability. We have some takes like cloudron, sandstorm, yunohost but nothing is "mainstream".
If you remove the UI from an Android app, what's left that's android specific?
This is entirely a market issue; you can port Unity games provided you can adapt to the weaker GPU, but you have to deal with the small screen and touch controls. Plus people have got used to everything being free on Android, so the really big money makers left have to be gatcha-monetized.
> On Android you don't need all kinds of containerization nonsense with 100MB packages for even the tiniest things.
Have you looked at some Android package sizes lately? They all bundle their dependencies.
But, chromeos is sort of like that and GKE nodes use it to run k8s stuff. I can see it being used to run containers like that, although with much disdain.
I can see an android inspired thing but android with it's app stores and rather peculiar administrative burden would make a bad fit imho.
Fyi: there are android laptops and desktops but nobody likes them.
I mean, I hate android but I hate all populat mobile OSes compared to desktop and server variants because of UI , walled garden and severe restrictions.
Try that with having to serve hundreds or thousands of users all over the world so that responses come back in a reasonable amount of time.
There's things being done today in backend development that are probably overcomplicated, but Android is certainly not going to be the solution. And if your use case is really simple (e.g. personal hobby project and you're the only user), you can also just run some program from a single VPS, that's certainly very easy to do (and can be automated with all sorts of tools).
For anyone new to backend development, I would anyway recommend to ignore docker and microservices and other such things at the beginning and just try to get a program to run on a single server (and having it being accessible from outside). All the other technologies build on top of this, and they exist for various reasons to make things more maintainable/scalable/secure, but they're not essential, in a strict sense, to backend development.
Somehow I feel uncomfortable with the suggestions you make, but I find it hard to articulate. Somehow this does not sound like an attractive model, it sounds very "involved". Let me try to articulate why.
I think a lot of the Android tooling sound new-ish, but actually I find it to be old-world in the server space. We have been moving more and more into declarative infra-as-code paradigms: Spin up a multitude of servers from a single text file that declares the final state of the entire architecture. Think Docker compose, Kubernetes/Terraform, Ansible, Chef/Puppet, Nix(OS).
In a world where your servers/configs live in Git, where is the advantage for something as involved as Android, which in the end is just a Linux kernel with some APIs on top (and a privacy invading proprietary layer, again, not your point I guess)?
Keep in mind, that little stability it does have is for mobile loads not server loads.
It is insecure and most of the security is applied by a poor mans implementation of containers. The rest is done through appstore scanning, restrictions and limitations on who can publish an app.
Others mentioned ChromeOS but I think the Google effort in this direction lies in Fuchsia today. The Zircon kernel is quite different from Linux from what I can tell, but given enough effort and time (not necessarily by Google) may become a viable target for server workloads.
In both there are many issues - the tab index is often weird, some parts of the UI may be inaccessible at all, some widgets don't even have a different colour when they are highlighted.
Some apps start in portrait mode by default, so you without a 3rd party app they are sideways.
Even without that it's sometimes random which way round apps will start.
Android is a disaster using the UI this way.
I mean, you're serveer isn't walking into retail stores, so why would Goggle want to track that?
The primary purpose of android is a user data harvesting platform. I'm already dismissing large numbers of modern cars because of this.
The main reason there's no such OS is because developers by and large will not pay for software if they could use something free instead. That's it, that's the only reason. Once there were quite a few such server operating systems, e.g. Solaris and Windows Server, but they've all been crushed by Linux because Linux costs nothing and that is overwhelmingly the most important criteria for developers. See also the massive Red Hat drama lately. Note that they'll happily fork over a lot if the alternatives also cost money, which is why everything commercial for devs takes the form of services not software because they'd have to pay for servers anyway so once you've crossed that bridge why not pay for expensive fancy servers in the form of cloud services too. But a generic OS platform you could use anywhere? Devs won't go for it unfortunately. They'd rather chew devops glass than do that. It's not entirely irrational. There's safety in numbers and Linux's complexity = job security and career advancement, after all.
OK so what would an "Android for servers" actually look like? The big problem with defining this is that Android gets a lot of its simplicity from not caring about scalability. It's scoped to a very specific set of use cases which don't involve processing much data. The moment you talk about a server OS, are you even talking about one machine anymore? Or something more like Kubernetes where the "OS" is lots of computers fused together. Is your server platform meant to power a 10,000 machine cluster or is it focused on single machines? You talk about uploading .apks to the server which suggests you're after something more single-user focused, which is a lot simpler to do but again there's no demand because people would rather just create accounts on the 10k machine cluster and share all their data (despite what the EU thinks nobody cares about data privacy, convenience wins every time).
So yeah - summing up, there could be something way more sane, more structured, simpler, more consumer-like in its usability. But whoever tried to create such a thing would go bankrupt because nobody would buy it. You may not like it and find it a nightmare but for better or worse devops is a job and companies would rather grow their empire by hiring people to do it than pay a third party for easy to use software that means they don't have to.
there are much better servers and desktops. using android for these makes me feel sick.
Wrt. to servers Android is fundamentally designed to run phone applications in all of it's fine tuning, optimizations and internal design. You really don't want to run that as a base for servers (same for iOs). Not even considering that Android is missing tons of functionality server software uses all the time.
> On Android, we have a really nice design pattern where the OS pretty much provides everything, and stuff you might want to swap out can be done with a service provider app of some type.
same for Linux which most servers run on, just often easier and more flexible then on android and without a lot of phone use-case specific overhead android comes with
> On servers, we have a nightmare tangle of Microservices and crap.
this is fully unrelated to the operating system, you have microservices not because operating systems succ, you have them for stuff like auto scaling, fault isolation, replaceable components etc. _across many hardware nodes_ potentially distributed across all the world.
> It's just... so much more sane and structured.
no, it really isn't
> Why is the Steam Deck Linux based while Android hardly has any decent games?
Because google is clamping down control on android.
Because Android isn't that good for games.
Because it's just easier for valve to make windows games run on desktop Linux then on android.
Because the app stores market dynamics make it hard for many kinds games to be profitable. Android has a tone of game, just many crap idle clickers and stuff like that, because that still sells well enough.
I mean consider this: Google itself did more then just one time try to find a way to get ride of android and replace it with something else, better working. They just failed because it wasn't pragmatically possible wrt. the existing ecosystem.
EDIT: Also a lot companies don't really run desktop/server Linux, they put a application into a contain which can be hosted on Linux, and might contain many parts of a server Linux for convenience reasons, but logically it's more like directly running only their application on a linux kernel then anything else. If you want nice abstractions about how this servers can interact, something which in general is seen more as infrastructure ten OS tasks, you would need something like a distributed web OS or infrastructure abstraction layer, i.e. not Android (they do exist with varying degree of success).
EDIT2: Yes the current state of cloud computing is pretty bad, but really trying to put Android in there wouldn't help at all IMHO.
We don't change anything. Management likes this because we don't incur extra costs developing, training, deploying, advertising, and using this new paradigm.
On top of that, you're asking devs and sysadmins to entirely change the way they're doing things. Maybe the returns are actually worth it, but either your idea has very little market penetration and why would anyone spend the time to learn it, or it does (how?) And you're training yourself on an entirely new system with no connection to the old one, effectively learning your entire job again.
To put it simply, the reason we're not doing it is that we're not changing things at all, for the most part.