Bright IT: Webentwicklung - Damals und Heute

Interview mit Arkadiusz Gryczka, Senior Developer bei Bright IT

IT und Webentwicklung entwickeln sich ständig weiter. Erfahrene Entwickler haben gesehen, wie sich die Branche verändert hat. Sie haben neue Wege zum Testen, Analysieren und Implementieren neuer Tools erlernt, um robuste Front- und Backend-IT-Services zu liefern.

In den letzten Jahren zeigte sich ein branchenweiter Trend hin zu Microservices und Headless-Architekturen. Viele Entwickler haben sich außerdem von monolithischen Architekturen entfernt. Andere Ansätze und Technologien wie API-first, GraphQL und AWS (Amazon Web Services) haben sich ebenfalls etabliert, um das Arbeiten für Entwickler einfacher und effizienter zu gestalten. 

Arkadiusz Gryczka, Senior Developer bei Bright IT, entwickelt seit über fünfzehn Jahren und hat im Laufe seiner Karriere viele Transformationen erlebt. Ich hatte die Gelegenheit, mit ihm über die Zukunft der IT-Services, die Entwicklung der Branche und seine Gedanken zu aktuellen IT-Trends zu sprechen.

Welche Programmiersprachen verwendest du heutzutage, und welche ist deine bevorzugte Sprache?

Arkadiusz Gryzcka: Das ist eine gute Frage, die auch zeigt, wie sich die Branche in den letzten ein oder zwei Jahrzehnten entwickelt hat. Bevor ich bei Bright IT anfing, war meine primäre Programmiersprache Java und Java EE (Enterprise Edition) in Verbindung mit deren Spezifikationen, insbesondere EJB, JPA und JSF. Als ich bei Bright IT anfing, begann ich ein Abenteuer mit einer völlig neuen Sprache - eine willkommene Herausforderung. Obwohl ich immer noch das Java-Ökosystem oder auch nur die JVM nutzte, meinte ich damit SCALA. Diese Sprache war zunächst auf den akademischen Bereich beschränkt, entwickelte sich aber zu einer leistungsfähigen Alternative zu anderen "langatmigen" Java-Sprachen für Geschäftsanwendungen. SCALA ist eine interessante Sprache, weil man sich knapper fassen kann und der Code als Java EE-Anwendung integriert und ausgeführt werden kann. Das erhöht die Effizienz und reduziert die Redundanz. Ein weiterer Vorteil von SCALA ist, dass es viele "leichtere" Lösungen und Frameworks bietet, die die Entwicklung vereinfachen, indem sie notwendige Abstraktionen bereitstellen und die Arbeit innerhalb vieler verschiedener Problemklassen standardisieren. Die kurze Antwort auf deine Frage wäre also, dass ich lieber in SCALA programmiere.

Was sind einige der Tools, die du am häufigsten verwendest?

AG: Wie die meisten Entwickler ist mein primäres Werkzeug die IDE oder integrierte Entwicklungsumgebung. Darüber hinaus bestimmt in der Regel das jeweilige Projekt an dem ich arbeite, was ich verwenden werde, um das beste Endprodukt zu liefern. Wenn ich zum Beispiel mit einem Datenbank-lastigen Projekt arbeite, ist es hilfreich, eine Benutzeroberfläche zu haben, die die Visualisierung der Ergebnisse von Suchanfragen verbessert. Natürlich verwende ich in der Regel auch einen Webbrowser, der mit der Google-Suche ausgestattet ist.

Was gefällt dir am besten an deiner Rolle als Entwickler?

AG: Ich habe einen analytischen Verstand, was einer der Gründe ist, warum ich mich für den Beruf des Entwicklers entschieden habe. Das Finden von logischen Lösungen für komplexe Probleme und die konsistente Umsetzung ist sehr erfüllend und eine der Hauptaufgaben eines Entwicklers. Da sich die IT ständig weiterentwickelt, genieße ich es, immer auf dem neuesten Stand zu sein und meine Zeit damit zu verbringen, neue Fähigkeiten und Programmiersprachen zu lernen. Außerdem liebe ich die Flexibilität, die mir dieser Beruf gibt; als Entwickler kann ich im Grunde von überall aus arbeiten, solange ich Zugang zum Internet habe.

Gibt es etwas, das dir als Entwickler keinen Spaß macht?

