Glossar (IT)

A

Agile Softwareentwicklung

• Agile Softwareentwicklung bezeichnet Ansätze im Softwareentwicklungsprozess, die die Transparenz und Flexibilität erhöhen und zu einem schnelleren Einsatz der entwickelten Systeme führen sollen, um so Risiken im Entwicklungsprozess zu minimieren. Die Kernidee besteht darin, Teilprozesse möglichst einfach und somit beweglich (=agil) zu halten. In 2001 entstand das sogenannte Manifest für agile Softwareentwicklung, das aus vier Werten und zwölf Prinzipien besteht.

  „Individuen und Interaktionen mehr als Prozesse und Werkzeuge Funktionierende Software mehr als umfassende Dokumentation Zusammenarbeit mit dem Kunden mehr als Vertragsverhandlung Reagieren auf Veränderung mehr als das Befolgen eines Plans“

• Die vier Werte besagen, dass für eine erfolgreiche Entwicklung von Programmen zwar formale Grundlagen wie standardisierte Prozesse, Dokumentation sowie vorgegebene Rahmen und Handlungsanweisungen durch Verträge notwendig sind, weiche Kriterien wie Kommunikation, Rücksichtnahme auf Beteiligte und flexibles Agieren jedoch mindestens ebenso wichtig sind.

• Um diese Werte zu berücksichtigen, wurden deshalb die zwölf Prinzipien formuliert, die bei der agilen Softwareentwicklung befolgt werden sollen:

  „Unsere höchste Priorität ist es, den Kunden durch frühe und kontinuierliche Auslieferung wertvoller Software zufrieden zu stellen. Heiße Anforderungsänderungen selbst spät in der Entwicklung willkommen. Agile Prozesse nutzen Veränderungen zum Wettbewerbsvorteil des Kunden. Liefere funktionierende Software regelmäßig innerhalb weniger Wochen oder Monate und bevorzuge dabei die kürzere Zeitspanne. Fachexperten und Entwickler müssen während des Projektes täglich zusammenarbeiten. Errichte Projekte rund um motivierte Individuen. Gib ihnen das Umfeld und die Unterstützung, die sie benötigen und vertraue darauf, dass sie die Aufgabe erledigen. Die effizienteste und effektivste Methode, Informationen an und innerhalb eines Entwicklungsteam zu übermitteln, ist im Gespräch von Angesicht zu Angesicht. Funktionierende Software ist das wichtigste Fortschrittsmaß. Agile Prozesse fördern nachhaltige Entwicklung. Die Auftraggeber, Entwickler und Benutzer sollten ein gleichmäßiges Tempo auf unbegrenzte Zeit halten können. Ständiges Augenmerk auf technische Exzellenz und gutes Design fördert Agilität. Einfachheit - die Kunst, die Menge nicht getaner Arbeit zu maximieren - ist essenziell. Die besten Architekturen, Anforderungen und Entwürfe entstehen durch selbstorganisierte Teams. In regelmäßigen Abständen reflektiert das Team, wie es effektiver werden kann und passt sein Verhalten entsprechend an.“

• Beispiele für agile Methoden in der Softwareentwicklung sind Crystal, eXtreme Programming, Scrum, oder Feature Driven Development.

Links:

• https://de.wikipedia.org/wiki/Agile_Softwareentwicklung
• http://www.it-agile.de/
• https://www.youtube.com/watch?v=ZUwo8tKoYnQ
• https://www.youtube.com/user/WirSindAgile/videos
• https://www.youtube.com/watch?v=PpZ-Pxrvc84

Ansible

• Ansible ist eine Open-Source-Plattform zur Orchestrierung und allgemeinen Konfiguration und Administration von Computern. Sie kombiniert Softwareverteilung, Ad-hoc-Kommando-Ausführung und Konfigurationsmanagement. Sie verwaltet Netzwerkcomputer über SSH und erfordert keinerlei zusätzliche Software auf dem zu verwaltenden System. Module nutzen zur Ausgabe JSON und können in jeder beliebigen Programmiersprache geschrieben sein. Das System nutzt YAML zur Formulierung wiederverwendbarer Beschreibungen von Systemen

Links:

• https://realguess.net/2014/12/21/ansible-update-servers-to-the-latest-and-reboot/
• https://de.wikipedia.org/wiki/Ansible
• https://noqqe.de/blog/2015/07/12/ansible-mein-neues-pssh/
• http://de.slideshare.net/stephanhochhaus/automatisierte-infrastruktur-mit-ansible
• http://www.admin-magazin.de/Online-Artikel/Konfigurationsmanagement-mit-Ansible
• http://www.admin-magazin.de/Das-Heft/2015/04/Workshop-Automatisierung-mit-Ansible
• https://docs.ansible.com/
• http://www.ansible.com/
• http://www.admin-magazin.de/Online-Artikel/Konfigurationsmanagement-mit-Ansible
• https://www.youtube.com/watch?v=xew7CMkL7jY
• https://www.youtube.com/watch?v=2jXHxkLBOHg
• https://docs.ansible.com/ansible/intro_getting_started.html
• http://www.techsomnia.net/2013/11/ansible-apt-get-updateupgrade/
• https://docs.ansible.com/ansible/apt_module.html
• https://docs.ansible.com/ansible/intro_patterns.html
• https://bildung.xarif.de/xwiki/bin/Informatik/Grundlagen
• https://gitlab.xarif.de/thomass/ansible_documentation/tree/master
• https://bildung.xarif.de/xwiki/bin/Informatik/Ansible
• http://www.linux-magazin.de/NEWS/Orchestrierungssoftware-Ansible-1.4-verfuegbar
• https://www.tutorials.de/threads/ansible-vagrant-docker-aehm-haeaeaeae-wie-jetzt.400719/

Ant

