Blog

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

Übersicht über das Apache Hadoop Ökosystem

Die Apache Hadoop Technologie erfreut sich einigen Jahren sowohl als On-premise Installation als auch als Cloud Lösung großer Beliebtheit bei Unternehmen. Google, Facebook, AOL, Baidu, IBM, Yahoo und viele Unternehmen setzen auf die bewährten Werkzeuge des Hadoop Ökosystems im die eigenen Daten zu extrahieren, aufzubereiten und auszuwerten. Diese Zusammenstellung von einzelnen Komponenten zur Hortonworks Apache Hadoop Distribution funktioniert analog zu der Zusammenstellung vieler vieler open-source Einzelwerkzeuge zu einer GNU/Linux Distribution.

Apache Hadoop selbst ist eine Sammlung (Framework) von open-source Softwarekomponenten, welche zusammen die Entwicklungen von Softwarellösungen ermöglichen die Probleme mit großen Datenmengen und viel Rechenleistung lösen können. Verteilte Datenhaltung und verteiltes Rechnen wird meist auf Rechnerverbünden (Clustern) aus Standardhardware (PC, Server) durchgeführt. Alle Hadoop Module sind so entwickelt worden, dass Hardwareversagen jederzeit berücksichtigt wird und von den Modulen selbst abgefangen werden kann – ein Job, der auf einem Rechner ausgeführt wurde bei dem ein Defekt eingetreten ist, wird automatisch auf einem anderen, verfügbaren Knoten nochmals gestartet, so dass für den Endnutzer kein Ausfall sondern allenfalls eine kurze Verzögerung bemerbar ist.

Mit diesem Blogartikel möchten wir zunächst einen Überblick über die Hadoop Kerntechnologien und das darauf aufbauende Ökosystem vermitteln. Anschließend gehen wir auf einzelne, wichtige Bausteine mit Schlüsselfunktionen nochmals einzeln ein. Nach dem Lesen des Artikels haben Sie einen umfassenden Überblick über die wichtigsten Apache Hadoop Komponenten.

Maurice KnoppÜbersicht über das Apache Hadoop Ökosystem
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

Daten perfekt visualisieren

Visualisierung nimmt beim Thema Big Data eine Schlüsselrolle ein. In der Mehrzahl der Projekte steht am Ende eines datengetriebenen Prozesses die Visualisierung des Ergebnisses. Daten müssen verständlich und nachvollziehbar dargestellt werden um letztlich strategische und operative Entscheidungen des Managements zu unterstützen. In diesem Beitrag möchten wir Werkzeuge vorstellen die sich

  1. für die Erstellung von optisch ansprechenden, einmaligen oder wiederkehrenden Berichten, (etwa Verkaufzahlen nach Regionen auf Tagesbasis, Zuschauerverteilungen und Marktanteile des gestrigen Sendetages oder Voraussagen zur zukünftigen Geschäftsentwicklung)
  2. für die Visualisierung bei der explorativen Datenanalyse (z. B. zur Verdeutlichung eines Sachverhalts. Das Clustering von Wörtern eines Textes – etwa zur Erzeugung einer visuellen Zusammenfassung als Word-Cloud oder die graphische Ausgabe (plotting) bei der AdHoc-Analyse einer (SQL-,CSV-) Datenquelle) und
  3. für die Darstellung von (live) Charts innerhalb von Webanwendungen eignen (Dashboards, damit geschäftskritische Kennzahlen – etwa der Prozentsatz an Ausschussware am Ende einer Produktionslinie oder Detailauswertungen zum Webseiten-Traffic mit einer Software wie Google Analytics).

Im folgenden werden wir einige Werkzeuge vorstellen, die sich für alle drei Anwendungsfälle eignen.

Maurice KnoppDaten perfekt visualisieren
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

Kubernetes und OpenShift Security 1 – Attack Surface

