Allgemein

Digitale Transformation: Probleme mit serviceorientierten Architekturen – Teil 4

Ein kleines Beispiel: Das Unternehmen XYZ hat die Vorteile um Microservices, automatisierten Tests, Containern und CI/CD verstanden und hat es eingeführt. sie haben sich entschieden ihren software Monolithen in Modul A und Modul B zu zerteilen, die als eigenständige Services laufen. Ferner ein Modul C mit einigen neuen und unabhängigen Funktionen. Diese Module wurden in Container gepackt und unter Kubernetes deployed. Als sie anfingen diese Module in Produktion zu deployen stellten sie erste Probleme fest:

  • Manchmal waren einige Services sehr inkonsistent in ihrem Antwortverhalten und haben sehr lange zum Abarbeiten der requests gebraucht.
  • Manche Services haben unter Last gar nicht mehr geantwortet
  • Wenn Service B keine Anfragen beantworten konnte dann antwortete Service A auch nicht, aber nur manchmal und für bestimmte Requests.
  • Beim Deployment haben sich Bugs eingeschlichen, die während den automatisierten  Tests nicht abgefangen wurden. Die Deployments wurden im sogenannten Blue/Green deployment durchgeführt. Hierbei wird das neue Deployment komplett in separaten Containern gestartet („green“) und wenn das Deployment durchlief und die Container gestartet wurden, dann wurde der Traffic komplett umgeschwenkt von den alten („blue“) Containern auf die Neuen. Sie hatten gehofft, dass blue-green deployments das Risiko von Deployments verringern würden, aber in der Praxis roch es wieder nach „big-bang“ Releases; was sie eigentlich verhindern wollten. Zumindest hatten die Berater das so gesagt 😉
  • Die Teams von Service A und B hatten jeweils eine komplett unterschiedliche Implementierung der Security. Team A wollte sichere Verbindungen mit Zertifikaten und Private Keys. Team B hatte eine eigene Implementierung favorisiert mit Servlet Interceptors. Team C hat gar keine Security Maßnahmen ergriffen, da es sich um interne Dienste handelte hinter einer Firewall.
Masiar IghaniDigitale Transformation: Probleme mit serviceorientierten Architekturen – Teil 4
Mehr

Digitale Transformation: Automatisierte Tests, Container und CI/CD – Teil 3

Dieser Artikel ist Bestandteil einer Reihe welches technische Aspekte der digitalen Transformation beleuchtet.

Automatisierte Tests

Beim Lernen geht es darum, Feedback zu erhalten und unsere Fähigkeit, ein Ziel zu erreichen zu verbessern. Automatisierte Tests ermöglichen es uns, wichtige Teile der Feedbackschleife näher an unsere Entwicklungsabteilung heranzuführen. Wenn wir Änderungen an unserem Code vornehmen, können wir Regressionstests einrichten, um Fehler oder unerwartete Abweichungen von den vorgesehenen Funktionen zu erkennen. Obwohl Komponententests kritisch sind, sollte ein starker Schwerpunkt für automatisierte Tests auf Szenario- oder Funktionstests liegen. Diese Art von Tests zwingen uns, über die API des Dienstes nachzudenken und erlauben es uns auch, einen Einblick zu bekommen, wie unser Code verwendet wird, da unsere Tests letztendlich Verbraucher unserer API sind. Ein starker Fokus auf Feature-Tests wird auch das von unseren Kunden erwartete Verhalten bestätigen, nicht nur das Innenleben des Codes. Schließlich, da sich die Details der Implementierung aufgrund von Refactoring, Rückzahlung der technischen Schulden, Wartung usw. ändern, sollten sich unsere Funktionstests selten ändern müssen.

Masiar IghaniDigitale Transformation: Automatisierte Tests, Container und CI/CD – Teil 3
Mehr

Digitale Transformation: Microservices – Teil 2

In dem letzen Artikel in dieser Serie haben wir festgestellt, dass es bei der digitalen Transformation im Grunde darum geht Hypothesen aufzustellen, die es zu validieren gilt. Wir brauchen Experimente, die wir für echte Nutzer / Kunden ausrollen und beobachten was die Zielgruppe mit unserer Hypothese anstellt. Aus den Erkenntnissen stellen wir neue Hypothesen auf usw. Das Ziel ist ein Endprodukt welches der Kunde maßgeblich mit beeinflusst hat. Der beste Weg ist also echte Kunden zu nehmen.