• Apache Ant (englisch für Ameise) ist ein in Java geschriebenes Programm zum automatisierten Erzeugen von ausführbaren Computerprogrammen aus Quelltexten.

• Es erfüllt den gleichen Zweck wie das sehr verbreitete Programm make, nämlich die automatisierte Erstellung von installierbaren Software-Paketen aus existierendem Quelltext, Bibliotheken und sonstigen Dateien

Architektur

• ist die Beschäftigung mit der Frage, wie man Code strukturiert und orchestriert.

Monolithische Architektur

• Die einfachste Architektur ist dabei der Monolith – es gibt nämlich nur ein einziges, großes, in sich geschlossenes Gebilde. Der Monolith funktioniert ohne Schichten oder sonstige Struktur, weshalb er am ehesten einer "Nicht-Architektur" entspricht, über die man nicht nachdenken muss, sondern die in gewissem Sinne einfach entsteht.

Client-Server

• Der nächstkomplexere Ansatz ist die Client-Server-Architektur, bei der eine Anwendung in zwei Teile zerlegt wird – ein Frontend und ein Backend. In einigen Situationen ist diese Architektur das natürliche Vorgehen, beispielsweise bei der Webentwicklung, die generell die im Webbrowser ausführbare UI von der auf dem Server ausgeführten Geschäftslogik und dem Datenzugriff trennt. Auch mobile Anwendung folgen häufig diesem Ansatz.

• Der große Vorteil dieses Ansatzes ist die Möglichkeit, Konsistenz und Integrität an zentraler Stelle kontrollieren und sicherstellen zu können – das ist jedoch zugleich auch der größte Nachteil, denn derartig gestaltete Systeme weisen mit dem zentralen Server einen Single Point of Failure auf, der das System im Vergleich zu anderen Ansätzen anfälliger für Angriffe oder Zensurmaßnahmen macht.

Peer to Peer (P2P)

• Eine Alternative dazu stellen P2P-Architekturen dar, die dezentral und verteilt arbeiten, aber gänzlich ohne Server auskommen: Stattdessen sind alle Knoten einander gleichgestellt, und sie tauschen die Daten direkt aus. Eine derart aufgebaute Anwendung nachhaltig zu stören, ist sehr aufwendig, da sich das System um entstandene Löcher sozusagen selbst neue Wege sucht – im Zweifelsfall über andere Knoten.

• Historisch gesehen sind P2P-Systeme primär aus den verschiedenen mehr oder minder legalen Tauschbörsen bekannt, die vor allem um die Jahrtausendwende verbreitet waren. Die gleichen Konzepte, Protokolle und Methoden lassen sich aber auch zur Entwicklung von Geschäftsanwendungen verwenden.

Servicebasierte Architektur

• Eine Mischung von all dem stellen die verteilten servicebasierten Architekturen dar, die auf der Idee basieren, eine Anwendung in kleinere fachliche Einheiten zu zerlegen, die unabhängig voneinander entwickelt, betrieben, getestet und aktualisiert werden können. Das Grundprinzip ist dabei nicht neu, denn bereits Mitte der 90er-Jahre gab es mit SOA und WOA entsprechende Ansätze, die aber technisch noch sehr aufwendig waren.

• Inzwischen stellen Micro- und Nanoservices die gängige Vorgehensweise bei diesem Architekturtyp dar, was häufig zudem mit Serverless-Ansätzen aus der Cloud kombiniert wird. Die Ideen dahinter sind aber nach wie vor die gleichen, nämlich eine Anwendung als einen Verbund von einzelnen, autarken und autonomen Diensten aufzubauen, statt eine einzige große Software zu entwickeln.

B

Big Data

• Mit "Big Data" werden große Mengen an Daten bezeichnet, die u.a. aus Bereichen wie Internet und Mobilfunk, Finanzindustrie, Energiewirtschaft, Gesundheitswesen und Verkehr und aus Quellen wie intelligenten Agenten, sozialen Medien, Kredit- und Kundenkarten, Smart-Metering-Systemen, Assistenzgeräten, Überwachungskameras sowie Flug- und Fahrzeugen stammen und die mit speziellen Lösungen gespeichert, verarbeitet und ausgewertet werden

Big Nudging

• Als Nudging wird der Versuch der Verhaltensbeeinflussung bezeichnet, um Leuten dabei zu „helfen“, das „Richtige“ zu tun – also zum Beispiel Apfel essen statt Cola trinken. Und zwar nicht indem man sie mit Informationen und Argumenten überzeugt, sondern indem man sie wohlmeinend manipuliert, ihnen eine Art Stups (nudge) in die richtige Richtung gibt.

BizDevOps

BizDevOps, auch bekannt als DevOps 2.0, ist ein Ansatz für die Softwareentwicklung, der die Zusammenarbeit von Management (Business), Entwicklern (Devolper) und Betriebsmitarbeitern (Operations) fördert, damit das Unternehmen Software schneller entwickeln, besser auf die Nachfrage der Benutzer reagieren und letztlich den Umsatz maximieren kann.

• Links
  • https://www.computerweekly.com/de/definition/BizDevOps
  • https://entwickler.de/devops/in-vier-schritten-zu-mehr-wertschopfung

C

CAP Theorem

Das Akronym CAP steht für die Begriffe Consistency, Availability und Partition Tolerance.

Consistency

bedeutet, dass alle Clients jederzeit die gleichen Daten sehen.

Availability

bedeutet, dass alle Clients stets Lese- und Schreibzugriffe durchführen können.

Partition Tolerance

bedeutet, dass das System auch bei Ausfall einzelner Knoten als Ganzes weiter arbeiten kann.

• Links
• https://www.codecentric.de/wissens-hub/blog/grundlagen-cloud-computing-cap-theorem
• https://www.ionos.com/digitalguide/server/know-how/what-is-cap-theorem/?srsltid=AfmBOorvGOzi5McysQaeHtiEFvQG_Sv9nKYRHavki7D-kzj33dvF6_rD
• https://dzone.com/articles/better-explaining-cap-theorem