Kubernetes ist ein komplexes Gebilde aus vielen beweglichen Teilen. es ist hinter Linux das aktivste Projekt auf Github. Das Ökosystem mit 3rd Party Produkten, Plugins, Erweiterungen, Anbietern ist gewaltig. Hinzu kommt, dass selbst die Core features ständigen Änderungen unterworfen sind. Das sieht man allein an den API Versionen und Gruppen wie v1alpha1, v2beta3 usw. Leider erwächst aus dieser Komplexität eine gewisse Gefahr was das Thema Security angeht. Man ist froh, dass der Cluster aufgesetzt ist und funktioniert und die Entwickler schon erste Pods deployen und arbeiten können. Doch aus meiner Sicht ist das ein Problem. Denn ist der Cluster einmal aufgesetzt und im Betrieb, sind gewisse Änderungen nicht mehr oder sehr aufwändig zu bewerkstelligen. Komplexität ist kein Grund oder Entschuldigung die Security zu vernachlässigen. Und ich kann versichern, dass das Thema Security an sich ein komplexes Thema innerhalb des Kubernetes (und auch OpenShift) Universums ist. Von daher möchte ich eine Security Artikel Reihe starten die die verschiedenen Angriffs Vektoren und Security Maßnahmen beleuchtet.

Masiar IghaniKubernetes und OpenShift Security 1 – Attack Surface
Mehr

Must-have Ressourcen, Skills und Techniken für Data Engineers und Data Scientists

Nachdem wir in den Artikeln „Onboarding neuer IT-Mitarbeiter (DevOps, Big Data, Developer)“ und „Tutorial: IT-Basiswissen für DevOps, Big Data, Developer“ die grundlegenden Themen für neue IT-Fachkräfte vorgestellt und ein Tutorial zum Erlernen dieses Basiswissens gezeigt haben, möchten wir nun genauer auf Werkzeuge und Techniken eingehen, die speziell für Mitarbeiter im Bereich Data Engineering oder Data Science relevant sind.

Maurice KnoppMust-have Ressourcen, Skills und Techniken für Data Engineers und Data Scientists
Mehr

Container OS Vergleich

Seit dem Aufstieg der Container-Community in den letzten drei Jahren sind viele Unternehmen und Projekte entstanden, die wirklich innovative Wege zur Verwaltung von Anwendungen bieten.

Es gibt mehrere Projekte rund um das Thema Management, Netzwerk, Speicherung, Protokollierung, Überwachung und mehr (siehe diese Mind Map des Ökosystems). Die Container-Betriebssysteme spielen in diesem Ökosystem eine besonders wichtige Rolle.

In allen Unternehmen wo ich bisher als Berater unterwegs war gab es eine Frage die sich alle Entwickler stellten: Welches ist das beste Betriebssystem, um Container zu betreiben? Ein komplettes Linux? CoreOS? Was ist mit RedHat? Ich habe auch von etwas namens RancherOS gehört? Und diese ganzen „Atomic“ Systeme?

Masiar IghaniContainer OS Vergleich
Mehr

OpenShift 4 – Neue Features

Das OpenShift 4 Release steht vor der Tür. Zeit die neuen Features zu beleuchten. In diesem Artikel gibt es einen Überblick/Ausblick der neuen Features. In weiteren Artikeln behandeln wir dann die jeweiligen Features etwas genauer.

CoreOS

Das wichtigste zuerst: Wie vielleicht alle interessierten mitbekommen haben hat RedHat die Firma CoreOS übernommen. CoreOS hat einige sehr wichtige Produkte mit ins Boot gebracht, die konsequent von RedHat in OpenShift integriert werden. Im speziellen sind das CoreOS als Container Betriebssystem, Tectonic (die Kubernetes Plattform von CoreOS) und Quay als Container Registry. Alle Drei Produkte werden in OpenShift 4.0 integriert und lösen teilweise OpenShift eigene Konstrukte ab, wie z.B. die Registry. Das Operator Framework war schon in OpenShift 3.11 am Start (hierzu auch später ein Artikel).

Installer

OpenShift 4.0 kommt mit einem Installer, der die Installation in ausgesuchten Clouds wesentlich vereinfachen soll. In der Version 4.0 unterstützt der Installer nur AWS (und on-prem) und übernimmt auch die Infrastruktur Provisionierung eines Best Practice OpenShift Clusters. Ab 4.2 werden auch GKE und Azure unterstützt. Ab 4.1 kann man auch OpenShift auf selbstprovisionierten Infrastrukturen installieren (VmWare, AWS und BareMetal). OpenStack Unterstützung kommt ab 4.3.

Masiar IghaniOpenShift 4 – Neue Features
Mehr