Cloud Services - Fluch oder Segen?

Cloud Services, Software as a Service (SaaS) und Platform as a Service (PaaS) sind mittlerweile zum fixen Bestandteil der IT-Infrastruktur vieler Unternehmen geworden. Nun stellt sich die Frage: Welche Vorteile und Nachteile haben diese Services? Eine Betrachtung aus Entwicklersicht

Was ist der Unterschied zwischen SaaS, PaaS, Cloud-Services?

Auch wenn die Begriffe oft Synonym verwendet werden, unterscheidet sich die Bedeutung bei genauer Betrachtung:

• SaaS ist ein Software-Lizensierungsmodel, bei dem die Software im Regelfall nicht lokal gehosted wird. Es gibt aber auch bei SaaS die Möglichkeit, die jeweilige Applikation über die firmeneigene Hosting-Infrastruktur bereitzustellen.
• PaaS bietet Zugriff auf aufeinander abgestimmte Tools und Applikationen, mit deren Hilfe Kunden komplexe, vernetzte Tasks durchführen können. Beispielsweise Software Development und Testing^[1]
• Cloud-Services umfassen Softwarelösungen, die komplett von Dritten angeboten, gehostet und gewartet werden.

Dass diese Begriffe keine standardisierte Bedeutung haben, zeigt sich am Beispiel Atlassian: Hier wird die Atlassian Cloud als SaaS bezeichnet, während Atlassian Data Center „self-managed“ ist. Man könnte aber argumentieren, dass beides verschiedene Ausprägungen von SaaS sind.^[2] Paas wiederum kann als Erweiterung von SaaS verstanden werden, um nahezu das gesamte Toolset eines Unternehmens von lokalen Data Centern in eine dezentrale Location zu verlagern.

In diesem Artikel werden die Begriffe synonym verwendet.

Cloud-Services: Die Vorteile

Die Gründe für den Erfolg von in der Cloud gehosteten und bereitgestellten Dienstleistungen liegen aus Endkundensicht auf der Hand. Um einige Beispiele zu nennen:

• Keine eigene Infrastruktur nötig, somit wird Wartungs- und Implementierungsaufwand geringer
• Funktioniert häufig „out of the box“, es ist nur mehr Konfiguration für den eigenen Anwendungsfall nötig
• Support durch Anbieter der Cloud Lösung
• Unabhängig vom Standort
• Leicht skalierbar
• (Nahezu) 24/7 verfügbar

Doch auch als Developer kann eine Cloud-Lösung auf den ersten Blick Vorteile bringen. Im besten Fall ist das jeweilige Ökosystem gut ausgebaut, bietet viele verschiedene Anwendungsmöglichkeiten und hat eine gute Unterstützung für Third-Party-Entwickler. Es können eigene Apps oder Erweiterungen mit geringem Aufwand entwickelt und leicht für unterschiedliche Anwendungen des Ökosystems verfügbar gemacht werden. Außerdem muss der Developer oder Dienstleister sich keine Gedanken um Hosting der Anwendungen machen. Augenscheinlich bietet SaaS also einige gewichtige Vorteile. Ist es also empfehlenswert am besten den ganzen Tech-Stack über solche Lösungen abzudecken?

Bei genauerer Betrachtung lautet die Antwort: Es hängt davon ab.

Cloud-Services: Die Nachteile

Selbst wenn wir DSGVO-Bedenken, z.B. über die Verwaltung von sensiblen Daten in Datacentern mit unbekannter Location, außen vor lassen, gibt es einige andere gewichtige Gründe, sich gegen SaaS oder Cloud-Apps zu entscheiden. So ist es häufig ab einer bestimmten Anzahl an nötigen Lizenzen günstiger, selbst das Hosting der jeweiligen Anwendung zu übernehmen, selbst wenn der Aufwand für Wartung und Implementierung eingerechnet wird. Außerdem hat ein Unternehmen mehr Kontrolle über eine selbst gehostete Anwendung und kann diese besser den eigenen Bedürfnissen anpassen. Developer, die Entwicklungstätigkeit als Dienstleistung anbieten, folgen natürlich dem Kunden. Somit ist auch hier eine zu starke Konzentration der eigenen Expertise auf SaaS nicht sinnvoll.

