   | | Souveräne Clouds ohne Vendor Lock-in +++ Strategien zum Cloud-Exit +++ Moderne SAP-Entwicklung +++ IT-Recht 2024 +++ Ceph: Tipps aus der Praxis
|
| |
|
| Liebe Leserin, lieber Leser,
|
| wie viel mussten Sie dieses Jahr für Cloud-Dienste ausgeben? Dass die meisten Unternehmen (zu) viel für AWS, Azure & Co. bezahlen, wird ihnen oft erst klar, wenn es zu spät ist. Dabei gibt es durchaus Wege zurück aus der Kostenfalle Cloud, wie Titelautor Martin Loschwitz im Interview erklärt. Einen Überblick aller Themen des neuen Hefts finden Sie im Inhaltsverzeichnis der iX 1/2024.
| |
|
|
| |
|
|
| | | | Cloud: Absichtlich eingesperrt | |
| |
| |
Martin Gerhard Loschwitz ist freier Journalist, Trainer und Consultant rund um die Themen OpenStack, Ceph, Kubernetes und alles, was daran angrenzt.
Moritz: Viele Firmen gehen in die Clouds von Microsoft, AWS und Google. Sie wollen Kosten sparen und stellen dann fest, es wird teurer – oft sehr viel teurer – als gedacht. Woran liegt das und warum weiß man das nicht vorher?
Martin: Dafür gibt es etliche Gründe. Zunächst nutzen viele Unternehmen zwar die angebotenen Werkzeuge zur Kostenkalkukation, gehen bei ihren Berechnungen aber von zu wenigen benötigten Ressourcen aus. Schon die gebuchten Ressourcen schlagen oft also mit mehr Geld als erwartet zu Buche – auch, weil in Clouds einzelne Faktoren wie die Nutzung bestimmter Dienste wie Cloud Load Balancing (LBaaS) verschiedenste Faktoren verrechnen, das aber über das Portfolio des Anbieters hinweg nicht einheitlich ist. Manche Ressourcenarten verrechnen Traffic, andere beziehen eher die Anzahl von Anfragen über einen bestimmten Zeitraum ein. Wer nicht viel Erfahrung hat, vergisst also oft einzelne Posten und erlebt dann ein böses Erwachen.
Deutlich unterschätzt wird zudem die Arbeit, die regelmäßig nötig ist, um bestehende Set-ups in der Umgebung lauffähig zu halten, nachdem der Anbieter Änderungen vorgenommen hat. Einige Unternehmen verlassen sogar die Cloud wieder, weil umfangreiche CI/CD-Pipelines so viele laufende Kosten verursachen, dass der Betrieb auf eigener Hardware mit weniger Automation billiger wäre. Auch dieser Faktor ist im Vorfeld aber nur sehr schwer zu kalkulieren. Und je nach seiner Höhe stellt man dann möglicherweise sogar fest, dass die gesamte Kalkulation für den Ausflug in die Cloud hinfällig ist.
Moritz: Warum wird ist es oft so aufwendig und kostspielig, den Anbieter zu wechseln oder wieder ganz oder teilweise auf eigene Infrastrukturen zu gehen?
Martin: Jeder Hyperscaler hat ein Interesse daran, Kunden auf der eigenen Plattform zu behalten. Deshalb hantieren AWS & Co. mit klassischen Lock-in-Effekten. AWS CloudFormation, AWS EKS, die enthaltenen Monitoring-Werkzeuge und viele weitere Komponenten sind hochspezifisch für Amazon AWS konzipiert. Azure und Google machen das auch nicht anders. Das Problem ist also: Sind die eigenen Prozesse etwa auf AWS hin optimiert, käme der Wechsel zu einem anderen Anbieter regelmäßig einem weitgehenden Rewrite des Lifecycle-Managements der eigenen Anwendung gleich. On Premises steht zudem oft gar keine Cloud zur Verfügung, die Dienste wie LBaaS anbieten kann. Die entsprechenden Dienste sind dann durch eigene Werkzeuge zu ersetzen, was auch wieder Entwicklungsressourcen verschlingt.
|
| |
|
|
| |
|
| |
|
|
| | Martin Gerhard Loschwitz (links) im Gespräch mit iX-Redakteur Moritz Förster.
|
|
| |
|
| |
|
| | Moritz: Welche Techniken sollten Unternehmen am besten einsetzen, damit der Ausstieg gelingt?
Martin: Ganz generell hilft es, wenn man bereits bei der Entwicklung eigener CI/CD-Umgebungen darauf achtet, generische Werkzeuge wie Terraform zu nutzen. Diese bieten eine interne Abstraktion, sodass der Admin etwa nur festlegen muss, dass ein Loadbalancer zu starten ist. Auf AWS, Azure oder GCP nutzt das Werkzeug dann die jeweils angebotene Ressource der Plattform. Damit lassen sich bereits einige Probleme umgehen – etwa auch das zuvor schon beschriebene Problem, die eigene Automation auf Stand mit der Plattform zu halten. Denn im günstigsten Falle genügt es in einer solchen Situation, das Deployment-Werkzeug, etwa Terraform, auf eine neue Version zu heben, die mit den veränderten Anforderungen der Cloud zurecht kommt.
Ansonsten gelten die üblichen Hinweise: Je generischer eine Umgebung konzipiert ist, desto größer ist die Wahrscheinlichkeit, dass sie gut von einer Plattform in eine andere Umgebung zu verschieben ist. Dann lässt sich mit wenigen Handgriffen ein Proof-of-Concept-Setup (PoC) in einer anderen Umgebung etablieren, bei dem bloß noch die Daten zu migrieren sind. Wer hier eine gängige Datenbank nutzt, macht sich ebenfalls das Leben leichter. Kommt hüben wie drüben etwa MySQL zum Einsatz, ist die Migration mit Werkzeugen wie mysqldump gut schaffbar.
Moritz: Nicht nur die Kosten, auch die Sicherheit der Daten vor den neugierigen Augen Dritter treibt die IT-Verantwortlichen um. Souveräne Cloud-Angebote versprechen hier die Einhaltung der DSGVO und anderer strengen Regeln. Aber können solche Anbieter überhaupt technisch mit den Hyperscalern mithalten?
Martin: Das können sie in der Regel nicht, müssen sie aber meistens auch gar nicht. Das AWS-Portfolio umfasst hunderte Dienste, trotzdem nutzt der größte Teil von Kunden nur EC2, EBS, CloudFormation, S3 oder LBaaS – und ist damit weitgehend zufrieden. Das typische Pareto-Prinzip: 20 Prozent der Funktionen machen 80 Prozent der Kundschaft glücklich. Die restlichen 20 Prozent zu erschließen ist teuer und aufwändig und übersteigt die finanzielle Leistungsfähigkeit vieler gerade kleinerer Firmen erheblich. Dieser Rest wird letztlich aber so oder so bei einem Hyperscaler landen, oft weil die Anforderungen so spezifisch sind, dass nur AWS & Co. sie realistisch zu befriedigen vermögen. Kleinere Firmen geraten hier schnell in eine Sunk-Cost-Fallacy – sie werfen also schlechtem Geld immer mehr gutes Geld hinterher, um einen Wettlauf zu gewinnen, den sie gar nicht gewinnen können.
|
| |
| |
|
|
| |
|
| |
|
|
| | | | Im Heft geschmökert: Empfehlungen der iX-Redaktion | |
| |
|
| |
| | | | Der letzte Teil des Selbst-Hacking-Tutorials zeigt, wie man mit kostenfreien Open-Source-Tools ein Selbst-Audit von Cloud-Diensten durchführen und unsichere Standardeinstellungen sowie weitere Fehlkonfigurationen finden und beseitigen kann. Ich finde es immer wieder faszinierend, dass man mit wenig Kosten und relativ geringem Aufwand sein Sicherheitslevel deutlich steigern kann – wenn man nur will und einem die Problematik bewusst ist. Daher kann ich nicht nur den Cloud-Teil des Selbst-Audits empfehlen, am besten man nutzt die Weihnachtsferien für die Lektüre aller Teile.
– Ute Roos, iX-Redakteurin
|
| |
|
|
|---|
|
| |
|
| |
|
| | | | Die Sprache Elm ist vor allem durch das nach ihr benannte Architekturkonzept Model - View - Update bekannnt, sie eignet sich aber auch als JavaScript-Alternative. Auch wenn Elm keinen direkten Zugriff auf JavaScript bietet, wie es andere Programmiersprachen ermöglichen, garantiert es einen laufzeitfehlerfreien Ablauf. Es nutzt dafür definierte Schnittstellen zur Außenwelt und zu JavaScript. Der Artikel gibt einen Überblick darüber, wie Elm-Code und JavaScript zusammenspielen und miteinander kommunizieren.
– Nicole Bechtel, iX-Redakteurin
|
| |
|
|
|---|
|
| |
|
| |
|
|
| | | | iX-Workshops vorgestellt | |
| |
| |
In einem agilen Geschäftsumfeld ist es wichtig, Geschäftsprozesse kontinuierlich zu untersuchen, Engpässe zu erkennen und Abläufe zu optimieren. Mit der datengestützten Prozessanalyse durch Process Mining steht hierfür eine leistungsfähige Methode zur Verfügung. Der Workshop stellt diese Methode vor und zeigt, wie man mit Tools und Analysetechniken Daten aufbereitet, analysiert und daraus den tatsächlichen Prozessablauf abbildet, um daraus Maßnahmen für die Geschäftsprozessoptimierung abzuleiten.
|
| |
| |
|
| |
|
| |
|
|
| | | | Weitere Themen in der iX 12/2023 | |
| |
| |
2024 stehen Unternehmen zahlreiche IT-Regulierungen ins Haus. Wir schlüsseln auf, was Sie bei der NIS2-Richtlinie und dem Cyber Resilience Act beachten müssen und wie sich das Digitale-Dienste-Gesetz sowie das Energieeffizienzgesetz auf Ihr Geschäft auswirken. Außerdem zeigt das neue Heft, wie Sie zukunftsfähige Erweiterungen für SAP entwickeln und gibt Praxistipps für Ceph. Alle Themen finden Sie im Inhaltsverzeichnis der iX 1/2024.
Haben Sie Anregungen zum Newsletter oder zum Heft allgemein? Schreiben Sie mir unter fo@ix.de! Ich wünsche Ihnen eine gesegnete Weihnachtszeit, Ihr
|
|
| |
|
| |
 | | Neugierig geworden? Sie erhalten die iX 1/2024 ab dem 20. Dezember im heise Shop und ab dem 22. Dezember am Kiosk:
|
| |
| |
| |
| Diese E-Mail weitergeleitet erhalten?
|
| |
|
| |
|
| |
|
| Sie sind unter folgender Adresse eingetragen: unknown@unknown.invalid - .
Hier können Sie sich von künftigen Zusendungen abmelden.
| |
| Verantwortlich für den Inhalt:
Heise Medien GmbH & Co. KG
Karl-Wiechert-Allee 10
30625 Hannover
Telefon: +49 [0]511 5352-0
E-Mail: infoservice@heise.de
Registergericht:
Amtsgericht Hannover HRA 26709
|
| | Persönlich haftende Gesellschafterin:
Heise Medien Geschäftsführung GmbH
Registergericht:
Amtsgericht Hannover, HRB 60405
Geschäftsführer: Ansgar Heise, Beate Gerold
|
|
|---|
|
| |
| Herausgeber: Christian Heise, Ansgar Heise
Chefredakteur: Dr. Oliver Diedrich (verantwortlich)
Alle Rechte vorbehalten. Jegliche Vervielfältigung oder Weiterverbreitung in jedem Medium als Ganzes oder in Teilen bedarf der schriftlichen Zustimmung des Verlags. Copyright © 2024 Heise Medien GmbH & Co. KG
| |
|
|
|