AG: Ha! Insgesamt nein. Na gut… manchmal können Meetings überflüssig sein. Leute, die keine IT-Profis sind, verstehen oft nicht ganz unsere Rolle oder was wir tun. Das kann auch frustrierend sein. Ich würde nicht sagen, dass ich es mag, wenn sich Leute über unsere UI/UX (User Interface/User Experience) beschweren, gerade wenn sie keine Ahnung haben, wovon sie reden. Abgesehen davon hat die Rolle des Entwicklers, wie jeder Beruf, seine Vor- und Nachteile, aber für mich sind es hauptsächlich die Vorteile.

Wie hat sich die Branche verändert, seit du angefangen hast?

AG: Die größte Veränderung war, dass viele der Probleme, mit denen wir konfrontiert waren, als ich anfing, jetzt umfassende Lösungen haben. Es gibt jetzt auch mehr Standards: Tech-Giganten wie Google, Amazon und Facebook haben Sprachen etabliert und neue Frameworks entwickelt, die wertvolle Webdienste bereitstellen. Auch der Entwicklungsprozess selbst hat sich verändert. Als ich anfing, musste jeder Umfang der Dokumentation vom Kunden genehmigt werden, aber die neuen AGILE-Leitsätze erlauben es, Anforderungsspezifikationen komplett zu ändern. Zusätzliche Projektdokumentation ist leichter aktuell zu halten und Arbeitsmanagement-Tools wie JIRA vereinfachen das Aufgabenmanagement. Diese Kombination ermöglicht es, potenzielle Bedrohungen früher zu erkennen, so dass man effektiv reagieren kann.

In den letzten Jahren gab es einen Trend von monolithischen Architekturen zu Headless und Microservices. Kannst du die Unterschiede zwischen diesen drei Ansätzen/Architekturen erklären?

AG: Eine monolithische Architektur beinhaltet ein ganzes System auf einer Anwendung, und sowohl Frontend als auch Backend arbeiten als eine einzige Serveranwendung. Im Allgemeinen gibt es in einem Headless-System kein GUI (Graphical User Interface), sodass die Systeme über eine API kommunizieren und zusammenarbeiten. Microservices bauen das System als einen losen Satz von zusammenarbeitenden Diensten mit synchroner oder asynchroner Kommunikation auf.

Angenommen, du müsstest diese verschiedenen Ansätze einer Person ohne technischem Hintergrundwissen beschreiben, was würdest du sagen?

AG: Nehmen wir an, du und deine Freunde gründen ein kleines Geschäft. Ihr kauft die notwendigen Werkzeuge, Maschinen und Fertigungsanlagen und jeder Beteiligte bringt eine andere Fähigkeit mit. Um Geld zu sparen, beschließt ihr, diese zusätzlichen Fähigkeiten zu nutzen. Also beginnt jemand mit der Auslieferung, jemand anderes macht die Buchhaltung und eine weitere Person kümmert sich um den Verkauf. In diesem Fall habt ihr eine monolithische Struktur aufgebaut, die nicht zu 100 % funktionieren kann, wenn eine Person abwesend ist.

Nehmen wir nun an, dieses Geschäft entwickelt sich zu einem größeren Unternehmen und ihr müsst euer Vertriebsteam auslagern, um euch auf das Tagesgeschäft zu konzentrieren. Ihr stellt also ein externes Buchhaltungsteam ein und kümmert euch nicht darum, wie es seine Arbeit macht, sondern nur darum, dass es einen guten Service liefert. So wird euer Geschäft zu einem Headless-System, bei dem eure Mitarbeit notwendig ist, aber wie die Buchhaltungsfirma im Hintergrund arbeitet, hat keinen Einfluss auf den Erfolg oder den Betrieb eures Unternehmens.

Wenn das Unternehmen wächst, findet ihr euch mit spezialisierten Teams wieder. Einige arbeiten an der Produktionslinie, andere kümmern sich um die Lieferlogistik. Ihr habt Verkaufsteams und Manager für jede Abteilung. Ihr beschließt, dass das Verkaufsteam nicht allzu viel über die Produktionslinie wissen muss und umgekehrt; sie arbeiten unabhängig voneinander. Wenn nun also ein Auslieferungsfahrer krank ist, steht euer Betrieb nicht still, und euer Vertriebsteam erfährt nicht einmal, dass dies passiert ist. Alles funktioniert unabhängig voneinander, so dass ein reibungsloser Betrieb gewährleistet ist; Das ist jetzt ein Microservices-System.

Gehören monolithische Systeme bald der Vergangenheit an?

AG: Das glaube ich nicht unbedingt. Es gibt viele Fälle, in denen die Erstellung und Pflege eines Microservices-Systems aufgrund des Projektumfangs nicht notwendig ist. Ich denke, dass Headless-Systeme populärer werden, ebenso wie die Trennung der Frontend-Entwicklung.

