Veröffentlicht: von

Die AXA IT sucht eine(n) Praktikant/-in im Bereich IT Architektur und Strategie zum nächstmöglichen Termin.

Schwerpunkt hierbei ist das Thema Lifecycle Management:

  • Dazu gehört die Unterstützung der Architekten bei der Ermittlung des Lifecycles der AXA-Anwendungssysteme sowie bei der Entwicklung weiterer Konzepte in dem Umfeld.
  • Daneben ist eine Mitarbeit in weiteren strategischen Themen wie z. B. Innovationsmanagement möglich.

Dies kann im Rahmen eines Praxissemesters o.ä. erfolgen. Es gibt ein Notenlimit (2,7 oder besser). Für das Praxissemester zahlt die AXA eine feste Rate. Evtl. ist ein Stipendiat auf Stundenbasis möglich.

Interessenten wenden sich bitte an mich.

Veröffentlicht: von

Für das Wintersemester 17/18 biete ich ein Informatikprojekt an, bei dem die Studierenden in agilen Teams die Lehr- und Lernplattform ArchiLab weiterentwickeln. Die genauen Epics werden wir in einem ersten Workshop im September festlegen. Vermutlich wird es Richtung Integration verschiedener Teilsysteme als Microservice-Architektur gehen.

Wenn Sie interessiert sind, können Sie sich unverbindlich in ILIAS unter https://ilias.th-koeln.de/ilias.php?ref_id=987034&cmdClass=ilrepositorygui&cmdNode=oj&baseClass=ilrepositorygui anmelden. Ich lade Sie dann zu einem Kickoff ein, da können Sie sich Inhalt und Aufbau des Projekts anhören und dann endgültig über Ihre Teilnahme entscheiden.

Veröffentlicht: von

