Blog

Feeds

RSS 1.0-, RSS 2.0- oder Atom-Feed.

Domain-Driven Datenarchitektur

Viele Unternehmen investieren weiterhin in Data-Lake, in der Hoffnung, Daten in großem Maßstab demokratisieren zu können. Es ist jedoch bereits jetzt absehbar, dass darauf basierende Plattformen die Versprechungen nicht erfüllen werden können. Um die Probleme anzugehen, müssen wir die bisherigen Paradigmen des Data-Lake und seines Vorgängers Data-Warehouse überwinden und die Vorteile beider nutzen. Diese Lösung geht von einer verteilten Architektur aus, die den verschiedene Fachdomänen eine Self-Service-Dateninfrastruktur bereitstellt und die Daten als Produkte behandelt.

Wir arbeiten seit zwei Jahren am Aufbau eines Computercluster für das Fraunhofer ISE.

Dabei wurde von uns häufig erwartet, dass wir diesen zentralisiert, monolithisch und domänenunabhängig aufbauen, also als sog. Data Lake.

Die größte Herausforderung besteht nicht darin, einen Datensee zu erstellen, sondern die sich daraus ergebenden Chancen zu nutzen.

– Sean Martin, CTO Cambridge Semantics

Wir konnten jedoch bereits früher zusammen mit anderen Kunden erkennen, dass diese Chancen kaum genutzt werden konnten. Hier deswegen zunächst ein kurzer Überblick über frühere Architektur-Generationen:

Historie

  1. Generation: Enterprise Data Warehouse (EDW)

    Vor einem Jahrzehnt waren Daten meist ein Synonym für relationale Datenbanken. Meist führte dies jedoch zu hohen technischen Schulden in Form von tausenden nicht zu überarbeitenden ETL (extract, transform, load)-Jobs, die nur eine kleine Gruppe von Fachleuten versteht. Damit blieben jedoch die erhofften positiven Auswirkungen unerfüllt.

  2. Generation: Big-Data-Ökosystem mit einem Data Lake

    Jetzt können Daten eine erstaunliche Vielfalt von Formen annehmen einschließlich NoSQL, Zeitreihen und SQL. Dies ist auf den Wunsch zurückzuführen, immer schneller auf immer größere, vielfältigere und schnellere Datenquellen zu reagieren. Forscher werden jedoch mit dem Verstehen unterschiedlicher Arten der Datenhaltung vor zusätzliche Herausforderungen gestellt. Aktuell bekommen wir also zusätzliche Möglichkeiten, ohne dass jedoch die grundlegenden Probleme der vorgehenden Generation gelöst worden wären. Diese Ökosysteme mit lange laufenden Batch-Jobs werden mit all ihren Auswirkungen meist nur von hochspezialisierten Fachleuten verstanden. Zwar führte dies theoretisch zu einer Fülle von möglichen Analysen und Simulationen, diese konnten aber wegen ihres Umfangs und ihrer Komplexität praktisch nur selten realisiert werden.

    CockRoachDB und Spanner bieten darüberhinaus globale Konsistenz und Event stream processing (ESP) mit Abfragemöglichkeiten für aggregierte Log-Dateien.

    Ein Nachteil dieses Ansatzes besteht jedoch darin, dass er eher an low-level Database Events als an Geschäftsereignisse auf höherer Ebene gebunden ist, die für uns die Grundlage einer ereignisorientierten Architektur sein sollte – Ereignisse sollten in ihren Domänen explizit erfasst werden oder Statusübergänge sollten nicht impizit erschlossen werden müssen.

Beiden Generationen sind jedoch die folgenden Architekturfehler gemeinsam:

  1. zentral und monolithisch
  2. sequenzierte Pipeline
  3. spezialisiertes Eigentum

Ad 1. Zentral und monolithisch

Alle zugänglichen Daten wurden erfasst und dem ETL (extract, transform, load)-Dreischritt unterworfen:

  1. Extract

    Möglichst alle Daten wurden erfasst, unabhängig davon, ob sie für eine spezifische Fachdomäne benötigt wurden oder nicht.

  2. Transform

    Die Transformation der Daten erfolgte üblicherweise ebenfalls nicht in Hinblick auf die konkreten Erfordernisse sondern vielmehr in Hinblick auf eine möglichst universelle Verwendbarkeit. Häufig wurden die Daten auch noch mit Informationen aus anderen Datenquellen angereichert um prinzipiell noch umfassendere Analysen machen zu können.

  3. Load

    In diesem Schritt wurde darauf geschaut, dass die Daten für eine Vielzahl von Fachdomänen über die gewünschten Protokolle bereitgestellt werden können.

Während wir bei der Anwendungsentwicklung in den letzten Jahren darauf achteten, dass das Design spezifisch für die jeweilige Domäne ist und auch nur in diesem spezifischen Kontext funktionieren muss, wurde Domain Driven Design bei den Datenplattformen weitgehend ignoriert. Dies führte dann zu den bekannten Problemen:

  • Die Aufwände, diese domänenunspezifischen Daten zu harmonisieren, nahmen zu.
  • In vielen Fällen war zu sehen, dass die Integration neuer Datenquellen verzögert oder blockiert wurde, weil sie nicht in das universelle Schema passen wollen.

Die von uns vorgeschlagene Alternative wird nicht zu fragmentierten, isolierten und domänenorientierten Daten führen, die schwer zu entdecken sind sowie spezifisches Wissen zum Verstehen und verarbeiten benötigen. Dies wären dann auch nur wieder fragmentierte Data Warehouses, wie sie sich häufig zur Umgehung der oben genannten Probleme angestaut haben und die nun als technische Schulden weitere Innovationen behindern.

Ad 2: Sequenzierte Pipeline

Der ETL (extract, transform, load)-Dreischritt offenbart jedoch noch weitere Schwierigkeiten, die sich aus der sequentiellen Aufteilung der Funktionen ergeben. Die Motivation für das Sequenzieren der Datenverarbeitung lag in der bestehenden Arbeitsteilung der Forschungsteams.

Organisationen, die Systeme entwerfen, … sind auf Entwürfe festgelegt, welche die Kommunikationsstrukturen dieser Organisationen abbilden.

– Melvyn E. Conway: Conway’s Law, 1967

Obwohl diese Gliederung ein gewisses Maß an Skalierung zu bietet scheint, da Teams verschiedenen Phasen der Verarbeitungspipeline zugewiesen werden, kommt dieser Effekt jedoch meist nicht zum Tragen, da bei neuen Features meist alle Sequenzen der Pipeline überarbeitet werden müssen.

So müssten z.B. für die Ergänzung der Strom-Ex- und Import-Daten um geplante und ungeplante Kraftwerksausfälle alle drei ETL-Bereiche angepasst werden.

Ad 3: Spezialisiertes Eigentum

Das dritte Problem hängt damit zusammen, wie die Teams strukturiert sind, die die Plattform erstellen und betreiben. Meist sind diese Teams isoliert von denjenigen, die diese Plattform für ihre Analysen und Simulationen nutzen. Sie erlangen also meist keine Kenntnis von den Datenquellen und deren Verwendung; sie sollen nur betriebliche und analytische Anforderungen erfüllen, ohne jedoch jemals ein klares Verständnis für eine konkrete Anwendung der Daten zu erhalten.

Die nächste Generation von Datenplattformen

Aus den oben angesprochenen Problemen wird deutlich, dass ein Paradigmenwechsel erforderlich ist. Ein Paradigmenwechsel, der in anderen IT-Bereichen bereits stattgefunden hat und dort bereits die Erprobungsphase verlassen hat: Domain-Driven Architecture, Self-Service-Plattforms und Product Thinking führen zu ubiquitous computing in einem vermaschten Netz (engl. Mesh).

Domain-Driven Architektur

Domänenorientierte Aufteilung und Eigentum der Datensätze

Eric Evans Buch Domain-Driven Design hat nicht nur die moderne Software-Architektur tiefgreifend beeinflusst, sondern auch die Organisationsentwicklung: Nicht nur wurden monolithische Systeme in Microservices zerlegt, auch die um Technologieschichten (Datenbank, Anwendungslogik, UI) organisierten Teams wurden umgewandelt in domänenspezifische Teams.

Bei einem solchen dezentralen Datenmanagement ist dann die Herausforderung, wie diese domänenspezifischen Daten gemeinsam genutzt werden können. Dies ist gut in Ben Stopfords Data Dichotomy-Artikel beschrieben.

Um nun eine monolithische Datenplattform zu dezentralisieren, müssen wir auch unsere Einstellung zu Ort und Eigentum dieser Daten überdenken: statt fleißig Daten in unseren eigenen, zentral gelegenen Data Lake zu übernehmen, müssen nun die Fachdomänen selbst für das Hosting dieser Daten sorgen und sie in einfach zu verarbeitender Weise zur Verfügung stellen. Dies kann dann zur Folge haben, dass wir dieselben Daten, jedoch für jede der Fachdomänen unterschiedlich aufbereitet, so auch in verschiedenen Domänen speichern.

Damit verlagert sich der Datenfluss von einem sequenzierten Pipeline-Prozess hin zu einer domänenspezifischen Aufbereitung.

Quelldomän-Datensätze

Einige Domänen richten sich natürlich nach der Herkunft der Datensätze. Meist entstehen diese Datensätze sehr nahe an der Quelle, an der die Daten entstehen. Idealerweise übernehmen die Lieferanten dieser Datensätze auch die Gewähr, dass diese hinreichend integer sind.

Note

Diese Datensätze enthalten meist nur Rohdaten, die zum Zeitpunkt der Erstellung möglichst genau wiedergeben und nicht für einen bestimmten Konsumenten angepasst oder modelliert sind.

Verbraucherorientierte und gemeinsam genutzte Datensätze

Einige Domänen bestimmen sich nicht aus der Herkunft sondern dem Ziel, das erreicht werden soll. Auch ansonsten unterscheiden sich diese Datensätze erheblich von denjenigen der Quelldomäne: Sie werden jedoch transformiert, um einen möglichst einfachen Zugriff darauf zu erlauben. Hier entsteht also eine Pipeline zur Bereinigung, Aufbereitung, Aggregation und Bereitstellung der Daten.

Self-Service-Platforms

Es gibt jedoch nicht nur innerhalb der Domänen von verbraucherorientierten Datensätzen Verarbeitungspipelines, sondern auch bereits bei Quelldomän-Datensätzen: Dort müssen die Daten auf Vollständigkeit überprüft werden und frei von Dubletten sein.

Um die Komplexität solcher Pipelines jedoch so gering wie möglich zu halten, werden sie immer nur innerhalb ihrer eigenen Domäne behandelt. Dort können dann auch Service-Levels für die Daten dieser Domäne definiert werden wie Aktualität, Fehlerraten etc.

Product Thinking

