If you're, say, Box, you're implementing only the endpoint, and mostly don't need your own directory, because all your customers bring their own. The difference is that, in practice, if you're "just" a large non-IT enterprise or "just" a cloud provider, then you're not implementing the whole solution any more, only half of it. The most problematic holdouts are the likes of Adobe who refuse to write applications that play nice with NAS-type filesharing so that just leaves you with file syncing instead. And for the 1-man-photo business all of the local stuff still works and you really wouldn't have gotten anything out of 'server' anyway. There are of course still some true file-based processes where Apple is still used a lot, but even that is no longer local-file-only a lot of the still and motion processing is done either super small locally or simply distributed to dedicated systems like render farms. All that is left is basic file sharing that is sometimes done locally, and even that is becoming more and more stupid to implement in a workflow or business process. Do you really still need classical 'user' and 'group' membership things? Network accounts? Local web servers? Pretty much anything of significance is in a private or public cloud, if only because the fast pace and scaling. We are in between the legacy 'directory' based networks with authentication etc, and the more robust and expansive beyondcorp type setups. To be fair: while they did leave all the classical 'server' type use cases out in the cold and are making it worse every release, it's not actually the future or the best practice to still roll out. And it's one with slim-enough profit margins, that Apple doesn't want to compete. Not because of the cloud (which is mostly a complementary use-case) but rather because this software-solution vertical has now evolved into a turn-key hardware-appliance solution vertical. They'd buy a NAS.Īnd, IMHO, that's why Apple haven't kept Server.app up to date. No SMB office-manager who needs this kind of functionality these days would buy a Mac or PC, to set up server software on it and leave it sitting there headless in the office. Plus, since a NAS isn't going to be doing any desktop-OS things, the software for it can be slimmed down enough to run on lower-specced hardware, making the appliance itself much cheaper than the sort of machine required to run Server.app smoothly. A NAS is a standalone box that receives automatic updates, is 100% remote-management enabled by default, can be easily reset to factory settings, and can't be messed up by employees who think it'd be neat to run local native apps on it, "since it's a computer just sitting there." Synology's set of first-party OS packages has 1:1 feature parity (and then some) with every function Server.app either has, or used to have.Īnd that's the key-word here: appliance. IMHO, the direct competitor of Server.app in the "SMB office server" use-case is actually a Synology NAS appliance.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |