K(o)ennen Sie schon „DevOps“? Machen Sie SAS? Dann lohnt sich eventuell ein frischer Blick auf die Kombination! Denn immer mehr Unternehmen probieren, ihren produktiven Betrieb auch in die Hände der Software-Entwickler zu legen (2 von 3 laut Jenkins) – speziell in der Analyse, insbesondere beim agilen Modellieren und dem Veredeln von Daten.
Worum geht es bei DevOps? Und wie sieht Ihre Datenstrategie aus?
DevOps ist ein Kunstwort, sogar eine Kunst. Gemeint ist damit die Zusammenführung von Entwicklung („Developers!“) und dem Betreiben des Entwickelten („Operations“). Hinter dieser Kombi kann ein Team stehen … oder sogar ein und dieselbe Person. Klingt reizvoll … oder doch eher abenteuerlich?
Denn nach reiner Lehre widerspricht das der klassischen Funktionstrennung („Gewaltenteilung“ nannte das mal ein Wirtschaftsprüfer im Frankfurter Osten). Meint im Hinblick auf Analytics: Kollege A wünscht, B baut, A testet‘s, C produziert dann damit woanders (hoffentlich korrekte) Zahlen.
Inzwischen aber hat der Analyst programmieren gelernt. Und das vielleicht auf einer virtuellen Maschine inklusive Tools, die er sich beim AWS/MS-Durchstöbern in den Warenkorb gelegt hat: Zuvor werden sie erst mal nach Gusto konfiguriert – und ab diesem Moment vom selben Entwickler betrieben, gewartet, bezahlt und später entsorgt.
Warum macht man das? Aus Not und „just because“ – weil es geht. Die „Not“ ist jene Zeit, die der Fachanalyst warten muss, bis sein Werk mal „in PROD“ ist: Frustrierend lange Release-Zyklen, die oftmals zu lange brauchen, um noch von Wert zu sein. Da macht er, der Data Scientist, das doch besser gleich selbst, inklusive Plattform (virtuell) und Daten (in-Memory) und geliehenem Blech (Cloud-Hoster). Spaß macht es auch. Weil Macht.
SASler arbeiten „oft schon immer so“!?
„Ja, und?“, fragen Sie. Denn das kommt einem gestandenen SAS Entwickler alles nicht neu vor, das ist jahrzehntealte Kultur. Entwickeln und Betreiben in einer Oberfläche, aus einer Hand, wenngleich manchmal hinter vorgehaltener, ähem. Und montags morgens dem Operating das Log vorlesen, Skript kurz anpassen, sorry, neu anstarten. Wer sonst soll das denn leisten?!
Konkret und unter uns: Per SIGNON-Makroschleife mal kurz „noch ein paar Rechenknechte wecken", mit SCL ganze Job-Netze orchestrieren, mit FSP & AF magisch eine Oberfläche erfinden. DevOps’en? Das konnten Sie und ich und MVS schon, als „vorne noch die 19 stand“, Y2K und so.
Deployment, Scheduling, Versionierung: okay.
Diese pragmatisch-agile Arbeitsweise beißt sich leider manchmal (?) mit dem Anspruch einer Governance, ja, Compliance. Dieser Anspruch kommt von außen, von nebenan, von oben oder plötzlich im Urlaub via Handy.
Viele Unternehmen haben daher diese DevOps-Welten mit ergänzenden Werkzeugen unterfüttert, Stichwort: Software-Lifecycle-Management. Beispielsweise Scheduler (Tivoli, UC4), Versionskontrollierer (CVS, Subversion) oder Dokumenten-Tools inklusive Workflows zur Kollaboration (Confluence, Sharepoint). Hinzu kommen im SAS Umfeld auch zahlreiche Eigenentwicklungen („Berater-Tools“) und Hauslösungen wie SAS Data Governance …
Zukunft heute … Cloud, API, Docker statt auf die IT warten? Und natürlich weiterhin SAS!
Seit ein, zwei Jahren nimmt der DevOps-Trend zunehmend an Fahrt auf und erfasst auch deutlich wahrnehmbar die Welt der Data Scientists, Stichwort DataOps. Je nach Use Case wählt man eine bunte Mischung aus Tools & Engines, individuell oder universell, sprich: Cloud, Container und Marktplätze.
Denn auch Ihr SAS System lebt vermutlich nicht lokal auf Ihrem PC – sondern auf mindestens einem Server. Womöglich ist der schon virtuell, bald hybrid verteilt oder „in fernen Wolken-Farmen angemietet“ … Es geht auch schmaler: SAS als Container, vorgefüllt oder per Rezept selbst gemacht. Oder gehostet vom Hersteller SAS, auch in Frankfurt. Das kann dann sehr elegant sein, Rechenleistung bei Bedarf auf den Punkt gebracht. Wohlgemerkt: High-End Machine-Learning-Algorithmen in-Memory, eh klar, aber (pst!) auch das gute, alte BASE SAS der späten Achtziger! Läuft.