In anderen Bereichen wurden Produkte schon viel früher über Projekte gestellt, s.a. Products over Projects. Zukünftig werden die Teams einer Datendomäne den Forschungsteams ihre Funktionen als APIs zur Verfügung stellen und liefern so einen Baustein für die Schaffung höherer Funktionalitäten und Auftragswerte. Damit ein solches Produkt erfolgreich wird, müssen die Daten folgende Eigenschaften aufweisen:

  • Ein Datenprodukt muss leicht auffindbar sein

    Eine übliche Implementierung besteht in einer Registrierung und einem Datenkatalog aller Datenprodukte mit ihren Metainformationen. Diese zentrale Anlaufstelle ermöglicht Datenkonsumenten, die Datensätze ihres Interesses leicht zu finden.

  • Jedes Datenprodukt muss eine eindeutige Adresse haben

    Diese Adresse muss einer globalen Konvention folgen und anderen Benutzern erleichtern, programmatisch auf diese Daten zuzugreifen. Und auch wenn die zugrundeliegenden Speicher und Datenformate unterschiedlich sind, z.B. Events als Stream von Kafka Topics oder Kolumnen in Apache Parquet, so müssen diese Daten doch einheitlich adressierbar sein um Reibungsverluste beim Auffinden und Zugreifen auf diese Daten gering zu halten.

  • Die Daten müssen vertrauenswürdig und wahrheitsgemäß sein

    Hierfür werden Service-level Objectives (SLOs) definiert und überwacht. Hierfür werden die Daten bereinigt, Dubletten entfernt und automatisiert Integritätstests durchgeführt.

    Ebenso sollte die Datenherkunft (engl.: Data Lineage) als Metadaten bereitgestellt werden um die Eignung für spezielle Bedürfnisse ermitteln zu können.

    Die SLOs können jedoch zwischen den einzelnen Datenprodukten variieren.

  • Die Semantik und Syntax sollte leicht zugänglich sein

    Datenschemata sind häufig der Ausgangspunkt für die Bereitstellung von Self-Service-Datenbeständen. Daher werden sie üblicherweise zusammen mit Beispieldatensätzen leicht zugänglich veröffentlicht.

  • Die Daten sollten interoperabel sein

    Auch wenn die Daten in einzelnen Fachdomänen verwaltet werden, so ist jedoch erklärtes Ziel, die Daten domänenübergreifend korrelieren zu können. Voraussetzung für effektive Korrelationen sind das Einhalten bestimmter Standards und Harmonisierungsregeln. Dies wird z.B. über die Definition von Feldtypen, die Identifizierung bestimmter Polyseme in verschiedenen Domänen, Adresskonventionen für Datensätze, gemeinsame Metadatenfelder, Event-Formate wie z.B. in der CloudEvents Specification) festgelegt etc.

  • Der Zugriff auf Produktdatensätze muss sicher sein und sollte einer globalen Zugriffskontrolle unterliegen

    Hierfür können Single Sign On und Role Based Access Control verwendet werden.

Vermaschtes Netz

Domain-Driven Architecture, Self-Service-Plattforms und Product Thinking kommen zusammen in einem vermaschten Netz. Einerseits besteht dieses aus verteilten Datenprodukten, die sich an Domänen orientieren und die im Besitz unabhängiger und funktionsübergreifender Teams sind; andererseits nutzen sie eine gemeinsame Dateninfrastruktur mit einer Hosting-Plattform und ETL-Bibliotheken. Darüberhinaus wird die Vereinheitlichung von batch- und streaming-Jobs, z.B. mit Apache Beam, die problemlose Verarbeitung adressierbarer polyglotter Datensätze ermöglichen. Das Beam-Modell basiert auf dem Dataflow-Modell, mit dem sich die Logik elegant ausdrücken lässt. Zudem werden von Beam auch verschiedenste Runner unterstützt, u.a. Apache Flink, Apache Spark und Apache Samza, s.a. Beam Capability Matrix. Es ist jedoch zu beachten, dass die Runner unterschiedlichste Fähigkeiten haben und die Bereitstellung einer übergreifenden API ein schwieriges Unterfangen bleibt.

Beam hat darüberhinaus ein umfangreiches Set an eingebauten I/O-Transformationen, die einen großen Teil der Daten-Pipeline-Anforderungen abdecken dürfte. Und falls diese nicht ausreichen sollten, können auch benutzerdefinierte Transformationen definiert werden.

Zum Weiterlesen

Eric Evans: Domain-Driven Design

ein nicht einfach zu lesendes Buch, aber die kanonische Quelle für Domain-Driven Design.

In Kapitel IV wird das Ermitteln der Domänengrenzen beschrieben.

Vaughn Vernons: Implementing Domain-Driven Design
konzentriert sich auf strategisches Design und erläutert in Kapitel 2 ausführlich, wie eine Domäne in begrenzte Kontexte untergliedert wird.
William Kent: Data and Reality
und auch wenn das Buch etwas in die Jahre gekommen ist, so ist es doch weiterhin relevant für das Datenmanagement.

Das Problem mit SSH Agent-Forwarding

Am 12. April 2019 wurde die Website matrix.org gehackt. Anschließend wurden auf GitHub einige der Fehler veröffentlicht, die diesen Angriff ermöglicht haben, u.a. [SECURITY] SSH Agent Forwarding. Eine Zusammenfassung dieser Fehler findet sich in Repost of the security issues. Dabei war der initiale Fehler, dass den Entwicklern SSH-Forwarding erlaubt wurde.

Problem und Lösungen für SSH Agent-Forwarding

Selbst in den man pages von ssh_config wird gewarnt:

