Warum bekommen es die Kultusministerien es einfach nicht hin mit den Schulclouds?
Mebis ist vor den Weihnachtsferien unter der Last der Nutzeranfragen zusammengebrochen. Das hat viele Nachfragen ausgelöst und Wasser auf die Mühlen derjenigen laufen lassen, die proprietäre Lösungen wie MS-Teams bevorzugen: „Siehste, die Kultusministerien bekommen es nicht auf die Reihe!“ Ich möchte in diesem Artikel einmal eine Lanze brechen für die Situation, in denen sich Fachreferate in Kultusministerien befinden und vor welchen Aufgaben sie stehen, wenn man wirklich eine Plattform landesweit zur Verfügung stellen möchte.
Shortread
- Fachpersonal mit IT-Kompetenz ist im öffentlichen Bereich rar. Wer hier etwas erreichen und kreativ oder pragmatisch sein möchte, muss oft Entscheidungen treffen und Menschen blind vertrauen, die er/sie zunächst nicht versteht. Man braucht Mut zum Handeln. Der wird aber nicht belohnt – schon gar nicht von der Öffentlichkeit (s.u.).
- Handelt man einfach und setzt um, kommen mit Sicherheit kritische Nachfragen zum Ausschreibungsrecht. Das ist momentan kaum einzuhalten. Bei den Summen, von denen wir reden, kommen wir zumindest mit dem Anspruch „landesweit“ immer in die europaweite Ausschreibung. Wenn man es ganz eng am Auschreibungsrecht macht, muss man offen ausschreiben und kann das spätere Produkt nur in Grenzen vorherbestimmen.
- Beachtet man das Ausschreibungsrecht, kommen mit Sicherheit kritische Nachfragen zum Thema Datenschutz. Der technisierte Schulbetrieb auf Distanz stellt ohne transparent und demokratisch verabschiedete gesetzliche Regelungen für manche Kritiker per se „einen schweren Grundrechtseingriff“ dar. Dass Schule, die gar nicht stattfindet, auch Grundrechte berühren könnte, ist bei den Nachfragenden oft nicht so entscheidend – auch nicht, dass beim Betrieb durch die öffentliche Hand Daten in der öffentlichen Hand verbleiben und Formalia im Prinzip nachgeholt werden könnten.
- Beachtet man das Ausschreibungsrecht und Datenschutzrecht kommen kritische Nachfragen zur Einbindung der Betroffenen in den Entscheidungsprozess. Die Berücksichtigung von Datenschutzaspekten schränkt technische Möglichkeiten erheblich ein. Die Lösungen, die dabei herauskommen müssen, werden fast zwangsläufig pädagogisch unbefriedigend sein.
Das kann man alles berücksichtigen und machen. Es dauert aber Jahre. Die Ministerien können also handeln und dafür öffentlich „auf die Fresse“ bekommen oder sie können die notwendigen Schritte für eine transparente und rechtsfeste Umsetzung gehen und für ihre Langsamkeit „auf die Fresse“ bekommen.
Ja, das hätte man ggf. weit früher in Angriff nehmen müssen. Hat man aber nicht. Dafür gibt es ja auch berechtigt „auf die Fresse“. Aber helfen tut das auch nicht gerade.
Der Ausweg: Man handelt jetzt systemlogisch m.E. oft gerade so, dass man sich nicht dem Untätigkeitsvorwurf aussetzen muss, aber auch nicht zu viel Geld versenkt, was man dann später verantworten muss. Das diese oftmals „Verlegenheitslösungen“ im Betrieb mit allen Schüler:innen nicht standhält, ist langfristig besser verantwortbar, als wenn man gleich sehr viel Geld investiert hätte. „Es waren halt die Umstände!“
Longread
Schauen wir uns mal Moodle an und tun wir so, als wollten für das landesweit ausrollen. Daran lässt sich ganz hübsch die gesamte Bandbreite an Herausforderungen zeigen:
Moodle ist erstmal so eine Art Programm. Eigentlich noch viel weniger. Es ist viel mehr ein Text mit vielen Anweisungen. Dieser Text muss von einem Übersetzer („Interpreter“) in etwas übersetzt werden, was ein Browser wie Firefox oder Chrome anzeigen kann. Das nennt man „Seitenquelltext“ und den kann man sich anzeigen lassen, wenn man auf einer Internetseite die rechte Maustaste drückt und „Seitenquelltext anzeigen“ auswählt. Dieser Seitenquelltext wird von einem weiteren, diesmal echten Programm („Webserver“) an den Browser bzw. Anwender ausgeliefert. Für das Prozedere braucht man primär einen schnellen Prozessor (CPU). Etwas Hauptspeicher (RAM) gehört auch dazu.
Damit Moodle Daten speichern und ausgeben kann, wird ein Datenbanksystem (DBMS) verwendet. Das ist ein Programm, welchen Daten sehr effizient speichern und i.d.R. noch viel effizienter wieder ausgeben kann. Das klappt besonders gut, wenn die Daten möglichst vollständig im Hauptspeicher (RAM) liegen. Selbst eine SSD ist deutlich langsamer beim Zugriff.
Große Dateien lassen sich nicht sinnvoll in einem Datenbanksystem ablegen. Moodle legt nur Verweise (Links) in seine Datenbank, die dem Moodlecode sagen, wo ein Bild oder eine PDF-Datei zu finden ist. Dateien werden in Storages gelagert. Für den RAM wären sie schlicht zu groß. Storages können SSDs (teuer) oder normale Festplatten (günstig) sein. Moodle verschlüsselt aber seine Dateien. Zum Ver- und Entschlüsseln braucht man wiederum CPU-Leistung. RAM zum Ausliefern braucht man verhältnismäßig wenig, da Dateien in kleinen Portionen und nicht vollständig verschickt werden.
Wenn man Moodle selbst aufsetzt, wird man i.d.R. sowas bauen:
Alle drei Komponenten laufen auf dem gleichen Server und konkurrieren dann um CPU, RAM und Storage. Man kann für 50,- Euro Server mieten, die für 800‑1000 Schüler:innen ausreichen. Allerdings kommt es sehr stark auf die Nutzung an: Wenn man vorwiegend Kurse baut, in denen lediglich Aufgaben und PDFs koexistieren, klappt das spielend. Die dazu nötigen Abfragen sind harmlos. Wenn aber z.B. das Testmodul oder der Chat exzessiver genutzt werden, kann es schnell aus sein mit der Freude an der tollen Funktion. Dann muss man den nächstgrößeren Server kaufen oder herumoptimieren (mehr als 15–20% holt man damit aber nach meiner Erfahrung nicht raus).
Ich bin davon überzeugt, dass alle Installationen von Moodle auch auf Landesebene genau so angefangen haben: Erst mal einen Testserver aufsetzen und schauen, wie der Betrieb so läuft.
Das Spiel „Hardware upgraden“ ist aber irgendwann zu Ende: Wenn viele Anfragen hereinkommen, startet der Webserver mehr Interpreter. Diese produzieren dann mehr Anfragen an das Datenbanksystem. Und sie belegen mehr RAM.
Der Moodleserver fängt an zu sterben, wenn die Daten aus der Datenbank nicht mehr in den Hauptspeicher passen. Dann kommen diese Daten auf die langsame Festplatte. Dadurch stauen sich Anfragen, die das DBMS unter normalen Umständen spielend bewältigt hätte und immer mehr Interpreter müssen warten und werden nicht beendet. Wenn RAM und Auslagerungsspeicher voll sind, werden die Überlebensinstinkte des Betriebssystems geweckt. Dieses beginnt nun damit, Interpreter zu beenden, um wieder RAM frei zu bekommen. Die Anfragen an diese Interpreter laufen nun ins Nirwana und es geht für den Nutzer entweder ins Nirwana (Connection timed out) oder mit einem letzten Lebenszeichen in den Kurort (500 – Bad Gateway). Ein Absturz ist das technisch gesehen nicht. Das System selbst funktioniert ja noch, tut aber nicht das, was es soll.
Was tun?
Eine simple Möglichkeit besteht darin, die Arbeit einfach auf mehrere Server zu verteilen. Das geht mit diesem einfachen Verfahren, wenn Schulen jeweils eigene Moodlesysteme erhalten sollen,
Wenn man merkt, dass ein Server überlastet ist, schiebt man die entsprechende Schule einfach auf einen neuen. Man kann auch Schulen, die nicht viel Last erzeugen, mit mehreren anderen auf einen Server packen. Kommen neue Schulen, kauft man neue Server dazu.
Ich baue davor gerne noch einen Proxy. Ein Proxy speichert Seiten, die schon einmal von Moodle gebaut worden sind in seinem Speicher als Kopie. Wenn ein Anwender wieder genau diese Seite anfordern, muss man nicht den Moodleserver selbst damit behelligen. Die einzelnen Moodleserver machen dabei immer noch alles gleichzeitig: Moodlecode + DBMS + Storage.
Für so ein Setup muss man erheblich mehr können als beim ersten. Vor allem beim Überwachen der Server. Und man sollte z.B. das Verschieben einer Schule auf einen anderen Server tunlichst automatisieren. Sich einen Rootserver mieten und mit einem Verwaltungstool Moodle zu installieren reichen dann nicht mehr. Trotzdem ist das Setup sehr simpel, da die Moodlesserver für sich selbstständig arbeiten. Den Proxy kann man z.B. durch Failover-IPs im Notfall als „single point of failure“ automatisch eliminieren.
Ich wette, dass auch auf Landesebene das oft die erste Eskalationsstufe ist, weil man solche Setups selbst als Laie noch mit eigenen Mitteln hinbekommt.
Mebis hat noch mehr Probleme
Mebis ist eine zentrale Installation. Es gibt keine Segmentierung in Einzelmoodlesysteme für Schulen. Wildes Herumgeschiebe der Schulen ist nicht möglich. Also muss man noch eine Schippe Komplexität drauflegen und jetzt wirklich skalieren.
Man trennt jetzt keine Moodlessysteme – das geht ja auch gar nicht. Man trennt die einzelnen Komponenten wie Moodlecode, DBMS und Storage auf. Man kann dadurch die einzelnen Server auf ihre Aufgabe hin optimieren. Für den Moodlecode viel CPU-Wumps, für die Datenbank viel Speicher. Und man kann Read-Only-Datenbanken vorhalten, aus den nur gelesen wird. Schreiboperationen bei Moodle sind vergleichsweise gering. Ein diesmal richtiger Loadbalancer entscheidet je nach Auslastung der CPU-Nodes, wohin die Anfrage geht. Wenn es nicht reicht, stellt man neue Server dazu. Wenn man es gut macht, beliebig viele. Für ein ganzes Bundesland wird man das über Rechenzentrumsgrenzen hinaus machen müssen. Und die Server müssen untereinander durch schnelle Verbindungen vernetzt sein. Die Daten müssen ja unter den DBMS- und Storage-Servern schnell aktualisiert werden Monitoring bleibt Pflicht. Und Backups. Und Desaster-Recovery.
Durch Automatisierung kann man schnell reagieren. Große Anbieter wie itslearning dürften vergleichbare Setups fahren und selbst die haben sich bezüglich der Anfragemenge beim Wechsel ins Schulszenario C offenbar stellenweise verkalkuliert.
Microsoft und Google stellen aller Wahrscheinlichkeit nach nicht mal mehr eigene Server für solche Aufgaben hin. Das wird so ziemlich alles in wirklich großen Rechenzentrum mit abertausenden von Maschinen virtualisiert sein. Bei einer drohenden Überlastung „bläst“ sich das System dann automatisiert auf.
Das Problem der Ausschreibung
Das letzte Setup kann man nicht durch eine beschränkte Ausschreibung (drei Vergleichsangebote) bekommen. Da geht es um mehr Taler. Das Teure ist weniger die später Skalierung (der Zubau an Servern). Das Teure ist der Gehirnschmalz, der in die Konzeption fließen muss. Schon für die Ausschreibung braucht man für das Lastenheft immense technische Kenntnisse. Wer bei der Konzeption einer Ausschreibung mitwirkt (und so jemanden wird man brauchen), darf übrigens später nicht mehr mitbieten.
Schon ein kleines Setup wird dadurch immens teuer. Rechnen tut sich eine solche Vorbereitung nur bei späteren Wachsen in die Breite. Daher wird man erst schlicht das Geld dafür nicht bekommen. Und wenn man es krisenbedingt dann doch bekommt, sind die Anbieter und IT-Spezialisten, die so etwas hochziehen könnten, auf wunderbare Weise mit Aufträgen ausgelastet.
Das ist Menschen mit begrenztem technischen Know-How nicht vermittelbar. Oder – wäre Corona nicht gekommen – wäre man in der Presse bitterböse verprügelt worden, dass man so viel Geld für ein so kleines Setup verballert hat.
Was wesentlich leichter daherkommt, ist die Ausschreibung eines spezifischen Produkts wie z.B. Microsoft Teams. Dafür dürften sogar extra Berater / Lobbyisten von Microsoft oder Apple oder … ins Haus kommen, die die Ministerien bei der Erstellung einer sachgerechten Ausschreibung „unterstützen“. Um das Ausschreibungsrecht einzuhalten, müssen das strenggenommen Mitarbeiter:innen einer „Tochter“ des Großunternehmens sein (s.u.).
Und natürlich ist diese Variante für die Fachreferate der Kultusministerien attraktiv!
Das Datenschutzproblem
Das einzige mir bekannte System, das in Zusammenarbeit mit einem Landesdatenschutzinstitut entwickelt worden ist, ist die niedersächsische Bildungscloud (NBC). Über die dadurch verbleibende Funktionalität mag sich jeder selbst ein Bild machen. Die NBC bzw. die darunterliegende HPI-Schulcloud ist unter starkem Beschuss hinsichtlich der Finanzierung – Ausschreibungsrecht halt.
Bei großen us-amerikanischen Anbietern ist die Datenschutzproblematik oft noch nicht geklärt. Schlägt ein Kultusministerium hier zu, gibt es öffentlichen Unmut. Deswegen ist der Datenschutz der erklärte Feind derjenigen, die schnell handeln und ebenso schnell zu einem funktionsfähigem System kommen wollen. Auf deren Seite stehen zurzeit viele Anwender, deren Anforderungen man eigentlich oft so zusammenfassen kann: „Wenn eine öffentlich finanzierte Cloud mir nicht das bieten kann, was mir MS-Teams bietet, dann ist sie nichts!“ Spoiler: Systeme, die den Datenschutz berücksichtigen, können das rein formal schon nicht.
Die „Gefahr“, die von großen Anbietern ausgeht, ist eine noch sehr abstrakte – wie etwa die Aussicht auf die zweite Coronawelle im August für die meisten Kultusministerien. Es ist absolut nicht abzuschätzen, was uns da bei der Verwendung von Schüler:innendaten durch das Silicon-Valley noch bevorstehen könnte. Das Vertrauen in reine Lernplattformanbieter ist da noch gefühlt größer – die werden ja auch niemals an Investoren verkauft werden, oder? Bei komplett offenen Systemen wie z.B. Moodle hat man als öffentliche Hand die volle Kontrolle und alle Probleme und Herausforderungen gegen sich.
Das Beteiligungsproblem
Gegen Anwender:innen, die eine Lösung mit ihren Features gewohnt sind, lässt sich schwer etwas durchsetzen, was technisch einen Rückschritt darstellt. Lehrmanagementsysteme sind hier viel besser geworden, aber eben immer noch nicht richtig gut. Außerdem gibt dann noch Leute wie mich, die große Schwierigkeiten mit Lehrmanagementsystemen haben. Apple, Microsoft, itslearning, die NBC und Moodle sind deshalb so erfolgreich, weil sie Schule so abbilden, wie Schule ist: Die Lehrkraft gibt die Strukturen bis hin zu „Laufwegen“ (Lernpfade) vor, die die Schüler:innen dann entlanglaufen. Man kann Lehrmanagementsysteme anders nutzen – nur braucht man sie dann eigentlich nicht mehr.
Onenote kann das gute, alte Schulheft technisch am allerbesten imitieren und zudem alle Hefte immer für die Lehrkraft verfügbar machen. Ob letzteres ein Vorteil ist, müsste man noch diskutieren. Für mich gibt nicht viel Übergriffigeres als ein Blick auf alle Bildschirme z.B. via Apple Classroom. Aber das entspricht den Anforderungen, die an Apple herangetragen werden.
Anwender:innen sind oft in Verbänden organisiert. Ein Verband ist immer das Gegenüber des Kultusministeriums bei Benehmensprozessen. Die Mitglieder werden gerade im Bereich der Anwendung digitaler Technologie extrem heterogen sein. Herzlichen Glückwunsch bei der Konsensfindung.
Das Qualifizierungsproblem
Um eine Schulcloud sinnvoll nutzen zu können, muss man in der Anwendung digitaler Werkzeuge kompetent sein. Lassen wir diesen Punkt lieber. Der Artikel ist eh schon zu lang.
Fazit
Schulclouds in der öffentlichen Hand zu entwickeln war auch schon vor Corona nicht so einfach. Die Kompromisslösungen können dem jetzigen Ansturm nicht gewachsen sein und auch nicht problemlos und unbürokratisch aufgepustet werden. Wenn ich ein Kultusministerium mit der Aufgabe einer schnellen Umsetzung beraten müsste, würde ich zu einem Fertigprodukt raten.
Formal sind viele Fachreferate in den MKs fit. Der Weg zu einem Lehrmanagementsystem in der öffentlichen Hand ist mehr als steinig: Technische Expertise, Ausschreibungsrecht, Beteiligungsverfahren – alles viel einfacher mit Lock-in-Lösungen, wie es Teams, itunes oder auch Webweaver oder itslearning oder <beliebiges Lehrmanagementsystem> nunmal so sind.
Moodle ist eine echte Ausnahme, weswegen ich den bayrischen Weg mit Mebis persönlich absolut klasse finde. Muss jetzt halt technisch nur noch laufen. Wenn es die Bayern nicht schaffen, ist die Weltordnung nicht nur in der Bundesliga außer Kraft gesetzt.
This work by Maik Riecken is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International
Pingback: mebis und Teams - (k)ein Vergleich - Gedanken aus der Schule
Toller Beitrag! Vielen Dank für die Hintergründe und die sachlichen Informationen!
Wenn man denn irgendwann vielleicht mal die technischen Probleme beiseite geschafft haben sollte würde es mich als Lehrer noch freuen, wenn moodle/mebis auch endlich wirklich zukunftsorientiert betrieben werden würde. Ich denke da an eine vollumfängliche App, intuitivere Kommunikationsformen (ein viel besserer Chat, einen Feed statt ein Forum), Stift-Integration (du hattest ja das Beispiel OneNote erwähnt). Für LehrerInnen mag die Gestaltung von Kursen in moodle ja supertoll und modern sein, aber SchülerInnen kann man halt weder mit Foren im Stil der 2000er locken noch mit einer Plattform, die nur im Browser wirklich gut läuft und allein vom Design her schon schreit „Ich bin eine Schullösung“.
Vielen Dank für diesen herausragenden Artikel! Selten die technische und die vergaberechtliche Seite so schön auf den Punkt gebracht gesehen.
Meine Frage: Was spricht gegen „Moodle-per-Schule“?
Ich stelle mir das so vor: es gibt eine fertige Kiste, die man sich als Schule von einem Anbieter XYZ konfigurieren und in den Keller stellen lässt. Schüler-/Lehrerdaten aufgespielt und das Ding sollte laufen. Oder?
Datenschutz: check. (Alle Daten im Keller der Schule)
Auschreibung: check(?) (Auftrag im Umfang von x.000EUR bis x0.000EUR)
Technik: check. (< 2000 User, d. h. load balancing und größere Komplexität ist hinfällig)
Wartung: check. (Vertrag mit Anbieter XYZ)
Und: es muss ja nicht unbedingt moodle sein (und in 2021 auch nicht unbedingt php). Niemand wird sich beschweren, wenn ein Moodle-Ersatz weniger komplex zu bedienen ist und dafür eine poliertere Oberfläche hat.
Was wünschenswert wäre: dass der moodle-Ersatz open source wäre. Dann gäbe es an der Stelle (Code-Seite) datenschutz-/vergabe-rechtlich weniger (keine?) Probleme. Wenn die KMs für ein paar Stellen, Vereine oder Stiftungen Geld locker machen würden, sollte das doch zu schaffen sein. Oder bin ich da übermäßig optimistisch? Moodle wurde, soweit ich weiß, zuerst von einer Einzelperson ins Leben gerufen und itslearning von Studenten. Und man blicke nach BaWü: linuxmuster – 2003 initial vom KM finanziert – existiert bis heute.
Technisch macht das Fa. IServ aus Braunschweig mit Ihrer Schulnetzwerklösung so. Das klappt, weil sowohl die Hardware als auch die Serverwartung zentral durch die Firma erfolgt. Das kann man keiner Schule aufbürden. Bei Moodle und auch jeder anderen Plattform gilt es, Updates zeitnah zu prüfen und einzuspielen – dabei kann immer viel schiefgehen. Da lässt sich kaum ein Anbieter drauf ein.
Ein weiteres Problem sind die Internetanbindungen der Schule. Als Faustformel sollten es je 500 SuS schon so um die 1Gbit/s symmetrisch sein.
Der dezentrale Ansatz hat seinen Charme. Leider driften Menschen mit und ohne IT-Kompetenz immer mehr auseinander in ihrem Wissen und sind in der Fläche nicht in der benötigten Anzahl vorhanden.
Auch deswegen wandert ja viel „in die Cloud“. Dort glaubt man, IT-Kompetenz und Hardware zusammenziehen zu können – bietet aber auch ein viel lohnenderes Ziel für Angriffe als dezentrale Netzwerke. Auch Datenabflüsse und Störungen betreffen immer alle Nutzer:innen.
Hallo zusammen, auch meinerseits vielen Dank an Maik für den ausführlichen, erhellenden und ermutigenden Beitrag! Bzgl. der Frage, ob nicht alternativ zum zentralen Ansatz jede Schule ihre eigene Moodle-Instanz bekommen sollte: Beim initialen Aufbau von mebis war diese Option neben weiteren Varianten durchaus im Blick. Allerdings bestand als weitere wichtige Anforderung die Möglichkeit eines optionalen Zugriffs durch SchülerInnen und Lehrkräfte (etwa über Nutzung eines Einschreibeschlüssels) auf Kurse anderer Schulen z. B. im Rahmen von Kooperationen. Nicht zuletzt war es diese Anforderung, die nach fachlicher Beratung und Abwägung aller Pros und Cons (im Jahr 2012) zur Entscheidung einer zentralen Instanz aller Schulen führte.
Du schreibst
‚„Wenn eine öffentlich finanzierte Cloud mir nicht das bieten kann, was mir MS-Teams bietet, dann ist sie nichts!“ Spoiler: Systeme, die den Datenschutz berücksichtigen, können das rein formal schon nicht.‘
Mit sind Datenschutz-Bedenken gegen im nicht-EU-Ausland gehostete Dienste bekannt, und auch gegen einen Mutterkonzern in den USA, aber gibt es grundlegendere Bedenken gegen einen Clouddienst wie MS Teams?
Mit anderen Worten, wenn ein EU-Konzern in EU-Rechenzentren eines EU-Public-Cloud-Anbieters einen mit MS Teams konkurrierenden Dienst betrieben würde, gäbe es da noch andere Datenschutz-Probleme?
Annahme:
Jemand baut sowas wie MS-Teams, unterliegt vollständig europäischem Recht und hostet ISO-zertifiziert in Europa und liefert rechtskonforme ADV und alles mit.
Funfact:
Das macht z.B. die niedersächsische Bildungscloud. Aber Landesdatenschutzbeauftragte nehmen einzelne Funktionen trotzdem immer noch sehr genau unter die Lupe. Nur unter wirklich ganz engen Voraussetzungen und mit zig Einwilligungen und einer definierten Zweckbestimmung dürftest du als Schule unter den jetzigen gesetzlichen Rahmenbedingungen es etwa Schüler:innen ermöglichen, sich untereinander oder gar mit Schüler:innen anderer Schulen zu vernetzen (Dokumente teilen etc.).
Die gesetzlichen Grundlagen, die die DS-GVO hier „öffnen“ gibt es noch nicht.
Microsoft Cloudservices in Europa werden von der Telekom gehostet. Unser Anwalt hat hat geprüft und alles für DSVGO konform erklärt… Ich finde Teams Perfekt für Schulen und mit Active Diretory habe ich auch noch ein sinnvolles Rechtmanagement. Groups muss ich dann noch In Klassen und Projekte in Fächer unebnennen dann geht es aber ganz gut :)
Vielen herzlichen Dank für die Zusammenstellung. Sie sprechen sehr viele wichtige Aspekte an, die mich seit Jahren ärgern und ich leider auch keine Lösung kommen sehe.
Ich habe zu Mebis einige Zahlen im Kopf, allerdings muss ich zugeben, dass ich nicht mehr weiß, woher sie kommen und überhaupt, ob sie stimmen, da ich sie jetzt auch nicht nachkontrolliert habe. Ich denke, dass ich die Zahlen aus der Tagespresse habe.
Es waren bis vor der schweren Auslastung die Dienste auf 4 VServern verteilt. Soweit, so gut. Die Zugriffe waren verhältnismäßig niedrig und v.a. auch über den Tag verteilt (v.a. auf den Nachmittag).
Es wurden dann wegen der zusätzlichen Belastung 4 weitere Server dazugeschaltet, was grundsätzlich für Entlastung, aber eben leider auch Belastung des Systems geführt hat. Denn eine vernünftige Lastverteilung ist keine simple Sache, die man nebenbei löst und v.a. dann nicht, wenn gewisse serveradministrative Vorstrukturierungen nicht von Anfang an mitgedacht wurden. Ein laufendes System umzustrukturieren klappt nur, wenn man alles abschaltet und neu aufschaltet. On the fly geht da gar nichts! Und genau an dieser Stelle ist die Expertise, die Sie ansprechen von entscheidender Bedeutung.
Aus meiner Sicht scheitert Mebis an drei Stellen:
– Es wurde mehr Aufwand in ein schickes Gewand gesteckt, da die Entscheidungsträgen von der dahinterliegenden Technologie keine Ahnung haben, aber bei den Klickdemos begeistert sind. Layout ist aber nur eine Verschleierung (dennoch wichtig!)
– Die Technologie von Mebis ist leider noch aus der Zeit von PHP5. Web2.0 Aktivitäten sind vorhanden, aber das ist einfach alles andere als gängige Praxis. Man vergrault so mehr Nutzer, weil sie das Gefühl haben, dass das Tool nicht funktioniert. (warum klicke ich ein Icon am Smartphone an und es funktioniert und Mebis bekommt ‚gefühlt‘ einfachere Sachen nicht hin?)
– Die von Ihnen gestellt Serverfrage: Hier hat sich die Entwicklung auch in eine ganz andere Richtung bewegt. Cloudsysteme, statt verteilten Einzelservern ist die Lösung. Hier werden bedarfsgerecht CPU, RAM und sonstige Komponenten zugeschaltet. Aktuell mit riesigen Peaks gegen 8.00 und genau diese sekundengenau Abrechnung ist aber wohl der Knackpunkt und wird damit niemals flächendeckend kommen, sofern rechtliche Voraussetzungen nicht gegeben sind.
Das Thema „Mit der Cloud wird alles besser“ ist ein für mich recht nerviges. MS-Teams skaliert nicht deswegen gut, weil es „in der Cloud ist“. Es skaliert deswegen gut, weil viel Gehirnschmalz in den Aufbau einer Skalierung hineingeflossen ist. Die Cloud ist ja nichts großartig anderes als ein Verbund vieler Rechner – heute mit virtuellen Maschinen oder Microservices. Diesen Gehirnschmalz müsste man auch in Moodle „pressen“ – dann könnte sich das „in der Cloud“ genauso gut aufpusten wie MS-Teams. Teams hat das bloß schon.
Touchibuntioberflächen können einfaches tatsächlich leichter und anwenderfreundlicher. Ein Apple-Lernartefakt sieht aber immer aus wie ein Apple-Lernartefakt, weil die jeweilige App bzw. der zugehörige Programmierer den Rahmen setzt. Und Moodle läuft schon sehr lange nicht mehr auf PHP5.x :o)… Für mich sind GUIs oft absolut ineffizient und zeitfressend. Aber für Menschen am Anfang einer IT-Erfahrung sind sie wichtig. Gleichzeitig wecken sie aber auch Erwartungen: „Es muss immer so sein wie bei …“ Zu wissen, wie man bei Word eine Fußnote klickt, ist eine schnell veraltende Information. Zu wissen, wie Fußnoten eingesetzt werden und wie man sich diese Funktion in unterschiedlichen Programmen erschließen kann, ist eine Kompetenz. In der Arbeitswelt kann ich mir nicht aussuchen, was mir der Arbeitgeber vorsetzt (das wird ganz oft nicht Teams sein …). Aber auch das ist ein weites Feld.