0 Treffer
◀◀

Glossar (IT)

A

Agile Softwareentwicklung

Links:

Ansible

Links:

Ant

Architektur

Monolithische Architektur

Client-Server

Peer to Peer (P2P)

Servicebasierte Architektur

B

Big Data

Big Nudging

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.

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.

Cattle vs Cats

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

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:

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.

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.

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.

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.

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.

Doxing

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

E

Efail

Elasticsearch

F

G

GitOps

Gradle

Groovy

H

Hadoop

Hackerethik

I

Infrastructure as Code (IaS)

J

K

Kafka

L

Lucene

M

Maven

Microservices

Monolith

Modul-Monolith

Deployment-Monolith

Laufzeit-Monolith

Munin

N

O

Openstack

Openshift

P

Q

R

Redis

Links:

RRDtool

S

Scrum

Links:

Self-contained Systems (SCS)

Serviceorientierte Architektur (SOA)

Simple Object Access Protocol (SOAP)

Social Engineering

-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

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

U

V

Varnish

W

X

Y

Z