Steht die moderne IT vor einer Herausforderung, greifen Verantwortliche immer öfter auf ein vermeintliches Allheilmittel zurück: die Migration von Lösungen in die Cloud. Doch ist diese Maßnahme tatsächlich die Universallösung? Nun, die Antwort darauf ist ein entschiedenes „Jein“.
Analytics-as-a-Service und Analytics in der Cloud sind seit Längerem ein viel diskutiertes Thema. Die Vorteile liegen klar auf der Hand: Cloud Services lassen sich, gemäß den eigenen Anforderungen, einfach nach oben oder unten skalieren. So wird Analytics auch für kleinere Unternehmen erschwinglich, die sich keine großen Investitionen in die nötige Infrastruktur leisten können. Jüngste Entwicklungen beschleunigen diesen Trend weiter: Durch Analytics-Plattformen in der Public Cloud wird Analytics-as-a-Service für eine stetig wachsende Zahl an Nutzern immer attraktiver.
SAS hat vor kurzem angekündigt, dass die SAS Analytics-Lösungen ab sofort komplett in der Cloud verfügbar sind. Mit SAS Viya als Basis können Nutzer ihre Analytics bei verschiedenen Public-Cloud-Anbietern betreiben, wie z.B. Amazon Web Services (AWS), Microsoft Azure, etc. Dank zahlreicher Quickstart-Optionen ist die komplette Einrichtung praktikabel und einfach; in kurzer Zeit ist alles up and running.
Ist die Nutzung von Analytics in der Cloud also wirklich so einfach? In der Theorie schon, doch es gibt – wie so oft – einige Dinge, auf die man achten muss.
Die Infrastruktur der Zukunft: Code
Wer Analytics in die Cloud migrieren möchte, muss die genutzte Infrastruktur als Code begreifen. Das bedeutet, sie muss wie Software behandelt und durch Programmieren selbst „zusammengebastelt“ werden. Mit anderen Worten: Das Rechenzentrum besteht nicht mehr aus Hardware in Form speziell konfigurierter Server (Serverless Computing). Die Infrastruktur wird stattdessen von einer Reihe computerlesbarer Daten definiert. So können diese Daten überall und auf jedem Server ausgeführt werden – die Quintessenz der Cloud-Definition.
Alle großen Cloud-Anbieter ermöglichen ihren Kunden, auf den von ihnen genutzten Servern individuelle Umgebungen per Scripting zu erstellen – also über einen Infrastructure-as-a-Code-Ansatz. Die dafür genutzten Tools sind zum Beispiel der Microsoft Azure Resource Manager, CloudFormation von Amazon Web Services oder der Cloud Deployment Manager von Google. Diese Dienste sind zwar anbieterspezifisch, funktionieren aber für gewöhnlich alle mit der gleichen Art von Code.
Wie man es nicht machen sollte
So weit, so elegant. Doch wie zu erwarten, gibt es auch einige Dinge zu beachten. Einige Beispiele zeigen, warum. Erst kürzlich hat ein Programmierer namens Anthony Spiteri auf seiner Website https://anthonyspiteri.net/public-cloud-and-infrastructure-as-code-the-good-and-the-bad-all-in-one-day/ einen Erfahrungsbericht veröffentlicht, der zeigt, wie schädlich schon eine kleine Nachlässigkeit sein kann. Spiteri hatte versehentlich sowohl seinen AWS-Zugang als auch den entsprechenden Geheimschlüssel beim Code-Repository GitHub hochgeladen. Er bemerkte den Fehler unmittelbar danach und löschte die Information innerhalb von fünf Minuten.
Doch als er den Code erneut benutzen wollte, gab es ein Problem. Sein AWS-Account war schon kompromittiert und sein Zugangsschlüssel geändert worden. Das Protokoll zeigte bereits einige missbräuchliche Aktivitäten und die Nutzungsgebühren schossen in die Höhe. Um hier kurz eine Lanze für AWS zu brechen: Der Support war extrem hilfsbereit, der Account wurde sofort gesperrt und die Rechnung storniert. Trotzdem: Die Tatsache, dass innerhalb von fünf Minuten eine Rechnung in Höhe von knapp 1.500 Euro zusammenkommt, ist schon besorgniserregend.
Public-Cloud-Anbieter nutzen zweifellos gute und reibungslos funktionierende APIs für den Zugriff auf ihre Plattformen. Letzten Endes ist das einer der Gründe, warum Infrastructure-as-a-Code so unkompliziert anzuwenden ist. Das gilt aber auch für andere Nutzer mit böswilligen Absichten, die somit leichtsinnige Fehler schnell ausnutzen können. Deswegen empfiehlt es sich, entsprechende Vorkehrungen zu treffen und bei der Speicherung von Anmeldedaten auf Best Practices zurückzugreifen.
Starthilfe gefällig?
Wie also nutzt man Analytics in der Public Cloud, ohne die Sicherheit aus den Augen zu verlieren? Eine Plattform wie SAS Viya bringt in dieser Hinsicht entscheidende Vorteile.
So stellt SAS dem Nutzer zum Beispiel „Rezepte“ zur Verfügung, die auf den Vorlagen der Cloud-Anbieter basieren und so eine schnelle Einrichtung ermöglichen. Außerdem sind Referenzanwendungen verfügbar, die neben der benötigten Netzwerkinfrastruktur für öffentliche und private Subnetze auch Sicherheitsfeatures für die Transportschicht bereitstellen. Die Topologie der verteilten Software entspricht zudem den Best Practices von SAS. Und zahlreiche Tipps und Ratschläge für die Implementierung von SAS über Amazon Web Services verringern die Wahrscheinlichkeit, dass dem Anwender ein ähnlicher Fehler unterläuft wie Anthony Spiteri.
Sollte sein Fehler also abschreckende Wirkung haben? Nein, nicht wirklich. Spiteri hat offen zugegeben, sich nicht an Best Practices gehalten zu haben. Wer sie dagegen einhält, ist gut geschützt. Die Implementierung von SAS Viya mithilfe der bereitgestellten Vorlagen und Systeme ist, allgemein betrachtet, relativ sicher. Es geht darum, Risiken zu erkennen und sie zu minimieren – und genau hier kann die Zusammenarbeit mit einem großen Anbieter entscheidende Vorteile bringen.