Gibt es einen "One-size-fits-all"-Ansatz?

AG: Architekturen und Technologien, die wir verwenden, basieren immer auf funktionalen und nicht-funktionalen Anforderungen und erfordern eine separate Analyse. Es gibt also keine Möglichkeit, ein System zu haben, das auf jedes Projekt zugeschnitten ist, da jedes Projekt seine spezifischen Herausforderungen aufweist, und die Identifizierung des besten Ansatzes ist eine der wichtigsten Aufgaben des Entwicklerteams.

Wie hat die Abkehr von monolithischen Systemen deine Arbeit beeinflusst?

AG: Ich habe an Projekten gearbeitet, bei denen zahlreiche Systeme zum Einsatz kamen, und selbst in monolithischen Systemen verwendet man immer noch neue Ansätze. Es ist also nicht immer das System, das die Technologie beeinflusst, sondern der größte Unterschied liegt in der Architektur, für die man ein talentiertes DevOps-Team braucht.

Kannst du neben den bereits erwähnten Systemen einige andere neuere Beispiele nennen?

AG: Es gibt API First, ein Ansatz, bei dem das Design und die Entwicklung einer Anwendungsprogrammierschnittstelle vor der Implementierung vorbereitet werden. GraphQL ist eine leistungsstarke Abfragesprache, die die API standardisiert und es ermöglicht, nur relevante Daten abzufragen. GraphQL API verwendet JSON als Abfrage- und Datenformat und ist flexibler im Vergleich zur einfachen REST API. AWS - Amazon Web Services ist ein umfangreicher Satz von Cloud-Diensten, mit denen man alle Arten von Systemen ohne eigene IT-Infrastruktur aufbauen kann. So kann man sich auf den Kern der geschäftlichen Anforderungen oder Lösungen konzentrieren, anstatt sich mit bekannten und definierten Herausforderungen in Bezug auf Hardwareressourcen oder Leistung, Backups, Serververwaltung usw. herum zu schlagen.

Wie hängt das alles zusammen und passt in das Gesamtbild?

AG: Diese Konzepte wurden eingeführt, um reale Herausforderungen zu lösen, als sich neue Ansätze für die Softwareentwicklung entwickelten. Keines davon ist ein Allheilmittel, und jedes Projekt ist anders. Daher müssen IT-Lösungen die Bedürfnisse des Kunden ausgleichen und das beste System für das jeweilige Projekt bieten. Es ist die Aufgabe des Entwicklerteams, die beste Wahl zu treffen, auch wenn das Marketing manchmal anderer Meinung ist.

Abgesehen von neuen Abfragesprachen, Hosting-Möglichkeiten und Entwicklungsansätzen, was sind einige andere Fortschritte?

AG: Mit den jüngsten Fortschritten tauchen neue Herausforderungen auf, und wir lernen ständig, wie wir sie erkennen und effektiv angehen können. Ich möchte an dieser Stelle nicht mit zu vielen Details langweilen, aber manchmal müssen wir als Entwickler unser Denken über das System komplett ändern. Zum Beispiel können QCRS (Command and Query Responsibility Segregation) und Event Sourcing von Microservices genutzt werden, um sie skalierbarer zu machen. Aber wir müssen in der Lage sein, mit Daten aus Read-Modellen zu arbeiten, die nicht immer auf dem neuesten Stand sind.

Fazit

Sowohl die Front- als auch die Backend-Entwicklung und UI/UX haben sich verändert, und für die Webentwickler von Bright IT ist es von größter Bedeutung, immer auf dem neuesten Stand zu sein. Die Fähigkeit zur automatischen Skalierung war eine der bedeutendsten Veränderungen in der IT-Entwicklung des letzten Jahrzehnts, und diese robusten Architekturen helfen Unternehmen jeder Größe, Zuverlässigkeit und starke Leistung zu gewährleisten.

Arkadiusz Gryzcka hat kürzlich bei der Umsetzung der neuen Website für Swarovski Optik mitgearbeitet, bei der ein Headless- und Serverless-Ansatz zum Einsatz kam. Dieses neuartige System ist die nächste Evolution für Cloud-basierte Systeme und stellt eine große Veränderung für UI/UX sowie Front- und Backend-Entwicklung dar. Im zweiten Teil unseres Interviews erläutert er die Vorteile und Überlegungen hinter dem System anhand des Relaunches der Webseite von Swarovski Optik.