Jump to content

pantsoff

Mitglieder
  • Gesamte Inhalte

    343
  • Benutzer seit

  • Letzter Besuch

  1. Deine Ex Firma ist halt nicht der Nabel der Welt https://aws.amazon.com/devops/what-is-devops/
  2. Nicht unbedingt die Länge, überhaupt die neuen TLDs sind das Problem und werden von vielen Security Features negativ getagged.
  3. Natürlich spielen Release Zyklen eine Rolle. Aber, dein Beispiel vorausgesetzt, niemand installiert 20mal ein ERP inkl. individueller Konfiguration. Da muss sehr wohl Automatismus her. Ich sehe jetzt nicht wieso ein Deployment Prozess aufwendiger ist, als 20 mal das Ding rauf und runter zu installieren - okay, beides kann sein, das kann man wohl nicht allgemein gültig sagen und hängt vom Einzelfall ab. Es gibt heute Technologien, die das OS und vieles drum herum von der Applikation entkoppeln. Aber: Mal abgesehen davon, dass ich beim manuellen Deployment jedesmal menschliches Versagen als Fehlerquelle berücksichtigen muss. Außerdem: Genau der eine Mensch kann dann das ERP rauf und runter konfigurieren. Und wenn der krank ist, im Urlaub, ausgeschieden aus dem Unternehmen? Im Idealfall gibt es eine Deployment Pipeline, die jeder aus dem Team mit kurzer Anleitung ausführen kann (ich sage bewusst Deployment Pipeline und nicht Delivery Pipeline, beschränken wir das ganze auf sagen wir das Deployment einer VM und anschließender ERP Installation / Konfiguration inkl. der Anlage aller benötigter Komponenten). Natürlich kann der Automatismus mehr Zeit kosten, dagegen halte ich nach wie vor das Argument der "Reproduzierkarbeit" (und ein bißchen "Dokumentation", bewusst in Anführungszeichen). Da muss halt jede Firma für sich entscheiden, wo die Prios sind. "Automation first" ist mein Ansatz. Ich lasse Dir hier aber deine Meinung und gebe Dir in Einzelfällen recht, da kann der Automation-first Gedanke "teurer" sein (trotzdem sinnvoll aus meiner Sicht). Naja, temporäre Ressourcen in der Cloud sind bei den meisten Anbietern ein Witz, teuer sind Produktivumgebungen (lange Laufzeiten, viel Traffic ingress/egress etc.). Deine Schlussfolgerung ist dann also: Sysadmins sind für die Systeme da, die aufgrund wirtschaftlicher Aspekte nicht automatisiert werden können? Puh, das ist ja mal harter Stoff, ich kenne sehr viele super fitte (Programmier und Scripting-fähige Sysadmins -> sind das jetzt eigentlich auch DevOps? :)). Jemand aus der Sysadmin Franktion hier, der etwas dazu sagen möchte? Beim nächsten Punkt hast du mich nicht verstanden. Jeder im Unternehmen KÖNNTE (also rein von der Sache her) alles. Darum geht es doch aber nicht. Es geht darum, wer ist wofür am besten geeignet. Ist der Entwickler in Zeiten von Cloud und Co. am besten geeignet, seine Infrastruktur Ressourcen selbst zu administrieren? Es gibt viele Entwickler/Sysadmins die aus meiner Sicht NICHT geeignet sind, Projektmanager oder Berater zu sein (es gibt natürlich alle Fälle) und genauso den umgekehrten Fall (vom Potential). Letzer Punkt, Beispiel Monitoring im ERP System: Natürlich bietet das AWS und Co. nicht an, aber der Entwickler weiß doch am allerbesten, wann ein Alarm schießen soll, sobald dieser und jener Wert in der Datenbank steht? Woher soll der Sysadmin wissen, dass beim Parsen eines Logfiles genau diese Zeile gemeldet werden muss? Natürzlich muss der Monitoring Service des Providers mit Inhalt gefüttert werden (Tritt Fall A ein passiert Aktion B), aber der Monitoring Service des Providers ist bereits fertig im Portfolio, ist hochverfügbar geclustert und skaliert mit zunehmender Workload automatisch mit. Vielleicht ist der Entwickler besser dafür geeignet, das fertige Monitoring System mit Inhalt zu füttern, da er seine Applikation besser kennt als der Admin.
  4. Der Entwickler des Produkts kennt doch die Toolchain für das eigene Produkt am besten. Da ihm die Cloud viel Komplexität abnimmt, kann er sich die Toolchain, die für die Cloud Infrastruktur notwendig ist, leichter aneignen. Er wird damit am ehesten geeignet, alle Aufgaben zu übernehmen. Vielleicht haben wir bald nur noch DevOpsler? Okay, verschiedene Punkte. Ja man muss nicht alles automatisieren, aber wieso nicht? Wenn ich den Cluster nur einmal im Jahr brauche, habe ich das Infrastructure-as-Code Snippet trotzdem noch zur Hand, denn damit stelle ich "Reproduzierbarkeit" sicher. Ein wichtiger Faktor für Q&A / CI / CD und Testin . Automatisierung schafft in gewisser Weise "Dokumentation" und "Gleichheit" und damit Reproduzierbarkeit. Nimm jetzt bitte nicht das Wort "Dokumentation" auseinander, ich denke du verstehst, wie es in dem Kontext gemeint ist :). Ich finde nach wie vor keine guten Gründe in deiner Argumenation, wieso ich dediziertes Sysadmin Personal brauche. Updates -> Macht der Cloudprovider (wenn ich es will) Security -> Macht der Cloudprovider (für alles, was nicht mit meinem eigenen Code/Konfigs. zu tun hat) Monitoring -> Bietet der Cloudprovider as a service nginx Cluster -> Bietet der Cloudprovider as a service DBCluster -> .... Ja ich bin bewusst etwas überspitzt, die Grundaussage aber bleibt: Der Cloudprovider nimmt so viel Komplexität und bietet mir viele "Services", um die sich sonst ein Sysadmin kümmern würde. Nochmal, mein Standpunkt basiert auf Argumenten, die immer wieder in der Diskussion fallen. Diese Diskussion möchte ich hier führen. Meinen eigenen Standpunkt (oder meine Meinung dazu) habe ich noch gar nicht kundgetan. Ich vertrete jetzt erstmal die Sicht, dass der Entwickler alles selbst kann (und dafür sogar am besten geeignet ist).
  5. @Arvi - Du siehst DevOps schon stark in einer Position, man muss halt den Bullshit-Bingo-Faktor berücksichtigen. Für manche ist es eine Philosophie, die gewisse Ziele verfolgt. Man will von den klassischen Problemen weg, dass die Entwicklung ein Produkt fertigt, dass von einer operativen Abteilung betrieben wird. Kommt es zu Problemen, geht die Schuldzuweisung los. Die Reibung unter Betreibern und Herstellern des Produkts ist naturgemäß groß. Devops kann durch Neustrukturierung von Teams und Methoden dafür sorgen, dass jeder für seine eigenen Produkte komplett veranwortlich ist (Motto: Wir haben es entwickelt, wir betreiben es auch, entsprechend groß ist unser Qualitätsanspruch, da wir die Konsequenzen im operativen Betrieb ausbaden). Eine weiterer DevOps Aspekt ist der Tatsache geschuldet, dass wir eine Cloud-Shift haben. Kenntnisse von Sysadmins spielen in der Cloud keine Rolle (SAN, Netzwerk, Server, Hardware, Cluster etc. nimmt die Cloud an vielen Stellen ab). Stattdessen brauchen wir Automatisierer: "Infrastructure-as-Code" - Wir brauchen keine "Betreiber" mehr, das machen ebenfalls alles Entwickler, wir brauchen in Zukunft nur noch Entwickler (NoOps) / Automatisierer. Ich schreibe das aus neutraler Sicht und möchte damit nur sagen, DevOps muss nicht in einer Position verankert sein.
  6. Erzähl das mal den "DevOps" Hipstars :).
  7. Achso - Also legt deine alte Firma verglichen mit deinem alten Vertrag jetzt 950 monatlich brutto drauf? Das hört sich besser an. Trotzdem wechselst Du für 100€ (wenn du es mit Deinem jetztigen Gehalt vergleichst) zurück in das alte "Leid". 950 € brutto sind schon fair - trotzdem und ohne Dich näher zu kennen, würde ich dir raten, trotzdem mal Erfahrungen in einer anderen Firma zu sammeln. Das erweitert den Horizont ungemein....gerade in den ersten Jahren Berufserfahrung.
  8. 100€ im Monat?? 13. Gehalt (nicht fix - sondern Zielvereibarung)?? Wertschätzung eines Arbeitgebers zeigt sich allein monetär - Floskeln und Arschkriecherei zählen nichts, das ist reines Ködern. Das ist ein Witz..... Lass dich nicht so leicht fangen. Eine Größenordnung deines jetztigen Gehalts wäre noch ein guter Anhaltspunkt.
  9. http://www.adminarsenal.com/admin-arsenal-blog/secure-password-with-powershell-encrypting-credentials-part-2/
  10. Mit "secure-strings" in powerShell kannst du das clear-type PW umgehen.
  11. Meiner Meinung nach vollkommen Wumpe was genau deine Ausbildung war. IT ist so breitgefächert, wichtig ist, was du gemacht hast und was du kannst. Fisis mit Coding Skills werden Developer, Fiaes mit Routing Skills werden Netzwerker.... Die Firmen wissen doch viel zu oft selbst nicht, was genau die Unterschiede sind...die wollen wissen was du für ein Portfolio hast.
  12. Hast du jemals ein Comptia Zertifikat abgelegt? Comptia hat alles, sowohl Einsteiger- als auch Zertifikate für Fortgeschrittene. Am besten berichte ich deshalb mal authentisch als jemand, der z. B. den Security+ dort vor ein paar Jahren abgelegt hat (mittlerweile abgelaufen). Vom Wissen her war es eine sehr gute Auffrischung und teilweise auch eine Bereicherung für Themengebiete, in denen ich weniger theoretisches Wissen hatte. Schöne Einführung in Kryptografie z. B., prinzipiell werden alle drei großen Säulen der Security eingeführt, nicht nur rein technischer Fokus. Ja teilweise auch Basiswissen, allerdings deckt er so gut wie alle Bereiche der IT Security ab. Danach weiß man eventuell wo man hin will -> selbst Security hat diverse Vertiefungsrichtungen. Wer vllt. mal CISSP werden will, hat hier eine gute Basis. Ich habe es nicht bereut. Hat es mir im Lebenslauf geholfen? -> Vielleicht, es wurde nicht wirklich thematisiert - Die Comptia Zertifikate scheinen in den USA anerkannter zu sein. Hat es mich persönlich weitergebracht einen besseren Überblick über IT Security an sich zu bekommen? -> auf jden Fall Hat sich die Sache gelohnt? -> Auf jeden Fall. Ich wollte bewusst herstellerunabhängig ansetzen und bin denke ich gut damit gefahren. Ja der Network+ im Gegensatz zum CCNA ist abgespeckt, aber ich denke nicht, dass man das für alle Zertifkate sagen kann, die Comptia anbietet. BTW geht Comptia immer mehr von der stupiden multiple Choice Prüfung weg - es waren praktische Szenarien in der Prüfung (Firewall Ruleset Config. u. ä.)
  13. Oha nix Routing....NAT->Destination NAT oder abgekürzt DNAT ist das Zauberwort.... Eventuell musst du die dazugehörige Firewall Policy bauen....oder diese Sophos macht das automatisch mit.

Fachinformatiker.de, 2019 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

×
×
  • Neu erstellen...

Wichtige Information

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