Cattle vs Cats

One of the core concepts in DevOps is the preposition of Cattle vs Pets to describe the service model.

• Links
  • https://www.hava.io/blog/cattle-vs-pets-devops-explained

Clearnet / Surface Web

das restliche, offene World Wide Web, das mitunter auch als "Clearnet" oder "Surface Web" (Oberflächennetz) bezeichnet wird. Dessen Inhalte sind unter Endungen wie .de oder .com zu finden. Sie lassen sich mit gängigen Internetbrowsern wie Google Chrome, Firefox oder Internet Explorer aufrufen und werden von verbreiteten Suchmaschinen wie Google erfasst.

Links:

• http://bit.ly/2Fe4bCd
• http://bit.ly/2FgWDyv
• http://bit.ly/2FgWHOL

Cloud-Schichtenmodell

Infrastructure as a Service (IaaS)

Der Cloud-Anbieter stellt eine High-Level-API bereit, mit der man Infrastrukturkomponenten wie Netzwerke oder Virtuelle Maschinen erstellen und konfigurieren kann. Der Anbieter kümmert sich um die Infrastruktur: Hardware wie VMs/Server, Netzwerk und Storage. Der Anwender ist für die Konfiguration und Wartung der darüber liegenden Betriebssysteme, Datenbankserver, Application-Server und Anwendungen selbst zuständig.

Containers as a Service (CaaS)

beschreibt eine Form der Container-basierten Virtualisierung, bei der Container-Engine, Orchestrierung und die darunter liegenden Compute-Ressourcen als Service von einem Cloud-Anbieter an die Nutzer ausgeliefert werden. In einigen Fällen wird CaaS auch verwendet, um die Container-Support-Dienste eines Cloud-Anbieters zu kennzeichnen.

• Google Container Engine (GKE)
• Amazon EC2 Container Service (ECS)
• Microsoft Azure Container Service (ACS)

Platform as a Service (PaaS)

Der Cloud-Anbieter stellt nicht nur die Infrastruktur, sondern die gesamte Umgebung bereit, auf welcher der Anwender seine selbstgeschriebene Software entwickeln, installieren und betreiben kann. Der Cloud-Anbieter kümmert sich um die dahinterliegende Infrastruktur und die Plattform (Betriebssystem, Datenbankserver, Middleware und so weiter), der Anwender um seine eigene Software und Programmierung.

Function as a Service (FaaS)

Hier stellt der Cloud-Anbieter einen Service bereit, bei dem der Entwickler eine Funktion (ein kleines Programm) bereitstellen kann. FaaS ist aus der Schichtensicht relativ ähnlich zu PaaS. Das heißt, der Entwickler muss sich nicht um die Infrastruktur und Plattform (zum Beispiel das Betriebssystem) kümmern. Der Unterschied ist, dass bei PaaS eine Umgebung dauerhaft im Hintergrund läuft. Auch wenn es keine Aufgaben oder Anfragen gibt, läuft wenigstens ein Prozess im Hintergrund, während bei FaaS erst beim Aufruf der Funktion der Dienst in Bruchteilen einer Sekunde gestartet, die Funktion ausgeführt und anschließend wieder schnell beendet wird. FaaS ist oft dann sinnvoll, wenn es sich nicht lohnt, eine ganze Plattform im Hintergrund laufen zu haben, um nur hin und wieder eine bestimmte Funktion auszuführen. Ein Anwendungsbeispiel wäre eine Funktion, die Bilder auf eine bestimmte Größe skaliert. Diese Aufgabe dauert in der Regel nur (Milli-)Sekunden und wird von zahlreichen Anwendungen an unterschiedlichen Stellen benötigt. Diese Bildskalierungsfunktion könnte man als FaaS bereitstellen und von mehreren Webanwendungen, die zum Beispiel auf PaaS laufen, aufrufen.

• AWS Lambda (Amazon)
• Google Cloud Functions (Google)
• Cloud Functions von IBM
• Cloud Fn von Oracle
• Webtask.io
• Hook.io
• Azure Function

Software as a Service (SaaS)

Der Cloud-Dienstleister stellt alles zur Verfügung: Infrastruktur, Plattform und Software. Der Anwender kann die Software mit eingeschränkten Konfigurationsmöglichkeiten seinen Bedürfnissen anpassen.

Continuous Delivery

Continuous Delivery (CD) bezeichnet eine Sammlung von Techniken, Prozessen und Werkzeugen, die den Softwareauslieferungsprozess (englisch: Deployment) verbessern.

Techniken wie Continuous Integration (CI), Testautomatisierung und kontinuierliche Installation erlauben in Kombination mit agilen Methoden die Entwicklung qualitativ hochwertiger Software. Software-Build-Jobs auf CI-Servern wie Jenkins ermöglichen ein automatisiertes Testen und Erstellen von „Nightly“- oder „Release“-Versionen. Diese Versionen können mit Hilfe von CD automatisiert auf Entwicklungs-, Test-, Integrations- und Produktivumgebung eingespielt werden.

Die Automatisierung der Integrations- und Auslieferungsprozesse ermöglicht schnelle, zuverlässige und wiederholbare Deployments. Erweiterungen oder Fehlerkorrekturen können somit mit geringem Risiko und niedrigem manuellem Aufwand in die Produktivumgebung oder zum Kunden ausgeliefert werden. Continuous Delivery wird primär in Kombination mit agilen Methoden eingesetzt. Für eine Einführung von Continuous Delivery wird häufig eine Umsetzung des DevOps-Ansatzes empfohlen.

Continuous Deployment

Der letzte Schritt ist Continuous Deployment (CD). Die gleiche Abkürzung wie Continuous Delivery und deswegen denken vielleicht auch viele Leute, dass es dasselbe ist. Es gibt jedoch einen kleinen Unterschied zwischen beiden.

