Alle Artikel in der Kategorie “Uncategorized

Kommentare 0

Eine Data Science Übersicht zum schnellen Einstieg

Data Science ist aktuell soweit in aller Munde („Daten sind das neue Öl“), dass es für jedermann sinnvoll ist ein Verständnis der Zusammenhänge zu bekommen.
Die Autoren von Datascience Central haben dazu eine sehr gute und einfache Mindmap erstellt. Sie nennen sie den Manager Einstieg in das Thema.

Das Original findet sich auf Coggle.
Die Map ließt sich von links mit den diversen datenbezogenen Aspekten wie Quellen, Datenablagen über die notwendigen Hintergründe/Voraussetzungen (Mathematik, oben und sinnvolle Programmiersprachen, unten) zu den Anwendungsgebieten rechts.

Kommentare 0

Wie man sich schnell ein vCenter Dashboard aufbauen kann

Diese Woche scheint die Vmware Woche auf diesem Blog zu sein. Nachdem graphR. Post kommt nun ein weiterer Vmware bezogener Artikel.
Ein Kollege wies mich die Tage auf seinen SexiGraf PoC hin:

SexiGraf is a vSphere centric Graphite appliance with a Grafana frontend.

SexiGraf belegt sicherlich einen der vorderen Plätze im „Dümmster Name eines IT Tools Wettbewerb“. Ungeachtet dessen ist es eine schnelle Möglichkeit sich ein Dashboard mit netten Charts der wichtigsten vCenter Parameter zu bauen. SexiGraf basiert auf einer virtual Appliance, die ein Grafana basierendes Frontend bereit stellt.
Via Perl und dem vSphere SDK for Perl werden VI und VSAN Metriken abgerufen und über die eingebauten Tools gespeichert und im Anschluss via Grafana visualisiert:

Die Basis Einrichtung geht in ein paar einfachen Schritten:

  1. Download der Appliance
  2. Deployment der Appliance im Cluster
  3. Konfiguration der Einstellungen (im Kern Netzwerk), die Appliance kommt im DHCP Modus
  4. Eintragen der vCenter Konfig
  5. Fertig – nun nur noch mittels Browser im Grafana Dashboard anmelden und die fehlenden Credentials nachpflegen.

Schon kann man sehen wie die Basis Dashboards mit Daten befüllt werden.
Für ein Quick-and-Dirty Dashboard, beispielsweise in einer schnell installierten Test-Umgebung ist das allemal ausreichend.

Kommentare 0

Intelligente Autos – wie wäre es mit besseren Boardsystemen

Die Zukunft des Autos ist autonome Mobilität. Soweit sind sich die Experten einig. Dazu müssen die Autos in der Lage sein die Verkehrssituation richtig einzuschätzen und die Daten der verbauten Sensoren in den richtigen Kontext zu bringen.
Aktuell fahre ich einen 2016er VW Passat Kombi („Variant“) – ja, mit Drecksschleuder Diesel Motor usw. Diesem Passat hatte ich seinerzeit einige Assistenzsysteme konfiguriert. Unter anderem eine Verkehrszeichenerkennung, eine automatische Distanzregelung, sowie eine standardisierte Regenerkennung.
Fährt man nun beispielsweise auf der Autobahn, so zeigt das Auto im Cockpit die aktuell erlaubte Höchstgeschwindigkeit. In Deutschland gibt es die Besonderheit, dass es auch Zeit- oder Wetterabhängige Geschwindigkeitsregelungen gibt. Dazu gehört eine reduzierte Geschwindigkeit bei Regen oder zwischen 22-6 Uhr.
Ein Beispiel warum etablierte Hersteller von Autos aktuell mit simplen „Verknüpfungen“ von vorhandenen Daten scheitern ist für mich das folgende:
Obwohl dem „Bordcomputer“ über die diversen Sensoren alle Eckdaten zur Verfügung stehen, ist das Auto in genau diesen unscharfen Situationen nicht in der Lage die passende Geschwindigkeit anzuzeigen.
Wo ist das Problem?
Eigentlich ginge es nur darum vorhande Daten zusammen zuführen. Der Regensensor erkennt regen, der Verkehrszeichensensor erkennt ein Zeichen mit Wetterabhängigkeit – zeige genau dieses Geschwindigkeit an. Es ist nach 22:00, zeige diese Geschwindigkeit an.
Doch anscheinend sind solche einfachen Zusammenhänge eine signifikante Herausforderung. Ich frage mich bei dem Blick auf die Zukunft der Mobilität, wie weit wir wirklich von autonom fahrenden Autos entfernt sind.
Bildquelle: https://pixabay.com/de/adeje-teneriffa-nacht-1575437/

