Jump to content

Fachinformatiker - Blog

  • Einträge
    32
  • Kommentare
    108
  • Aufrufe
    39.174

Mitwirkende

Konferenzreview: DevOpsCon 2015 in München

Melde dich an, um diesem Inhalt zu folgen  

1.065 Aufrufe

Hallo Welt!

Besser spät als nie möchte ich euch von der DevOpsCon 2015 in München berichten. Dort habe ich zum ersten mal "ernsthaft" den Entschluss gefasst, unter die Blogger zu gehen und die ganzen Gedanken, die mir im Kopf rumschwirren, zu "Papier" zu bringen.

Disclaimer: Aufgrund der Menge an Infos, Tools und Eindrücke der Konferenz kann und werde ich hier nur einen Einblick in die für mich interessantesten Themen geben und über das allgemeine Konferenzfeeling schreiben. Für mehr müsst ihr schon selbst dahin. ;) Es lohnt sich aber, die Themen für Sommer/2016(Berlin) sind im Verhältnis zum Termin Winter/2015 noch recht ähnlich.

sheraton_pool.jpg?w=533&h=300
Pool im 23ten Stock des Hotels - Nicht DAS, aber definitiv eins der Highlights der 3 Tage

Vorwort

Vom 23.11 - 25.11 2015 waren zwei Kollegen von mir(einer der zwei bloggt übrigens auch schon eine ganze Weile) im Sheraton Hotel München im Arabellapark und hatten den Plan, in den zwei Tagen Konferenz und einem Tag Praxis-Workshop so viel wie möglich mitzunehmen, ohne angesichts der Menge an Informationen zu verzweifeln.

Von München selbst haben wir außer einem Besuch im "Burger House 2", was ja auch nicht wirklich "typisch München" ist, nicht wirklich viel mitbekommen. Das ist in Anbetracht der vollgepackten Tage aber auch normal, die BASTA! Spring, die ich 2014 besucht habe, hat einen ähnlichen Effekt verursacht. Außer nem Hefeweizen abends in der Lobby war da nicht mehr viel zu holen bei mir.
Nach dem Abendessen ging es mit den Kollegen eine Runde im Pool schwimmen, den grandiosen Ausblick auf den Liegen um den Pool genießen, den nächsten Tag planen und damit war der Abend meistens auch schon rum.

Tag 1(Workshop)

Zum geschmeidigen Start in den Montag gab es den "Docker-Basis-Workshop" von und mit Peter Roßbach, seines Zeichens Systemarchitekt, Docker-Experte der ersten Stunde und "DevOps"-Enthusiast. Selbst bis dato auf *nix-Systemen völlig unbedarfte Entwickler(wie mich) waren mit Peters Anleitung und aufgrund der Einfachheit der Docker-Syntax in der Lage, in Kürze Container für Webserver, Datenbankserver mit entsprechenden Befehlen zu erzeugen und die Netzwerke gleich mit zu konfigurieren. Mächtiges Tool und mächtige Architektur diese Container-Technologie. Mit einer verhältnismäßig niedrigen Hemmschwelle zum Einstieg und Unmengen an Blogs, Snippets und Infomaterial zu Docker selbst im Netz scheinen die Docker-Container in *nix-Umfeldern eine echte Bereicherung zu sein, wenn es darum geht, skalierbar schnell Infrastruktur bereitzustellen. Obwohl ich mit Infrastruktur und mit Linux bisher wenig zu tun hatte, das hat definitiv mein Interesse geweckt. Der Raspi liegt im Warenkorb. Bücher zu Docker übrigens nicht, die sind oft schon beim Erscheinen veraltet.

Nicht vorenthalten möchte ich euch noch folgendes Zitat von Peter zur Frage , wie man diese Technologie in einer abgeschotteten, kontrollierten Konzern-IT-Infrastruktur implementieren könnte:

"So eine Docker-Welt in einer Enterprise-Company zum Laufen zu bringen kann ein Scheiß-Sport sein."

¯\_(ツ)_/¯

Tag 2&3(Konferenz, Expo)

Nach einem überschaubaren ersten Tag gab es an den Tagen 2 und 3 ausschließlich Vorträge, Keynotes und informell gestaltete Treffen zum Austausch(Open Space-ig).

Gemeinsam war allen von mir besuchten Vorträgen, das sie unglaublich viel Lust aufs "Basteln" machten. Was sich in der Praxis aufgrund der Open Source-Natur vieler genutzten Tools als gar nicht so schwierig herausstellen sollte.

Am interessantesten waren für mich die Talks zum Thema Unternehmenskultur und Veränderung in der Organisationsstruktur des "DevOps"-Unternehmens. Besonders hervorstechend waren da für mich zum einen Wix.com(WYSIWYG-Baukasten für Webseiten) und zum anderen dm(Ja, die Drogerie). Bei Wix war sehr interessant, wie der Referent Aviran Mordo klar und einfach zeigte, dass man nicht jedes Tool benutzen muss, solange man nicht den "Schmerz spürt", den der Einsatz des Tools zu lindern vermag. Wenn deine Idee grundsätzlich Mist ist, bringen dir die besten Tools nichts, deine Idee bleibt Mist.