Machst Du Continuous Delivery, so legst Du fest, wann Du in Produktion gehst. Bei Continuous Deployment machst Du das nicht.Jeder erfolgreiche Build resultiert in einem automatisierten Deployment in Produktion.

In beiden Fällen kannst Du leicht in Produktion gehen, aber bei Continuous Delivery ist es eine Wahl.

Continuous Integration

Continuous Integration hat das Ziel, die Qualität der Software über permanente Integration ihrer einzelnen Bestandteile zu steigern. Statt die Software nur in sehr großen Zeitabständen kurz vor der Auslieferung zu erstellen, wird sie in kleinen Zyklen immer wieder erstellt und getestet. So können die Integrationsprobleme oder fehlerhafte Tests frühzeitig und nicht erst am Tag des Release erkannt werden. Durch die kleinen Deltas zwischen den einzelnen Builds sind Fehler wesentlich leichter zu finden und zu beheben.

Grundvoraussetzung für die kontinuierliche Integration ist, dass der Quellcode in einem Versionskontrollsystem verwaltet wird und die Entwickler ihre Arbeitsstände auch permanent in dieses zurückspielen. Typischerweise wird die Software nach jedem Commit, oder bei sehr zeitintensiven Builds zumindest regelmäßig mehrmals täglich, gebaut. Im Anschluss werden Tests und Codeanalysen durchgeführt. Abschließend wird die Software beispielsweise auf einem Stage-System bereitgestellt. Die Entwickler und, wenn gewünscht, weitere Beteiligte werden über den Build-Vorgang benachrichtigt und haben die Möglichkeit, sich Ergebnisse, Logs und Analysen anzuschauen.

So bekommen die Entwickler fehlerhafte Commits nicht erst durch die Kollegen mitgeteilt, sondern schon zeitnah durch die permanente Rückmeldung der „unabhängigen Kontrollinstanz“ Continuous Integration Server. Den Projektleitern und Kunden stehen, je nach Bedarf, stets aktuelle Informationen über den Entwicklungsstand oder ein aktuelles Testsystem zur Verfügung.

D

Darknet

Ein Darknet ist ein digitales Netz, das sich vom sonstigen Internet abschirmt und mit technologischen Mitteln die Anonymität seiner Nutzer herstellt. Wer Inhalte anbietet, wer mit wem kommuniziert und worüber, das alles wird mithilfe von Verschlüsselungstechnologien verschleiert.

DataOps

DataOps ist eine agile, prozessorientierte Methodik, um Analysen zu entwickeln und bereitzustellen. Michele Goetz, Vice President und Principal Analyst bei Forrester, definiert DataOps als "die Fähigkeit, Lösungen zu ermöglichen, Datenprodukte zu entwickeln und Daten für den Geschäftswert über alle Technologieebenen hinweg zu aktivieren - von der Infrastruktur bis hin zur Experience".

Laut Dataversity besteht das Ziel von DataOps darin, das Design, die Entwicklung und die Wartung von Applikationen zu rationalisieren, die auf Daten und Datenanalysen basieren. DataOps soll die Art und Weise verbessern, wie Daten gemanagt und Produkte erstellt werden - und diese Verbesserungen mit den Unternehmenszielen koordinieren.

• Links
  • https://www.computerwoche.de/a/was-ist-dataops,3553890

Deep Web

bezeichnet Inhalte, die nicht von Suchmaschinen erfasst werden können. Das kann unterschiedliche Gründen haben: weil es sich um geschlossene Intranets von Unternehmen oder Organisationen handelt, weil Seiten nicht oder nur kaum über Links mit dem sonstigen Web verbunden sind oder weil Inhalte von Bezahlschranken vor einem automatisierten Zugriff geschützt sind.

DevOps

Was bedeutet Devops? DevOps ist eine Wortneuschöpfung, die sich aus den Begriffen “Development” (Dev) und “Operations” (Ops) zusammensetzt. Es beschreibt den Ansatz, die typischerweise getrennten IT-Bereiche “Entwicklung” (Development) und “Betrieb” (Operations) zu vereinen.

• Links
  • https://www.computerwoche.de/a/wie-devops-die-it-beschleunigen,3071433
  • https://azure.microsoft.com/de-de/resources/cloud-computing-dictionary/what-is-devops

DevSecOps

DevSecOps ist ein Kunstwort, das sich aus jeweils drei Buchstaben der drei Begriffe Development, Security und Operations zusammensetzt. "Dev" steht für Entwicklung, "Sec" für Sicherheit und "Ops" für Betrieb. Es handelt sich um ein Konzept, das den DevOps-Gedanken um die Aspekte der Software-Sicherheit erweitert.

• Links
• https://www.security-insider.de/was-ist-devsecops-a-1084945/

Doxing

Ist das internetbasierte Zusammentragen und anschließende Veröffentlichen personenbezogener Daten, zumeist mit bösartigen Absichten gegenüber den Betroffenen.

E

Efail

• Aktive Inhalte im E-Mailclient müssen deaktiviert werden. Dazu zählt die Ausführung von html-Code und das Nachladen externer Inhalte, die oftmals aus Design-Aspekten erlaubt sind.
• E-Mailserver und E-Mailclients müssen gegen unauthorisierte Zugriffsversuche abgesichert sein.
• Prinzipiell gilt: Nutzer sollten einerseits das Nachladen von HTML-Inhalten abstellen, was ohnehin grundsätzlich empfehlenswert ist – und die hoffentlich bald kommenden Sicherheitsupdates von Plug-ins wie Enigmail oder GPGTools so bald wie möglich installieren. Andererseits sollten sicherheitshalber alle Rückkanäle für das Nachladen weiterer Inhalte (auch das automatische Laden von PGP-Schlüsseln) deaktiviert werden.

