Markus Kollers

Hi, ich bin Markus. Ich entwickel Cloud-native Software, meistens Web-basiert, lerne gerne neue Technologien kennen und realisiere innovative Projekte.

Über mich

Seit knapp 10 Jahren bin ich in der Softwareentwicklung tätig, habe eine Berufsausbildung zum Fachinformatiker Anwendungsentwicklung abgeschlossen und ein Studium als Diplom-Wirtschaftsinformatiker (Fachhochschule) absolviert. Softwareentwicklung ist nicht nur mein Beruf, sondern auch meine Leidenschaft. So habe ich mich schon während meiner Ausbildung in meiner Freizeit kontinuierlich mit neuen Themen und Technologien beschäftigt und dies bis heute fortgeführt.

Dabei hat mich nie ein spezifischer Teil in der Kette der Softwareentwicklung interessiert, sondern immer das große Ganze. Jeder der schon einmal komplett auf sich selbst gestellt ein Softwareprojekt realisiert hat weiß, dass er sich nicht auf das Frontend, Backend oder Datenbanken alleine fokussieren kann. Niemand nimmt einem dabei die anderen Aufgaben ab, man muss sich um alles selber kümmern. Aus diesem Grund habe ich Erfahrung in allen Bereichen der Softwareentwicklung sammeln dürfen oder viel mehr müssen. Selbstverständlich kann man sich nicht mit allen Aspekten und Variationen der Softwareentwicklung auskennen und von sich behaupten auf allen ein Experte zu sein. Natürlich habe auch ich Spezialgebiete und Themen auf denen ich mich nicht oder nur wenig auskenne. Einige Bereiche stehen noch auf meiner To-do-Liste, andere habe ich subventioniert und mich stattdessen auf Alternativen fokussiert.

Webentwicklung

Mein Spezialgebiet liegt dabei ganz klar in der Webentwicklung. Ich war schon immer ein Verfechter des World Wide Web, da es eine Geräte- und Betriebssystemunabhängige Plattform darstellt. Das Web schließt niemanden aus, nur weil er lieber mit Linux oder Mac arbeitet, oder keine Administrationsrechte auf seinem Firmenrechner besitzt. Trotz vieler Versuche plattformunabhängige Sprachen und Frameworks zu schaffen, ist es keiner Technologie so gut gelungen wie dem Web. Dank moderner Browser, JavaScript-Frameworks und weiterer Technologien lassen sich inzwischen genauso mächtige Anwendungen im Web bauen, wie sie früher nur mit nativen Anwendungen denkbar waren. Und das ökonomisch wesentlich effizienter als es die Entwicklung einer nativen Anwendung für mehrere Geräte und Betriebssysteme wäre.

Zu Beginn habe ich noch mit serverseitigem Rendering mit PHP oder ASP.NET gekämpft, dann aber nach Erscheinen von AngularJS auf Single Page Applications gewechselt. Von Anfang an war ich von der Reaktionsfreudigkeit und Skalierbarkeit eines Architekturmodells mit Client-seitigem Rendering begeistert. Dabei bin ich dem Angular-Framework treu geblieben und habe seit Erscheinen der Beta von Angular 2 auf die neue Version des Frameworks gewechselt und seitdem mehrere Projekte mit Angular realisiert. Mit inzwischen fast drei Jahren Erfahrung und dem Erscheinen von Angular 8 kann ich Erfahrung in der Umsetzung und Optimierung von Enterprise-Anwendungen mit diesem Framework vorweisen.

Durch das Aufkommen von Progressive Web Apps (PWA), welches auch Thema meiner Diplomarbeit war, ist das Web noch stärker geworden. So sind inzwischen auch Funktionen wie die Installierbarkeit, Offline-Fähigkeit oder Push-Notifications in Webanwendungen möglich. In der Kombination mit einem SPA-Framework wie Angular, React oder VueJS ist es nahezu spielend einfach eine schnelle, reaktionsfreudige und Offline-fähige Anwendung zu bauen, die früher nur mit nativen Anwendungen denkbar waren. Dabei habe ich dutzenden Personen eine PWA an die Hand gegeben und sie konnten den Unterschied zu einer nativen mobile App nicht feststellen. Schnallt man nun noch ein Hybrid-App Framework wie Electron oder Cordova davor, erhält man bei Bedarf dennoch eine native App, ohne redundanten Anwendungscode.