aviranmordo_microservices_vs_monoliths.j
Das Bild spricht denke ich für sich.

dm im Kontrastprogramm merkte recht schnell, dass man als "Drogerie" mit offenen Augen und Ohren durchaus Gewinn mit ordentlichen Onlineportalen und Webshops machen kann. Ein Onlineshop, der schnell auf die Bedürfnisse der verschiedenen Kunden reagieren kann und in kurzen Abständen qualitativ hochwertige Stände online stellen kann war hier das Credo. Daraus folgte fast natürlich und logisch eine Umstellung des Deployment-Prozesses in Richtung Continuous Delivery und ein damit einhergehendes Umdenken in der Unternehmensorganisation.
Im Verlauf des Talks wurde klar, dass zum einen Vertrauen und Offenheit für ein solches Umdenken notwendig sind. Zum anderen auch, dass dafür nicht jeder bereit ist. Unterm Strich kam jedoch eine effizientere Organisation bei dem Prozess heraus.

Fazit - TL;DR

Das nicht immer alles eitel Sonnenschein ist, war bei allen Vorstellungen von Tools oder Prozessen, die durchlebt wurden, immer zu erkennen. DevOps an sich bedeutet in erster Linie, Verantwortung gemeinsam zu übernehmen für ein geteiltes Bild eines Produkts oder eines Prozesses. Was oft vergessen wird, ist aber, dass dieses Bild manchmal gar nicht existiert oder abteilungsübergreifend völlig anders wahrgenommen wird.

Empathie, echtes Verständnis füreinander und für die Anforderungen des Gesprächspartners waren immer wiederkehrende Merkmale, die notwendig sind, damit so etwas wie Continuous Delivery funktionieren kann.

 

Tools, Tools, Tools!

Zum Abschluss noch ein paar Links und Einzeiler zu vorgestellten Tools, falls jemand bastelwütig wird:

  • Docker - Software, mit der man andere Software(z.B. Betriebssysteme, Webserver, Datenbankserver,...) virtualisiert in "Containern" verpacken kann, die dann auf jedem System funktionieren
  • Hadoop -  Framework für verteilte Software. Man nehme 10 Raspis, schalte sie zusammen und e voilá: Man hat einen Hadoop-Cluster-Datenbankserver
  • ELK-Stack - Bestehend aus Elasticsearch, Logstash und Kibana zum Durchsuchen, Ablegen und Visualisieren von Logs aller Art
  • OWASP ZAP - Zum manuellen oder automatisierten Security-Scan(aktiv, passiv) von Webanwendungen, auch automatisiert in Jenkins verwendbar
  • Jenkins - Tool für Continuous Integration und so ziemlich alles, was dazu gehört. Lächerlich viele und gute Plugins verfügbar
  • Consul - Service Discovery-Tool, das neue Dienste, die verfügbar werden, automatisch erfasst und diese verwalten kann. Nützlich aber erst, wenn man schon mehrere Microservices im Einsatz hat, sonst tut es auch ein DNS-Eintrag
  • Github - Viel mehr als nur das, aber hauptsächlich ein Repository-Server für GIT

Euer "devopsdad" Patrick aka Goulasz

 

Melde dich an, um diesem Inhalt zu folgen  


1 Kommentar


Empfohlene Kommentare

Erstelle ein Benutzerkonto oder melde dich an, um zu kommentieren

Du musst ein Benutzerkonto haben, um einen Kommentar verfassen zu können

Benutzerkonto erstellen

Neues Benutzerkonto für unsere Community erstellen. Es ist einfach!

Neues Benutzerkonto erstellen

Anmelden

Du hast bereits ein Benutzerkonto? Melde dich hier an.