Elasticsearch

• Elasticsearch ist eine Suchmaschine auf Basis von Lucene. Das in Java geschriebene Programm speichert die Suchergebnisse in einem NoSQL-Format (JSON) und gibt sie über ein RESTful-Webinterface aus. Elasticsearch-Konfiguration der Wikipedia-Server

• Elasticsearch ist neben Solr der am weitesten verbreitete Suchserver. Er ermöglicht auf einfache Weise den Betrieb im Rechnerverbund zur Umsetzung von Hochverfügbarkeit und Lastverteilung

F

G

GitOps

• Der Begriff GitOps geht auf das von Weaveworks-CEO Alexis Richardson geprägte Schlagwort "Operations by Pull Requests" zurück, dass eine Kombination von Continuous Delivery (Applikationen) und Infrastructure as Code (IaC) auf der Basis der Versionsverwaltungssoftware Git beschreibt. Sämtliche zum Verteilen der Anwendungen und zum Deklarieren der Infrastruktur notwendigen Informationen liegen dabei in einem Git-Repository, dass den Single Point of Truth (SPoT) repräsentiert.

• Die Idee zu GitOps entstammt dem Kubernetes-Umfeld. Mittlerweile entstehen aber auch mehr und mehr Möglichkeiten, GitOps mit anderen Betriebsumgebungen (z.B. virtuellen Maschinen) zu benutzen. Die Umsetzung von GitOps erfolgt bei Kubernetes nach dem Operator-Pattern. Ein Operator ist eine Cloud-native Anwendung, die beim Betrieb von anderen Anwendungen unterstützt. Ein GitOps-Operator prüft regelmäßig oder „on push“ den im Git beschriebenen Wunsch-Zustand des Clusters gegen den tatsächlichen Zustand des Clusters. Bei Änderungen passt der GitOps Operator den Cluster entsprechend an. Die bekanntesten Implementierungen sind Flux und ArgoCD. Beide sind Projekte der Cloud Native Computing Foundation, unter deren Schirmherrschaft auch Kubernetes entwickelt wird.

• Deklarative Konfiguration: Alle Ressourcen müssen vollständig deklariert sein.

• Versionskontrolle und unveränderlicher Storage: Die Beschreibungen sind in einem Repository abgelegt, das unveränderbare Speicherung und Versionierung bietet.
• Automatisierte Verteilung: Die Umsetzung der Beschreibungen aus dem Repository in die Laufzeitumgebung muss vollständig automatisiert erfolgen.
• Softwareagenten: Sie gleichen den Zustand des Systems ab und stellen die in der Deklaration beschriebenen Ressourcen bereit.
• Geschlossener Kreislauf: Sobald Abweichungen zwischen der deklarativen Konfiguration und dem Ist-Zustand des Systems auftreten, werden passende Aktionen ausgelöst.
• Links:
  • https://de.cloudflight.io/presse/gitops-continuous-deployment-fuer-kubernetes-35460/
  • https://www.informatik-aktuell.de/entwicklung/methoden/gitops-und-kubernetes-ein-neuer-stern-am-cloud-himmel.html
  • https://medium.com/devops-dudes/gitops-evolution-of-devops-bfdb639dc387
  • https://jaxenter.de/devops/gitops-jenkins-x-interview-aschemann-devopscon-89789
  • https://www.dev-insider.de/gitops-tools-in-der-uebersicht-a-943715/
  • https://www.dev-insider.de/wie-funktioniert-gitops-in-der-praxis-a-928759/

Gradle

• Gradle ist ein auf Java basierendes Build-Management-Automatisierungs-Tool, vergleichbar mit Apache Ant und Apache Maven. Gradle nutzt eine auf Groovy basierende domänenspezifische Sprache (DSL) zur Beschreibung der zu bauenden Projekte. Im Gegensatz zu Maven-Projektdefinitionen (pom.xml) sind Gradle-Skripte direkt ausführbarer Code.

Groovy

• Groovy ist eine Programmiersprache und Skriptsprache, die dynamische und statische Typisierung unterstützt. Sie zählt zu den Sprachen, die auf der Java Virtual Machine ausgeführt werden, was eine Verfügbarkeit für viele Plattformen wie insbesondere Linux, Mac OS X und Windows ermöglicht. Das Design-Ziel des ursprünglichen Entwicklers James Strachan bestand darin, eine „geschliffene“ Fassung der Java-Syntax mit den Konzepten von Ruby zu verbinden.

H

Hadoop

• Apache Hadoop ist ein freies, in Java geschriebenes Framework für skalierbare, verteilt arbeitende Software. Es basiert auf dem MapReduce-Algorithmus von Google Inc. sowie auf Vorschlägen des Google-Dateisystems und ermöglicht es, intensive Rechenprozesse mit großen Datenmengen (Big Data, Petabyte-Bereich) auf Computerclustern durchzuführen

Hackerethik

• Die Hackerethik bezeichnet eine Sammlung ethischer Werte, die für die Hackerkultur ausschlaggebend sein sollen. Für diese Ethik gibt es mittlerweile verschiedene Definitionen. Zentrale Werte in den verschiedenen Aufstellungen sind Freiheit, Kooperation, freiwillige und selbstgewählte Arbeit sowie Teilen.

I

Infrastructure as Code (IaS)

• Die Abkürzung IaC steht für Infrastructure as Code „programmierbare Infrastruktur“. Es handelt sich um einen konzeptionellen Ansatz aus dem IT-Umfeld, der die Bereitstellung von Infrastrukturleistungen wie Rechenleistung (Computing), Speicherplatz (Storage) und Netzwerk (Networking) mithilfe von maschinenlesbarem Code ermöglicht. Oft wird IaC auch als programmierbare Infrastruktur bezeichnet.