Agent forwarding should be enabled with caution. Users with the ability to bypass file permissions on the remote host (for the agent's Unix-domain socket) can access the local agent through the forwarded connection. An attacker cannot obtain key material from the agent, however they can perform operations on the keys that enable them to authenticate using the identities loaded into the agent.

Einfach ausgedrückt: Wenn der Jump Server kompromitiert ist und SSH Agent-Forwarding als Verbindung zu einem anderen Computer verwendet wird, kann auch der Zielhost angegriffen werden.

Statt SSH Agent-Forwarding sollte besser ProxyCommand oder ProxyJump (ab OpenSSH 7.3) verwendet werden, da dann die TCP-Verbindung über ssh an den Zielhost weitergeleitet wird und so eine Ende-zu-Ende-Verschlüsselung realisiert wird. Falls dann jemand auf dem Jump Host versucht, die Verbindung mit einem Man-in-the-Middle-Angriff zu unterbrechen, warnt ssh vor dieser Unterbrechung.

ProxyCommand kann z.B. folgendermaßen konfiguriert werden:

Host bastion
  HostName bastion.example.org

Host target
  HostName target.example.internal
  Port 2222
  ProxyCommand ssh -W %h:%p bastion

Die entsprechende Konfiguration mit ProxyJump kann z.B. so aussehen:

Host bastion
  HostName bastion.example.org

Host target
  HostName target.example.internal
  Port 2222
  ProxyJump bastion

Alternativ können beide Optionen selbstverständlich auch über die Befehlszeile angegeben werden:

ssh -o 'ProxyJump=bastion.example.org' target.example.internal -p 2222

Eskalation

Die Eskalation von Privilegien hätte vermieden werden können …

  • wenn die Entwickler nur den Zugriff bekommen hätten, der unbedingt benötigt wird und nicht root-Zugriff auf alle Server.
  • wnn nicht alle Server direkt über das Internet erreichbar gewesen wären.
  • wenn mit sshd_config nicht Schlüssel in authorized_keys2 hinzugefügt werden könnten.
  • wenn nicht vertrauliche Daten im Repository für die interne Kommunikation gespeichert worden wären.
  • wenn auf den Hosts nur die eigene Konfiguration gespeichert gewesen wäre.
  • wenn die Log-Dateien besser analysiert und Warnmeldungen bei ungewöhnlichem Verhalten geschickt worden wären.
  • wenn GPG-Schlüssel zum Signieren von Paketen nicht auf Production-Hosts hinterlegt gewesen wären.
  • wenn Zwei-Faktor-Authentifizierung (2FA) verwendet worden wäre, z.B. mit Yubikey.

Case Study: Plone Dexterity und VueJS Form Generator

Für das Portal der ITAD auf Basis von Plone sollte die Cusy GmbH ein komplexes Formular mit über 100 Feldern leichter bedienbar machen. Dies erreichten wir durch

  • die Gliederung der Felder in sog. Fieldsets
  • unmittelbare, Client-seitige Validierung der Feldinhalte
  • redaktionell konfigurierbare Sichtbarkeit der einzelnen Felder
  • automatische Formatierung von Zahlen und Texten

Plone-Dexterity schien uns wenig geeignet, um abhängige Felder zu implementieren. Für diese wie auch die anderen Anforderungen schien uns der Vue Form Generator deutlich besser geeignet.

Mit dem Vue Form Generator implementierten wir die Formulare als Web-Komponenten mit JSON (siehe z.B. github.com/vue-generators/…/main.js). Solche JSON-Felddefinitionen werden sowohl für die Bearbeitung wie auch die Ansicht der Formulare verwendet. Zusätzlich nutzten wir noch einige Nicht-Standard-Feldtypen, die der Vue Form Generator bereitstellt: Optionale Felder. Die Dexterity-basierten Artikeltypen erhalten die Formulardaten per AJAX. Serverseitig werden sie erneut validiert und ggf. als Annotationen gespeichert. In den Schemas dieser Dexterity-Inhaltstypen sind nur die Metadaten des Dublin-Core gespeichert.

Für uns ist das Resümee dieser Fallstudie, dass VueJS und der Vue Form Generator einfach in Plone integriert werden können. Dabei werden mit JSON die Formulare definiert und Dexterity lediglich als Backend zum Speichern der Formulardaten verwendet.

Mattermost – die datenschutzkonforme Slack-Alternative

Mattermost vereint die Team-Kommunikation an einer Stelle, ist durchsuchbar und von überall erreichbar, ob mit dem Browser, als Desktop- oder mobile App. Es ist sicher, konfigurier- und skalierbar von kleinen Teams bis hin zu großen Unternehmen.
Sicherheit
Bereitstellung moderner und HTTPS-verschlüsselter Kommunikation. Ihr bleibt im Besitz eurer Daten und werdet niemals eingesperrt.
Konfigurierbarkeit
Nutzt eine flexible, datenschutzkonforme Lösung für Unternehmen mit umfassender API und offenem Quellcode auch für mobile und Desktop-Apps.
Skalierbarkeit
Mettermost lässt sich einfach skalieren von kleinen Teams bis hin zu großen Unternehmen.

Funktionen

Direkt-, Gruppen- und öffentliche Nachrichten

Mattermost erlaubt sowohl Direktnachrichten, Nachrichten an ein bestimmtes Team oder an die Öffentlichkeit. Dabei lassen sich alle Nachrichten durchsuchen.

Datenaustausch

Mattermost erlaubt auch den einfachen Austausch von Dateien und Bildern. Dabei könnt ihr selbstverständlich auch wählen, ob ihr diese mit einzelnen Personen, Teams oder öffentlich teilen wollt. Und natürlich könnt ihr auch mehrere Dateien und Bilder gleichzeitig hochladen.

Webhooks

Mattermost bietet sog. Webhooks an, mit denen sowohl eingehende wie auch ausgehende Nachrichten konfiguriert werden können. Diese sind Slack-kompatibel. Darüberhinaus unterstützt Mattermost auch Markdown als Auszeichnungssprache.

Unter Apps & Integrations findet ihr eine Reihe von nativen Anwendungen für iOS, Android, Windows, OS X, und Linux. Hier finden sich auch einige Implementierungen für

Migration von Slack

Die Nutzerkonten und Archive der verschiedenen Kanäle bei Slack lassen sich einfach in Mattermost importieren.

Video-Konferenz

Mattermost unterstützt Video- und Audio-Anrufe. Hierfür können wir unseren Kunden einen eigenen Jitsi-Meet-Server zur Verfügung stellen, und Mattermost integriert diese Videokonferenzen dann im jeweiligen Chat.

Microservices – Definition

Microservices, wie wir sie verstehen, unterteilt eine einzelne Anwendung in eine Reihe von kleinen Diensten, die jeweils als eigenständiger Prozess laufen und leichtgewichtig miteinander kommunizieren, oft über eine HTTP-Resource-API.

Diese Dienste implementieren Geschäftsprozesse, die unabhängig und automatisiert einsetzbar sind. Die zentrale Verwaltung dieser Dienste wird auf ein Minimum reduziert und kann in unterschiedlichen Programmiersprachen geschrieben sein und unterschiedliche Speichertechnologien nutzen.

Abgrenzung gegen Monolithen

Die Idee der Microservices ist entstanden aus der Abgrenzung zu monolithischer Software, die verschiedene Geschäftsprozesse in einer Anwendung zusammenfasst. Genauer gesagt werden diese Monolithen üblicherweise in einer Schichtenarchitektur mit drei oder vier Schichten konzipiert:

  1. eine Benutzeroberfläche bestehend aus HTML-Seiten und Javascript, die in einem Browser dargestellt wird
  2. einer meist relationalen Datenbank bestehend aus vielen Tabellen
  3. und einer serverseitigen Anwendung die HTTP-Anfragen beantwortet, dazu fachdomänspezifische Logik ausführt und Daten aus der Datenbank aufruft und aktualisiert.

Bei einer solchen monolithischen Anwendung läuft die Logik für die Bearbeitung einer Anforderung meist in einem einzigen Prozess und für die grundlegenden Funktionen wird nur eine Programmiersprache verwendet. Die Anwendung wird dann durch Klassen, Funktionen und Namespaces aufgeteilt. Meist kann eine solche Anwendung auf dem Laptop des Entwicklers ausgeführt und getestet und eine Deployment-Pipeline verwendet werden, um sicherzustellen, dass Änderungen ordnungsgemäß getestet und in die Produktion überführt wurden. Sie können die Monolithen horizontal skalieren indem Sie viele Instanzen hinter einem Load Balancer laufen lassen.

Solche monolithischen Anwendungen wurden jahrelang von uns erfolgreich betrieben, aber sie fingen zunehmend an, uns zu frustrieren, und zwar bei den folgenden Szenarien:

  • Änderungszyklen müssen aufwändig koordiniert werden, d.h. selbst wenn nur ein kleiner Teil der Anwendung geändert werden soll, muss meist der gesamte Monolith neu gebaut und in Betrieb genommen werden.
  • Zudem wird es im Laufe der Zeit immer schwerer, eine gute modulare Struktur aufrechtzuerhalten, so dass bei Änderungen wirklich nur ein Modul betroffen ist.
  • Schließlich führt Skalierung immer dazu, dass die gesamte Anwendung repliziert werden muss, anstatt nur diejenigen Teile zu replizieren, die tatsächlich unter Last stehen und mehr Ressourcen erfordern.
Microservices

Eine monolithische Anwendung liefert alle Funktionalität in einem Prozess …

Skalierung von Microservices

… und skaliert durch Replikation des Monolithen auf mehreren Maschinen.

Um solche Frustrationen zu vermeiden, setzen wir seit vielen Jahren Microservices-Architekturen ein, die Anwendungen in einzelne Dienste unterteilt. Diese Services sind nicht nur unabhängig voneinander implementierbar und skalierbar, sondern bieten auch feste Kontextgrenzen, so dass unterschiedliche Dienste auch in der jeweils geeigneten Programmiersprache geschrieben und von verschiedenen Teams entwickelt und betreut werden können.

Monolith

Bei einer Microservices-Architektur wird jedes Funktionselement in einem separaten Service ausgeliefert …

Skalierung von Monolithen

… und skaliert durch die Verteilung dieser Dienste über Server, repliziert nach Bedarf.

Dabei erschienen uns Microservices gar nicht besonders neuartig oder innovativ – sie erinnerten uns vielmehr an eines der Designprinzipien von Unix:

Mache nur eine Sache und mache sie gut.

Dieses Designprinzip ist jedoch in monolithischen Anwendungen nicht berücksichtigt worden.

Microservices – Architektureigenschaften

Auch wenn Microservices nicht klar definiert sind, so weist ihre Architektur doch meist gemeinsame Merkmale auf.

Aufteilen der Anwendung in Servicekomponenten

Dabei haben für uns Komponenten die folgenden Eigenschaften:

  • unabhängig
  • austauschbar
  • erweiterbar

Die wesentliche Bedeutung von Microservices ist also die Aufteilung einer Anwendung in einzelne Dienste. Diese werden nicht mit anderen über In-memory-Function-Calls sprechen und unterscheiden sich damit deutlich von Serviceobjekten aus dem Domain-driven Design, die gemeinsam in nur einem Prozess ausgeführt werden.

Wesentlich für die Nutzung von Servicekomponenten und nicht als Bibliotheken ist, dass sie unabhängig voneinander eingesetzt werden können. Wenn eine Anwendung aus mehreren Bibliotheken in einem einzigen Prozess besteht, führt eine Änderung an einer einzelnen Komponente dazu, dass die gesamte Anwendung neu geordnet werden muss. Bei einer Zerlegung dieser Anwendung in mehrere Servicekomponenten jedoch sollte nur ein Service neu implementiert werden müssen. In seltenen Fällen könnte es jedoch auch hier vorkommen, dass Schnittstellen neu definiert werden müssten. Dies sollte durch die Architektur jedoch so weit wie möglich unterbunden werden.

Eine weitere Konsequenz der Verwendung von Serviceskomponenten ist eine explizite Komponentenschnittstelle. Dabei haben jedoch die meisten Sprachen leider keinen guten Mechanismus, um eine explizite Schnittstelle zu definieren. Oft ist es nur Dokumentation oder Disziplin, die verhindert, dass eine Komponentenschnittstelle geändert wird. Dies erhöht dann das Risiko einer unnötig engen Kopplung der Komponenten. Servicekomponenten vermeiden dies einfach durch explizite Remote-Call-Mechanismen.

Damit werden jedoch auch die Nachteile solcher Services offenbar:

  • Remote-Calls sind deutlich teurer als In-Process-Calls.
  • Auch sind die Remote-APIs allgemeiner gefasst und scheinen häufig schwerer bedienbar.
  • Und auch wenn die Zuordnung von Verantwortlichkeiten zwischen Komponenten geändert werden soll, so ist dies meist deutlich aufwändiger da auch Prozessgrenzen überschritten werden müssen.

Zwar werden Services häufig um einen Laufzeitprozess modularisiert, ein Service kann jedoch auch aus mehreren Prozessen bestehen, wie beispielsweise einem Prozess für die Anwendungslogik und einem für die Datenbank, die nur von diesem Service verwendet wird.

Organisation um Geschäftsprozesse

Wenn eine große Anwendung aufgeteilt werden soll, erfolgt diese häufig anhand der Technologie-Schichten, also z.B.

  • UI
  • Anwendungslogik
  • Datenbank

Wenn die einzelnen Teams jedoch genau diesen Schichten entsprechend zusammengesetzt werden, werden sie bei Änderungen meist versuchen, diese innerhalb ihres Zuständigkeitsbereichs umzusetzen. In der Folge wird sich in allen Schichten Logik wiederfinden. Dies ist nur ein Beispiel für Conways Gesetz.

Organisationen, die Systeme entwerfen, … sind auf Entwürfe festgelegt, welche die Kommunikationsstrukturen dieser Organisationen abbilden.

– Melvyn E. Conway, 1967

Funktional getrennte Teams führen zu funktional getrennter Architektur

Bei einer Microservices-Architektur wird die Anwendung nicht in unterschiedliche Schichten sondern in unterschiedliche Services unterteilt. Dabei reicht die Implementierung eines solchen Services von der persistenten Speicherung über Schnittstellen zu anderen Diensten bis hin zur Benutzeroberfläche. Infolgedessen sind die Teams funktionsübergreifend, einschließlich Expertise zur jeweiligen Datenbank, UI und Projektmanagement.

Funktionsübergreifende Teams führen zu funktionsübergreifenden Services

Produkte, nicht Projekte

Meist wird Software in einem Projekt entwickelt, bei dem die Software zu einem bestimmten Zeitpunkt ausgeliefert werden soll. Demnach wird mit der Fertigstellung die Software an ein Wartungsteam übergeben und das Projektteam aufgelöst.

Wir bevorzugen jedoch ein anderes Modell: ein Team nennt die Software über den gesamten Lebenszyklus hinweg sein eigen. Diese Verantwortung des Entwicklungsteams für die Software auch in der Produktion sehen wir auch in der DevOps-Kultur. Dadurch erhalten die Entwickler unseres Erachtens deutlich bessere Einblicke, wie sich ihre Software in der Produktion verhält und von den Anwendern angenommen wird. Durch diese Produkt-Mentatlität erhalten die Entwickler nicht nur besseren Einblick in die gewünschte Funktionalität sondern können zunehmend auch erkennen, wie der Geschäftsprozess optimiert werden könnte.

Wir betreuen unsere Anwendungen schon seit sehr langer Zeit über den gesamten Lebenszyklus hinweg, auch wenn wir sie früher häufig monolithisch, z.B. auf Basis des Web-Frameworks Zope gebaut haben, so erscheint und doch die feinere Granularität von Microservices förderlich für die Produktorientierung zu sein.

Intelligente Endpunkte und dumme Verbindungen

Bei der Erstellung von Kommunikationsstrukturen zwischen verschiedenen Diensten gibt es viele Produkte und Ansätze, die die Kommunikation deutlich erschweren können indem sie beachtliche Anforderungen an die beteiligten Komponenten stellen. Ein gutes Beispiel hierfür ist der Enterprise Service Bus (ESB), der oft anspruchsvolle Aufgaben übernehmen muss wie Message Routing, Choreographie etc.

Microservices hingegen fördern eher intelligente Endpunkte und dumme Verbindungen. Aus Microservices aufgebaute Anwendungen sind meist entkoppelt und so unzusammenhängend wie möglich. Sie besitzen ihre eigene Geschäftslogik und funktionieren wie Filter im Unix-Sinne: sie erhalten eine Anfrage, wenden ihre Logik darauf an und liefern eine Antwort zurück. Die Kommunikation erfolgt meist über einfache REST-Protokolle und nicht über komplexe Protokolle wie Service choreography, BPEL oder Orchestrierung durch zentrale Werkzeuge. Dabei sind die häufigsten Protokolle HTTP-Request-Response, ldap und Lightweight Messaging, z.B. mit RabbitMQ oder ZeroMQ. Sie übernehmen zuverlässig den asynchronen Nachrichtenaustausch ohne überhaupt nur eine Ahnung von der Geschäftslogik zu haben.

Bei einer monolithischen Anwendung sprechen die einzelnen Komponenten mit den anderen meist über einen Methoden- oder Funktionsaufruf. Und dies dürfte dann auch eines der größten Probleme sein um Änderungen bei einem solchen Monolithen vorzunehmen.

Dezentrale Organisation

Zentralisierte Organisationen neigen dazu, sich auf nur eine einzige Technologieplattform zu reduzieren. Dies kann jedoch dazu führen, dass gegebenenfalls auch ein unpassendes Werkzeug zur Lösung des Problems verwendet werden soll.

Wir wählen das passende Werkzeug für die jeweilige Aufgabe!

Wir versuchen schon lange nicht mehr alles in eine monolithischen Anwendung integrieren zu wollen. Stattdessen entwickeln wir nützliche Services, die häufig auch bei anderen Projekten wieder eingesetzt werden können.

Dezentralisierte Organisation

Wenn wir die Komponenten des Monolithen in Services aufteilen, haben wir die Wahl, wie wir sie bauen. Da verwenden wir dann z.B. ReactJS, um eine einfache Berichtseite zu erstellen und C++ für einen Real-Time-Service. Auch wählen wir die passende Datenbank für die jeweilige Datenstruktur.

Dezentrales Datenmanagement

Wenn wir über das Datenmanagement einer Anwendung nachdenken, machen wir dies häufig anhand der Kontextgrenzen (bounded context) aus dem Domain-driven Design: DDD teilt eine komplexe Fachdomäne in mehrere, möglichst klar umrissene Zusammenhänge auf und bildet daraus die Beziehungen zwischen ihnen ab. Üblicherweise lassen sich diese Kontextgrenzen sehr einfach auf Microservices abbilden wohingegen sie bei Komponenten von Monolithen sehr leicht verwischt werden können.

Neben der Teamzuordnung trennen die unterschiedlichen Kontexte auch das jeweils dahinterliegende Datenbankschemata. Microservices tendieren daher auch dazu, ihre eigenen Datenbanken zu verwalten.

Dezentralisierte Datenbanken

Die dezentrale Organisation der Teams rund um ihren Microservice führt auch zu einer verteilten Verantwortung für die Daten z.B. bei Updates. Während bei monolithischen Anwendungen meist auf Transaktionssicherheit geachtet wird, um die Konsistenz der Daten zu erhalten, so erfordert dies jedoch auch eine zeitliche Kopplung, die kaum über mehrere Services hinweg aufrechterhalten werden kann. Daher setzen die meisten Microservice-Architekturen auf eine transaktionslose Koordination zwischen den Diensten und auf eventual consistency, d.h. ein Datensatz wird irgendwann konsistent sein, sofern nur eine hinreichend lange Zeit ohne Schreibvorgänge und Fehler vorausgegangen ist.

Evolutionäres Design

Eine wesentliche Frustration bei Monolithen ist, dass sie mit der Zeit immer schwerer weiterzuentwickeln sind da eine modulare Struktur nur mühsam aufrechtzuerhalten ist und dadurch Änderungen aufwändiger und langwieriger sind. Daher erschien uns die Zerlegung in einzelne Services eine angenehme Möglichkeit zu bieten um eine Anwendung leichtgewichtig weiterentwickeln zu können.

Wir haben viele Anwendungen übernommen, die monolithisch entworfen und gebaut wurden. Meist dauert es mehrere Jahre bis wir einen solchen Monolithen vollständig ablösen können. Aber neue Features fügen wir meist als Microservices ein, die die API des Monolithen verwenden. Dieses Vorgehen ist nicht nur praktisch für nur vorübergehende Änderungen wie Kampagnen etc., sondern auch in anderen Bereichen, die sich häufig ändern. So wird die Funktionalität des ursprünglichen Monolithen immer geringer bis er dann schließlich ganz abgelöst werden kann.

Evolutionäres Design

Microservices – Nutzen und Kosten

Nutzen Kosten
Modularität
Microservices fördern die Modularität, was vor allem für große Teams hilfreich ist.
Verteilte Systeme
Verteilte Systeme sind schwieriger zu administrieren, da sie deutlich komplexer sind.
Unabhängiges Deployment
Einfache Services sind einfacher und mit geringerem Risiko bereitzustellen.
Eventual consistency
Die Aufrechterhaltung starker Konsistenzu ist in verteilten Systemen nur sehr schwierig aufrechtzuerhalten. Dies bedeutet, dass jeder Service eventuell consistency selbst managen muss.
Technologische Vielfalt
Ihr könnt die zu Eurem Service passenden Sprachen, Frameworks und Datenspeicher frei wählen.
Operationale Komplexität
Ihr benötigt qualifizierte System-Ingenieure, um die verschiedenen Dienste managen zu können.
Einfachere Skalierbarkeit
Ihr müsst nicht die gesamte Anwendung skalieren sondern nur den Teil, der zuviel Last erhält.
 
Bessere Trennungskontrolle
Mit Microservices können vertrauliche Daten getrennt werden und damit eine höhere Sicherheit erlangt werden.
 

Modularität

Microservices fördern üblicherweise die Modularität von Anwendungen, da ungenügende Modularität schnell zu sehr viel höheren Aufwänden und Risiken führt. Kleine, überschaubare Moduleinheiten lassen sich viel einfacher ändern da die Konsequenzen überschaubarer bleiben.

Ein weiterer Vorteil von Microservices sind das dezentrale Datenmanagement, bei dem jeder Service seine eigene Datenbank verwaltet und ggf. die API anderer Services durchläuft.

Verteilte Systeme

Microservices sind verteilte Systeme, wodurch die Komplexität deutlich erhöht wird.

Zunächst wirkt sich dies auf die Performance aus, da Remote-Calls deutlich langsamer sind. Wenn jeder Service jedoch viele andere Services befragen muss wird die Latenz schnell unerträglich. Dem kann zwar dadurch begegnet werden, dass die Anfragen asynchron und feingranularer gestellt werden sowie die Antworten ggf. zwischengespeichert werden.Dies verkompliziert jedoch den Programmcode erheblich.

Fehlertoleranz

Die Komplexität wird noch weiter erhöht, da Ihr Euch nicht auf eine gültige Antwort in einer bestimmten Zeit verlassen könnt. So solltet Ihr schon beim Design Eures Services darauf achten, dass dieser fehlertolerant ist. Wie das geschehen kann, ist z.B. in Principles of chaos engineering oder in Fault Tolerance in a High Volume, Distributed System. So entwickelte z.B. Netflix Chaos Monkey, der zufällig Prozesse von Instanzen und Containern beendet, um sowohl die Ausfallsicherheit als auch die Zuverlässigkeit der Gesamtanwendung zu testen. Wenn Services aber jederzeit ausfallen können, wird es umso wichtiger, den Fehler schnell zu erkennen und den Service möglichst automatisiert wieder bereitstellen zu können. Daher wird die Echtzeitüberwachung der betriebs- und geschäftsrelevanten Metriken immer wichtiger.

Dies sind nur einige der Probleme von verteilten Systemen; weitere findet Ihr in Fallacies of Distributed Computing Explained).