Wenn man nun schon ausschließlich im Web unterwegs ist und sich keine Gedanken über die Positionierung seiner Anwendung in App-Stores machen muss, rutscht das Thema Suchmaschinenoptimierung (SEO) natürlich noch viel mehr in den Vordergrund. Durch mehrere Jahre Erfahrung in der technischen SEO-Optimierung von Webseiten und meiner Zertifizierung zum Google Mobile Web Specialist kann ich Ihre Webseite so optimieren, dass Ihr Content optimal ranked. Falls Sie Bedarf an der Marken-Strategie oder Content haben kann ich Sie gerne an Kontakte aus meinem Freelancer-Netzwerk vermitteln.

Mehr erfahren

Software-Architektur

Regelmäßig höre ich die Frage „Was macht eigentlich ein Software-Architekt?" - doch bevor wir uns dieser Frage widmen: Was ist eigentlich eine Software-Architektur? Software ist mehr als nur Features. Häufig wird getrennt zwischen funktionalen und nicht-funktionalen Anforderungen. Während die fachlichen Anforderungen meistens vom Kunden oder der Fachabteilung vorgegeben werden, werden die nicht-funktionalen Anforderungen gerne als selbstverständlich vorausgesetzt. Hierzu zählen unter Anderem:

• Stabilität (Verfügbarkeit, Wiederherstellbarkeit, Fehlertoleranz...)
• Aussehen und Usability (Corporate Design, Mobile-Fähigkeit, Verständlichkeit...)
• Sicherheit (Authentifizierung, Autorisierung, Datenschutz...)
• Performance und Effizienz (Antwortzeiten, Ressourcenbedarf, Skalierbarkeit...)
• Wartbarkeit und Betrieb (Verständlichkeit, Dokumentation, Anpassbarkeit, Erweiterbarkeit...)

Um diese Punkte zu erfüllen Bedarf es Erfahrung in unterschiedlichen Disziplinen der Softwareentwicklung und es kann nicht erwartet werden, dass ein Junior-Developer diese Anforderungen vollumfänglich überblicken und erfüllen kann, auch wenn er dies von sich behauptet. Ein sehr passendes Zitat hierzu:

Das große Problem dabei ist, dass Softwareentwicklung und Programmierung für die meisten Kunden und Fachbereiche nicht greifbar und verständlich ist. Aber sind wir mal ehrlich: Wenn der Auspuff an Ihrem Auto locker ist, gehen sie zu einem erfahrenen Mechaniker oder lassen sie den Nachbarsjungen das ganze mit Klebeband richten? Beides wird das Problem lösen, das eine langfristig, das andere nicht.

Sucht man nun bei Google nach dem Berufsbild des Software-Architekten findet man viele unterschiedliche Beschreibungen. Gleiches habe ich in meiner bisherigen Berufserfahrung erleben dürfen. Häufig wird der Vergleich zur klassischen Architektur gezogen, bei der ein Architekt das Gebäude plant, während Handwerker und Bauarbeiter das Gebäude bauen. Tatsächlich sind gewisse Parallelen in der Software-Entwicklung vorhanden, allerdings gefällt mir die Vorstellung des Architekten in seinem Elfenbeinturm nicht. Meiner Auffassung nach braucht der Software-Architekt Entwickler-Stallgeruch und sollte auch möglichst nah mit den Entwicklern zusammen arbeiten oder sogar selber mit entwickeln. Nur so kann ein ausreichender Austausch und Wissenstransfer gewährleistet werden. Die Vorstellung einmal eine Architektur zu konzipieren und diese nicht wieder nachjustieren zu müssen ist meiner Erfahrung nach unrealistisch. Diese Interpretation wird auch in vielen Unternehmen so gelebt. So ist der Software-Architekt häufig ein erfahrener Kollege, den man als auch Chef-Entwickler bezeichnen könnte.