• Zur Bereitstellung von Infrastrukturleistungen müssen keine manuellen Konfigurationsarbeiten ausgeführt werden. Die Infrastruktur wird über Skripte oder Programmfiles beschrieben und automatisiert gemäß den Vorgaben konfiguriert. Das Erstellen der Infrastruktur ist ein mit dem Programmieren von Software vergleichbarer Vorgang.

J

K

Kafka

• Mit Apache Kafka stellen wir ein ungewöhnliches Messaging-System vor. Es besticht durch persistente Speicherung der Nachrichten, hohen Transaktionsdurchsatz und gute Skalierbarkeit. Kafkas Architektur ermöglicht dadurch nicht nur den Einsatz in Online-Szenarien mit zeitnaher Verarbeitung, sondern auch in Offline-Szenarien mit stark zeitverzögerter Verarbeitung von Nachrichten.

• Ursprünglich bei LinkedIn entwickelt, ist Apache Kafka seit Anfang 2011 ein Apache-Incubator-Projekt. Kafka ist ein in Scala implementiertes, verteiltes Messaging-System, das über ein Java-API auch in Java-Applikationen verwendet werden kann. Im Wesentlichen kann man mit Kafka eine Reihe persistenter Queues mit hohem Durchsatz bereitstellen. Ursprünglich wurde es konzipiert, um bei LinkedIn der Flut von Logs Herr zu werden.

• Links

• https://goo.gl/2vAGs2

L

Lucene

• Apache Lucene ist eine Programmbibliothek zur Volltextsuche. Lucene ist freie Software und ein Projekt der Apache Software Foundation.

M

Maven

• Maven ist ein Build-Management-Tool der Apache Software Foundation und basiert auf Java. Mit ihm kann man insbesondere Java-Programme standardisiert erstellen und verwalten.

Microservices

• Microservices sind ein Architekturkonzept der Anwendungsentwicklung. Was sie von herkömmlichen, monolithischen Ansätzen unterscheidet, ist die Art und Weise, wie Apps in ihre Kernfunktionen aufgeschlüsselt werden. Jede Funktion bzw. jeder Service kann unabhängig entwickelt und implementiert werden. Das heißt, individuelle Services können ohne jegliche Beeinflussung anderer Services funktionieren

• Vorteile:

• Schnelle Markteinführung
• Skalierbar
• Robustheit
• Einfache Implementierung

• kürzere Entwicklungszyklen

• Nachteile:

• Identifikation von Abhängigkeiten
• Komplexere Testszenarien
• größerer Monitoring/Überwachungsaufwand
• Erschwertes Debugging

Monolith

• Unter dem Begriff Monolith wird in der Softwarearchitektur ein Softwaresystem als zusammenhängende logische Einheit verstanden. Je nach Perspektive ist es sinnvoll, den Begriff noch weiter zu unterscheiden

Modul-Monolith

• Bei dieser Art des Monolithen wird der gesamte Quelltext des Softwaresystems innerhalb eines Moduls organisiert. Ein Modul kann bspw. eine JAR-Datei oder eine DLL sein. Das einzige Werkzeug zur Strukturierung und Organisation sind in diesem Fall programmiersprachliche Mittel wie z. B. Packages oder Namespaces.

Deployment-Monolith

• Bei dem Deployment-Monolithen ist der Quelltext in unterschiedlichen Modulen organisiert. Allerdings müssen die Module beim Deployment immer als Ganzes ausgeliefert werden und können nicht unabhängig voneinander deployt werden. Ausnahmen wie OSGi bestätigen hier die Regel.

Laufzeit-Monolith

• Bei dieser Art von System handelt es sich in der Regel um einen Deployment-Monolith, der weitere Funktionen über Remote Calls angebunden hat

• Man spricht trotzdem von einem Monolithen, wenn die Remote-Systeme zwingend für den normalen Betrieb der Software zur Verfügung stehen müssen und nicht fehlertolerant (resilient) angebunden sind.

• Links:

• https://www.informatik-aktuell.de/entwicklung/methoden/vom-monolithen-zu-self-contained-systems.html#c27236

Munin

• Die freie Software Munin ist ein Werkzeug zur Überwachung von Rechnern in einem Rechnernetzwerk mit Status- und Prozess-Visualisierung. Ein zentraler Rechner, der sogenannte „Master“, sammelt Leistungsdaten von im Netzwerk verteilten Computern, den „Nodes“, speichert diese und stellt die Daten mittels Webschnittstelle graphisch dar. Die Speicherung der Messwerte geschieht mit Hilfe von RRDtool.

N

O

Openstack

• OpenStack ist ein Softwareprojekt, das eine freie Architektur für Cloud-Computing zur Verfügung stellt. Initiiert wurde es von Rackspace sowie der NASA und wird von diversen anderen Firmen, unter anderem AT&T, Canonical, Hewlett-Packard Enterprise, Intel, Red Hat, Huawei und IBM unterstützt

Openshift

• OpenShift ist eine von Red Hat entwickelte Produktreihe von Container-Anwendungsplattformen für Cloud Computing. Im Unterschied zu Virtualisierung beziehungsweise virtuelle Rechner gilt die Container-Technologie als weniger ressourcenintensiv und lässt sich viel einfacher verwalten

P

Q

R

Redis

• Redis ist eine In-Memory-Datenbank mit einer einfachen Schlüssel-Werte-Datenstruktur (englisch: key value store) und gehört zur Familie der NoSQL-Datenbanken (ist also nicht relational). Nach einer Erhebung von DB-Engines.com ist Redis der verbreitetste Schlüssel-Werte-Speicher.

• Die einfache Struktur der Datenbank eignet sich weniger für komplexe Datenstrukturen, die überwiegend in der Datenbank selbst abgebildet werden soll, dafür ist der große Vorteil von Redis, dass es schneller ist als relationale Datenbanken wie z. B. MySQL. Bis zu ca. 100.000 Schreibvorgänge und ca. 80.000 Lesevorgänge pro Sekunde sind auf herkömmlicher Hardware möglich.