Unabhängiges Deployment

Ein Schlüsselprinzip von Microservices ist, dass Services Komponenten sind und daher unabhängig voneinander bereitgestellt werden können. Dies hat den Vorteil, dass Ihr bei Änderungen an einem Service nur diesen Testen und neu bereitstellen müsst. Zudem sollte selbst ein vollständiger Ausfall dieser einen Komponente nicht zum Ausfall anderer Teile des Systems führen sondern nur zu einem geringeren Funktionsumfang führen. Dieser Vorteil kommt jedoch erst richtig mit Continuous Delivery zum Tragen.

Eventual consistency

Ihr kennt sicher alle das Problem, dass Ihr ein Update durchgeführt habt und dennoch könnt Ihr die Änderungen nicht sofort sehen. Dies kann einfach damit zusammenhängen, dass gerade der eine Knoten aktualisiert wird während Eure Anfrage von einen noch nicht aktualiserten Knoten beantwortet wird. Solche Inkonsistenzen können auch zu schwerwiegenderen Problemen führen. Und auch wenn bei Monolithen leichter Transaktionssicherheit hergestellt werden kann, so sind sie keineswegs frei davon, z.B. wenn die Cache-Invalidation nicht zuverlässig ist.

Technologische Vielfalt

Da jeder Microservice eine unabhängige Einheit ist, habt Ihr auch erhebliche Freiheit bei der Auswahl Eurer Technologie. Microservices können in verschiedenen Sprachen geschrieben werden, verschiedene Bibliotheken und Datenspeicher verwenden. Auf diese Weise können Teams ein geeignetes Tool für den Job auswählen. Ihr könnt also profitieren davon, dass sich manche Sprachen und Bibliotheken besser für bestimmte Arten von Problemen eignen.

Dies ist jedoch nicht der einzige Vorteil der technischen Vielfalt von Microservices. Auch die Verwendung unterschiedlicher Versionen einer Bibliothek kann Upgrades deutlich vereinfachen. Bei einem Monolithen könnte ein Teil des Systems eine neue Funktion einer Sprache oder Bibliothek nutzen wollen, das Upgrade kann jedohch nicht verwendet werden, wenn dadurch ein anderer Teil des Monolithen kaputt geht.

Umgekehrt besteht jedoch die Gefahr, dass die technologische Vielfalt zu viel wird, sodass das Team überfordert werden kann. Die meisten mir bekannten Organisationen lassen nur eine begrenzte Anzahl von Technologien zu. Dies erleichtert dann z.B. auch die Überwachung der vielfältigen Tools da sich die Anzahl der Environments reduziert.

Operationale Komplexität

Die Möglichkeit, kleine unabhängige Module schnell bereitzustellen, ist ein großer Vortiel für die Entwicklung, stellt jedoch gleichzeitig eine zusätzliche Belastung für den Betrieb dar, da aus einem halben Dutzend Anwendungen jetzt Hunderte kleiner Mikrodienste werden können. Viele Organisationen werden die Schwierigkeit, mit einem solchen Schwarm sich schnell ändernder Tools umzugehen, als unmöglich empfinden. Tatsächlich wird dies auch nur mit Continuous Delivery möglich sein. Die Komplexität verlagert sich also von den einfacher werdenden Microservices zum gemeinsamen Betrieb dieser zunehmenden Anzahl dieser Services.

Einfachere Skalierbarkeit

Es liegt auf der Hand, dass Microservices besser den Service skalieren können, der unter erhöhter Last steht. Dies ist jedoch noch nicht alles: bei Microservices könnt Ihr auch schneller und präziser erkennen, welcher Teil unter Last steht.

Bessere Trennungskontrolle

Mit Microservices können Sie vertrauliche Daten trennen und diesen Daten mehr Sicherheit verleihen. Durch die kontrolliertere Steuerung des gesamten Datenverkehrs zwischen Microservices dürfte dies das Risiko, bei einem Einbruch umfassend Zugriff auf alle Daten zu erhalten, deutlich erschweren. Mit der zunehmenden Bedeutung von Sicherheitsproblemen ist dies eine wichtige Überlegung bei der Verwendung von Microservices.

Resümee

In diesem Artikel werden nur allgemein die Kosten und Nutzen von Microservices dargelegt. Er kann nicht die Entscheidung für ein konkretes Projekt vorwegnehmen, sondern nur dazu beitragen, dass Ihr die verschiedenen Faktoren berücksichtigt. Jeder Kosten- und Nutzenfaktor hat für verschiedene Systeme ein unterschiedliches Gewicht. Beurteilt, welche Faktoren für Euer System am wichtigsten sind und wie sie sich auf Euren speziellen Kontext auswirken. Erschwerend kommt hinzu, dass Architekturentscheidungen normalerweise erst sinnvoll beurteilt werden können, nachdem ein System ausgereift ist.

Microservices – Hype oder Zukunft?

Auch wenn wir bei vielen Anwendungen auf einer Microservices-Architektur aufgebaut haben, so sind wir doch nicht überzeugt, dass Microservices eine universelle Lösung sind.

So haben wir zwar durchaus schon Erfahrungen gemacht mit evolutionärem Design, bei dem eine einzelne Komponente ausgetauscht wurde, uns fehlt jedoch noch die Erfahrung beim Refactoring über Services hinweg: hier wird nicht nur das Verschieben von Code deutlich schwieriger als bei monolithischen Anwendungen. Auch die Koordinierung der Schnittstellenänderungen mit allen Teilnehmern, zusätzliche Schichten von Rückwärtskompatibilität und Testen verkomplizieren den Umbau.