Kommentare 2

Planung und Aufwandsschätzung in Projekten

Als „klassischer“ Projektleiter ist man heutzutage gefühlt von der alten Schule. Uncool, nicht „agile“, nicht state-of-the-art. Die wenigsten haben halbwegs Ahnung über agile Methoden, aber lassen wir das an der Stelle…
Eine klassische Disziplin die man von Projektleitern erwartet, ist die Planung. Planung von Aktivitäten, Arbeitspaketen, Aufgaben und was es sonst noch so alles gibt. Selten wird der Planungsvorgang als klassische „handwerkliche“ Tätigkeit gesehen, meistens ist die Erwartung das der Projektmanager durch Magie oder Zauberkunst einen Plan erstellt. Einen Plan, der passen muss. Die sachliche Betrachtung ist ein Stück weit einfacher. Projektpläne entstehen in der Regel nicht durch Eingebung sondern durch sachliche Analyse. Analyse des Projektendproduktes, Zerlegung dieses in seine Einzelteile und dann Abschätzung der Aktivitäten und deren zeitlichen Aufwände.
Kurzum, 99% Arbeit und maximal 1% „Kreativität“.
Nachdem man die diversen Aktivitäten ermittelt hat, in der Prince2 Welt wird das oftmals über die Zerlegung des Ergebnisprodukts in Teilprodukte (Produktbasierte Planungstechnik), gilt es deren Aufwände abzuschätzen. Hier haben sich diverse Methoden (“Best Practice“) zur Schätzung ergeben, die teilweise auch im Prince2 Workbook so aufgeführt werden:

  1. Top-Down-Schätzung: Man nähert sich von oben an den Planwert. Typischerweise hilft diese Methode in einer frühen Phase oder bei einer sehr allgemeinen Aussage. Als Beispiel kann die Verteiler der Ressourcen dienen, es werden 30% Engineering und 30% Testing basierend auf Erfahrungen benötigt. Geht schnell, ist aber unpräzise.
  2. Bottom-Up Schätzung: Jede einzelne Aktivität wird für sich geschätzt. Das kann durch ausführliche Diskussion mit Fachexperten, vorausgegangenen Projekten oder Erfahrungswerten stattfinden.
  3. Vergleichsbasiertes Schätzen: Für mich ein zu häufig vernachlässigter Ansatz, dabei wird systematisch auf bestehende Daten zurückgegriffen. Im Laufe der Zeit sollten Organisationen mit Projekterfahrung einen entsprechenden Fundus an Daten besitzen. Leider wird aber oftmals beim Projektabschluss auf eine entsprechende Dokumentation verzichtet. Oder die Daten sind zu unstrukturiert.1 Im Idealfall besitzt man für bestimmte Aktivitäten aber Vergleichs- oder Referenzwerte, die der Projektleiter auf diese neue Planung anwenden kann.
  4. Parametrische Schätzung: Die offizielle Beschreibung lautet Ermittlung von Schätzwerten, wo immer möglich anhand von Messdaten/empirischen Daten und Korrelationsanalysen(…)“. Kollegen von mir haben eine Metrik, an der sie die Aufwände einer Infrastruktur basierend auf der Anzahl und Typ der eingesetzten Infrastrukturkomponenten hochrechnen können. Beispielsweise, x Loadbalancer mit y Regeln bedeuten ein Engineering Aufwand von z.
  5. Ein-Punkt-Schätzung: Nutzung/Berechnung eines einzelnen Wertes als beste Schätzung.
  6. Delphi-Methode: Sehr aufwendige Methode, da mittels Fragebögen und unabhängiger Befragung von diversen Gruppen (Experten, Fachfremde, etc.) Fragerunden geführt werden, die mittels Rückkopplung verfeinert werden.
  7. Drei-Punkt-Schätzung: Mittels der Drei-Punkt-Schätzung oder PERT-Schätzung habe ich bislang die besten Erfahrungen gemacht. Dabei werden Fachexperten gebeten den besten Fall, den wahrscheinlichsten Fall und den schlechtesten Fall einer Aktivität zu schätzen. Damit wird dann der gewichtete Durchschnitt errechnet.2 Als Formel dient (BestCase + 4 x LikelyCase + Worstcase) / 6

