Moin;
Am Freitag, den 06.03.2020, 14:54 +0100 schrieb JokerG ermany:
> Also Quasi matrix, openproject und nextcloud in einem.
> Das ist schon ein Brett...
>
Ja. All das in einem, und noch etwas mehr, dazu (für Windows) native
Desktop-Clients und Verknüpfung mit dem lokal installierten Office.
Wenn man das in der "großen" Ausbaustufe fährt, geht das bis zu dem
Punkt, an dem es nichtmal mehr eine lokale Anmelde-Domäne braucht,
sondern der Nutzer sich mit den Credentials, mit denen er sich im Web
bei office.live.com anmeldet, auch in der Organisation an jedem
Windows-PC anmelden kann und seine Daten und Arbeitsumgebung zur Hand
hat, ohne dass diese Integration ein merklicher Mehraufwand ist. Dem
hat self-hosted FLOSS derzeit aus meiner Sicht leider absolut nichts
entgegenzusetzen. :(
> Was mich momentan stört ist das unkomplizierte "alles in die Cloud"
> verschieben ohne das die Folgen wirklich abgeschätzt werden.
> Wenn es wenigstens selfgehostet wäre
Das ist schwierig zu bewerten. Ich kenne in den Diskussionen viele IT-
Leute, die mit dem Verschieben in die Cloud prinzipiell auch nicht
glücklich sind, andererseits aber auch sehen: Vieles, was mit Cloud
geht, geht im Eigenbetrieb wirtschaftlich kaum noch. Anwendungen sind
extrem komplex. Du hast eine relativ große Bandbreite an Zeug in Deiner
Umgebung. Und Du hast immer zu wenig Leute.
Plakatives Beispiel: Ich stamme aus einer Organisation, die aus dem
Selfhosting kommt. Wir betreiben eine Fachanwendung für knapp 15k
registrierte Nutzer mit relativ hohen Verfügbarkeitsanforderungen.
Unsere eigene Anwendung haben wir trotz dünner Besetzung in der IT
(fünf Entwickler, knapp zwei Leute für Operations) recht gut im Griff.
Mit dem "Umsystem", das Du für Office, Service, Vertrieb, ... brauchst,
ist das schwieriger. Wir haben Redmine (als Ticket-System und Wiki
sowie für Urlaubsplanung und Zeiterfassung), NextCloud (für Kalender
und Filesharing) und hatten lang OpenFire als internen XMPP-Chat.
Und dann hast Du Situationen wie diese: Das Redmine hat einen
funktional kritischen Bug, den die Fachabteilung gelöst braucht. Die
Lösung dafür gibt es - aber die ist nicht trivial und erst in der
nächsten Major-Version verfügbar. Diese wiederum braucht die
nächsthöhere Major-Version von Rails, die wiederum eine sehr viel
neuere Ruby-Version benötigt, als Du in dem Debian stable - Server (mit
stabilen respektive hoffnungslos veralteten Paketen) aus den Repos
verfügbar hast. Zwar gibt es für neueres Ruby ein gesondertes Repo,
aber das macht Deinen apache/Passenger kaputt, den Du brauchst, um das
Redmine den Nutzern zu servieren. Und damit wird aus einer eigentlich
kleinen Aufgabenstellung eine große Nummer, in der Du Deine
Betriebsressourcen über mehrere Tage komplett "versenkst", weil Du
einen Plan erarbeiten musst, wie Du das Thema löst mit minimaler
Downtime (die Anwendung darf maximal einen halben Tag "offline" sein)
und minimalem Impact (Monitoring, Puppet, ... gehen von Debian stable -
Servern aus).
Und das passiert nicht einmal alle fünf Jahre, sondern einmal alle paar
Monate, mit verschiedenen Anwendungen. Dazu kommt eine schier
unübersichtliche Menge an Technologie-Stacks (wir haben/hatten Java für
unseren eigenen Kram, Rails/Ruby für Redmine, PHP+Apache für NextCloud,
und wenn Du Elastic Stack für Logging und gitlab für die Entwickler in
der Hand hast, willst Du gar nicht wissen, was dort alles an
Komponenten drin steckt). Das stemmst Du irgendwann nicht mehr, zumal
dann in Selfhosting ja auch noch Hardware und ein wenig sonstige
Infrastruktur (Mail-Server, Web-Dienste, ...) dazukommen. Docker und
Co. hat dort *etwas* geholfen, erhöht aber letztlich auch die
Komplexität für das gesamte System.
Und dann werden SaaS-/Cloud-Dienste ganz plötzlich interessant: Wir
sind mittlerweile mit Redmine bei easyredmine.com. Damit sind wir auch
in der Cloud, aber wir haben den gesamten Rails/Ruby-Stapel, den wir
nicht kennen und auch nicht kennen wollen, vom Schirm. Ich hätte das
System gern "unter unserer Kontrolle", aber der Aufwand dafür steht
leider in keinem Verhältnis...
> Es wird immer mehr in die Cloud verschoben und ich bin der Meinung,
> dass mal eindeutig geklärt werden soll, ob das wirklich zulässig ist.
Ja, das definitiv, das wäre mAn extrem notwendig. Dann wäre aber
möglicherweise auch der Ausweg ein anderer: Nicht zwingend "mehr
Selfhosting", sondern vor allem auch mehr Wettbewerb. Mehr lokale
Dienstleister. Vermutlich bräuchte es auch eine Trennungsforderung, die
untersagt, alle solche Leistungen aus einer Hand zu beziehen. Aber das
ist noch schwieriger durchzusetzen...
> Aber der nächste Kandidat, der versucht immer mehr die Kunden dazu zu
> drängen in die Cloud zu verschieben, ist SAP.
> Im Privatwirtschaftlichen Bereich angeblich sogar relativ
> erfolgreich. Irgendwann geben Sie vielleicht gar kein Support mehr
> für das Selfhosting.
> HR war wohl kurz davor...
SAP ist leider dasselbe: Eine verdammt komplexe Anwendung, die zu
betre
