- Client- und Mitarbeiterbetreuung inhouse, wobei einem da Baramundi bzgl. Softwarerollout, etc. hilft
- Serverbetreuung, Wartung, Bereitstellung inhouse (gesamte Landschaft)
- Betreuung der eigenen Virtualisierungsumgebung, derzeit noch VMware
- Installation und Einrichtung von MSSQL und Oracle DB auf Kundensystemen unter Windows Server inkl. Migration von Alt- auf Neusystemen und ggf. dabei anfallen Anpassungsarbeiten auf Clients
- je nach Kunde kann es sein das der Server erst zu uns kommt, von mir entsprechend vorbereitet, dann zum Kunde geliefert und von mir dann per Fernwartung das abschließende gemacht wird
- Einrichtung der Clients bei Kunden dahingehend, das unserer Software darauf genutzt werden kann
- Import Kundendatenbanken inhouse, damit die Softwareabteilung Problemanalyse etc. machen kann. (Import läuft von alleine aber Nacharbeiten, Ankündigungen, etc. nicht.)
- Netzwerk liegt glücklicherweise bei anderen, denn mit den Sachen hab ich schon genug um den Kopf.
Bei einzelnen Sachen noch externe DL mit im Boot, z.B. beim Domino-Server.
Bei AWS, Azure und Co stehend: Nichts. Microsoft 365 wird auch nicht genutzt.
Ist es ein Sysetmhaus, wo du arbeitest?
Hört sich irgendwie danach an.
Das ist auch dann ein Genickschuss, wenn die Internetverbindung Marke Klingeldraht ist und das ist häufig bei Entsorgungsunternehmen und Deponien der Fall, die gerne am Arsch der Welt liegen.
Das ist aber das Problem der Firma und nicht der Cloud als solche.
Schrems 3 steht noch aus und es ist offen, was unter einem President-elected Trump noch auf einen zukommt. Ansonsten fallen einem die Abhängigkeiten OnPrem dann auf die Füße, wenn es irgendein Abomodell ist.
Ich persönlich habe nichts gegen ein Abomodell und ich kann die Hersteller auch absolut verstehen, warum sie es machen. Das größte Problem ist, dass man im Laufe der Zeit X verschiedene Versionen der Software im Feld hat und diese Versionen muss man dann auch pflegen. Durch das Abo wird man als Kunde gezwungen die Software aktuell zu halten, quasi eine win-win Situation. Schon mal eine Software betrieben, die seit 10 Jahren End-on-life ist? Ich schon, das macht kein Spaß.
Auch in der Cloud ist es ja so, dass die Services permanent upgedatet werden. Einer der Gründe warum wir in OCI gehen ist unser Oracle Analytics Server. Das Ding upzugraden ist jedes Mal ein Projekt für ein halbes Jahr und da haben wir einfach kein Bock mehr drauf. Das gibt es in der Cloud, als Oracle Analytics Cloud, wird von Oracle betrieben und gewartet, wir laden nur unsere Modelle und Reports rein, erstellen die Verbindungen zu unseren OnPrem DBs und Abfahrt. Wenn ein Releasewechsel ansteht, kriegen wir gesagt, hey Freunde, testet euer Zeug auf der und der Umgebung und dann könnt ihr migrieren. Oder wir können auch einen Releasewechsel auslassen. Klar kostet der Spaß, aber ich muss nicht meine wertvolle Zeug mit Lifecyclethemen verschwenden. Zusätzlich können wir auch noch den Fachberei erziehen, dass die Software, die wir einsetzen eben Geld kostet und nicht "ist halt mal da" ist...
Da würde ich abwarten wie es sich entwickelt, da es abhängig von oVirt ist, was wiederrum Upstream von RHV ist, was von Redhat aber komplett abgekündigt wurde. Ersatz Seitens Redhat dafür: Openshift.
Dann eher Richtung Hyper-V, Proxmox oder XCP-NG mit Xen Orchestra schauen. Wenn man eine Citrix-Subscription hat, kann man auch Richtung Xenserver schielen.
Wir haben Oracle VM schon im Haus, aber in klein und die Leute kennen sich damit aus, da ist Kosten/Nutzen entscheidend.
Citrix-Dreck haben wir auch, leider. Ich (und ein paar andere Admins) nutze Citrix nur um auf meine Workstation zu kommen. Sprich am NetScaler anmelden (mit MFA über Azure) und dann per Xen auf meine Workstation, das funktioniert super und ist absolut stabil. Der "eigentliche" Citrix, also Apps ist der letzte Scheiss, meine Meinung.
OnPrem wurde aber viel noch selbst gemacht, man hatte Leute im Haus, die sich mit dem OS auskennen. Die können sowas dann mit entsprechendem Aufwand auch migrieren. Bei vielen Cloudanbietern kann man sich aber z.Bn ein ganzes OpenShift-Cluster mieten und muss sich dann z.B. nicht mehr um Netzwerk, OS oder Virtualisierung kümmern. Spart zwar Geld, aber wenn man die Experten nicht mehr im Haus hat, ist man gegenüber den Anbietern und deren Politik ausgeliefert.
Wie ich schon sagte, wenn man es "richtig" macht und man muss auch nicht alles selber machen.
Wir nutzen in Azure den k8s Cluster mit einzelnen Pods, wo unsere Software läuft, in Docker containisiert. Für sowas braucht man immernoch Leute, die sich auch mit dem OS auskennen, sonst kann man sowas auch nicht aufsetzen und betreiben, da gehört auch Netzwerk, Firewall, Security insgesamt dazu. Ist ja nicht so, dass man die Leute gar nicht mehr braucht, das ist ein Irrtum.
Mal eine Verständnisfrage als Laie: wozu sind Virtualisierungen eigentlich nützlich?
Das habe ich bis heute nicht richtig verstanden.
Eine effiziente und sinnvolle Ressourcenverteilung.
Ein Beispiel: du hast zwei Systeme, die unterschiedlich arbeiten, ein OLTP (wo tagsüber die Arbeit stattfindet) und ein DWH-System, wo nachts richtig die Post abgeht, aber tagsüber eher weniger benutzt wird, bzw. nur vom Fachbereich für irgendwelche Auswertungen.
Nun kannst du hergehen und sagen, für die OLTP Anwendung brauche ich mindestens 4 CPUs, und wenn die Ressourcen frei sind, dann halt mehr, und das über den Zeitraum X, also tagsüber. Für DWH brauche ich mindestens 16 CPUs, und wenn frei, dann gib ihm alle, die verfügbar sind, und das über den Zeitraum Y, also nachts.
Damit hast du sichergestellt, dass auch wenn DWH richtig Druck macht, die OLTP Anwendung immernoch geht.
So (naja, in etwa) nutzen wir es im Oracle Umfeld, das Zeug läuft auf IBM Power9 und dann halt auf LPARs.
Ist das eine andere Umgebung um da spezielle Software drin laufen zu lassen? Welche unter dem OS normal nicht laufen würde?
Das kann man damit auch machen. Wenn die Software bestimmte Versionen von irgendwelchen Libs und etc benötigt, dann kann man das in eine VM packen und dort laufen lassen, auch wenn man eine isolierte Umgebung braucht. Wobei da geht man eher in Richtung Container (also Docker beispielsweise).