Der Software-Architekt verantwortet die Erfüllung und Überwachung der nicht-funktionalen Anforderungen. Zudem kann er je nach Organisation bei der Definition der fachlichen Anforderungen unterstützen, bei der Einschätzung des Aufwands helfen und anderen Abteilungen wie Marketing oder Vertrieb beraten. Für die Erfüllung seiner Hauptaufgabe sollte er den Kunden oder Fachbereich beraten, denn die Entscheidung darüber, ob eine Anwendung bspw. als Windows-Client Anwendung oder Desktop-Only entwickelt wird, kann einen massiven Schaden verursachen, wenn diese Entscheidung nachträglich revidiert werden muss. Sind allgemeine Plattform-Fragen und der der funktionale Umfang geklärt, muss sich der Architekt Gedanken darüber machen wie er diese Anforderungen umsetzen kann. Während es dabei früher hauptsächlich um die Wahl weniger Technologien und Frameworks, sowie der Strukturierung von Code eines Monolithen ging, ist die Aufgabe im Cloud-Zeitalter etwas komplexer geworden.

Zumeist wird bei der Softwareentwicklung der groß Gedacht. Man möchte seine Anwendung nicht für ein paar Dutzend Nutzer entwickeln, dafür ist der Aufwand auch einfach zu kostspielig. Das Ziel ist meistens eine global genutzte Anwendung mit mehreren hunderttausend oder Millionen von regelmäßigen Nutzern. Für dieses Ziel müssen meistens viele und komplexe Funktionen implementiert werden, welche in einer monolithischen Architektur meistens sehr schwer zu warten und erweitern sind. In Zeiten von agilen Vorgehensmodellen wie Scrum und Co., bei denen erwartet wird in kurzen Intervallen Änderungen und Erweiterungen an einer Anwendung vorzunehmen, kann dies eine Entwicklungsabteilung sehr schnell lahmlegen oder Qualität kosten. Ebenfalls kritisch ist die Skalierbarkeit: muss ein Monolith plötzlich das hundertfache an Anfragen bearbeiten kommt es zu einem Bottleneck-Problem, bei dem ein einzelner Bereich der Anwendung dieser Last nicht mehr standhalten kann. Möchte man nun dieses Bottleneck mit mehr Ressourcen versorgen, so muss in der Regel das ganze System skaliert werden. Dies führt zu einem unnötig hohen Bedarf an Ressourcen und damit zu unnötig hohen wirtschaftlichen Kosten.

Um diesen Problemen Herr zu werden, wird heut zutage vermehrt auf Microservice-Architekturen gesetzt, bei denen die Anwendung in mehrere kleine Dienste getrennt wird. Diese Dienste sind jeweils für einen Teilbereich zuständig, sind leichter zu verstehen, mit unterschiedlichen Sprachen und Frameworks entwickelt werden und können einzeln veröffentlicht und skaliert werden. Doch möchte man nun anstatt einmal im Jahr, einmal pro Woche eine neue Version seiner Anwendung veröffentlichen, welche nun aus dutzenden einzelner Services besteht, ist der Aufwand für ein Release und dessen Qualitätskontrolle erheblicher größer. Dies lässt sich nur durch Automation lösen. Mithilfe von Continuous Integration, Continuous Delivery bzw. Continuous Deployment (CI/CD) wird dieser Vorgang automatisiert, sodass dutzende von Releases an einem Tag möglich sind. Doch dies geschieht nicht von selbst: der Architekt muss sich nun unter Anderem über folgende Dinge Gedanken machen:

• Wie viele Services werden benötigt und welche Funktion kommt in welchen Service?
• Welche Sprache und welche Frameworks werden für welchen Microservice verwendet?
• Wie sprechen die Services miteinander?
• Wie lässt sich das Hosting und die CI/CD-Pipeline von Services mit unterschiedlichen Technologien realisieren?
• Wie läuft die Dokumentation und Versionierung der Services ab?

Und dabei liegt es natürlich in seiner Verantwortung die von ihm skizzierte Architektur ins Team zu bringen, neue Technologien und Prozesse zu vermitteln und ggf. auch mal von seinem Plan abrücken, wenn es sich mit dem Know-how oder der Kultur des Entwickler-Teams nicht vereinbaren lässt.

Mehr erfahren