Im Rahmen einer seriösen „klassischen“ Planung gilt es zudem noch ein paar Regeln zu beachten:

  • Ressourcen sollten niemals zu 100% verplant werden, aus den bekannten Gründen (Krankheit, Overhead, etc.) – maximal 80%!
  • Ressourcen, die an mehreren Projekte parallel arbeiten können noch weniger geplant werden, da der Overhead steigt und die „Umschaltzeiten“ merklich ansteigen.
  • Je nach Situation werden oftmals „Wunschwerte“ geplant. Wenn beispielsweise der Geschäftsführer am Planungsworkshop teilnimmt und dieser ein bestimmtes Interesse hat, werden die Teilnehmer oft opportunistisch schätzen. 3
  • Im Idealfall sollte ein übergreifendes Team bei der Schätzung teilnehmen, der jeweilig für die Erarbeitung des Produktes verantwortliche das letzte Wort bei der Schätzung haben.
  • Und der no-brainer zum Schluss, es sollten immer hinreichend Puffer, besser noch „Zeitreserven“ für sonstige Abstimmungen und unerwartete Ereignisse („Probleme im Projekt“) eingeplant werden.
  1. Hier bin ich seit längerem der Meinung, dass Spracherkennung und Maschinelles Lernen eine Lösung bieten können
  2. Ich habe hierzu ein nettes MS Project Template mit eingebauter PERT Funktion erstellt. Bei Interesse hinterlasse bitte einen Kommentar und ich sende es Dir zu.
  3. Schnell besteht hierbei die HiPPO (highest paid person’s opinion, highest paid person in the office) Gefahr
Kommentare 0

Warum benötigt man ein Service Mesh bei einem Cloud Deployment

Im Cloudcast #298 wurde Linkerd vorgestellt. Linkerd (gesprochen linker-dee) ist ein Service Proxy, der dazu dient die Kommunikation zwischen lose gekoppelten System oder Microservices zu orchestrieren. Früher nannte man sowas manchmal auch ESB (Enterprise Service Bus).
Der Unterschied zu den ehemaligen SOA (Service Oriented Architecture) Ansätzen der Nuller Jahre, wo man in der Regeln versucht hat statische Systeme miteinander zu koppeln folgt der Ansatz des Service Mesh der Annahme moderner Cloud Paradigmen wonach die Services unstet sind. Das bedeutet sind sind in Teilen verfügbar, werde teilweise aufskaliert („Autoscale“), oder abgebaut bei weniger Last. Im Idealfall orchestriert sich das System selbst, sei es nun gesteuert durch entsprechende Container-Manager wir Kubernetes oder Docker Swarm oder durch andere Mechanismen.
Das Konzept eines Service Mesh dient nun dazu entsprechende Inter-Service-Requests zu gewährleisten und zu steuern.

A service mesh is a dedicated infrastructure layer for handling service-to-service communication. It’s responsible for the reliable delivery of requests through the complex topology of services that comprise a modern, cloud native application. In practice, the service mesh is typically implemented as an array of lightweight network proxies that are deployed alongside application code, without the application needing to be aware. (But there are variations to this idea, as we’ll see.)
The concept of the service mesh as a separate layer is tied to the rise of the cloud native application. In the cloud native model, a single application might consist of hundreds of services; each service might have thousands of instances; and each of those instances might be in a constantly-changing state as they are dynamically scheduled by an orchestrator like Kubernetes. Not only is service communication in this world incredibly complex, it’s a pervasive and fundamental part of runtime behavior. Managing it is vital to ensuring end-to-end performance and reliability.

Da setzt linkerd nun an. Aus ehemaligen twitter Produktleuten und hinreichend mit VC Kapital ausgestattet, ist es sicherlich kein komplett neues Konzept.

The service mesh is ultimately not an introduction of new functionality, but rather a shift in where functionality is located. Web applications have always had to manage the complexity of service communication. The origins of the service mesh model can be traced in the evolution of these applications over the past decade and a half.
Consider the typical architecture of a medium-sized web application in the 2000’s: the three-tiered app. In this model, application logic, web serving logic, and storage logic are each a separate layer. The communication between layers, while complex, is limited in scope—there are only two hops, after all. There is no “mesh”, but there is communication logic between hops, handled within the code of each layer.


Inter-Service Kommunikation, load-balancing, latency-assurance, all diese Features können durch ein Service Mesh unterstützt werden. Die Plugin Architektur von linkerd finde ich am reizvollsten, da hierdurch sogar einfache Protokollumsetzungen möglich sind.
linkerd ist seit neuem auch Teil der CNCF.