Microsoft-Alternativen – Migration zu OpenSource-Technologien
Für eine große deutsche Forschungsgesellschaft entwickeln wir eine Migrationsstrategie von Microsoft 365 zu OpenSource-Technologien. Dabei geht es einerseits darum, die digitale Sourveränität zurückzuerhalten und andererseits erhöhte Sicherheitsanforderungen zu erfüllen. Dies soll nun unter Verwendung freier und quelloffener Software (FLOSS) erreicht werden. Insgesamt ähnelt das Projekt dem Microsoft Alternatives-Projekt (MAlt) des CERN und dem Projekt Phoenix von Dataport.
Die Grundsätze des Projekts sind:
- Allen Mitarbeiter*innen soll der gleiche Service geboten werden
- Vendor lock-ins sollen vermieden werden um das Risiko der Abhängigkeit zu verringern
- Die Daten sollen weitestgehend im Besitz der Forschungsgesellschaft bleiben
Dabei evaluieren wir für viele Services alternative Lösungen, implementieren Prototypen und Pilotprojekte.
Produktgruppe | Service | Product to evaluate | Status |
---|---|---|---|
Identitäts- und Zugriffsmanagement | LDAP | OpenLDAP | 🏭 Produktion |
Personal Information Management | Zimbra | 🚦 Evaluation | |
Kalender | Zimbra | 🚦 Evaluation | |
Kontakte | Zimbra | 🚦 Evaluation | |
Kollaboration | Dateiaustausch | NextCloud | 🏭 Produktion |
Office-Integration | NextCloud | 🚦 Evaluation | |
Direktnachrichten/ Chat | Mattermost | 🏭 Produktion | |
Videokonferenzen | Jitsi Meet | 🏭 Produktion | |
Suche | Suchmaschine | OpenSearch | 🚦 Evaluation |
Frontend/ Visualisierung | OpenSearch Dashboards | 🚦 Evaluation | |
Authentifizierung/ Zugriffskontrolle | Open Distro Security | 🚦 Evaluation | |
Nächste-Nachbarn Klassifikation | Open Distro KNN | 🚦 Evaluation | |
Projektmanagement | Aufgaben/Meilensteine | GitLab | 🚦 Evaluation |
Zeiterfassung | gitlabtime | 🚦 Evaluation | |
Dokumentation | GitLab Wiki | 🚦 Evaluation | |
Compliance-Management | Richtlinienverwaltung, Audit-Management | GitLab Compliance Management | 🚦 Evaluation |
Forschungssoftware [1], [2] | Paketmanager | Spack | 🏭 Produktion |
IDE | JupyterHub | 🏭 Produktion | |
Entwicklungsumgebungen | Jupyter Kernels | 🏭 Produktion | |
Software-Versionierung | Git | 🏭 Produktion | |
Datenversionierung | DVC | 🏭 Produktion | |
Erhebung und Speicherung von Daten | Intake | 🛫 Pilot | |
Tabellenkalkulation | ipysheet | 🏭 Produktion | |
Geodaten | PostGIS | 🏭 Produktion | |
Kartographische Daten | OpenStreetMap | 🏭 Produktion | |
DevOps | GitLab CI/CD Pipeline | 🛫 Pilot | |
Dokumentation | Sphinx | 🏭 Produktion |
Hosting-Strategie
Innerhalb der Forschungsgesellschaft gibt es im wesentlichen drei verschiedene Hosting-Varianten:
- Gesellschaftsweite Infrastruktur
- Infrastruktur, die institutsübergreifend von einem Großteil der Forschungsprojekte und Verwaltungen genutzt wird, soll von der zentralen IT der Forschungsgesellschaft bereitgestellt werden.
- Institutsweite Infrastruktur
- Infrastruktur, die für die speziellen Forschungsbereiche eines Instituts benötigt werden oder die IT-Unterstützung vor-Ort benötigen, sollen von der IT des jeweiligen Instituts bereitgestellt werden.
- Betriebs- und Georedundanz
- Diese werden im Wesentlichen durch Institutskooperationen oder durch Kooperationen einzelner Institute mit der IT der Forschungsgesellschaft hergestellt. Technologisch werden hierfür Floating IPs und das Virtual Router Redundancy Protocol (VRRP) verwendet wobei die Entscheidungen auf Basis von BGP-Announcements getroffen werden.
[1] | Für die Infrastruktur, auf der die Forschungssoftware entwickelt wird, gibt es ausführliche Dokumentationen, die unter der BSD-3-Clause-Lizenz veröffentlicht sind: |
[2] | Hier stellt das geplante einheitliche API eine deutliche Vereinfachung dar; siehe auch Announcing the Consortium for Python Data API Standards. |