Um die Servicegrenzen besser erkennen zu können scheint es zunächst eine gute Idee zu sein, nicht mit einer Microservices-Architektur zu beginnen sondern mit einer monolithischen Architektur, die modular aufgebaut ist (s.a. Martin Fowler: Monolith First). Wenn sich die passenden Komponenten im Lauf der Zeit bewährt haben, sollen sie dann in Microservices zerlegt haben. Diese Idee scheint uns jedoch problematisch da In-Process-Interfaces selten gut auf Service-Interfaces abbilden lassen.

Dennoch bleiben wir optimistisch, dass Microservices mit ihren Eigenschaften zu deutlich besserer Software führen, vor allem wenn es sich um komplexe Anwendungen handelt.

Produktivität und Komplexität

aus Martin Fowler: Microservice Premium

Technische Schulden

Wir entwickeln meist in kurzen Zyklen die von unseren Kunden angefragte Funktionalität. Meistens räumen wir unseren Code auch nach mehreren Zyklen auf wenn sich die Anforderungen kaum noch ändern. Manchmal jedoch muss auch der schnell entwickelte Code in die Produktion übernommen werden. Technische Schulden ist diesbezüglich eine wunderbare Metapher, die von Ward Cunningham eingeführt wurde um über solche Probleme nachzudenken. Ähnlich wie finanzielle Schulden können technische Schulden zur Überbrückung von Schwierigkeiten verwendet werden. Und ähnlich wie bei finanziellen Schulden sind bei technischen Schulden Zinsen zu bezahlen, nämlich in Form von zusätzlichen Anstrengungen um die Software weiterzuentwickeln.

Im Gegensatz zu finanziellen Schulden lassen sich technische Schulden jedoch sehr schwer beziffern. Wir wissen zwar, dass sie die Produktivität eines Teams bei der Weiterentwicklung der Software behindern, aber wir uns fehlen die Berechnungsgrundlagen, auf denen diese Schuld beziffert werden könnte.

Um technische Schulden zu beschreiben, wird meist unterschieden zwischen bewussten und versehentlich eingegangenen technischen Schulden sowie zwischen umsichtigen oder waghalsigen Schulden. Daraus ergibt sich der folgende Quadrant:

  versehentlich überlegt
umsichtig »Nun wissen wir, wie wir es machen sollten!« »Wir müssen jetzt liefern und mit den Konsequenzen umgehen.«
waghalsig »Was ist Software-Design?« »Wir haben keine Zeit für Software-Design!«

Zum Weiterlesen

Cheat Sheets für unsere Python-Seminare

Für unsere Python-Schulungen für Daten-Analyst*innen, Wissenschaftler*innen und Forschungssoftware-Ingenieur*innen haben wir Cheat Sheets erstellt, die es unseren SchulungsteilnehmerInnen erlaubt, schnell das Gelernte wiederverwenden zu können:

Python Cheat Sheet

Python Cheat Sheet Python Cheat Sheet 2

python-for-beginners-cheat-sheet.pdf, PDF, 70.4 KB

Pandas Cheat Sheet

Pandas Cheat Sheet Pandas Cheat Sheet 2

pandas-cheat-sheet.pdf, PDF, 52 KB

Git Cheat Sheet

Git Cheat Sheet Git Cheat Sheet 2

git-cheatsheet-web.pdf, PDF, 437 KB

Und falls ihr weitere Fragen zu unserem Schulungsangebot habt, ruft uns gerne an unter der Telefonnummer +49 30 22430082 oder schreibt eine Mail an training@cusy.io.

2016 – das Jahr, in dem HTTPS die 50-Prozent-Hürde nahm

Unzählige Organisationen haben im vergangenen Jahr ihre Websites auf das sichere Transportprotokoll umgestellt: Heise, The Guardian, Wired, SourceForge, und viele mehr. Laut Mozillas Telemetrie-Daten übertraf der TLS-verschlüsselte Traffic im Oktober erstmals die 50-Prozent-Marke. Vermutlich wird es jedoch wohl noch viele Jahre dauern bis alle Sites verschlüsselt ausgeliefert werden und HTTP deaktiviert werden kann.

Es gab jedoch auch einige neue Angriffe: SLOTH (Security Losses from Obsolete and Truncated Transcript Hashes), Sweet32 und DROWN ließen uns nicht vergessen, dass alte, unsichere Algorithmen weiterhin eine Bedrohung darstellen.

Zertifizierungsstellen sind nach wie vor bedeutend, wenn es um die Sicherheit von TLS geht. Der Rauswurf von WoSign und StartCom erinnerte daran. Erfreulicherweise gibt es mit Let's Encrypt nun auch freie zertifikate die erheblich zur Verbreitung von HTTPS beigetragen haben. Und dank Zertifikatstransparenz, die für alle neuen Zertifikate ab Oktober 2017 erforderlich ist, kann der Missbrauch in diesem Bereich heute viel besser erkannt werden.

Auch TLS 1.3 wird ab Anfang 2017 die Sicherheit und Leistung für verschlüsselte Verbindungen deutlich verbessern.

Und wer sich weiter über diese Themen informieren möchte, kann sich die Videos einiger Vorträge beim 33ten Chaos Communication Congress (33C3) anschauen:

Cusy 2016 Jahresrückblick

DevOps als API

Anfang des Jahres sind wir unserer Vision ein gutes Stück näher gekommen. Wir nutzen eine API, mit der automatisiert VMs erstellt, konfiguriert und gelöscht werden können. Damit erhält unsere Kundschaft die Möglichkeit, ihre Infrastruktur zu programmieren. Einzelne Systeme oder ganze Cluster können mit der API auf programmatischem Wege und jederzeit reproduzierbar bereitgestellt werden. Mehr über unsere Devops-Vision erfahren Sie in Die Vision von Cusy – DevOps als API.

Neue Verteilung der Verantwortung in DevOps

IT-Compliance

Da vermutlich auch Privacy Shield kein sicherer Hafen werden wird, gehen wir davon aus, dass immer mehr Unternehmen sich nach einem verlässlichen IT-Partner in Deutschland umsehen werden. Unsere Kunden sind auf zukünftige Herausforderungen, die vor allem aus der neuen Datenschutzgrundverordnung erwachsen, gut vorbereitet. Wir können Unternehmen, die ihre IT-Compliance verbessern wollen, tatkräftig unterstützen.

Fördermitgliedschaften

Digitale Gesellschaft

Mitte des Jahres sind wir Fördermitglied der Digitalen Gesellschaft geworden.

Die Digitale Gesellschaft ist ein gemeinnütziger Verein, der sich für Grundrechte und Verbraucherschutz im digitalen Raum einsetzt. Der Verein möchte die offene digitale Gesellschaft erhalten und fördern. Er kämpft gegen den Rückbau von Freiheitsrechten im Netz und engagiert sich für einen freien Wissenszugang, für mehr Transparenz und Partizipation sowie für eine kreative Entfaltung digitaler Potenziale.

Bessere Datenschutzmaßnahmen

Härtung

Nachdem Cusy von Anfang an sehr viel Wert auf technische und organisatorische Datenschutzmaßnahmen für den Betrieb im Rechenzentrum legt, haben wir Mitte des Jahres nun auch mit unseren Maßnahmen für die Absicherung der Admin-Workstations die Sicherheit deutlich erhöht. Unsere Richtlinien und Checklisten hierfür veröffentlichten wir auf unserer Website.

Transparenzbericht

Kurz vor dem erstem Geburtstag der Cusy GmbH am 29. September, veröffentlichten wir unseren ersten Transparenzbericht.

Continuous Everything

Auf der Cusy-Plattform können unsere Kunden nun auch mit Jenkins ihre Anwendung automatisiert installieren und aktualisieren. Damit sind wir einer Continuous Everything-Plattform sehr viel näher gekommen. Selbstverständlich beraten wir unsere Kunden gerne, wie sie dies technisch auf der Cusy-Plattform realisieren können.

Alternative zur Google Search Appliance

Da die Google Search Appliance ihr End of Life erreicht hat, haben wir uns nach Alternativen umgeschaut. Momentan testen wir einen Software-Stack u.a. mit Elasticsearch, Security für Authentifizierung, Autorisierung und Verschlüsselung sowie Watcher für Benachrichtigungen.

Im ersten Quartal 2017 werden wir unseren Kunden eine zuverlässige und leistungsstarke Alternative nach dem deutschen Datenschutz bereitstellen können.

Cusy Transparenzbericht 2016

Letztes Jahr veröffentlichten wir unseren ersten Transparenzbericht für die 2015 gegründeten Cusy GmbH. Auch 2016 erreichten uns keine Auskunfts- oder Herausgabeverlangen von Strafverfolgungs- oder Sicherheitsbehörden.

Unser Engagement für unsere Nutzer

Die meisten Online-Dienste erhalten gelegentlich rechtliche Anfragen Dritter in Bezug zu Benutzerdaten. Wir legen hohen Wert auf Transparenz und das Vertrauen unserer Nutzer in die Sicherheit ihrer Daten. Im Folgenden informieren wir Sie deshalb in aggregierter, statistischer Form, wie oft wir im Jahr 2016 derartige Rechtsanfragen Dritter erhalten und wie wir auf sie reagiert haben. Näheres finden Sie in unseren Informationen über den Umgang mit Rechtsanfragen zu Benutzerdaten.

Art der Anfragen

Rechtsanfragen Dritter mit Bezug zu Benutzerdaten kommen vor allem unter zwei Aspekten in Betracht:

  • Anfragen von Strafverfolgungs- und Sicherheitsbehörden, z.B. der Staatsanwaltschaft. In Betracht kommt beispielsweise die Beschlagnahme von Daten oder Postfächern oder eine Telekommunikationsüberwachung nach §§ 94, 99, 100a StPO. Anfragen der Staatsanwaltschaft setzen in der Regel voraus, dass die jeweiligen Informationen oder Daten in einem strafrechtlichen Ermittlungsverfahren als Beweismittel von Bedeutung sein können.
  • Privatrechtliche Auskunfts- und Unterlassungsansprüche Dritter, z.B. bei Urheber- oder Wettbewerbsrechtsverletzungen nach § 101 UrhG oder §§ 823, 1004 BGB. Dies kann z.B. in Betracht kommen, wenn Benutzer über Cusy Daten oder Informationen öffentlich zugänglich machen und damit Urheberrechte oder sonstige Rechte Dritter verletzen. Ziel ist es dann meistens, die rechtsverletzenden Inhalte zu sperren oder zu entfernen (Unterlassungsansprüche) oder nähere Informationen über den Verletzer und die Verbreitung der rechtswidrigen Inhalte zu erhalten (Auskunftsansprüche).

Anzahl der Anfragen in 2016

Auskunfts- oder Herausgabeverlangen von Strafverfolgungs- oder Sicherheitsbehörden
Von deutschen Behörden 0
Von ausländischen Behörden 0
Davon formal und inhaltlich korrekt / nicht korrekt - / -
Zivilrechtliche Unterlassungsansprüche
Aufgrund von Urheberrechtsverletzungen 0
Aufgrund sonstiger Rechtsverletzungen 0
Davon formal und inhaltlich korrekt / nicht korrekt - / -
Zivilrechtliche Auskunftsansprüche
Aufgrund von Urheberrechtsverletzungen 0
Aufgrund sonstiger Rechtsverletzungen 0
Davon formal und inhaltlich korrekt / nicht korrekt - / -

Resümee

Wir wollen so offen wie möglich sein, damit Sie rechtliche Risiken und die damit verbundenen Auswirkungen auf Ihre Projekte besser beurteilen können. Deshalb beabsichtigen wir, ähnliche Transparenzberichte auch in den nächsten Jahren zu veröffentlichen.

