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.
Anbieter wie Microsoft betonen seit Jahren, dass man im Gegensatz zum eigenen Rechenzentrum in ihrer Cloud je nach Ressourcenbedarf skalieren kann. Sie verwenden oft das Stromnetz als Analogie: Wenn ich meine Wohnung saugen möchte, bekomme ich über die Steckdose kurzfristig die notwendige Energie für meinen Staubsauger. Ich zahle nur für genau das, was ich tatsächlich verbrauche und benötige keinen eigenen Generator.
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.
Fehler, die der Kunde im laufenden Betrieb findet, sind teuer. Fehler, die in der Entwicklungsphase gefunden werden, sind günstiger zu beheben. Am besten wäre es, Fehler von vornherein zu vermeiden. Ein Schritt in diese Richtung ist die Beachtung von Best und Worst Practices für den C#-Code. Wurden wirklich alle IDisposables disposed? Entspricht der Code den Coding Guidelines und ist dadurch leicht lesbar und wartbar? SonarQube nimmt sich genau dieses Problems an.
![Portrait: Albtraum menschliches Gesicht [Video]](https://entwickler.de/wp-content/uploads/2014/11/bildschirmfoto_2014-01-21_um_15.51.01-300x200.jpg)
Der Begriff „Wahnsinn“ bekommt durch das neue Projekt des Künstlerkollektivs Milkyeyes auf einmal eine positive Konnotation. Denn das, was sich die beiden...