Die FG Systemgestaltung entwickelt zurzeit die e-Learning-Plattform ArchiLab (siehe http://blogs.gm.fh-koeln.de/bente/archilab/). ArchiLab ist eine webbasierte Lehr- und Lern-Plattform für die Vermittlung von komplexem Expertenwissen, wie etwa Methoden der Software-Architektur.

Zur Unterstützung der Weiterentwicklung und der Lehreinführung von ArchiLab in den Informatik-Bachelorveranstaltungen Softwaretechnik 1 und 2 suche ich zwei studentische Hilfskräfte (17h/Woche, 1 Jahr).

Aufgaben der Stellen

  • Unterstützung bei der Produktifizierung des in Studentenprojekten erstellten Codes (Bugfixing, Administration etc.)
  • Implementierung von Features
  • Testautomatisierung
  • Refactoring
  • Mitwirkung an Architekturworkshops und Backlogplanung
  • Oganisatorische Unterstützung der Lehreinführung
  • organisatorische Unterstützung der laufenden Studentenprojekte

Voraussetzungen

  • Interesse an spannender Programmierarbeit im Team
  • Gute Programmierkenntnisse (Java, Spring Boot und Angular2 von Vorteil)
  • Interesse an Softwarearchitektur und der Diskussion von Designentscheidungen
  • Veranstaltungen ST1 und 2 (oder vergleichbar) mit überdurchschnittlichem Ergebnis absolviert

Beginn der Stellen

Bewerbung sofort, Arbeitsbeginn dann wahrscheinlich ab Oktober

Bewerbung

Wenn Sie Interesse haben, bewerben Sie sich bitte per Email an marco.reitano@th-koeln.de und stefan.bente@th-koeln.de.

Sie müssen keinerlei Lebenslauf etc. beifügen, aber sagen Sie uns in der Email bitte in ein paar kurzen Sätzen, was Sie an der Stelle reizt und warum wir Sie einstellen sollten.

Veröffentlicht: von

(This is a procedure information. German version below)

Procedure for Scientific Writing Course and Exam

Each Guided Project Type A has a component „Scientific Writing“. The credits are distributed as such:

  • 8 CP: software or business related part (the „B“ part, so to say)
  • 5 CP: team processes / coaching part (the „A“ part)
  • 1 CP: Scientific Writing

Scientific writing will be taught once a year, in winter semester. The course material is available in ILIAS (*** Link to be added ***). Course attendance is voluntary. There is a mandatory oral exam with Profs. Bente and Westenberger, which can be taken twice a year:

  • Winter semester: immediately after the 2nd part of the Scientific Writing course, usually in November.
  • Summer semester: in the first exam period, around end of July.

Exception for this semester (SS2017)

As the first exam period is already (nearly) over, participants in SS17 GP-A projects do have two options:

  1. Prepare by self study. We will offer an exam date in the 2nd exam period (Sep/Okt, date yet to be announced)
  2. Attend the Scientific Writing course in WS17, and use the exam date then (as of current planning: some time in 27.11.-01.12.,  Profil2 week)

************************************************************************************************

(Deutsche Version)

Verfahren für Kurs und Prüfung „Scientific Writing“

Jedes Guided Project Typ A hat eine Komponente „Scientific Writing“. Die CP verteilen sich wie folgt:

  • 8 CP: der fachliche (Software / Business) Teil (der „B“-Teil, sozusagen)
  • 5 CP: Teamprozesse / -coaching (der „A“-Teil)
  • 1 CP: Scientific Writing

Scientific writing wird einmal im Jahr als Kurs angeboten, im Wintersemester. Das Kursmaterial ist in ILIAS verfügbar (*** Link folgt ***). Die Teilnahme am Kurs ist freiwillig. Es gibt eine verpflichtende mündliche Prüfung mit den Professoren Bente und Westenberger. Diese findet zwei Mal im Jahr statt:

  • Wintersemester: unmittelbar nach dem zweiten Teil des Scientific-Writing-Kurses, normalerweise im November.
  • Sommersemester: in der ersten Prüfungsphase, um Ende Juli.

Ausnahme für dieses Semester (SS2017)

Da die erste Prüfungsphase (nahezu) vorbei ist, haben die Teilnehmer der SS17-GP-A-Projekte zwei Möglichkeiten:

  1. Vorbereitung im Selbststudium. Wir werden ein Prüfungsdatum in der zweiten Prüfungsphase anbieten (Sep/Okt, genaues Datum wird noch bekanntgegeben)
  2. Teilnahme am Scientific-Writing-Kurs im WS17, und dann die Prüfung unmittelbar danach. (Aktuelle Planung: in der Profil2-Woche, 27.11.-01.12.)

Veröffentlicht: von

Problemstellung

Die Microservices-Architektur bietet im Vergleich zur monolithischen Architektur verschiedene Vorteile wie Agilitat, Skalierbarkeit, unabhangige, autonome, modulare Prozessen und Modulen usw. und hat damit viel Aufmerksamkeit in den letzten Jahren erregt. Doch die Implementierung bleibt immer noch eine Herausforderung. Bei dem Wandel von monolitischer Architektur zu Microservices wird die innerliche Komplexitaet eines Vintage-Systems zur Komplexitaet der Interaktionen zwischen einer Mehrzahl unabhaengiger schmaler Services umgewandelt.
Doch wie wird diese neue Herausforderung heutzutage gemeistert? Welche Design-Praktiken haben sich im Laufe des Jahres entwickelt, die es erlauben die wachsende Komplexitaet von modernen Systemen zu beherrschen?

Abgeleitete Forschungsfrage

Die zugrundeliegende Forschungsfrage lautet:

  • Welche Anforderungen werden heutzutage an ein Microservice-basiertes verteiltes System gestellt?
  • Welche Herausforderungen ergeben sich bei der praktischen Umsetzung und Anwendung des Microservice-Konzeptes?
  • Welche Loesungen bieten sich an?

Bearbeiter

Ilya Sukhov

Abgabe

Anfang 2018

Veröffentlicht: von

Problemstellung

In der Entwicklung von größeren objektorientieren Softwareprodukten entstehen zumeist eine Vielzahl von Utility- und Helperklassen sowie Methoden in weiteren Klassen verschiedener Schichten, die bestimmte Aspekte der Fachlichkeit wie zum Beispiel Validierung oder Konvertierungen behandeln und in unterschiedlichsten Paketen zu finden sind. Dies führt zu doppeltem Code, da die Codestücke anderen Entwicklern nicht bekannt sind und schwierig gefunden werden. Vor allem spätere Änderungen der Fachlichkeit führen zu Mehraufwand, da diese an mehrere Stellen verteilt ist und erstmal gefunden werden muss. Manchmal fallen diese Probleme erst in späten Testphasen oder gar im Produktionsbetrieb auf, das zu weiteren Problemen führt. Zudem sind auch die APIs und Konstruktoren durch eine Aneinanderreihung von nativen Datentypen fehleranfällig, schlecht les- und wartbar. Dem Code fehlt eine Robustheit, die sich vor allem bemerkbar macht, sobald Entwickler die Projekte verlassen oder neu hinzukommen, die sich im spezifischen Projekt nicht auskennen.

Abgeleitete Forschungsfrage

  • Wie kann die vorhandene Fachlichkeit im Code so positioniert werden, dass ein sprechendes Domain Model entsteht und von Entwicklern schneller gefunden und besser verstanden wird?
  • Warum lohnt es sich, auch native Attribute in Entitäten als vollwertige fachliche Klassen auszumodellieren?
  • Welche Probleme treten bei der Umsetzung in JavaEE-Frameworks auf? Wie können diese gelöst werden?

Vorgehen

Zuerst werden an Hand einer Literaturrecherche die wichtigsten Aspekte des DomainDrivenDesigns mit Prinzipien der Softwareentwicklung (Objektorientierung, Clean Code, Design Patterns, Refactoring) in Verbindung gebracht. Dabei wird besonderen Wert auf Fachlichkeit an der richtigen Stelle, lesbaren Code und Auffindbarkeit gelegt.
Anschließend werden diese Eigenschaften als Anforderungen an ein auf JavaEE-basierendes Framework gestellt. Dabei steht besonders JPA und EJB als Backend, sowie JSF als Frontend im Fokus. Dabei werden auch Negativbeispiele herkömmlicher Programmierung aufgezeigt. Insgesamt wird ein Framework für Rich Domain Models entworfen, welches für eine erhebliche Reduzierung von Utility-Klassen und eine bessere Auffindbarkeit der Fachlichkeit sorgt.
Danach wird das Framework mittels Praxisbeispiele entwickelt und deren Funktionalitäten gezeigt. Abschließend findet noch eine Handlungs- und Einsatzempfehlung des entstandenen Frameworks im Vergleich zur herkömmlichen Programmierung statt.

Bearbeiter

Daniel Janßen

Abgabe

Ende 2017

Veröffentlicht: von

Problemstellung

Die Entwicklung von Cross-Plattform Anwendungen stellt, insbesondere für kleine Unternehmen, noch immer eine große Herausforderung dar: Gewöhnlich wird zur Umsetzung C++ und etablierte Bibliothekslösungen wie Qt genutzt. Aus wirtschaftlicher Sicht kann dies eine große Herausforderung darstellen, da die Verfügbarkeit von erfahrenen C++-Entwicklern im Vergleich zu etwa erfahrenen JavaScript-Entwicklern deutlich geringer ist, durch das geringe Angebot jedoch auch die Gehälter für diese Entwickler oft sehr hoch sind. Ähnlich verhält es sich mir C++-Cross-Plattform-Bibliotheken, die entweder wie Qt für eine kommerzielle Verwendung lizensiert  werden müssen, oder im Falle von freien Bibliotheken wie GTK++ oft veraltet sind und keine moderne User Experience bieten.

Electron soll dieses Problem lösen: Durch die Chromium-Engine, Node.js und V8 ist man in der Lage mittels JavaScript, CSS und HTML Desktop-Anwendungen mit Plattform-übergreifend gleicher Funktonalität sowie Aussehen zu erstellen. Die Entwicklung mit Javascript ist aus den oben angeführten Gründen auch aus wirtschaftlicher Sicht interessant. Ebenso ist Electron aus Usability-Gründen interessant, da durch die Verwendbarkeit populärer JavaScript-Bibliotheken eine zeitgemäße und von Web-Anwendungen vertraute User-Experience geschaffen werden kann. Letztlich besteht auch die Möglichkeit eine mit Electron umgesetzte Anwendung als Browser-basierte Web-Anwednung verfügbar zu machen, oder gar auf dieser Grundlage eine Mobile-Variante zu entwickeln.

Durch die relative Neuheit der Technologie sind bisher größtenteils Anwendungen mit nur geringem Funktionsumfang umgesetzt worden. Die wenigsten haben eine höherwertige grafische Aufmachung und basieren auf wenig rechenintensiven Operationen. In der Arbeit soll geklärt werden, inwiefern sich Electron zur Umsetzung von komplexen Anwendungen eignet.

Unter dieser Definition werden Anwendungen verstanden, die auf großen Mengen komplex aufgebauten, voneinander abhängigen Daten operieren. Diese sollten grafisch ansprechend präsentiert werden und für den Nutzer intuitiv und schnell erfassbar sowie veränderbar sein. Dabei muss der Nutzer immer unmittelbares Feedback auf seine Aktionen erhalten, Ladezeiten sollten minimal sein und Animationen bzw. die Bildwiederholungsraten müssen flüssig sein. Eine weitere Konkretisierung sowie Quantifizierung der genannten Merkmale wird Teil der Arbeit sein.

Weitere zu untersuchende Aspekte sind die folgenden:

  • Aus Usability-Sicht soll untersucht werden, wie komplex es sich gestaltet, auf verschiedenen Plattformen, insbesondere PC und MacOS, tatsächlich das gleiche „Look-And-Feel“ zu erreichen.
  • Aus Entwicklersicht soll untersucht werden, wie kompatibel Electron mit bestehenden Javascript-Bibliotheken sowie bestehenden Programmstücken in anderen Sprachen ist. Außerdem soll geprüft werden, ob und in welchem Maß plattformspezifischer Code erforderlich ist.

Durch die Nutzung von Webtechnologien zur Umsetzung von Anwendungen und Chromium zur Darstellung soll auch untersucht werden, wie komplex sich die Portierung einer Electron-Anwendung als Web-Anwendung gestaltet. Dies ist besonders aus wirtschaftlicher Sicht interessant, um neue Anwendergruppen zu erreichen.

Für viele Electron-Projekte existierte bereits eine Vorlage in Form einer Web-Anwendung: Der umgekehrte Weg, eine Web-Anwendung aus einer bestehenden Electron-Anwendung zu entwickeln wurde, wenn überhaupt, nur selten gegangen. Inwiefern und unter welchen Umständen eine solche Herangehensweise sinnvoll und machbar ist soll ein weiterer zentraler Punkt der Arbeit sein.

Abgeleitete Forschungsfrage

Zusammenfasssend lässt sich die Forschungsfrage der Arbeit wie folgt zusammenfassen:

  • Ist es möglich, unter den oben genannten Definition als komplex geltende Anwendungen mit Electron umzusetzen?
  • Welche Vor- und Nachteile bietet Electron gegenüber anderen Möglichkeiten und worauf muss bei der Entwicklung mit Electron geachtet werden?

Vorgehen

Es muss ein Anforderungskatalog erstellt werden, der klar und verständlich zusammenfasst, welche Anforderungen an eine komplexe Software mit den weiter oben beschriebenen Merkmalen gestellt werden. Aufgrund dieser Anforderungen sollen typische Komponenten, wie beispielweise interaktive Textfelder oder interaktive Flowcharts, bestimmt werden. Diese sollen später zur  praktischen Überprüfung umgesetzt werden. Zunächst werden jedoch die Vor- und Nachteile sowie besondere Merkmale von Electron herausgearbeitet, sowie möglicher Alternativen vorgestellt und vergleichen. Zum Vergleichen der Alternativen mit Electron werden neben der Umsetzbarkeit der vorher als notwendig definierten Komponenten auch wirtschaftliche und nutzer- sowie entwicklerseitige Anliegen herangezogen.

Schließlich werden ein oder mehrere Proof-Of-Concepts zur Umsetzung der definierten Komponenten erstellt. Dazu werden Komponenten gewählt die in Software Articy:draft verwendet werden, die durch das Erfüllen der genannten Anforderungen an eine komplexe Software  als Praxisbeispiel dient. Nach der Umsetzung der Proof-of-Concepts soll durch eine praktische Umsetzung abgeschätzt werden wie komplex sich die Portierung als Web-Anwendung gestaltet. Weiterhin soll die Portierung auf mobile Geräte erprobt werden und abgeschätzt werden, ob eine Anpassung unter wirtschaftlichen sowie entwicklungstechnischen Gesichtspunkten anstatt einer kompletten Neuentwicklung zu rechtfertigen ist.

Externer Kooperationspartner

Articy Software GmbH

Bearbeiter

Jonas Frenz

Abgabe

Ende 2017

Veröffentlicht: von

Problemstellung

Durch die stetig steigende Komplexität von Softwaresystemen und den damit verbundenen hohen und umfangreichen Kundenanforderungen im Bereich der funktionalen als auch nicht-funktionalen Anforderungen kann die Wahl einer geeigneten Architekturform erfolgsentscheidend für ein Projekt sein. Hierbei können die Ausprägungen der nicht-funktionalen Anforderungen, wie Funktionalität, Zuverlässigkeit, Benutzbarkeit, Effizienz, Wartbarkeit, Übertragbarkeit, als Anhaltspunkt für die passende Architektur dienen. Außerdem können die Anforderungen Ausschlag für die zu verwendenen Strukturen, Komponenten, Bibliotheken und Frameworks bei der Entwicklung geben.
Bei der Planung von JavaScript Web Applikation müssen diverse Entscheidungen früh im Projekt getroffen werden und wirken sich nachhaltig auf die Qualität der entwickelten Applikation aus. Die Entscheidungen betreffen zum einen die Frage, ob eine Client- oder Serverseitige-Architektur in Frage kommt und welchen internen Aufbau (Single-Page- oder Multi-Page-Applikation) der Client aufweisen soll. Darüber hinaus müssen passende JavaScript-Frameworks ausgewählt werden, um die gestellten Anforderungen möglichst einfach und kostengünstig umsetzen zu können.

Im Rahmen der Masterarbeit sollen daher bestehende Architekturmuster für JavaScript Web Applikationen betrachtet und miteinander verglichen werden. Des Weiteren sollen bestehende JavaScript Clients analysiert werden, um Gemeinsamkeiten in der Umsetzung der zugrunde liegenden Aufgabe und wiederkehrende Problemstellungen aufzudecken. Auf diese Weise soll eine Sammlung von Best-Practices für die Erstellung von JavaScript Clients herausgearbeitet werden.  Auf Grundlage der daraus gewonnen Erkenntnisse soll letztendlich eine Referenzarchitektur entstehen, die als Orientierungshilfe für die zu treffenden Architekturentscheidungen dient.

Abgeleitete Forschungsfrage

  • Welche typischen Aufgaben bestehen bei der Implementierung von JavaScript Clients und welches JavaScript-Framework eignet sich für welche Problemstellung?
  • Welche erprobten Architekturmuster existieren für JavaScript Clients und wie sieht deren Umsetzung in der Praxis aus?
  • Wie lässt sich eine Referenzarchitektur für JavaScript Clients definieren und wie sieht deren Umsetzung aus?

Vorgehen

Die erste Phase der Masterarbeit sieht die Einarbeitung in die Thematik vor. Dabei erfolgt die Auseinandersetzung mit der entsprechenden Fachliteratur im Bereich von bestehenden Architekturmustern, wie die Serviceorientierte Architektur (SOA), die Resource-oriented Client Architektur (ROCA) und die Qualitätssoftwarearchitektur (Quasar). Des Weiteren werden verschiedene Formen von Softwarearchitekturen bei JavaScript Web Apps betrachtet. Dabei liegt der Fokus auf den Unterschieden von Single-Page-, Multi-Page- sowie Echtzeitwebapplikationen und dem in diesem Zusammenhang eingesetzten Model-View-Controller-Pattern. Darüber hinaus werden verschiedene JavaScript-Frameworks untersucht, wobei sich die Auswahl der jeweiligen Frameworks hierbei an Frameworks, die bei Capgemini aktiv zum Einsatz kommen, orientiert.

Die zweite Phase befasst sich mit der Untersuchung von Architekturmustern und deren Umsetzung bei JavaScript Clients in der Praxis. Hierbei sollen Open Source Applikationen auf wiederkehrende Architekturmuster hin analysiert werden, um herauszufinden, welche typischen, wiederkehrenden Aufgaben bei der Erstellung von Clients existieren und wie diese durch den Einsatz von JavaScript-Frameworks unterstützt werden.

In der dritten Phase soll aus den zuvor gesammelten Analyseergebnissen eine Referenzarchitektur für JavaScript Clients erstellt werden. Dazu sollen die für eine Referenzarchitektur notwendigen Konventionen herausgearbeitet werden. Anschließend sollen, auf Grundlage dessen, die Definition einer Referenzarchitektur und eine abschließende praktische, exemplarische Anwendung der Referenzarchitektur an verschiedenen JavaScript-Frameworks erfolgen.

In der letzten Phase erfolgen die Ergebnissicherung und die wissenschaftliche Aufbereitung dessen in Form der Masterarbeit.

Externer Kooperationspartner

Capgemini Köln

Bearbeiter

Sebastian Domke

Abgabe

Ende 2017

Veröffentlicht: von

Problemstellung

In vielen Unternehmen werden Konfigurationsdateien verwendet, um Softwaremodule für ihren projektspezifischen Einsatz anzupassen. Das Erstellen von Konfigurationsdateien kann komplex sein und dadurch viel Zeit in Anspruch nehmen. Aus diesem Grund bietet es sich an, den Entwicklungsprozess durch Editoren zu unterstützen.

Die Konfigurationsdateien sind in der Regel unternehmensspezifisch. Das kann dazu führen, dass es notwendig wird, einen unternehmensspezifischen Editor zu erstellen, der die speziellen Anforderungen seines Einsatzkontextes abdeckt.

Die Arbeit soll sich mit einer Technologieauswahl für einen unternehmensspezifischen grafischen Editor befassen. Diese soll mittels eines Proof-of-Concept der kritischen,  unternehmensspezifischen Anforderungen an einen solchen Editor überprüft werden. Dabei soll insbesondere die Frage geklärt werden, ob (und wenn ja, wie) trotz der speziellen Anforderungen grafische Standard-Frameworks zum Einsatz kommen können, um die Entwicklungskosten zu minimieren.

Als Untersuchungsgegenstand dient das Anlagenvisualisierungsystem UniWare, mit dem der Materialfluss und Zustand der Anlagensteuerung eines Logistiksystems überwacht werden kann. Der zu erstellende Editor dient dazu, Uniware-Anlagenmodelle zu erstellen.

Abgeleitete Forschungsfrage

  • Welche Technologie bietet sich an, um einen grafischen Editor für Anlagemodelle zu realisieren? Ist eine Eigenentwicklung nötig, oder können Standard-Frameworks verwendet werden?
  • Welche Kompromisse ergeben sich durch Standard-Frameworks, und wie kann man deren Auswirkungen minimieren?

Vorgehen

Die Arbeit soll in drei Phasen unterteilt werden.

  1. Marktstudie: In der ersten Phase werden die kritischen Anforderungen an einen solchen grafischen Editor aufgestellt. Mit diesen Kriterien wird der Markt auf mögliche grafische Frameworks untersucht, mit deren Hilfe die Anforderungen von Unitechnik an einen grafischen Editor umgesetzt werden können.
  2. Make-or-Buy-Entscheidung: In der zweiten Phase soll auf der Basis der Marktstudie eine Technologieauswahl durchgeführt werden, die sich entweder für eine Eigenentwicklung oder die Realisierung mit einem Standard-Framework entscheidet. Für die Entscheidung wird ein Kosten-Nutzen-Kriteriensystem aufgestellt, gemäß dessen die Alternativen bewertet werden.
  3. Lösungsarchitektur und Proof-of-Concept: In der dritten Phase werden erfolgskritische Anforderungen ausgewählt und die Eignung der ausgewählten Technologie durch einen Prototypen überprüft. Auf Basis dieser Prüfung wird die Technologieauswahl noch einmal abschließend bewertet.

Externer Kooperationspartner

Unitechnik Systems GmbH

Bearbeiter

Florian Bornes

Abgabe

August 2017

Veröffentlicht: von

Problemstellung

Es gibt derzeit verschiedene Cloudanbieter sogenannter „Serverlessdienste“. Durch Nutzen dieser Dienste begibt man sich in eine gewisse Abhängigkeit des Anbieters. Ungeklärt ist jedoch, wie stark eine solche Abhängigkeit tatsächlich ist und mit welchem Aufwand eine Migration zu einem anderen Anbieter verbunden ist. Des Weiteren stellt sich in diesem Zusammenhang die Frage, ob man eine Serverlessarchitektur von vorne herein so planen kann, dass diese möglichst anbieterunabhängig ist bzw. mit möglichst minimalem Aufwand eine Migration durchgeführt werden kann. Dieses Problem soll exemplarisch am Projekt „OC|Expo-Experience“ untersucht werden. Das Projekt wurde in der AWS-Cloud entwickelt, als Vergleichsanbieter soll Microsoft Azure genutzt werden. Der Vergleich beschränkt sich hierbei auf die im Projekt verwendeten Dienste (API-Gateway, Lambda, DynamoDB und Cognito).

Abgeleitete Forschungsfrage

  • Wodurch unterscheiden sich die Serverlessdienste, insbesondere „Lambda“ von AWS und „Functions“ von Microsoft Azure, voneinander?
  • Ist ein Umzug von AWS nach Azure möglich? Wenn ja wie und mit welchem Aufwand? (am Bsp. von OC|Expo-Experience)
  • Wie kann man die Architektur von vorne herein so planen, dass diese möglichst anbieterunabhängig ist?
  • Wie stark (und warum) ist man bei Verwendung der o.g. Dienste an AWS gebunden?

Vorgehen

Zunächst einmal sollen die zentralen Dienste bei AWS und Azure miteinander verglichen werden, um zu ermitteln ob eine äquivalente Verwendung, und wenn ja wie, möglich ist.

Nach dieser ersten Recherche soll für das Projekt OC|Expo-Experience ermittelt und dokumentiert werden, welche Schritte bzw. Anpassungen für eine Migration nötig sind und welchen Aufwand dies (qualitativ) bedeutet. Für das „worst-case“-Szenario, dass ein Umzug nicht oder nur mit erheblichem Aufwand möglich ist, wird dies nachvollziehbar und begründet dokumentiert.

Auf Basis dieser Erkenntnisse sollen dann „good practices“ entwickelt werden, wie man von Beginn an eine möglichst hohe Anbieterunabhängigkeit erreichen kann.

Abschließend kann dann die Frage beantwortet werden, wie stark man sich unter Verwendung der o.g. Services an Amazon bindet.

Projektpartner

Opitz Consulting GmbH

Bearbeiter

Jannik Blähser

Abgabe

August 2017