Wenn Sie Fragen, Anregungen oder anderes Feedback haben, nehmen Sie bitte gerne Kontakt mit uns auf.

Cusy Transparenzbericht 2015

Dies ist der erste Transparenzbericht der 2015 gegründeten Cusy GmbH.

Unser Engagement für unsere Nutzer

Die meisten Online-Dienste erhalten gelegentlich rechtliche Anfragen Dritter in Bezug zu Benutzerdaten. Wir legen hohen Wert auf Transparenz und das Vertrauen unserer Nutzer in die Sicherheit ihrer Daten. Im Folgenden wollen wir euch deshalb in aggregierter, statistischer Form darüber informieren, wie oft wir im Jahr 2015 derartige Rechtsanfragen Dritter erhalten haben und wie wir auf sie reagiert haben. Näheres findet ihr in unseren Informationen über den Umgang mit Rechtsanfragen zu Benutzerdaten.

Art der Anfragen

Rechtsanfragen Dritter mit Bezug zu Benutzerdaten kommen vor allem unter zwei Aspekten in Betracht:

  • Anfragen von Strafverfolgungs- und Sicherheitsbehörden, z.B. der Staatsanwaltschaft. In Betracht kommt beispielsweise die Beschlagnahme von Daten oder Postfächern oder eine Telekommunikationsüberwachung nach §§ 94, 99, 100a StPO. Anfragen der Staatsanwaltschaft setzen in der Regel voraus, dass die jeweiligen Informationen oder Daten in einem strafrechtlichen Ermittlungsverfahren als Beweismittel von Bedeutung sein können.
  • Privatrechtliche Auskunfts- und Unterlassungsansprüche Dritter, z.B. bei Urheber- oder Wettbewerbsrechtsverletzungen nach § 101 UrhG oder §§ 823, 1004 BGB. Dies kann z.B. in Betracht kommen, wenn Benutzer über Cusy Daten oder Informationen öffentlich zugänglich machen und damit Urheberrechte oder sonstige Rechte Dritter verletzen. Ziel ist es dann meistens, die rechtsverletzenden Inhalte zu sperren oder zu entfernen (Unterlassungsansprüche) oder nähere Informationen über den Verletzer und die Verbreitung der rechtswidrigen Inhalte zu erhalten (Auskunftsansprüche).

Anzahl der Anfragen in 2015

Auskunfts- oder Herausgabeverlangen von Strafverfolgungs- oder Sicherheitsbehörden
Von deutschen Behörden 0
Von ausländischen Behörden 0
Davon formal und inhaltlich korrekt / nicht korrekt - / -
Zivilrechtliche Unterlassungsansprüche
Aufgrund von Urheberrechtsverletzungen 0
Aufgrund sonstiger Rechtsverletzungen 0
Davon formal und inhaltlich korrekt / nicht korrekt - / -
Zivilrechtliche Auskunftsansprüche
Aufgrund von Urheberrechtsverletzungen 0
Aufgrund sonstiger Rechtsverletzungen 0
Davon formal und inhaltlich korrekt / nicht korrekt - / -

Resümee

Wir wollen so offen wie möglich sein, damit Sie rechtliche Risiken und die damit verbundenen Auswirkungen auf eure Projekte besser beurteilen könnt. Deshalb beabsichtigen wir, ähnliche Transparenzberichte auch in den nächsten Jahren zu veröffentlichen.

Wenn ihr Fragen, Anregungen oder anderes Feedback habt, nehmt bitte gerne Kontakt mit uns auf.



Bei diesem Transparenzbericht sind wir beraten worden von Rechts­an­walt Carsten Gerlach.

Safe-Harbor Abkommen endgültig ausgelaufen

Der auf IT-Recht spezialisierte Anwalt Dr. jur. Hajo Rauschhofer hat auf seiner Anwalts-Website darauf hingewiesen, dass Unternehmen, die Kundendaten in den USA verarbeiten, unverzüglich Verhandlungen mit einem datenschutzkonformen Leistungsanbieter aufnehmen sollten, um Bußgelder in Höhe von bis zu 300.000 EUR zu vermeiden.

Im Oktober kippte der Europäische Gerichtshof das so genannte Safe-Harbor-Abkommen zwischen der EU und den USA. Seit dem 1.2.2016 ist auch die Übergangsfrist abgelaufen und alle Unternehmen, die Daten mit den USA austauschen, agieren in einer rechtlichen Grauzone. Datenschutzbehörden können Unternehmen, die personenbezogene Daten nicht datenschutzkonform in die USA transferieren, mit einem Bußgeld in Höhe von bis zu 300.000 EUR belegen. Ein neues Abkommen, das Rechtssicherheit gewähren würde, ist nicht in Sicht.

Oft wird Unternehmen die Nutzung der EU-Standardvertragsklausel als Interimslösung empfohlen. Doch laut Dr. Rauschhofer ist auch diese Lösung nicht wirklich tragbar.

»Betrachtet man (…) die Komplexität und Kompliziertheit der Themen (…) müsste fast ein Wunder geschehen, wenn Anfang Februar ein Konsens über die Zulässigkeit des Datentransfers in die USA erzielt wird. Realistisch betrachtet bedeutet dies für die Verantwortlichen eines Unternehmens, die datenschutzrechtliche Zulässigkeit von Datenübermittlungen sicherzustellen. Soweit diese bislang noch in die USA erfolgen, dürfte zu erwarten sein, dass selbst auf Basis der EU-Standard-Vertragsklauseln diese als unzulässig angesehen werden.«

Die Datenschutzbehörden haben bereits im Oktober 2015 darauf hingewiesen, dass im Lichte des EuGH-Urteils die Standard-Vertragsklausel in Frage gestellt sei.

Da auch die sogenannte Einwilligungs-Lösung im Einzelfall problematisch sei, sieht Dr. Rauschhofer für Unternehmen nur eine sichere Lösung: ernsthaft über einen Exit nachzudenken und sofort Verhandlungen mit datenschutzkonformen IT-Dienstleistern innerhalb der EU aufzunehmen, denn es sei »davon auszugehen, dass eine prüfende Datenschutzbehörde kein Bußgeld verhängen wird, wenn das Unternehmen hier unverzüglich nach dem Scheitern einer Lösung eine rechtskonforme Umsetzung begonnen hat.

Abschließend rät Dr. Rauschhofer den Unternehmen:

»Als sorgfältiger Unternehmer sollte man daher nach unserer Auffassung bereits jetzt vorsorglich Verhandlungen mit datenschutzkonformen Anbietern aufnehmen.«

Als ein IT-Anbieter, der von Anfang an auf Datensicherheit und Datenschutz größten Wert gelegt hat, sieht sich Cusy einmal mehr bestätigt. Die Entwicklungs- und Betriebsplattform von Cusy ist so aufgebaut, dass sie die strengen Richtlinien des deutschen Datenschutzes erfüllt. Das entlastet Entwickler und Betreiber und gibt ihren mehr Sicherheit. Firmen, die zu einem datenschutzkonformen Anbieter wechseln möchten, bietet Cusy eine umfassende technische Beratung für mehr Datenschutz und Datensicherheit sowie eine tatkräftige Unterstützung bei der Migration ihrer Anwendungen.

Update 6.6.2016: Erste Bußgelder verhängt

Die Hamburger Datenschutzbehörde hat erste Bußgelder gegen Unternehmen verhängt. Nachdem der EuGH das Safe-Harbour-Abkommen im Oktober 2015 für ungültig erklärt hat, prüfte die Hamburger Datenschutzbehörde 35 international agierende Unternehmen in Hamburg. Drei Bußgeldbescheide sind mittlerweile rechtskräftig geworden. Die drei Unternehmen hatten auch sechs Monate nach dem Wegfall von Safe-Harbour noch keine datenschutzrechtlich akzeptable Alternative für den Transfer von persönlichen Daten in die USA geschaffen. Die Bußgelder fielen niedrig aus, da die Unternehmen ihr Verfahren inzwischen auf Standardvertragsklauseln umgestellt haben.

In seiner Presseerklärung weist die Hamburger Behörde aber daraufhin, dass im Rahmen der Privacy-Shield-Verhandlungen auch »über die Zulässigkeit der derzeit nicht beanstandeten alternativen Übermittlungsinstrumente, insbesondere sogenannter Standardvertragsklauseln, zu entscheiden sein« wird. Dies ist ein deutlicher Hinweis darauf, dass auch die Standardvertragsklauseln rechtlich umstritten sind und damit keine dauerhaft sichere Lösung darstellen. (Näheres dazu in diesem Artikel auf Heise Online.)

Die Empfehlungen von Dr. Rauschhofer, sich einen datenschutzkonformen IT-Dienstleister innerhalb der EU zu suchen, erhalten durch diese Entwicklung neue Aktualität.

Erste Bußgelder wegen Datentransfer in die USA verhängt

Die Hamburger Datenschutzbehörde hat erste Bußgelder gegen Unternehmen verhängt, die nach dem Auslaufen von Safe-Harbor Daten ohne Rechtsgrundlage in die USA übertragen haben.

Im Oktober kippte der Europäische Gerichtshof das so genannte Safe-Harbor-Abkommen zwischen der EU und den USA. Seit dem 1.2.2016 ist auch die Übergangsfrist abgelaufen und alle Unternehmen, die Daten mit den USA austauschen, agieren in einer rechtlichen Grauzone. Datenschutzbehörden können Unternehmen, die personenbezogene Daten nicht datenschutzkonform in die USA transferieren, mit einem Bußgeld in Höhe von bis zu 300.000 EUR belegen.

Die Hamburger Datenschutzbehörde hat nun erstmals ein solches Bußgeld verhängt. Die Behörde hat seit Oktober 2015 35 international agierende Unternehmen in Hamburg geprüft. Drei Bußgeldbescheide sind mittlerweile rechtskräftig geworden. Die drei Unternehmen hatten auch sechs Monate nach dem Wegfall von Safe-Harbor noch keine datenschutzrechtlich akzeptable Alternative für den Transfer von persönlichen Daten in die USA geschaffen.

Die Bußgelder fielen jedoch vergleichsweise niedrig aus, da die Unternehmen ihr Verfahren inzwischen auf Standardvertragsklauseln umgestellt haben.In seiner Presseerklärung weist die Hamburger Behörde aber darauf hin, dass im Rahmen der Privacy-Shield-Verhandlungen auch »über die Zulässigkeit der derzeit nicht beanstandeten alternativen Übermittlungsinstrumente, insbesondere sogenannter Standardvertragsklauseln, zu entscheiden sein« wird. Dies ist ein deutlicher Hinweis darauf, dass auch die Standardvertragsklauseln rechtlich umstritten sind und damit keine dauerhaft sichere Lösung darstellen. (Näheres dazu in diesem Artikel auf Heise Online.)

Die Datenschutzbehörden haben bereits im Oktober 2015 darauf hingewiesen, dass im Lichte des EuGH-Urteils die Standard-Vertragsklausel in Frage gestellt sei. Da auch Privacy Shield, das Nachfolgeabkommen von Safe Harbour umstritten ist, sollten Unternehmen, die auf der sicheren Seite sein wollen, jetzt Verhandlungen mit datenschutzkonformen IT-Dienstleistern innerhalb der EU aufzunehmen.

Was bringt die neue Datenschutzgrundverordnung (DSGVO)?