• Redis bietet Persistenz durch automatisiertes regelmäßiges Abspeichern oder per Protokolldatei, wodurch bei entsprechender Konfiguration auch eine ACID-konforme Dauerhaftigkeit erreichbar ist.

Links:

• http://redis4you.com/articles.php?id=001&name=Redis as session handler in PHP
• https://wiki.ubuntuusers.de/Redis
• https://www.digitalocean.com/community/tutorials/how-to-back-up-your-redis-data-on-ubuntu-14-04
• https://rtcamp.com/tutorials/php/redis-php-sessions/
• https://www.linode.com/docs/databases/redis/redis-on-ubuntu-12-04-precise-pangolin
• http://docs.funnelback.com/configuring_redis_to_work_with_multiple_servers.html

RRDtool

• RRDtool ist ein Programm, mit dem zeitbezogene Messdaten gespeichert, zusammengefasst und visualisiert werden können. Das Programm wurde ursprünglich von Tobias Oetiker entwickelt und unter der GNU General Public License (GPL) lizenziert. Durch die Veröffentlichung als freie Software haben inzwischen viele weitere Autoren neue Funktionalität und Fehlerbehebungen beigesteuert. RRDtool ist als Quelltext und als ausführbares Programm für viele Betriebssysteme verfügbar.

• Die Abkürzung RRD steht für „Round-Robin-Database“ und bezieht sich auf die Art und Weise, in der Daten von RRDtool gespeichert werden. Beim Anlegen einer Datenbank, einer so genannten „RRD-Datei“, wird genug Speicher für eine angegebene Zeitspanne angelegt. Nach dieser Zeitspanne wird die Datenbank nicht erweitert (die Datei wird nicht vergrößert), sondern die ältesten Daten werden überschrieben. Dieses „Reihum-Verfahren“ wird in der Informatik auch als Ringpuffer bezeichnet.

S

Scrum

• Vorgehensmodell der agilen Softwareentwicklung, das davon ausgeht, dass Softwareprojekte aufgrund ihrer Komplexität nicht im Voraus detailliert planbar sind. Aus diesem Grund erfolgt die Planung nach dem Prinzip der schrittweisen Verfeinerung, wobei die Entwicklung des Systems durch das Team nahezu gleichberechtigt erfolgt.

• Das zu entwickelnde System wird über Produkteigenschaften (Features) definiert, die im Product Backlog in einer priorisierten Reihenfolge festgelegt sind. Das Product Backlog ist anfangs nicht vollständig und wird mit der Zeit um weitere Eigenschaften erweitert bzw. um Eigenschaften reduziert. Die eigentliche Entwicklung des Systems ist in sogenannte Sprints unterteilt, die zwischen einer Woche und einem Monat dauern. In einem Sprint werden alle Eigenschaften umgesetzt, die zuvor aus dem Product Backlog ausgewählt und in das Sprint Backlog eingetragen worden sind. Das Ergebnis eines Sprints ist ein lauffähiges (Teil-)System. An einen Sprint schließt sich die Retrospektive an, in der der soeben abgeschlossene Projektabschnitt bewertet wird, um Erfahrungen zu verarbeiten und in Verbesserungen einfließen zu lassen.

• In Scrum sind drei interne und drei externe Rollen vorgesehen. Die internen Rollen sind (1) der Product Owner, (2) das Entwicklungsteam und (3) der Scrum Master.

• Zu den externen Rollen zählen (1) der Kunde, (2) der Anwender und (3) das Management.

• Der Product Owner ist mit dem Projektleiter zu vergleichen, der die Verbindung zum Kunden hält und mit diesem in regelmäßigem Kontakt steht. Er hat die Verantwortung hinsichtlich der Konzeption, der Projektkosten, der Terminierung und der Systemfunktionalität, weshalb er die Richtung bezüglich der Produkteigenschaften vorgibt. Der Product Owner nimmt die vom Team gelieferte Leistung hinsichtlich der Funktionalität ab. Er verwaltet die Produkteigenschaften im Product Backlog und priorisiert diese.

• Das Entwicklungsteam ist für die Realisierung der Eigenschaften verantwortlich. Es entscheidet, wie viele Eigenschaften in das Sprint Backlog übernommen und somit in einem Sprint umgesetzt werden. Das Team ist eigenverantwortlich in seiner Arbeit und verteilt die anfallenden Aufgaben untereinander. Das Team ist interdisziplinär zusammengesetzt, wobei jedes Teammitglied selbst aber auch interdisziplinär arbeiten muss. Das Team trifft sich zu Beginn eines jeden Tages für maximal 15 Minuten im Daily Scrum, in dem innerhalb des Teams jedes Mitglied über seinen Fortschritt und das nächste Ziel mithilfe von Burndown Charts berichtet. Alle Treffen werden vom Scrum Master moderiert, der dafür sorgt, dass das Team ungestört seiner Arbeit nachgehen kann und es von Anfragen von außen abschottet. Er ist nicht Mitglied des Teams und diesem nicht weisungsbefugt. Der Scrum Master kümmert sich um Probleme innerhalb des Teams und um mögliche Probleme, die das Team an der Entwicklung hindern.

• Anwender sind die Personen, die mit dem fertigen Produkt arbeiten müssen. Nur die Anwender können den Entwicklern Feedback darüber geben, ob das Produkt in jeglicher Hinsicht korrekt arbeitet und hinreichend gut benutzbar ist (Usability).

• Das Management ist in letzter Instanz verantwortlich dafür, dass das Scrum gelingt. Zu diesem Zweck muss es dafür sorgen, dass die Rahmenbedingungen wie Räumlichkeiten, Ressourcen, verfügbare Technik, personelle Ausstattung gegeben sind.