Jetzt anmelden
  • Blogkommentare

    • Einfach zu lesen und zu verstehen, hat mir geholfen, danke
    • Das Beispiel bei Raid 5, in dem du die Rechnung als Beispiel erstellst, finde ich etwas unglücklich. Ich würde mich hier eher mit den 0 und 1 und der errechnung der geraden / ungeraden Ergebnisbits entscheiden. Auch sind es nicht oft 5 Festplatten bei einem Raid 5. Eher mehr. Zu Raid 5 und 6, es gilt eigentlich, dass man die Paritybits auch wahllos verteilen kann. Es muss keine dedizierte Platte sein. Das zweite Paritybit kann auch diagonal gestripes über ein Array verteilt werden. Siehe NetApp   Viele Grüße   z.B. Jens Mander
    • 1. Bild ist raus. Zum Rest: Empfinde ich als nicht wichtig genug für einen Blog der die Grundlagen vermitteln soll.  
    • Erstens: Copyright ist dir unbekannt? Auch für einen Blogbeitrag darf man nicht einfach ein Bild aus dem Internet verwenden. Zweitens: der von dir verlinkte Controller dürfte nicht viel schneller sein als ein Software-Raid. Mehr dazu unter Punkt 4. Drittens: Ein echtes Hardware Raid gewinnt seine Leistung unter anderem auch dadurch, dass der Controller einen eigenen Cache besitzt. Warum schreibst du nichts darüber? Was ist mit einem BBU und warum sollte dieses Bauteil zwingend bei einem Raid dabei sein? Viertens: der von dir im Bild gezeigte Controller ist ein einfacher SATA-Controller aus alten Tagen (es ist ein PCI-X Controller, das war mal state of the art als ich zum ersten Mal intensiver mit IT in Verbindung kam), der ein RAID nur über die Treiber für die Karte erstellen kann, es also effektiv ein Controller für ein SOFTWARE-RAID ist. Siehe hier: https://www.semiconductorstore.com/cart/pc/viewPrd.asp?idproduct=42868
    • Ich kann die Infos nochmal raussuchen aber eigentlich ist es klar. bei RAID 6 werden 2 verschiedene Prüfsummen gebildet P und Q die auf die Platten verteilt werden. Unabhängig davon ob Q nun komplexer zu ermitteln ist als P braucht das mehr Rechenzeit. Das passiert zwar aufm Controller aber der kann auch nur n Operationen pro Sekunde. ob es belastbare Benchmarks gibt weiß ich nicht. Das gleiche gilt in ähnlicher Form fürs Rebuild und damit auch für den Betrieb im "degraded" Zustand. Je mehr Festplatten um so mehr Operationen pro Prüfsumme müssen durchgeführt werden. Auch ein XOR braucht Zeit, auch wenn es wenig ist.
    • 1. Danke, ich habe eine Zeile hinzugefügt die darauf hinweist das es noch mehr RAIDs gibt. 2. Ich hab ein wenig gesucht, aber zu dieser Aussage konnte ich leider auf die Schnelle keine Informationen finden, könntest du mir sagen wo du diese Info her hast? 3. Das die Performance während eines Ausfalls sinkt hatte ich unter RAID 5 erwähnt. Unter RAID 0 ist auch nochmal erwähnt dass bei mehr Festplatten die Ausfallrate höher ist. Beides könnte man natürlich in einen allgemeineren Bereich nehmen, das ist wahr. Was mehrere Platten in RAID 5/6 betrifft und das bei mehr Platten die Zeit für den Rebuild steigt konnte ich leider auch nicht verifizieren - nur das die Zeit mit der Größe der Platte logischerweise steigt (1TB hat eine kürzere Rebuild-Zeit als eine 2TB-Platte).
    • Mir fehlen hier noch typische Einsatzgebiete der jeweiligen RAID-Level, ein Verweis auf exotischere RAIDs. Es klingt auch ein wenig so als wäre RAID 6 ne total tolle Idee, allerdings erkauft man die Datensicherheit mit Performanceeinbußen gegenüber anderen Varianten. Es ist auch keine gute Idee viele Festplatten in ein RAID 5 oder 6 zu stopfen. Zum einen steigt die Wahrscheinlichkeit das mehrere Festplatten ausfallen und zum anderen steigt die Zeit für den Rebuild und die Performance sinkt während des Ausfalls.
    • Zu diesem Thema habe ich mit Patrick in einem fast zweistündigen Interview gesprochen. Wer mehr über die Arbeit eines UX-Experten erfahren möchte, kann gerne reinhören: Patrick Ziegler über User Experience (UX) und Usability. Und über Feedback freuen wir uns natürlich auch sehr!
    • https://www.ebay-kleinanzeigen.de/s-anzeige/halo-suche-jop-in-ein-anwalz-kanslei/716905036-105-4268
    • Ist doch ein Fake oder? https://www.ebay-kleinanzeigen.de/s-anzeige/ferkaufe-fiat-multipler-guter-zu-schtant/716565560-216-4268
       
  • Blogstatistik

    • Blogs insgesamt
      1
    • Einträge insgesamt
      29

Fachinformatiker.de, 2018 SE Internet Services

fidelogo_small.png

if_icon-6-mail-envelope-closed_314900.pnSchicken Sie uns eine Nachricht!

Fachinformatiker.de ist die größte IT-Community
rund um Ausbildung, Job, Weiterbildung für IT-Fachkräfte.

Fachinformatiker.de App


Get it on Google Play

Kontakt

Hier werben?
Oder senden Sie eine E-Mail an

Social media u. feeds

Jobboard für Fachinformatiker und IT-Fachkräfte

×

Wichtige Information

Fachinformatiker.de verwendet Cookies. Mehr dazu in unserer Datenschutzerklärung