Im April 2016 hat das EU-Parlament die neue Datenschutzgrundverordnung (DSGVO) beschlossen. Sie tritt spätestens im Sommer 2018 in Kraft und ist dann in allen EU-Ländern unmittelbar gültiges Recht. Eine Verordnung muss nicht wie eine Richtlinie in nationales Recht gegossen werden. Auf Unternehmen, Behörden und Selbstständige, die sich auch zukünftig gesetzeskonform verhalten wollen, kommt jetzt eine Menge Arbeit zu.

Deutsches Datenschutzrecht als Vorbild Infografik DSGVO

Die DSGVO übernimmt in weiten Teilen Regelungen und Grundsätze aus dem deutschen Datenschutzrecht. So ist zum Beispiel auch in Zukunft jede Nutzung von persönlichen Daten erst einmal grundsätzlich verboten, wenn sie nicht explizit erlaubt ist oder wenn der Betroffene der Nutzung seiner Daten ausdrücklich zugestimmt hat. Ferner bleiben die Grundsätze der Datensparsamkeit, der Transparenz und der Zweckbindung gültig.

Die neuen und verschärften Regelungen

Umfangreiche Informationspflichten

Die Informationspflicht von Unternehmen wurde verschärft. Sie sind zukünftig verpflichtet, den Nutzern ihrer Dienste Auskunft zu erteilen über die Rechtsgrundlage zur Datenverarbeitung, die Dauer der Speicherung, die Art und Weise der Weitergabe von Daten an Auftragsdatenverarbeiter und vieles mehr.

Recht auf Datenportabilität

Nutzer*innen haben in Zukunft ein Recht auf Datenportabilität. Sie können in Zukunft zum Beispiel darauf bestehen, dass ihre Daten in einem strukturierten, gängigen und maschinenlesbaren Format an einen anderen Anbieter weitergegeben werden. Diese Regelung soll die Entwicklung interoperabler Formate fördern und wird vermutlich Auswirkungen auf die Entwicklung neuer Softwaresysteme haben.

Rechenschaftspflicht und Beweisumkehr im Streitfall

Ein großer Aufwand erwächst Unternehmen, Behörden und Selbstständigen aus der Rechenschaftspflicht. Sie müssen geeignete technische und organisatorische Maßnahmen ergreifen, um lückenlos nachweisen zu können, dass sie datenschutzkonform handeln. In einem Artikel der ct wird darauf hingewiesen, dass sich hieraus haftungsrechtliche Konsequenzen ergeben und vor Gericht die Beweislast umgekehrt wird. Bisher mussten Betroffene vor Gericht nachweisen, dass das Unternehmen oder die Behörde für eine Verletzung des Datenschutzes die Verantwortung trägt. In Zukunft muss der Datenverarbeiter nachweisen, dass er datenschutzkonform gehandelt hat.

Datensicherheit nach ISO/IEC 27001

Strengere Regeln gelten zukünftig bei der Datensicherheit. Der Anbieter muss nach der neuen DSGVO die Vertraulichkeit, Integrität, Verfügbarkeit und Belastbarkeit der Systeme und Dienste gewährleisten, auf denen personenbezogene Daten verarbeitet werden. Eine Zertifizierung nach ISO/IEC 27001 kann dies sicherstellen.

Datenschutz-Folgenabschätzung

Auswirkungen auf die Entwicklung von Software dürfte eine weitere neue Regelung der DSGVO haben. Unternehmen müssen bei einer risikobehafteten Datenverarbeitung zukünftig eine Datenschutz-Folgenabschätzung durchführen. Falls sich aus dieser Abschätzung ein mögliches Risiko für die Betroffenen abzeichnet, müssen sie die zuständige Datenschutzbehörde darüber informieren. Diese soll dann innerhalb von acht Wochen dem Unternehmen schriftlich Empfehlungen zur Risikominimierung machen. Ob sich diese bürokratische Regelung in der Praxis bewährt, muss abgewartet werden. Softwareentwickler tun aber gut daran, Datenschutzüberlegungen in ihren Test-Szenarien abzudecken.

Hohe Strafen

Die DSGVO verpflichtet Unternehmen, Behörden und Selbstständige dazu, ein aufwändiges Datenschutzmanagement aufzubauen. Dass die EU es mit dem Datenschutz ernst meint, zeigen die neuen Sanktionen. Verstöße gegen die Verordnung können in Zukunft mit Strafzahlungen von bis zu 20 Millionen Euro oder bis zu 4 Prozent des globalen Umsatzes geahndet werden.

Nutzen Sie die Zeit bis zum Inkrafttreten der DSGVO!

Auch wenn die DSGVO erst in zwei Jahren in Kraft tritt, sollte man sich schon heute Gedanken zu Umsetzung machen. Nutzen Sie die nächsten Monate,

  • um sich einen umfassenden Überblick darüber zu verschaffen, wo und wie in Ihrem Unternehmen personenbezogene Daten verarbeitet werden,

  • um alle relevanten Datenverarbeitungsprozesse zu dokumentieren,

  • um ein Konzept zur Datensicherheit möglichst nach ISO 27001 zu erarbeiten und

  • um die Schritte vorzubereiten, die notwendig sind, um eine Datenschutz-Folgenabschätzung abgegeben zu können.

Die Datenschutz-Experten von Cusy stehen Ihnen bei technischen und organisatorischen Fragen gerne zur Verfügung. Als Kunde von Cusy profitieren Sie von einer technischen Infrastruktur, die bereits heute wichtige Vorgaben der neuen DSGVO erfüllt.

Weitere Informationen rund um die neue DSGVO finden Sie beim Berufsverband der Datenschutzbeauftragten Deutschlands (BvD) e.V.

Die Vision von Cusy: DevOps als API

DevOps: Die Hälfte des Weges ist geschafft

Nach Studien, über die Heise Developer kürzlich berichtete, arbeitet bereits die Hälfte der deutschen Entwickler nach dem DevOps-Prinzip. Als Befürworter von DevOps könnte man sich also zufrieden zurücklehnen und feststellen: die Hälfte des Weges ist bereits geschafft.

Doch dies ist nur die halbe Wahrheit. Wenn man sich anschaut, wie DevOps in vielen Unternehmen umgesetzt wird, so sieht man, dass ein Großteil der Pro-DevOps-Unternehmen bei der Umsetzung erst die Hälfte des Weges zurückgelegt hat. Zwar übernehmen Entwickler in DevOps-Teams mittlerweile Verantwortung für den Code auch im Betrieb, aber umgekehrt übernehmen noch nicht alle Sysadmins Verantwortung für die Infrastruktur auch in der Entwicklung. Häufig betreiben Entwickler-Teams immer noch eine eigene Infrastruktur für die Entwicklung, sodass die positiven Effekte des DevOps-Prinzips teilweise verfliegen.

Dass es sich bei DevOps um eine Veränderung der Kultur handelt und nicht bloß um die Nutzung einiger innovativer Werkzeuge, hat sich immer noch nicht überall herumgesprochen. Selbst viele Studien, in denen lediglich die Nutzung von bestimmten Werkzeugen wie Docker oder Puppet abgefragt wird, zeichnen ein falsches Bild von DevOps.

DevOps ist keine Werkzeugkiste, sondern eine Neuverteilung von Verantwortung im Unternehmen. In klassischen IT-Abteilungen ist die Verantwortung für die Bereiche Entwicklung/Testing und Produktion folgendermaßen verteilt.

Nicht selten befinden sich Development und Operations sogar in unterschiedlichen Abteilungen eines Unternehmens. In der DevOps-Kultur kippt die vertikale Trennung zwischen Entwicklung und Betrieb und es entsteht eine horizontale Schnittstelle.

Die Schnittstelle zwischen Dev und Ops kippt

Die Anwendungsentwickler übernehmen die Verantwortung für ihre Anwendung, unabhängig davon, ob diese sich in der Entwicklung oder in der Produktion befindet. Umgekehrt übernehmen die Systemverwalter aber auch die Verantwortung für die gesamte Infrastruktur von der Entwicklungsumgebung bis hin zur Produktivumgebung.

Der mit DevOps eintretende Paradigmenwechsel ist also im Wesentlichen einer, der die Verteilung von Verantwortung verändert und nicht einer, der nur neue Werkzeuge wie Puppet und Chef bereitstellt.

Cusy ist das Ops in DevOps

DevOps is the philosophy of unifying Development and Operations at the culture, practice, and tool levels, to achieve accelerated and more frequent deployment of changes to Production.

– Rob England www.itskeptic.org

Cusy erleichtert den Wechsel von der klassischen IT-Organisation zu agilen DevOps-Strukturen. Cusy übernimmt als Dienstleister die Verantwortung für die gesamte Infrastruktur: von Entwicklung über die Testumgebung bis hin zum Produktivsystem. Cusy ist das Ops in DevOps und entlastet Unternehmen von der Aufgabe, ihre Infrastruktur selbst zu pflegen. Cusy stellt Unternehmen dabei nicht nur die technische Infrastruktur zur Verfügung, sondern die komplette Entwicklungs- und Betriebsumgebung einschließlich aller benötigten Werkzeuge.

Anwendungsentwickler können sich dank Cusy bereits heute voll und ganz auf ihre Entwicklung konzentrieren. Sie müssen sich nicht um die Wartung und Pflege der notwendigen Entwicklungswerkzeuge wie Projektmanagement, Dokumentenmanagement, Versionsverwaltung kümmern.

Darüberhinaus stellt die Cusy-Plattform auch Werkzeuge für das Testen und die Produktion bereit wie Continuous Integration und eine Log-Management & Analyse bereit.

Und schließlich bietet Cusy auch Werkzeuge für Marketing und Support wie Webanalyse und Helpdesk.

Neben allen erforderlichen Werkzeugen stellt Cusy auch VMs für den Betrieb von Anwendungen bereit, die ein einfaches Continuous Delivery mit GitLab erlauben. Hierfür stellt Cusy eine API zum Erstellen, Ändern und Löschen von VMs bereitstellen. Damit ist die Vision von Cusy Wirklichkeit geworden: DevOps als API.

Datenschutzkonforme Webanalyse mit Matomo, vormals Piwik

Die statistische Auswertung von Seitenaufrufen ist für kommerzielle Website-Betreiber ein unverzichtbares Instrument zur Optimierung des eigenen Webangebots. Da bei der Analyse des Besucherverhaltens personenbezogene Daten gesammelt und verarbeitet werden, müssen datenschutzrechtliche Bestimmungen beachtet werden. Zahlreiche Unternehmen setzten bisher Google Analytics zur Webanalyse ein. Seit dem Auslaufen des Safe-Harbor-Abkommens mit den USA ist aber eine datenschutzkonforme Nutzung von US-Diensten problematisch.

Glücklicherweise gibt es mit der Open-Source-Software Matomo eine datenschutzkonforme Alternative zu Google Analytics. Matomo kann als reine Inhouse-Lösung betrieben werden, sodass keine datenschutzrechtlich sensiblen, personenbezogenen Daten in die USA transferiert werden. Sämtliche Daten bleiben auf den Systemen des Website-Betreibers.

Datenschutzkonform konfigurieren

Wie Sie Matomo datenschutzkonform konfigurieren, hat Cusy in einer aktuellen FAQ zusammengestellt. So können Sie beispielsweise IP-Adressen bei der statistischen Verarbeitung automatisch anonymisieren, indem die letzten beiden Oktette der IP auf Null setzen (Beispiel: 198.172.130.12 wird zu 198.172.0.0). Dies stellt sicher, dass sich Nutzeraktivitäten nicht mehr bestimmten Internetanschlüssen zuordnen lassen. Außerdem beschreibt die FAQ, wie Sie die in den Datenschutzrichtlinien geforderte Opt-Out-Möglichkeit implementieren können und die DoNotTrack-Funktion moderner Browser respektieren können.