An die IT stellt dies besondere Herausforderungen, denn wir müssen in der Lage sein Software schnell in Produktion zu bringen. Lange Release Zyklen sind hier kontraproduktiv. Die meisten Leser werden aber genau diese Probleme kennen. Es dauert zu lange neue Anforderungen umzusetzen und zu releasen. Hat man dann die neuen Features endlich online schlagen andere Dinge fehl, die vorher funktioniert haben. Microservice Architekturen, automatisierte Tests, Container, continuous integration und continuous delivery sind Mechanismen, die uns helfen diesen Prozess agil zu gestalten. Alles weitere Bausteine der digitalen Transformation.

Masiar IghaniDigitale Transformation: Microservices – Teil 2
Mehr

Scrum Wahnsinn – was digitale Transformation wirklich bedeutet – Teil 1

Bei der XYZ GmbH kann kein Projekt starten bevor ein Budget festgelegt worden ist. Bevor die Entwicklung des Projektes starten kann kommen die Business Stakeholder zusammen und legen die Top Prioritäten fest. Es gibt wochenlang wenn nicht monatelang Meetings, Powerpoint Slides mit geschätzten Kosten und ROI Zahlen, um das Projekt zu rechtfertigen und zu belegen warum das Projekt wichtig ist und warum gerade die gewählte Vorgehensweise die bestmögliche für XYZ GmbH ist. Die hohen Kosten und lange Lieferzeiten resultieren meist aus der Menge an Features welches das Projekt alles liefern soll. 

Wenn die Entscheidung einmal gefallen ist legen dann Business Analysten, Designer und Requirement Engineers los, um eine lange Liste an Anforderungen zusammen zu schreiben. Dies dauert Monate bevor die Anforderungen an die Entwicklung zur Umsetzung gehen. In dieser Phase finden Umpriorisierungen statt, Qualitätstests werden definiert und das Ganze für die Produktion optimiert vorbereitet. Am Ende ist das Projekt weder in-time noch in-budget.

Masiar IghaniScrum Wahnsinn – was digitale Transformation wirklich bedeutet – Teil 1
Mehr

Tutorial: IT-Basiswissen für DevOps, Big Data, Developer

Nachdem wir im Artikel „Onboarding neuer IT-Mitarbeiter (DevOps, Big Data, Developer)“ die grundlegenden Themen für neue IT-Fachkräfte vorgestellt haben, möchten wir nun anhand eines Tutorials zeigen, wie Wissen zu diesen Themen praktisch angewendet werden kann. Neue IT-Mitarbeiter können die nachfolgenden Tutorialaufgaben Schritt für Schritt durchlaufen und zum Abschluss die Projektdokumentation und die beiden kurzen Präsentationen einem Senior Entwickler vorlegen bzw. präsentieren.

Maurice KnoppTutorial: IT-Basiswissen für DevOps, Big Data, Developer
Mehr

Onboarding neuer IT-Mitarbeiter (DevOps, Big Data, Developer)

Damit Hochschulabsolventen aus MINT Fächern als IT-Fachkräfte möglichst schnell produktiv im Firmenumfeld arbeiten können, sollten diese die gebräuchlichsten Technologien und Werkzeuge kennen und verwenden können. Nachfolgend heben wir die wichtigsten Themen heraus und verweisen auf Ressourcen um diese schnell zu erlernen.

Maurice KnoppOnboarding neuer IT-Mitarbeiter (DevOps, Big Data, Developer)
Mehr

Red Hat OpenShift Installation mit GlusterFS Storage

OpenShift ist ein PaaS (Platform as a Service) welches den Betrieb von Docker Containern in einem Cluster vereinfacht. Ein wesentlicher Bestandteil der Platform ist das Thema Storage. Jede Anwendung hat unterschiedliche Anforderung an Kapazität. Die Idee ist, dass die Anwendung einfach definiert wieviel Speicherplatz sie benötigt und die Plattform provisioniert dynamisch die geforderte Kapazität in Form von Volumes. Diese Volumes stehen dem Container zu Verfügung unabhängig davon auf welchem Node der Container läuft. Wie könnte eine Lösung aussehen. In einfachen Formen könnte ein SAN angebunden werden, ebenso NFS als shared Mount. Diese Technologien sind aber „old school“ und nicht für moderne Container Plattformen geeignet. In diesem Artikel beschreiben wir das von Red Hat eingeführte Container Native Storage (CNS). „Native“ bedeutet, dass alle Komponenten first class citizens sind und selbst als Container in OpenShift laufen. Im Gegensatz dazu steht das Container Ready Storage. Dabei ist ein Plattform externe Storage Lösung gemeint, die dann in OpenShift integriert wird. Bei beiden Lösungen werden Storage Cluster eingesetzt wie GlusterFS oder Ceph. Diese beiden Technologien versprechen theoretisch unendliche Erweiterbarkeit von Speicher. Wie werden im folgenden sehen wie eine Installation von GlusterFS in der CNS Variante funktioniert.

