Viele, die den Weg von On-Premises-Software zu Cloud-basierten SaaS-Lösungen gehen, müssen eine Lektion auf die harte Tour lernen: Benutzer sehen und beurteilen die von uns Technikerinnen und Technikern erstellte Software ganz anders als wir.
So wie viele andere Personen in der Softwareentwicklung auch, habe ich das Programmieren mit Sprachen wie C++, Java und vor allem C# gelernt. Ich mag daher typisierte Sprachen, und mir sind die Vorteile einer vollwertigen IDE im Vergleich zu einem leichtgewichtigen Editor mit Konsole bewusst.
Immer wieder werde ich gefragt, wie sich Softwarearchitekturen bei SaaS in der Cloud von klassischer Software für den Betrieb bei Endkunden unterscheidet. Ein Aspekt ist die Wichtigkeit des Design-to-Cost-Ansatzes. Damit ist gemeint, dass die Betriebskosten einer SaaS-Lösung von Anfang an als wichtige, nicht funktionale Anforderung berücksichtigt werden.
Offene Software und Daten – in der öffentlichen Wahrnehmung sind diese Begriffe durchweg positiv besetzt. Mit Offenheit verbindet man, dass jederzeit mit jeder Technologie und von jeder Plattform aus mit Softwaresystemen interagiert und auf Daten zugegriffen werden kann.
Das Internet ist angesichts der Datenschutz-Grundverordnung (DSGVO) in Aufruhr. Jeden Tag flattern E-Mails in mein Postfach, in denen mir von allen möglichen Organisationen in blumigen Worten versichert wird, wie sehr ihnen Datenschutz am Herzen liegt und dass ich mit nur einem Klick dafür sorgen kann, dass mir keine wichtigen Informationen in den diversen Newslettern entgehen.
Wenn es um den immer weiter steigenden Automatisierungsgrad in der Wirtschaft geht, denken die meisten an Autofabriken, in denen kaum Menschen, aber viele Maschinen arbeiten. Oder an den Haushaltsroboter, der die weniger angenehmen Arbeiten in den eigenen vier Wänden übernimmt. In der Softwareindustrie allerdings sind es die Softwareroboter in der Cloud, die längst begonnen haben, unsere Arbeit zu revolutionieren.
Das gängige Paradigma in den frühen Jahren der Cloud war, dass die Cloud unsicher, unberechenbar (z. B. hinsichtlich der Kosten) und unkontrollierbar ist. Die Server im eigenen Rechnerraum waren greifbar. Die Tür des Rechnerraums konnte man persönlich absperren, und das vermittelte ein Gefühl von Sicherheit.
Neben meiner Arbeit als Berater und Softwareentwickler unterrichte ich einen Tag pro Woche an der höheren technischen Lehranstalt für Informatik in Perg (Österreich). Meine Schüler sind zwischen 17 und 19 Jahre alt und stehen daher kurz vor ihrem Karrierestart oder dem Beginn eines Studiums. Im Rahmen einer Berufsinformationsveranstaltung war ich an unserer Schule eingeladen, an einer Podiumsdiskussion teilzunehmen.
Eventbasierte Programmierung ist an sich nichts Neues. In grafischen Benutzeroberflächen bestimmen seit eh und je Ereignisse wie Mausklick oder Tastendruck den Programmablauf. Ähnliches gilt auch für hardwarenahe Programmierung, wo Ereignisse in Form von Interrupts signalisiert werden. Innerhalb von .NET-Programmen sind Events und Callbacks ebenfalls ein gängiger Mechanismus, um über Ereignisse zu informieren.
Strom kommt aus der Steckdose und Trinkwasser aus der Wasserleitung. Diese vereinfachte, fast schon kindliche Logik kommt daher, weil wir gelernt haben, uns über die komplexen Zusammenhänge, die hinter vielen alltäglichen Dingen stecken, keine Gedanken machen zu müssen. Über Jahrhunderte haben unsere Zivilisationen die Infrastruktur zur Versorgung mit Dingen wie Wasser, Strom, Gas, Fernwärme etc. perfektioniert. Selbst wenn wir die Hintergründe verstehen wollten, wäre das nicht so leicht möglich.
Wer jetzt in die Cloud einsteigt, ist kein „Early Adopter“ mehr, sondern eher ein „Late Follower“. Man sollte meinen, dass der Einstieg ins Cloud-Computing deshalb leichter wäre: Die Cloud-Provider hatten jahrelang Zeit, an ihren Services zu feilen, die Dokumentation zu vervollständigen, Trainingsunterlagen zur Verfügung zu stellen etc. Kurz gesagt, die Kinderkrankheiten sollten überstanden sein.
Dass sich typische Softwarearchitekturen in der Cloud von jenen im lokalen Rechenzentrum unterscheiden, hat sich mittlerweile herumgesprochen. Unzählige Artikel, Bücher und Vorträge auf Konferenzen behandeln dieses Thema. Ich möchte mich dem Themenbereich von einer anderen Seite nähern. Betrachten wir einmal Softwarearchitekten, also die Personen, die die Strukturen und das Design von Softwareprodukten entwerfen.