Aber kann man zumindest kleinen oder mittelgroßen Unternehmen SaaS-Lösungen empfehlen?

Hier lautet die Antwort ebenfalls: Es hängt davon ab.

Eine wichtige Entscheidung...

Somit sind wir beim Kern der Sache: Wie bei jeder Entscheidung muss auch bei der Wahl einer gewissen Lösung ein Evaluierungsprozess voran gehen, der Requirements beleuchtet und die Zukunft mit einbezieht. Vor allem die Zukunftssicherheit einer Lösung ist oft wertvoller als Ersparnisse auf kurze Sicht. Denkt daran: Migrationsprozesse sind oft langwierig und teuer, eine fundierte Entscheidung vermeidet häufiges Hin- und Her. Des Weiteren bedeutet die Entscheidung für eine Lösung in einem bestehenden Ökosystem häufig auch den „Lock-in“: Zwar bekomme ich Cloud-Anwendungen für verschiedenste Bereiche, doch diese arbeiten mitunter nur mit Anwendungen desselben Anbieters verlässlich zusammen. Und auch für Entwickler geht diese Entscheidung oft mit der Einschränkung auf ein bestimmtes Framework einher. Somit ist auch diese Wahl unter Einbeziehung eventueller zukünftiger Requirements zu treffen, da nicht jedes Framework jeden potenziellen Anwendungsfall (optimal) abdecken kann. Schlimmstenfalls müssen bei einem Wechsel der Cloud-Lösung eigene Plugins und Erweiterungen komplett neu entwickelt werden. Aber auch bei einem Umstieg im selben Ökosystem von einer Cloud-Lösung zu einer self-hosted Variante sind diese Programme nicht immer übertragbar, z.B. von Atlassian Cloud auf Atlassian Data Center.

Welche Herausforderungen die Verwendung einer SaaS-Lösung nun für Developer bedeuten kann, zeige ich folgend am konkreten Beispiel von Atlassian Jira Software Cloud und der Entwicklung eines Plugins mit Atlassian Forge.

Atlassian Forge: Plugin Development in der Cloud

Forge ist ein von Atlassian entwickeltes Framework. Es soll Atlassian Connect in der Cloud-Plugin-Entwicklung ablösen. Bei diesem Framework wurde vor allem dem Thema Sicherheit große Bedeutung beigemessen, da in Atlassian Produkten Unmengen an potenziell sensiblen Daten verarbeitet werden.^[3] Doch dieser absolut verständliche Fokus auf Sicherheit bedeutet für die Entwicklung einen erheblichen Mehraufwand. Wir bei razzfazz.io haben uns aktuell beim Development eines Plugins zur Risikoevaluierung für Jira Software Cloud dieser Herausforderung gestellt. Das von uns entworfene Plugin hat das Ziel, den von SEQIS entwickelten Risikoevaluierungsprozess der „Reise nach Rom“ abzubilden. Eventuell ist dieser Prozess ein Begriff – wenn nicht, hier eine sehr kurze Zusammenfassung:

Bei der Reise nach Rom wird anhand von zwölf Fragen zu verschiedenen Bereichen eines Features und der zugrundeliegenden Software erhoben, wie sich das (Business)-Risiko dieses Features zusammensetzt. Die Antworten der Fragen wurden bisher in ein Excel-Sheet mit Makros eingetragen und damit die verschiedenen Risiko-Kennzahlen berechnet. Das Ziel des von uns entwickelten Plugins ist nun, diesen Prozess in einem intuitiven Wizard abzubilden, und somit über ein paar Klicks die Risikobewertung eines Feature-Tickets oder einer Anforderung vorzunehmen.

^{Abbildung 1: Übersicht Reise nach Rom (Quelle: SEQIS GmbH)}

^{Abbildung 2: Prozess in Excel (Quelle: SEQIS GmbH)}

^{Abbildung 3: Reise nach Rom Wizard - Jira Software Cloud Plugin (Quelle: SEQIS GmbH)}

^{Abbildung 4: Reise nach Rom Wizard - Jira Software Cloud Plugin (Quelle: SEQIS GmbH)}

Welche Herausforderungen das für uns bedeutet hat und welche Lösungsansätze wir bei razzfazz.io dafür gefunden haben, soll anhand von zwei konkreten Beispielen beleuchtet werden.

