Vom ersten Website‑Auftrag zur AWS‑Serverless‑Architektur: Die Entwicklerreise von Igor Rusinov (Lead Back End Engineer, TourRadar GmbH)

Einleitung: Eine Karriere, die mit Neugier begann

In der Session "Igor Rusinov, Lead Back End Engineer at TourRadar" mit Speaker Igor Rusinov von TourRadar GmbH erleben wir eine klare, bodenständige Entwicklergeschichte: vom ersten Zugang zum unbegrenzten Internet an der Universität bis hin zur Verantwortung für skalierbare, wartbare Systeme in einer Serverless‑Welt auf AWS. Was uns als Redaktion von DevJobs.at beeindruckt: Diese Reise ist kein Zufall und keine Abkürzung, sondern das Ergebnis konsequenter Neugier, Praxisnähe und der Fähigkeit, mehrere Schritte vorauszudenken.

Mit dieser Beobachtung setzt Rusinov den Ton: Lernen geschieht dort, wo Fragen entstehen — und wo man Antworten praktisch erproben kann. Seine Geschichte liefert dabei drei große Leitmotive für Entwickler:innen:

• Lernen durch Tun, nicht nur durch Theorie.
• Vorausschauen und die Auswirkungen technischer Entscheidungen auf Teams und Systeme mitdenken.
• Technologien wählen, die Geschwindigkeit, Skalierbarkeit und Kosten realistisch ausbalancieren — in seinem Fall: Serverless auf AWS.

Der Ursprung: Unbegrenztes Internet, unbegrenzte Fragen

Als Igor Rusinov an der Universität zum ersten Mal freien Zugang zum Internet bekam, stellte sich nicht nur die Frage, was das Netz ist — sondern wie es funktioniert und wie man darin Dinge baut. Diese Haltung prägte sein Fundament als Entwickler.

Es sind zwei Details, die wir hervorheben möchten:

• Er richtete seinen Fokus früh auf Websprachen, die das Bauen ermöglichen: PHP und JavaScript. Nicht, weil sie „hip“ sind, sondern weil sie konkret Probleme lösen.
• Er nutzte frei verfügbare Ressourcen — Artikel, Bücher — und verband sie zügig mit praktischen Übungen.

Diese Mischung aus Theorie und Praxis ist kein Zufallsprodukt, sondern der erste Baustein für nachhaltiges technisches Verständnis.

Vom Hobby zum ersten Auftrag: „In ein paar Monaten hatte ich meinen ersten Kunden“

Innerhalb weniger Monate wechselte der Status vom Lernprojekt zur echten Auftragsarbeit:

Damit ergibt sich eine frühe Lektion, die viele Entwickler:innen kennen: Nichts motiviert stärker als ein fertiges Produkt in den Händen eines realen Nutzers oder Kunden. Es zwingt zur Qualität, zur Zuverlässigkeit — und zur Kommunikation. Die ersten Aufträge sind selten perfekt, aber sie bringen die Eigendynamik, die weiteren Lernschritte beschleunigt.

Der Übergang ins Berufsleben: Professionalisierung und Qualitätsdenken

Nach dem Studium ging es für Rusinov in eine Vollzeitanstellung als Webentwickler — und damit hinein in die Disziplinen, die Software langfristig tragen:

Das ist wichtig: Architektur, Tests und Codequalität sind keine dekorativen Extras. Sie sind die Werkzeuge, um Systeme zu bauen, die wachsen, Teamarbeit erlauben und sich über Jahre hinweg weiterentwickeln.

Drei Professionalitätsanker aus dieser Phase

• Codequalität als Teamvertrag: Nicht nur „funktioniert“, sondern „ist verständlich, testbar, änderbar“.
• Unit‑Tests als Sicherheitsnetz: Veränderungen ermöglichen, ohne ständig erstes Fundament zu gefährden.
• Architektur als Orientierung: Entscheidungen haben Konsequenzen — für Performance, Wartbarkeit und Teamzuschnitt.

Sechs Jahre TourRadar: Verantwortung als Lead Back End Engineer

Nach einigen Jahren wechselte Igor Rusinov zu TourRadar und ist dort seit sechs Jahren tätig. Heute ist er Lead Back End Engineer — eine Rolle, die nicht nur „mehr Code“, sondern vor allem „mehr Verantwortung“ bedeutet.

Diese End‑to‑End‑Verantwortung prägt den Alltag deutlich. Es geht nicht nur darum, Features zu liefern, sondern die Richtung vorzugeben — technologisch, prozessual und kommunikativ.

Vorausdenken als Pflicht: Skalierbarkeit und Wartbarkeit als Leitlinien

Besonders prägnant ist seine Beschreibung der mentalen Arbeit im Lead‑Alltag:

Skalierbarkeit ist dabei nicht nur „mehr Last aushalten“, sondern auch Team‑Skalierung: Wie leicht können Kolleg:innen Änderungen nachvollziehen? Wie minimiert man Abhängigkeiten? Wie reduziert man Betriebsaufwand? Wartbarkeit schließt Namensgebung, Modulgrenzen, Testbarkeit, Migrationspfade und dokumentierte Entscheidungen ein — der Stoff, aus dem schnelle Iterationen sind.