Links:

• https://de.wikipedia.org/wiki/Scrum
• https://de.wikipedia.org/wiki/Scrum#Sprint_Planning
• https://de.wikipedia.org/wiki/Scrum#F.C3.BCnf_Phasen_einer_Retrospektive
• http://scrum-master.de/Scrum-Meetings/Sprint_Planning_Meeting
• https://borisgloger.com/scrum/materialien/videos/
• https://borisgloger.com/scrum/scrum-flow/
• http://de.slideshare.net/axxessio/scrum-vs-wasserfall
• https://www.youtube.com/watch?v=PPO5GwSo0d4
• https://alphanodes.com/de/regeln-sprint-planning

Self-contained Systems (SCS)

• sind ein Architekturmuster der Informationstechnik, bei dem Funktionen in mehrere unabhängige Systeme separiert werden. So wird das logische Gesamtsystem zu einer Kollaboration mehrerer kleiner Software-Systeme

• Self-contained Systems sind Microservices ähnlich, aber es gibt einige Unterschiede: Ein System enthält weniger SCS als Microservices. Außerdem können Microservices mit anderen Microservices kommunizieren – sogar synchron. SCS hingegen sollen idealerweise gar nicht oder nur asynchron kommunizieren. Schließlich können Microservices eine getrennte UI haben, während ein SCS eine UI enthält

• SCS haben folgende Eigenschaften:

• Jedes SCS ist eine unabhängige Web-Anwendung.
• Jedes SCS wird von einem Team entwickelt.
• Kommunikation mit anderen SCSs oder Drittsysteme soll – wenn möglich – asynchron erfolgen.
• Ein SCS kann optional eine Service-API haben.
• Jedes SCS muss Daten und Logik enthalten.
• Ein SCS soll seine Feature für Endkunden mit einer UI nutzbar machen.
• Um enge Kopplung zu vermeiden, darf ein SCS keinen Geschäftscode mit anderen SCS teilen.

Serviceorientierte Architektur (SOA)

• Eine serviceorientierte Architektur (SOA) ist die zugrundeliegende Struktur, die verschiedene Services bei der Kommunikation untereinander unterstützt. SOA definiert, wie zwei Recheninstanzen (zum Beispiel Programme) interagieren, so dass eine Instanz eine Arbeitsleistung im Auftrag einer anderen Instanz ausführt. Serviceinteraktionen werden durch eine Beschreibungssprache definiert. Jede Interaktion ist in sich abgeschlossen und lose gekoppelt. Sie sind von anderen Interaktionen somit unabhängig.

• Links:

• https://www.computerweekly.com/de/definition/Serviceorientierte-Architektur-SOA

Simple Object Access Protocol (SOAP)

• ist ein Netzwerkprotokoll, mit dessen Hilfe Daten zwischen Systemen ausgetauscht und Remote Procedure Calls durchgeführt werden können. SOAP ist ein industrieller Standard des World Wide Web Consortiums (W3C)

Social Engineering

• Beim Social Engineering werden menschliche Eigenschaften wie Hilfsbereitschaft, Vertrauen, Angst oder Respekt vor Autorität ausgenutzt, um Personen geschickt zu manipulieren. Der Angreifer verleitet das Opfer auf diese Weise beispielsweise dazu, vertrauliche Informationen preiszugeben, Sicherheitsfunktionen auszuhebeln, Überweisungen zu tätigen oder Schadsoftware auf dem privaten Gerät oder einem Computer im Firmennetzwerk zu installieren.

-Beim Social Engineering nutzt der Täter den "Faktor Mensch" als vermeintlich schwächstes Glied der Sicherheitskette aus, um seine kriminelle Absicht zu verwirklichen.

Solr

• Solr ist ein in Lucene enthaltenes Servlet für entsprechende Container wie Apache Tomcat. Solr wurde ursprünglich von CNET entwickelt und Solar genannt.[9] Der Name war eine Abkürzung für Search on Lucene and Resin. Der Download von Solr umfasst als Beispiel eine Konfiguration mit Jetty.

• Solr kommuniziert über das Hypertext Transfer Protocol. Mittels HTTP POST können verschiedenste Dateiformate von XML über JSON bis PDF erfasst und auch Dokumente erstellt werden.Abfragen erfolgen mittels HTTP GET.

T

Twelve Factors

I. Codebase

One codebase tracked in revision control, many deploys

II. Dependencies

Explicitly declare and isolate dependencies

III. Config

Store config in the environment

IV. Backing services

Treat backing services as attached resources

V. Build, release, run

Strictly separate build and run stages

VI. Processes

Execute the app as one or more stateless processes

VII. Port binding

Export services via port binding

VIII. Concurrency

Scale out via the process model

IX. Disposability

Maximize robustness with fast startup and graceful shutdown

X. Dev/prod parity

Keep development, staging, and production as similar as possible

XI. Logs

Treat logs as event streams

XII. Admin processes

Run admin/management tasks as one-off processes

Links

• https://12factor.net/
• https://www.redhat.com/architect/12-factor-app-containers
• https://www.pluralsight.com/resources/blog/cloud/twelve-factor-apps-in-kubernetes
• https://medium.com/ibm-cloud/kubernetes-12-factor-apps-555a9a308caf

U

V

Varnish

• Varnish ist ein Web-Beschleuniger für dynamische Webseiten mit viel Inhalt. Im Gegensatz zu anderen Webbeschleunigern, die häufig aus clientseitigen Proxys oder aus Servern entstanden, wurde Varnish von Grund auf als Webbeschleuniger konzipiert. Varnish wird von namhaften Internetseiten wie Facebook, Twitter, SoundCloud[2], eBay, The New York Times, The Hindu, Vimeo, Die Zeit, Chefkoch.de und Wikipedia eingesetzt

W

X

Y

Z