Entwicklung in Cloud-Frameworks: Herausforderungen und Lösungsansätze

Kollaboration zwischen Entwicklern

Ein Thema, das im Software-Development eine große Rolle spielt, ist Kollaboration mit anderen Entwicklern. Doch schon hier hat das Framework einige unangenehme Überraschungen für Entwickler-Teams parat. Bei der Entwicklung von Applikationen mit Frontend-Aspekt (Allgemein: User Interfaces) bewährt sich ein iterativer Ansatz, den z.B. eingebaute Development-Server bei React oder Vue.js übernehmen. Damit ist es möglich, Änderungen am Code sofort in der Ansicht widergespiegelt zu sehen, was Entwurf und Design beschleunigt. Um eine ähnliche Developer-Experience wie bei React oder Vue zu haben, bietet Forge auch die Möglichkeit der interaktiven Entwicklung. Allerdings mit der Einschränkung, dass sicherheitskritische Änderungen (z.B. zusätzliche Berechtigungen für das Plugin) es erfordern, das Plugin neu zu builden und in die Cloud zu deployen. Somit ist vor allem am Anfang des Entwicklungsprozesses mit mehr Wartezeit für den Developer zu rechnen.

Wird nun eine neue App mit Forge erstellt, wird dafür eine einzigartige ID generiert, die diese App eindeutig einem Atlassian Developer Account zugeordnet. Dadurch bilden aber App-ID und Developer (bzw. der Account) ein untrennbares Paar.

Warum erschwert das nun die Entwicklung?
Da es sich hierbei um eine Cloud-Lösung handelt, kann das mit Forge entwickelte Plugin lokal nicht ausgeführt werden. Dazu ist es nötig, wie vorhin erwähnt, dieses in die Cloud zu deployen und auf einem passenden Atlassian Produkt zu installieren, z.B. Jira oder Confluence. Damit wird allerdings ein gleichzeitiges Arbeiten mehrerer Entwickler am selben Plugin unmöglich – da das Plugin eindeutig über ID und Account identifiziert wird, beeinflussen sich Änderungen unterschiedlicher Developer gegenseitig.

Unser Lösungsansatz
Bei razzfazz.io haben wir folgende Lösung dazu entwickelt: Wir erstellen mehrere Instanzen der Atlassian Cloud Produkte, jeweils eine pro Developer.

Somit kann für jeden Entwickler die App geklont und auf den Developer-Account dieses Entwicklers mit einer neuen App-ID registriert werden. Über Skripte und eine CI/CD-Pipeline wird die App-ID automatisch auf den jeweiligen Developer angepasst. Außerdem ermöglicht diese Variante uns, eine Jira-Instanz als Produktivumgebung zu definieren, worauf fertig umgesetzte Features automatisch deployed werden. Diese spiegelt somit den derzeitigen Entwicklungsstand des Plugins wider. Dadurch haben wir eine relativ einfache Möglichkeit geschaffen, dass mehrere Developer an verschiedenen Branches oder Features arbeiten und diese in der Cloud testen können. In der Theorie ist diese Lösung auch unbegrenzt skalierbar, da das erstellen eines Atlassian-Accounts und die Einrichtung einer Jira-Instanz keine Kosten verursacht.

Testbarkeit mit Unit-Tests

Ein mit dem vorherigen Thema zusammenhängender Aspekt ist die Testbarkeit. Bei razzfazz.io ist es unser Anspruch, von uns entwickelte Software umfassend mit automatisierten (Unit)-Tests abzudecken. Einerseits ermöglicht das uns Sicherheit beim Refactoring und bei der Entwicklung neuer Features, da dadurch eventuell eingeschleppte Fehler abgefangen werden.

Forge hat sich hier als sehr schwer zu Testen herausgestellt. Je nachdem welche von Atlassian bereitgestellte UI-Lösung verwendet wird (Forge UI Kit oder Custom UI)^[4][5], ist automatisiertes Testen schwer bis unmöglich. Forge UI Kit ist in der Entwicklung einfacher, bietet aber nur eingeschränkte Möglichkeiten zur Interaktion mit Atlassian Produkten. Das Custom UI hat weitaus mehr Flexibilität, bedeutet aber für den Entwickler mehr Verantwortung und einen größeren Aufwand bei der Implementierung. Beide Varianten sind React sehr ähnlich, womit sich die eingangs erwähnte Einschränkung auf ein Framework zeigt.