Arbeit über Teamgrenzen hinweg: Auswirkungen antizipieren und koordinieren

Leads arbeiten selten in Isolation. Änderungen in einem Systembereich strahlen auf andere Teams aus:

Diese Sätze klingen unspektakulär, doch sie sind das Rückgrat produktiver Organisationen. Wer Auswirkungen antizipiert, reduziert Reibung. Wer früh kommuniziert, vermeidet teure Überraschungen. Wer Koordination übernimmt, beschleunigt die Gesamtorganisation.

Praktiken, die wir aus dieser Haltung ableiten

• Frühzeitige Impact‑Analyse bei großen Änderungen: Wer ist betroffen? Welche Schnittstellen? Welche Deploy‑Fenster?
• Gemeinsame Konzepte und Migrationspfade: Schriftlich festhalten, was geändert wird und wie Teams folgen können.
• Cross‑Team‑Rituale: Regelmäßige Syncs, um technische Initiativen synchron zu halten.

Technischer Fokus: Mehr und mehr Serverless

TourRadar setzt, wie Rusinov erzählt, verstärkt auf Serverless‑Anwendungen. Für ihn ist das Konzept spannend und hilfreich.

Diese Argumente sind klassisch — und im Kontext wachsender Produktlandschaften äußerst relevant. Serverless verschiebt Verantwortlichkeiten von „Servern managen“ zu „Workflows und Funktionen designen“.

AWS als Plattform: Die konkreten Bausteine

Da TourRadar alles auf AWS hostet, setzt das Team auf den zugehörigen Serverless‑Baukasten:

Bemerkenswert ist die Bandbreite: Von stateless Compute (Lambda) über NoSQL‑Speicher (DynamoDB) bis zu Orchestrierung (Step Functions) und Schnittstellen (API Gateway). Der gemeinsame Nenner ist klar: Bausteine kombinieren, nicht Infrastruktur pflegen.

Warum diese Kombination Sinn ergibt

• Lambda Functions: Ereignisgesteuertes, skalierbares Ausführen von Logik ohne Serververwaltung.
• DynamoDB: Managed NoSQL mit Konsistenz‑ und Skalierungsoptionen, die zu Serverless‑Workloads passen.
• Storage: Persistenz, die nicht an Serverinstanzen gebunden ist.
• Step Functions: Visuelle/definierte Workflows, die komplexe Prozesse entkoppeln und robust machen.
• API Gateway: Schnittstellen als „Produkt“, zentral verwaltet und gesichert.

All das fügt sich zu Systemen, die schnell entstehen und wachsen können — bei planbaren Betriebskosten.

Lernen durch Tun: Der pragmatische Lernpfad

Rusinovs Lernphilosophie ist konsequent praxisorientiert.

Wichtig ist ihm dabei der Moment des Fertigstellens: Ein kleines, funktionierendes Produkt erzeugt Momentum. Es schafft Selbstvertrauen, Neugier — und den nächsten Schritt.

Warum Tutorials, die nicht „out of the box“ funktionieren, gut sind

Rusinov spricht einen Punkt an, den wir alle kennen:

Gerade diese Reibung ist wertvoll. Sie zwingt zu Verständnis, Fehlersuche, Lesen der Primärquellen. So entsteht belastbares Wissen — nicht nur „Rezeptwissen“.

Wähle dein Feld: Motivation ist der Motor

Bevor es losgeht, rät Rusinov, das eigene Interesse zu fokussieren.

Das ist mehr als ein Motivationsspruch. Wer ein Feld wählt, in dem echte Neugier besteht, bleibt länger dran, investiert tiefer und baut schneller Verständnis auf. Motivation schlägt reine Disziplin — vor allem über Jahre.

Up‑to‑date bleiben: Arbeit als Hauptquelle, ergänzt durch Medien

Wie bleibt man am Ball? Für Rusinov liefert der Job selbst das wichtigste Lernfeld:

Das gilt besonders in Umgebungen, die bewusst Innovation zulassen: Wer kontinuierlich Evaluierungen vornimmt, kann neue Technologien im Kontext echter Anforderungen testen. Darüber hinaus nutzt Rusinov klassische Kanäle:

Praktische Routinen für kontinuierliches Lernen

• Systemverbesserungen als „Lernvehikel“: Jede Optimierung ist ein Mini‑Projekt mit neuen Techniken.
• Kuratierte Newsletter: Relevante Signale im Rauschen, speziell zu AWS, PHP und den genutzten Frameworks.
• Bücher und Videos: Tiefgang und Kontext, der über Release‑Notes hinausgeht.

Handfeste Takeaways für Entwickler:innen und Teams

Aus der Session „Igor Rusinov, Lead Back End Engineer at TourRadar“ lassen sich konkrete Leitlinien ableiten — ohne Hokuspokus, dafür mit Wirkung:

• Starte klein, aber baue wirklich: Ein Tutorial, das in Stunden zu etwas Funktionierendem führt, ist Gold wert.
• Nutze Probleme als Lernchance: Wenn etwas nicht „out of the box“ klappt, entsteht das echte Verständnis.
• Denke ein paar Schritte voraus: Frage nicht nur „Was brauche ich heute?“, sondern „Was bedeutet das in sechs Monaten für Skalierung und Wartung?“
• Kommuniziere Auswirkungen: Wenn Änderungen andere Teams betreffen könnten, sprich früh, dokumentiere Migrationspfade und koordiniere.
• Lege Qualität früh fest: Codequalität, Unit‑Tests und Architektur sind die Grundlagen, die Tempo ermöglichen.
• Wähle Technologien, die zur Realität passen: Serverless kann Geschwindigkeit und Kosten vereinen — vor allem in Kombination mit Services wie Lambda, DynamoDB, Step Functions und API Gateway.
• Lerne im Job und daneben: Verbesserungsinitiativen am Produkt plus Newsletter/Bücher/Videos halten dich zuverlässig auf dem neuesten Stand.

Von der Idee zur Umsetzung: Der rote Faden in Rusinovs Arbeit

Was die Erzählung zusammenhält, ist der kontinuierliche Bogen „von der Idee zum Code“:

Das ist nicht nur eine Jobbeschreibung, sondern eine Einstellung zur Arbeit: Lösungen ganzheitlich denken, mit klaren Zielen, konkreten Kosten/Nutzen‑Abwägungen und einem Blick auf die Zukunftsfähigkeit. Genau hier steht Serverless exemplarisch: Man konstruiert Workflows aus Bausteinen, anstatt Infrastruktur zu zähmen.

Ein Blick auf den Alltag eines Leads: Entscheidungen als Multiplikator

Während der Code weiterhin zählt, werden Entscheidungen im Lead‑Alltag zum großen Hebel. Welche Services nutzt man? Wie schneidet man Systeme? Wie führt man Teams durch Änderungen? Jede Antwort beeinflusst Geschwindigkeit, Zuverlässigkeit und die Zufriedenheit der Kolleg:innen.

Rusinnovs Betonung auf Skalierbarkeit, Wartbarkeit und Kommunikation ist eine Erinnerung: Gute technische Führung ist vor allem gutes Vorausdenken und gutes Erklären. Nichts davon ist spektakulär — aber alles davon macht Teams schnell und Produkte robust.

Die Wirkung von Serverless richtig einordnen

Serverless ist kein Selbstzweck, sondern ein Mittel, um schneller Wert zu liefern und Betrieb zu vereinfachen. In Rusinovs Worten zeigt sich das pragmatisch:

Für viele Teams bedeutet das: weniger Kapazitätsplanung, weniger „undifferenzierte Schwerarbeit“ und mehr Fokus auf die Geschäftslogik. In der Praxis sind Design, Datenmodellierung und Orchestrierung die entscheidenden Kompetenzen — Kompetenzen, die Rusinov ausdrücklich in den Mittelpunkt stellt.

Lernen als Dauerzustand: Motivation, Reibung, Routine

Die Karriere von Igor Rusinov beginnt mit Neugier, setzt sich über frühe Kundenarbeit fort und reift in einer Rolle, die Produkt, Architektur und Teamarbeit verbindet. Das verbindende Muster:

• Motivation durch eigenes Interesse am Feld (Web, Games, Mobile — Hauptsache, es reizt dich).
• Lernen durch greifbare Ergebnisse (kleine Apps, die in Stunden entstehen und funktionieren).
• Reibung als Lehrmeister (Tutorials, die nicht sofort laufen, zwingen zum Verstehen).
• Berufliche Umgebung als Labor (Verbesserungen am System als Anlass, Neues auszuprobieren).

Schluss: Eine klare Blaupause für nachhaltiges Entwickeln

„Igor Rusinov, Lead Back End Engineer at TourRadar“ ist weniger eine Heldengeschichte als eine Blaupause für nachhaltige Entwicklungskarrieren. Finde das Feld, das dich wirklich interessiert. Baue früh etwas, das funktioniert. Nimm Qualität ernst. Denke voraus — für Skalierbarkeit, Wartbarkeit und Teamzusammenarbeit. Nutze Plattformen wie AWS, um dich auf das zu konzentrieren, was zählt: Funktionen und Workflows, die Wert schaffen.

Oder kurz in seinen eigenen Worten:

Diese Motivation — gepaart mit professioneller Strenge und einem gesunden Blick auf Technologieauswahl — macht aus Neugier nachhaltigen Impact.

• 

  

  Alberto Azambuja Neto, Product Manager at TourRadar

  Der Product Manager bei TourRadar Alberto Azambuja Neto erzählt im Interview über den Aufbau der Devteams, wie der Recuitment- und Onboarding-Prozess abläuft und welche Technologien Einsatz finden.

  Jetzt ansehen