Masiar IghaniRed Hat OpenShift Installation mit GlusterFS Storage
Mehr

Vom Monolithen zu Microservices – Eine Architektur Strategie

Die meisten Menschen außerhalb der IT bekommen meistens nicht mit, wie schwierig es ist, komplexe Enterprise-Systeme zu verwalten. Es ist ein feiner Balanceakt der auf dem Verständnis beruht, wie sich eine Veränderung auf das gesamte System auswirken wird.

Neue Entwickler verbringen Monate damit, die Codebasis des Systems zu studieren, bevor sie anfangen können daran zu arbeiten. Sogar die kenntnisreichsten Entwicklungsteams zögern Änderungen vorzunehmen oder neuen Code hinzuzufügen, weil es den Betrieb in einer unvorhergesehenen Weise stören könnte. Das hat zu Folge, dass selbst banalste Änderungen diskutiert und hinausgezögert werden.

Wenn Dinge schief gehen, beschuldigen sich Administration, Entwicklung und QA gegenseitig. Das Projektmanagement macht das fehlende Budget verantwortlich usw. Die Folge ist, dass  Unternehmen ihr Vertrauen in die IT verlieren und anfangen nach Outsourcer zu suchen, um das interne Team zu ersetzen.

Wenn Sie nicht gerade von einem Sabbatical wieder gekommen sind haben Sie sicherlich gehört wie Microservices dieses Szenario auf den Kopf stellen können, so dass eine neue, agilere Welt entsteht in dem Entwickler und Operations-Teams Hand in Hand arbeiten, um kleine, lose gekoppelte Software Bundles zu liefern.  Anstelle eines einzigen monolithischen Systems wird die Funktionalität von einem kleineren Satz von Diensten durchgeführt, die ihre Operationen koordinieren.

Masiar IghaniVom Monolithen zu Microservices – Eine Architektur Strategie
Mehr

Artificial Intelligenz im Enterprise Umfeld: Die Zukunftsaussichten

Künstliche Intelligent (KI, auch Artificial Intelligenz AI) ist bisher bekannt bei der Anwendung von super-intelligenten, humanoiden Robotern. Gewöhnlich wird die künstliche Intelligenz hinter den Kulissen als ein Algorithmus implementiert, der grosse Datenmengen verarbeitet um eine Reihe von profanen Aufgaben effizienter auszuüben als ein Mensch.

Obwohl die Meisten von uns weder mit einem selbstfahrendem Auto fahren (noch nicht) noch einen humanoiden Roboter in Anspruch nehmen, wird unser alltägliches Leben zunehmend beeinflusst von KI-Systemen, die Ton oder Bilder erkennen oder unser online-Verhalten analysieren, um uns vor Kreditkartenbetrug zu schützen oder uns im Web passende Reklame anzuzeigen.

Masiar IghaniArtificial Intelligenz im Enterprise Umfeld: Die Zukunftsaussichten
Mehr

Die Vorteile der Offshore Entwicklung – Liquid Workforce

Ein Großteil unserer Projekte werden seit Jahren Offshore entwickelt. Wir verfügen über ein weltweites Netzwerk von Software Spezialisten, hauptsächlich kommen unsere Software Spezialisten jedoch aus der Ukraine und Polen.

Die Entwicklung von Projekten im Ausland ist bis zu einem gewissen Grad der Komplexität äußerst lohnenswert! Das liegt nicht nur an den Preisvorteilen. Wir können Ihnen sagen, ob Ihr Projekt für die Offshore Entwicklung in Frage kommt, oder ob Sie lieber auf die Onsite Entwicklung zurückgreifen sollten.

Wie kann ein Offshore Projekt erfolgreich sein?

Masiar IghaniDie Vorteile der Offshore Entwicklung – Liquid Workforce
Mehr