Unser Interviewpartner Jonas von INTRAVIS
Dev-Interview mit Jonas
In unseren Dev-Interviews sprechen wir mit Entwickler:innen bei unterschiedlichsten Unternehmen. Heute spricht unser CTO Ilja mit Jonas, Technical Lead bei INTRAVIS – von Dev zu Dev.
Ilja: Hallo, Jonas! Ich bin Ilja, einer der Gründer von EntwicklerHeld.
Jonas: Hallo, Ilja!
Ilja: Hi, freut mich, dass du hier zu unserem Dev-Interview gekommen bist!
Jonas: Ja, ich bin sehr gespannt! Wir suchen ja schwerpunktmäßig in dem Bereich, für den ich mittlerweile zuständig bin. Seit drei Wochen bin ich nämlich Technical Lead von dem Team, das bei uns Cloud- und Industrie-4.0-Produkte entwickelt.
Ilja: Dann erzähl doch direkt, was man so bei INTRAVIS macht. Du hast ja schon deine leitende Position erwähnt.
Jonas: INTRAVIS ist ein Sondermaschinenbauer. Wir bauen industrielle Maschinen und Anlagen im Kunststoffverpackungsbereich. Wo es laut ist und quietscht auf dem Production Floor, dort werden unsere Maschinen verwendet. Wir bauen aber nicht nur die Maschinen, wir entwickeln auch die Software für diese. Eine besonders große Rolle spielt in diesem Bereich die Qualitätssicherung und Prüfung. Seit knapp 30 Jahren ist das auch unser Fokus, unser Bereich. Darin sind wir gut, mit diesem sind wir groß geworden und das ist unsere Welt. Die meisten unserer Prüfungen basieren auf Bildauswertung und Bildverarbeitung.
Natürlich haben wir uns auch neben der Qualitätssicherung mit der Zeit sehr viel Expertise angeeignet. Zum Beispiel in der Maschinensteuerung. Das ist eine Welt für sich. Aber wir haben auch Automatisierungsgruppen bei uns in der Software, die mit SPSen arbeiten. Auch eine geschlossene Welt, die für mich sehr fremd ist. (Lacht) Dann gibt es auch noch Human-Machine-Interfaces, womit man Nutzern ein Interface zur Verfügung stellt, was in der industriellen Welt auch ganz anders aussieht, als man das jetzt vielleicht von einer App oder so kennt.
Ilja: Das glaub ich. Und die Software, läuft die direkt dort vor Ort, quasi inhouse? Viele Unternehmen haben die Server ja abgeschottet und will man da etwas installieren, muss man immer vor Ort sein. Das macht es ja schwieriger.
Jonas: Oh, so weit war ich noch gar nicht mit der Historie von INTRAVIS. Also alles, was wir die Jahre gemacht haben, lief in der Maschine ab. Da ist ein dicker Rechner drin und alles passiert da drauf. Es gibt vielleicht eine Internetverbindung für das Team, um drauf zu kommen, aber das war es dann auch schon mit Connected. Also IoT kann man dazu nicht sagen. Dann kam uns aber die erste Produktidee für eine webbasierte Anwendung, um die Daten über die Produktion zu visualisieren. Und das war dann so eine On-Premises-Installation. Alles auf den Servern unserer Kunden mitsamt Datenbank aufgesetzt und was es noch so braucht. Aber davon sind wir mittlerweile weg. Jetzt haben wir den IntraVisualizer und der läuft komplett bei Amazon Web Services (AWS). Die Systeme wurden befähigt, eine Verbindung herzustellen und Daten hinzuschicken. Die Daten können wir in der AWS-Welt weiterverarbeiten und ein Frontend zur Visualisierung zur Verfügung stellen.
Ilja: Und wie war dein Werdegang bei INTRAVIS?
Jonas: Die meiste Zeit war ich selbst bei INTRAVIS Embedded System Engineer, also einem hardwarenahem Bereich und habe auch Elektronik entwickelt. Das Ganze ist immer mehr in den Firmware / Embedded Linux Bereich gegangen. Wir betreiben unsere Maschinen mit einem Embedded-Linux-Rechner. Und der jongliert sozusagen mit diesen Welten, die ich beschrieben habe. Die Industrieumgebung, wo alles superrobust und lange funktionieren soll, am besten nie geupdatet wird, weil: »Never change a running System!« Zu der Cloud-Welt, die ja total schnelllebig ist und man schnell mal ein Update hinschiebt, viel näher am Puls der Zeit. Und für das Vermitteln zwischen diesen zwei Welten war ich dann mit den Edge-Devices zuständig.
Ilja: Wie ging es dann weiter?
Jonas: Notgedrungen habe ich mir dann AWS auch noch angeeignet. Mit all seinen Tücken, die es nun mal mitbringt, muss man ja so sagen. Und vor drei Wochen habe ich dann die technische Leitung übernommen. Frontend-Geschichten sind aber gar nicht meine Welt, das habe ich schnell gemerkt.
Ilja: Okay, cool, das klingt spannend. Weil du ja grad AWS gesagt hast. Manchmal sagen die Firmen ja einfach: »Wir nutzen AWS – sprich, wir haben da VMs laufen und machen das gleiche, was wir vorher gemacht haben.« Wie ist das bei euch? Nutzt ihr die Möglichkeiten, die AWS zur Verfügung stellt?
Jonas: Mit allen Vor- und Nachteilen nutzen wir die AWS-Services, zu 100 Prozent. Die Vorteile sind auch wirklich viele. Ich meine, komplett skalierbare Zeitseriendatenbanken. Man schüttet einfach Daten rein und die werden weggeschrieben. An anderen Stellen greift man sich fast an den Kopf, weil man denkt: Das würde ich mit einer sehr kleinen VM hier sehr einfach gelöst kriegen, die dauerhaft läuft. Stattdessen immer den letzten Zustand aus der Datenbank abfragen. Total umständlich!
Ilja: Und wie ist das auf der Kundenseite? Merken die, dass ihr in der Cloud lauft? Nicht nur technisch, sondern auch von der Abrechnung her? Pro Prüfprozess oder dergleichen?
Jonas: Also das Lizenzierungsmodell ist schon so ausgelegt, dass wir da eine jährliche Lizenz abrechnen, welche die Kosten dann auch deckt. Ein größeres Problem ist, den Kunden davon zu überzeugen, dass die Daten ihr Werk verlassen. Es gibt Kunden, die wollen das partout gar nicht. Nach der Regel: »Kein Bit verlässt diese Halle!« Und wir sind noch immer Sondermaschinenbauer, nach wie vor! Damit verdienen wir unser täglich Brot, nicht mit Software-Integration. Mit diesem Produkt machen wir in diese Richtung grad die ersten Schritte. Da ist noch nicht der Anspruch, dass das die nächste Cashcow werden wird.
Ilja: Müsst ihr auch bedenken, dass das Produkt in der Werkshalle beim Kunden, also On-Premises laufen kann? Oder sagt ihr, die Zukunft entwickelt sich ohnehin in diese Richtung und dass ihr euch auf die Early Adopter konzentriert, für die das okay ist? Bei den anderen kann ja noch weiter das alte On-Premises-System genutzt werden. Wenn ich jetzt zum Beispiel als Entwickler oder Entwicklerin bei euch anfangen würde, wie viel Legacy hätte ich dann?
Jonas: Die alte On-Premises-Version läuft nur noch bei Kunden, die diese schon haben und wird da auch noch supportet. Wir verkaufen die nicht mehr neu. Vom alten Code ist ja nichts mehr übrig geblieben. Es war dann wirklich eine strategische Entscheidung. Cloud oder gar nicht! Allein schon wegen der steigenden Zahl von Kunden, da haben wir gar nicht die Kapazitäten, die On-Premises-Version zu warten.
Die höchste Devise ist immer: »Die Produktion muss weiterlaufen!«
Ilja: Man kann dann ja auch einfacher Updates einspielen, weil man nicht unbedingt vor Ort sein muss, oder?
Jonas: (Lacht) Ja, im Endeffekt ist das genau die Motivation für diese Edge-Device-Komponente. Wir können ja nicht einfach auf einem Gerät in der Produktionslinie ein Update aufspielen und dann steht die Produktion. Das kostet ja … in ein paar Minuten 3.000 €, in ein paar Stunden 10.000 € und dann sind es schnell 100.000 €. Die höchste Devise ist immer: »Die Produktion muss weiterlaufen!« Ganz, ganz klar! Mit dem Edge-Device haben wir uns da abgesichert, schlagen uns dann aber noch mit Kunden und IT rum, wegen der Verbindung nach draußen, aber das wird zum Glück weniger, weil wir hier schon Erfahrungen gesammelt haben und vorher Sachen klären können. Und von da ist es dann Cloud-Welt und dann ist dieser Teil schöner. (Lacht)
Ilja: Was ich ja auch interessant finde: Ihr seid ja in der Industrie in der Qualitätssicherung. Wie sichert ihr die Qualität eurer eigenen Software? Woher kommen neue Features? Wo kommt zum Beispiel der Code hin? Wie wird er ausgerollt? Passiert das alles automatisch oder manuell?
Jonas: Also erstmal, die nächsten Features, an denen wir arbeiten, kommen immer aus Diskussionen, die auch den Geschäftsführer mit einschließen. Er hat eine ganz gute Perspektive und klare Visionen. In Gesprächen kristallisieren wir die grobe Richtung raus und wissen, wohin es gehen soll, zum Beispiel sehr spezifische Notifications, wenn an der Maschine was ist. Das brechen wir auf einen Meilenstein herunter, mit unserer Iteration. Das brechen wir weiter runter auf GitLab-Issues, das ist unser Format, mit dem ein Entwickler dann auch gut arbeiten kann. Dann schreiben wir Specs für die Schnittstellen zwischen den einzelnen Komponenten. Da haben wir aus der Vergangenheit gelernt, denn früher hat jeder an verschiedenen Komponenten gearbeitet und erst dann haben wir uns um die Zusammenarbeit der Komponenten gekümmert. An diesem Punkt kann der Entwickler ein Feature implementieren und alles testen. Einzelne Komponenten werden relativ wenig getestet und auch nicht automatisch, aber man kann Testdaten hineinschicken und sehen, ob es klappt. Das Ausrollen kommt nach dem Abschluss eines Meilensteins. Noch nicht durch Continuous Integration und Deployment, sondern manuell, indem ein Release gebaut und bei AWS hochgeladen wird.
Ilja: Klingt nach einem sehr agilen Vorgehen und man kann schnell loslegen. Und man sagt ja immer, wichtig ist, das Richtige zu bauen, nicht irgendwas zu bauen! Macht man am Anfang schon Fehler, kann ja hinten auch nichts Gutes rauskommen. Die Bedürfnisse der Anwender sind unterschiedlich und die müssen berücksichtigt werden.
Jonas: Das ist auch für unser Team relevant. Der Hauptentwickler, der uns leider verlässt, hatte eine enge Feedback-Schleife, so nenne ich das jetzt mal, war viel mit Kunden in Kontakt und im Werk. Und ich würde das gern formalisieren und das nicht durch unseren Vertrieb ziehen und dann hört man vielleicht mal irgendwas, was nicht funktioniert und dann dauert das so lange, dass das Feedback wertlos ist. Wir müssen näher an die Kunden! Das ist eines meiner Ziele!
Ilja: Schön, finde ich gut! Kommen wir zu euren Programmiersprachen. C++, Frontend, React, Javascript, das steht in eurem Profil. Mit Frontend lasse ich dich zufrieden, weil du gesagt hast, du möchtest vielleicht nicht darüber reden. (Beide lachen)
Jonas: Ich habe mehr und mehr das Gefühl, man muss einfach ein guter Allrounder sein. Im Zusammenhang mit AWS gibt es gar nicht mehr so diese Kerntechnologien, die man da beherrschen muss. An einer Stelle kann man etwas mit Python programmieren. An einer anderen muss man in YAML deklarieren, wie was funktionieren soll. Und wo anders haben sie eine eigene SQL Engine aufgebaut und du musst dir jetzt irgendwie deren Syntax beibringen, die aber nicht dokumentiert ist. Es ist also nicht so, dass wenn du diese zwei Kerntechnologien (C++, JavaScript) beherrschst, sofort perfekt dafür geeignet bist. Die Datenverarbeitung auf unseren Systemen, das ist die C++-Welt. Ganz, ganz klar. Es gibt also keine Technologie A und B, mit der man für alles gewappnet ist.
Ilja: Also das beste Werkzeug für den Job suchen – sag ich mal – oder führt das zu zu viel Wildwuchs?
Jonas: Zum Glück haben wir nicht so viele Unstimmigkeiten an den Stellen, wo mehrere Leute wirklich an demselben Code arbeiten. Und wenn man nicht am selben Code arbeitet, definiert man die Schnittstellen dazwischen und alles ist gut.
Ilja: Ja, cool, verstehe ich. Ich habe am Ende immer eine provozierende Frage. Vielleicht hast du ja mitgekriegt, dass der CTO von Azure gesagt hat, dass C++ tot sei. Rust sei das neue C++ und jeder sollte nur noch in Rust schreiben. C++ hat seine Probleme, sonst wäre Rust ja nicht entstanden, aber wie siehst du das? Erzähl mal.
“C/C++ is deprecated” Quelle
Jonas: Also persönlich bin ich schon begeistert! Ich habe letztes Jahr hier ein Embedded-Projekt gestartet, das auf Rust basiert. Man wird bei Rust regelrecht gezwungen, die Dinge richtig zu machen. Man schlägt sich mit dem Borrow-Checker herum, aber wenn er zufrieden ist, funktioniert auch alles. Aber es ist eine ganz schöne Lernkurve, auf jeden Fall! Aber was Firmen angeht, im Embedded-Bereich, sind wir so weit hinterher, dass es so schnell nicht gehen wird, dass Entwickler schnell genug kompetent darin werden. Auch bei der Bildverarbeitung von INTRAVIS sehe ich das ähnlich. Sehr alte Welt, sehr viel Legacy. Und wir haben wenig Systemprogrammierung, wo Rust einfach gut ist, also sehe ich da gar nicht so die Notwendigkeit.
Ilja: Schön, dass jemand mal sagt, dass es sterben wird, aber ganz, ganz langsam.
Jonas: Ja! Ich komme aus der Elektronik und bin in die Cloud-Welt und an dieser Achse kann man die Schnelllebigkeit bemessen. In der Elektronikwelt gibt es Innovation, aber ganz gemächlich und es dauert bis das wirklich ankommt. In der Cloud-Welt muss man eher aufpassen, dass AWS nicht einem wieder unterm Hintern was weggeupdatet hat und man gar nicht hinterherkommt. Im Frontend ist es ja nicht so sehr, dass man gezwungen wird durch den Provider, sondern die Welt ist einfach schnelllebig. Die Entwickler:innen sind es gewohnt alles 6 Monate das Framework zu wechseln. (Lacht)
Ilja: Und dann bleibt nur noch eine abschließende Frage: Kaffee oder Tee?
Jonas: Ich trink Kaffee.
Ilja: Sehr gut!
Jonas: Aber ich weiß, dass wir sehr tolerant sind in der Firma und eine große Tee-Schublade haben.
Ilja: Ja, Toleranz ist immer gut! (Beide lachen) Jonas, hat mir Spaß gemacht!
Jonas: Mir auch, danke!
Über Intravis
Unser Firmenmotto “Wir lösen Probleme. Bevor sie entstehen.” trifft sowohl auf unsere Produktpalette schlüsselfertiger Systeme zur Qualitätskontrolle wie auch auf unsere Arbeit als Softwareentwickler zu. Mit Cutting-Edge-Technologien realisieren wir anspruchsvolle Bildverarbeitungssysteme und SaaS-Lösungen zur Qualitäts- und Prozessoptimierung und damit zu Kosteneinsparungen bei unseren Kunden und mehr Nachhaltigkeit im Bereich der Kunststoffverpackungen.
Wir beschäftigen uns schon heute mit Themen, die in den nächsten Jahren zu Herausforderungen für die Industrie werden. Wir fragen uns: Wie können optische Inspektionssysteme in Zukunft einen Mehrwert für den Produktionsprozess liefern? Welchen Beitrag leisten Qualitätsprüfungslösungen für die intelligente Fabrik der Zukunft? Wie können Inspektionssysteme und Analysesoftware helfen, die Produktionseffizienz zu steigern? Gemeinsam mit Kunden und Partnern darauf Antworten zu finden, treibt uns jeden Tag an.