Großer Funktionsumfang

Der Funktionsumfang von Matomo ist groß und umfasst neben Echtzeitanalyse, Mandantenfähigkeit und Kampagnentracking viele Leistungsmerkmale zur technischen und inhaltlichen Optimierung von Webseiten.

Privacy Shield ist kein sicherer Hafen

Nachdem der Europäische Gerichtshof das Safe-Harbor-Abkommen mit den USA für ungültig erklärt hatte, weil es nicht mit den europäischen Grundsätzen für den Datenschutz vereinbar ist, machte sich in Politik und Wirtschaft allgemeine Ratlosigkeit breit. Wie sollte es weitergehen? Jetzt haben sich EU und USA auf ein neues Abkommen geeinigt, das auf den Namen ›Privacy Shield‹ hört. Doch es scheint nicht geeignet zu sein, die bestehende Rechtsunsicherheit zu beseitigen.

So bezeichnete Jan Philipp Albrecht, der Berichterstatter des Europäischen Parlaments im Verfahren zur Europäischen Datenschutzverordnung, das Abkommen als einen Witz. Die EU-Kommission verkaufe fundamentale Bürgerrechte und riskiere, erneut vom Europäischen Gerichtshof gemaßregelt zu werden. Zentraler Punkt der Kritik ist, dass EU-Bürger*innen ihre Rechte nicht vor US-Gerichten einklagen können. Sie müssen ihre Datenschutzrechte auf dem Verwaltungsweg durchsetzen. Peter Schaar, der ehemalige Bundesbeauftragte für Datenschutz und Informationsfreiheit, hält es deshalb auch für fraglich, ob die neuen Bestimmungen in den USA, auf denen der ›Privacy Shield‹ aufbaut, den Rechtsschutzgarantien der EU-Grundrechte-Charta genügen.

Man kann also davon ausgehen, dass Datenschützer auch gegen ›Privacy Shield‹ vor dem Europäischen Gerichtshof klagen werden. Eine dauerhafte Rechtssicherheit für Unternehmen, die personenbezogene Daten in die USA transferieren, zeichnet sich erst einmal nicht ab. Das unangenehme Szenario, das zum Beispiel der auf IT-Recht spezialisierte Rechtsanwalt Dr. jur. Hajo Rauschhofer entwirft, bleibt damit immer noch bedrohlich aktuell. Das gilt auch für das Fazit des Rechtsanwaltes: Auf der sicheren Seite sind Unternehmen nur dann, wenn sie ihre Daten in Europa bei einem datenschutzkonformen Anbieter speichern und verarbeiten. »Als sorgfältiger Unternehmer«, so Dr. Rauschhofer »sollte man daher nach unserer Auffassung bereits jetzt vorsorglich Verhandlungen mit datenschutzkonformen Anbietern aufnehmen.«

Als ein IT-Anbieter, der von Anfang an auf Datensicherheit und Datenschutz größten Wert gelegt hat, sieht sich Cusy einmal mehr bestätigt. Natürlich kann Cusy nicht alle Datenschutzprobleme deutscher Unternehmen lösen. Aber die Entwicklungs- und Betriebsplattform von Cusy ist so aufgebaut, dass sie die strengen Richtlinien des deutschen Datenschutzes erfüllt. Das entlastet Entwickler und Betreiber und gibt ihnen mehr Sicherheit.

Firmen, die mit ihrer Entwicklungs- und Betriebsplattform zu einem datenschutzkonformen Anbieter wechseln möchten, bietet Cusy eine umfassende technische Beratung für mehr Datenschutz und Datensicherheit sowie eine tatkräftige Unterstützung bei der Migration ihrer Anwendungen.

Update:

Die deutschen Datenschützer lehnten auf der 91. Konferenz der unabhängigen Datenschutzbehörden des Bundes und der Länder das Abkommen in seiner bisherigen Form ab, da der Datenschutz in den USA nicht auf europäischem Niveau sei (Adäquanz). Sie schreiben in einem Beschluss, der kurzzeitig online war und von dem Rechtsanwalt Dr. Carlo Piltz gesichert werden konnte:

Der bislang vorgelegte Entwurf der Adäquanzentscheidung genügt nicht, um von einem angemessenen (essentially equivalent) Datenschutzniveau sprechen zu können. (…) Es besteht daher dringender Nachbesserungsbedarf. (…) Die Art-29-Gruppe kann auf der Basis der vorgelegten Dokumente keine zustimmende Stellungnahme zur Adäquanzentscheidung im Sinne von Erwägungsgrund 128 des Entscheidungsentwurfs abgeben. Sollte die KOM die Adäquanzentscheidung treffen, ohne die Defizite auszuräumen, wird die Art-29-Gruppe befürworten, dass diese Entscheidung (etwa durch Musterklagen einzelner Datenschutzaufsichtsbehörden) durch Vorlage an den EuGH überprüft wird.

Im Klartext heißt das: Die deutschen Datenschützer wollen, dass die Artikel-29-Datenschutzgruppe (ein EU-Gremium bestehend aus Vertretern der nationalen Datenschutzbehörden) Privacy Shield in der aktuellen Fassung ablehnt. Ferner soll die Gruppe die EU-Kommission auffordern nachzubessern und mit einer Klage vor dem EuGH drohen, falls die Kommission keine Nachbesserung vornehmen sollte. Ob die europäischen Datenschützer die Position ihrer deutschen Kolleg*inen übernehmen werden, ist noch nicht entschieden. Der Klageweg gegen Privacy Shield bleibt aber so oder so offen. Eine Lösung des Problems rückt damit in weite Ferne.   

Wenn Sie Fragen zu Datenschutz, Datensicherheit und IT-Compliance haben,
wendet euch vertrauensvoll an Veit Schiele von Cusy.
Telefon: +49 30 22430082
E-Mail: info@cusy.io

 

Happy New Year 2016!

Wir wünschen euch ein gutes Neues Jahr 2016 und hoffen, dass alle eure Wünsche in Erfüllung gehen werden.

Was wir uns wünschen:

  1. Mehr Datenschutz und Datensicherheit!

    Das IT-Sicherheitsgesetz hat im Juli den Bundesrat passiert. Es wird leider nicht zu mehr IT-Sicherheit führen, denn es ist an vielen Stellen schwammig formuliert, lässt Kontroll- und Durchsetzungsmaßnahmen vermissen und beschränkt sich zudem nur auf den Bereich der »kritischen Infrastruktur«. Die auf EU-Ebene verabschiedete Richtlinie könnte etwas wirkungsvoller sein, jedoch lässt auch sie kleine und mittelständische Unternehmen außen vor.

    In der digitalen Agenda (PDF: 280 KB) der Bundesregierung von August 2014 will Deutschland zum »Verschlüsselungsstandort Nr. 1 auf der Welt« werden. Die tatsächlich unternommenen Schritte sind hingegen sehr zaghaft und werden immer wieder durch gefährliche Forderungen nach Hintertüren für Strafverfolger etc. konterkariert.

  2. Vorratsdatenspeicherung wieder abschaffen!

    Am 18. Dezember ist das »Gesetz zur Einführung einer Speicherpflicht und einer Höchstspeicherfrist für Verkehrsdaten« in Kraft getreten. Damit sollen erneut anlasslos alle Kommunikationsdaten gespeichert werden. Dabei sind 2010 und 2014 in höchstrichterlichen Urteilen solche Maßnahmen für unrechtmäßig erklärt wurden. Wir sind daher zuversichtlich, dass Verfassungsbeschwerden gegen dieses Gesetz erfolgreich sein werden.

  3. Netzneutralität wiederherstellen!

    Die am 27. Oktober 2015 im Europäischen Parlament verabschiedete Verordnung zum Telekommunikationsbinnenmarkt enthielt leider keine Definition von Netzneutralität mehr. Damit ist die Gleichbehandlung von Daten bei der Übertragung im Internet und der diskriminierungsfreie Zugang bei der Nutzung von Datennetzen nicht mehr gewährleistet. Kaum war die Verordnung verabschiedet, kündigte die Telekom auch bereits eine Internet-Maut an: Anbieter, die eine besondere Übertragungsqualität wünschen, sollen zukünftig mehr bezahlen.

  4. Not again unsafe harbors!

    Das Urteil des Europäischen Gerichtshofs zur Unrechtmäßigkeit des Safe Harbor-Abkommens für Datenübermittlungen in die USA bestärkte uns in der Einschätzung, dass Datenschutz und Datensicherheit nur gewährleistet werden können in Ländern mit sehr ähnlichen gesetzlichen Regelungen. Wir müssen nun darauf achten, dass von der EU-Kommission nicht einfach ein neues Safe Harbor-Abkommen eingeführt wird.

  5. Fortführen unserer bisherigen Arbeit!

    Mit der cusy-Plattform wollen wir nächstes Jahr weitere Entwicklungswerkzeuge bereitstellen, die die Arbeit erleichtern und datenschutzkonform betrieben werden. Auch sollen Kunden auf dieser Plattform ihre eigenen Anwendungen betreiben können. Wir wollen somit einen kleinen Beitrag zu mehr Datenschutz und Datensicherheit leisten.

    Wir wollen auf cusy im nächsten Jahr weitere datenschutzkonforme Entwicklungswerkzeuge bereitstellen. Außerdem werden wir cusy zu einer Betriebsplattform weiterentwickeln, damit unsere Kunden ihre Anwendungen nicht nur datenschutzkonform entwickeln, sondern auch entsprechend sicher betreiben können.

Liebe Grüße

Euer Cusy-Team

cusy auf der FrOSCon 10

Mit einer erfreulichen Bilanz, aussichtsreichen Kontakten und der Motivation, unsere Plattform weiter auszubauen sind wir von der gut besuchten FrOSCon 2015 in unser Berliner Büro zurückgekehrt. Das Interesse bei Software-Entwicklern sowohl an unseren Diensten wie auch unserem Konzept zur Vereinfachung des Übergangs von Entwicklung zu Betrieb war groß. So wurde häufig auch unser Angebot genutzt, die Plattform 30 Tage langkostenfrei auszuprobieren.

  • Unsere Maßnahmen zur Einhaltung des bundesdeutschen Datenschutzes kamen sehr gut an.
  • Unser Konzept «All your data belongs to you!» mit der Möglichkeit, jederzeit auf eigene Datenspeicher kopieren zu können schaffte das Vertrauen zu einer fairen Geschäftsbeziehung.
  • Auch diejenigen, die bisher auf Inhouse-Lösungen für Development- und Operation-Tools setzten sahen in der cusy-Plattform eine deutliche Verbesserung der Datensicherheit bei reduzierten Kosten.

„Wir freuen uns sehr, dass unsere Geschäftsidee überzeugt und sehr gut angenommen wurde“, so der Gründer und Geschäftsführer der cusy GmbH, Veit Schiele.

So war die erste Messepräsenz der jungen Firma sehr vorteilhaft. Zu den Interessenten, die das Berliner Unternehmen kontaktierten, gehörten auch Mitarbeiter von großen deutschen Unternehmen. Hier bestätigte sich, dass cusy eine innovative Plattform mit enormem Potential ist.

Für das cusy-Messeteam waren die Gespräche am Stand sehr anregend. Sie konnten in zum Teil tiefgreifenden Fachgesprächen die bestehenden Lösungen erläutern und entwickelten zusammen mit Interessenten Ideen, wie die Plattform weiter ausgebaut werden könnte. Diese positive Erfahrung motiviert sie nun, intensiv die Plattform weiter auszubauen.

FrOSCon