Unser Lösungsansatz
Um unser Plugin testen zu können, war einiges an Recherche- und Entwicklungsaufwand sowie Reverse-Engineering vonnöten. Zwar konnte ein Großteil der App über automatisierte Tests abgedeckt werden, doch war es dafür nötig, das Projekt in eine bestimmte Struktur zu bringen, um die zu testenden Komponenten komplett von allen Forge-Modulen zu isolieren. Diese funktionieren außerhalb der nativen Cloud-Umgebung von Atlassian nicht und verhindern die Tests. Durch intelligente Architekturentscheidungen oder aufwendiges Mocking kann diese Trennung zwar ermöglicht werden, aber es bedeutet einerseits einen größeren Implementierungsaufwand und anderseits zwingt es eventuell das Projekt in eine Struktur, die ohne diese Voraussetzung weit einfacher wäre.

Wir haben uns entschieden, über die Projektstruktur diese Trennung zu ermöglichen. Somit konnten die UI-Komponenten des Plugins mit Standard-Testframeworks für React getestet werden. Bei razzfazz.io verwenden wir MochaJS, ChaiJS und SinonJS, welches in diesem Fall mit der React Testing Library kombiniert wurde. Dadurch konnte der Großteil unseres Test-Stacks wiederverwendet werden und musste nur minimal an die Anforderungen von React-UI-Tests angepasst werden.

Forge - ein Framework in Entwicklung

Forge ist zwar zur allgemeinen Verwendung veröffentlicht, aber einige Aspekte davon befinden sich noch in Entwicklung. Die fehlende Unterstützung für die Kollaboration mehrerer Entwickler z.B. ist Atlassian bekannt und es wird daran gearbeitet. Zur Testunterstützung gibt es bis Dato noch keine Informationen über eine Umsetzung, doch ist auch dieses Thema Atlassian bekannt. Es ist anzunehmen, dass mit zukünftigen Versionen des Frameworks die Entwicklung weit einfacher wird.

Ein Blick nach Vorne

Für unser Plugin zeichnet sich am Horizont schon weitere Arbeit ab: Da Atlassian Data Center im Enterprise-Bereich eine weit größere Nutzerbasis aufweist als Atlassian Cloud, erscheint es uns sinnvoll, das Plugin auch für diese Version zu portieren. Allerdings verwenden Data Center Apps ein komplett anderes Framework auf Basis von Java, wodurch eine Neuentwicklung eines Großteils der Oberfläche notwendig sein wird.

Jedenfalls steht die aktuelle Version der „Reise nach Rom“ (EN: Journey to Rome) bereits in Kürze im Atlassian Marketplace zur Verfügung. Sollten Sie Fragen dazu haben, kontaktieren Sie uns bitte gerne.

Die Zukunft...

Hoffentlich konnte anhand dieser praktischen Beispiele gezeigt werden, welche potenziellen Herausforderungen bei der Entwicklung in Cloud-Frameworks entstehen können und welche Überlegungen vor der Entscheidung für eine cloudbasierte Lösung essenziell sind. Mit hoher Wahrscheinlichkeit werden Cloud-Services und Saas-Lösungen eher ihren Marktanteil ausbauen bzw. versuchen, Kunden zum Umstieg auf Anwendungen in der Cloud zu bewegen. Die Vorteile von Cloud-Lösungen sind nicht von der Hand zu weisen: Sei es Skalierbarkeit, Verfügbarkeit und einfache Einrichtung für Unternehmen oder sinnvoll zusammengestellte Tools und Frameworks sowie schnelle Entwicklung einfacher Apps für Developer. Wenn eine passende Cloud-Lösung für einen gewissen Anwendungsfall existiert, kann das in vielen Fällen die einfachste und schnellste Lösung sein. Doch ist es sinnvoll, sich der Schwierigkeiten und Herausforderungen bewusst zu sein, die eine Entscheidung für diese Anwendungen oder Frameworks mit sich bringen können, um darauf passierend eine fundierte Entscheidung zu treffen.