Die Bescheinigungsstelle Forschungszulage (BSFZ) hat die Entwicklung von Polycrate als Forschungs- und Entwicklungsvorhaben im Sinne des Forschungszulagengesetzes anerkannt. Damit wird die eigenbetriebliche Forschungs- und Entwicklungsarbeit von ayedo an einem Automatisierungsframework bestätigt, das bestehende Werkzeuge und Technologien in einem gemeinsamen technischen Modell verbindet. Für diese Entwicklungsleistung hat ayedo das rote BSFZ-Siegel erhalten.
Forschung und Entwicklung als Teil unserer Arbeit
Bei ayedo beschäftigen wir uns täglich mit der Bereitstellung, Automatisierung und dem Betrieb von IT-Infrastrukturen. Dabei setzen wir auf etablierte Open-Source-Technologien wie Kubernetes, Ansible und weitere Werkzeuge aus dem Cloud-Native-Umfeld.
Diese Technologien lösen viele Aufgaben zuverlässig. Ihre Integration in komplexe Betriebsumgebungen bringt allerdings eigene Herausforderungen mit sich.
Eine Anwendung bereitzustellen, erfordert häufig mehrere voneinander abhängige Arbeitsschritte. Infrastruktur muss vorbereitet, Software konfiguriert, Zugangsdaten müssen verwaltet und verschiedene Werkzeuge in der richtigen Reihenfolge ausgeführt werden. Hinzu kommen unterschiedliche Versionen, kundenspezifische Konfigurationen und Anforderungen an die Wartbarkeit.
Die einzelnen Werkzeuge sind dafür meist vorhanden. Schwieriger ist es, ihre Zusammenarbeit so zu organisieren, dass Automatisierungen wiederverwendbar, nachvollziehbar und unabhängig von individuellen lokalen Entwicklungsumgebungen ausgeführt werden können.
Aus diesen Anforderungen heraus ist Polycrate entstanden.
Was ist Polycrate?
Polycrate ist ein von ayedo entwickeltes Automatisierungsframework mit einer eigenen Ausführungsumgebung, das auf Ansible aufbaut. Es ermöglicht, Anwendungen und IT-Infrastrukturen in wiederverwendbare Komponenten zu unterteilen, diese zu konfigurieren und über definierte Aktionen zu verwalten.
Dabei ersetzt Polycrate weder Ansible noch Kubernetes oder Helm. Stattdessen verbindet es bestehende Werkzeuge in einem gemeinsamen Automatisierungsmodell.
Im Mittelpunkt stehen drei Konzepte: Workspaces, Blocks und Actions.
Ein Workspace bildet den Kontext einer Infrastruktur oder Anwendung ab. Blocks enthalten die technische Implementierung einzelner Komponenten. Actions definieren, welche Operationen mit diesen Komponenten ausgeführt werden können.
Diese Trennung ist wesentlich für den technischen Ansatz von Polycrate: Die Implementierung einer Automatisierung wird von ihrer konkreten Verwendung getrennt.
Ein Team kann beispielsweise einen Block entwickeln, der einen Kubernetes-Cluster konfiguriert. Andere Teams können diesen Block in ihren eigenen Workspaces verwenden, ohne die zugrunde liegenden Ansible-Playbooks verändern oder deren interne Abläufe vollständig kennen zu müssen.
Die technische Komplexität verschwindet dadurch nicht. Sie wird an einer definierten Stelle verwaltet und muss nicht bei jeder Verwendung erneut umgesetzt werden.
Workspaces: Ein gemeinsamer Kontext für die Automatisierung
Ein Workspace ist die zentrale Organisationseinheit in Polycrate. Er enthält die Konfiguration einer Umgebung sowie die für ihre Verwaltung benötigten Blocks, Referenzen, Zugangsdaten und Artefakte.
Die zentrale Konfigurationsdatei heißt workspace.poly und verwendet YAML. Eine zusätzliche proprietäre Konfigurationssprache ist nicht erforderlich.
In einem Workspace kann beispielsweise festgelegt werden, welche Infrastrukturkomponenten eingesetzt werden, aus welchen Registries sie stammen und mit welchen Parametern sie betrieben werden sollen.
Der Workspace kann als Git-Repository verwaltet werden. Dadurch lassen sich Änderungen an der Infrastrukturkonfiguration versionieren, überprüfen und zwischen Teammitgliedern synchronisieren.
Besonders relevant ist dieses Modell bei der Verwaltung mehrerer Umgebungen. Entwicklungs-, Test- und Produktionssysteme können auf denselben technischen Bausteinen beruhen und dennoch unterschiedliche Konfigurationen verwenden.
Polycrate berücksichtigt außerdem die Verwaltung sensibler Informationen. Secrets und andere vertrauliche Artefakte können innerhalb des Workspaces verschlüsselt werden. Die Dokumentation sieht hierfür unter anderem eine auf age basierende Verschlüsselung vor.
Damit werden Konfiguration, Ausführung und der Umgang mit sensiblen Daten innerhalb eines gemeinsamen Modells organisiert, ohne Zugangsdaten unverschlüsselt im Versionsverwaltungssystem ablegen zu müssen.
Blocks: Wiederverwendbare Infrastrukturkomponenten
Blocks sind die modularen Bausteine von Polycrate.
Ein Block kann beispielsweise die Installation einer Anwendung, die Konfiguration eines Servers, die Verwaltung einer Datenbank oder die Bereitstellung von Kubernetes-Ressourcen abbilden.
Er enthält die für seine Aufgabe notwendige Automatisierungslogik, Konfiguration und die Definition der verfügbaren Aktionen.
Bestehende Ansible-Playbooks, Python-Skripte und andere Automatisierungsmechanismen können in Blocks eingebunden werden. Bereits entwickelte Automatisierungen müssen deshalb nicht grundsätzlich neu geschrieben werden.
Ein wichtiger Bestandteil ist die Paketierung über den OCI-Standard.
Blocks können als OCI-Artefakte bereitgestellt und über kompatible Registries verteilt werden. Dazu gehören beispielsweise Harbor oder andere OCI-kompatible Registries.
Damit können Infrastrukturbausteine ähnlich wie Container-Images versioniert, veröffentlicht und in unterschiedlichen Umgebungen wiederverwendet werden.
Die Versionierung spielt dabei eine zentrale Rolle. Statt eine Infrastrukturkomponente immer aus einem veränderlichen Entwicklungsstand zu beziehen, kann ein Workspace gezielt auf eine bestimmte Version verweisen.
Das erleichtert die Kontrolle über Änderungen und reduziert das Risiko, dass eine Aktualisierung eines gemeinsam genutzten Bausteins unbeabsichtigt andere Umgebungen beeinflusst.
Actions: Einheitliche Bedienung unterschiedlicher Werkzeuge
Ein weiterer Bestandteil von Polycrate ist das Action-Modell.
Eine Action beschreibt eine konkrete Operation, die mit einem Block ausgeführt werden kann. Das kann beispielsweise die Installation, Aktualisierung, Überprüfung oder Entfernung einer Komponente sein.
Die eigentliche Implementierung kann aus mehreren Ansible-Tasks, Skripten oder Aufrufen externer Werkzeuge bestehen.
Nach außen steht jedoch eine definierte Aktion zur Verfügung.
Eine solche Aktion lässt sich beispielsweise mit folgendem Befehl ausführen:
polycrate run nginx install
Die aufrufende Person muss dafür nicht wissen, welche einzelnen Ansible-Rollen, Konfigurationsdateien oder weiteren Werkzeuge intern verwendet werden.
Das ist insbesondere für Teams relevant, in denen unterschiedliche Personen mit derselben Infrastruktur arbeiten. Die technische Implementierung bleibt bei den Verantwortlichen für den jeweiligen Block, während die vorgesehenen Betriebsaktionen einheitlich aufgerufen werden können.
Auf diese Weise lassen sich auch bestehende Automatisierungen schrittweise in Polycrate integrieren, statt eine vorhandene Infrastruktur vollständig neu aufbauen zu müssen.
Reproduzierbare Ausführung statt individueller Tool-Konfigurationen
Ein häufiges Problem bei Infrastrukturautomatisierung sind Unterschiede zwischen den Ausführungsumgebungen.
Ein Ansible-Playbook kann auf einem Entwicklungsrechner funktionieren und auf einem anderen aufgrund abweichender Python-Versionen, fehlender Abhängigkeiten oder unterschiedlicher Tool-Versionen scheitern.
Polycrate begegnet diesem Problem mit einer containerisierten Ausführungsumgebung.
Die benötigte Toolchain wird in einem Polycrate-Container bereitgestellt. Dazu können unter anderem Ansible, kubectl, Helm und Python gehören.
Dadurch hängt die Ausführung weniger stark von der individuell eingerichteten Arbeitsumgebung einzelner Entwicklerinnen und Entwickler ab.
In Verbindung mit versionierten Blocks und definierten Workspace-Konfigurationen entsteht eine Grundlage für reproduzierbare Automatisierungsabläufe.
Reproduzierbarkeit bedeutet dabei nicht, dass jeder Vorgang unabhängig vom Zustand der Zielsysteme zwangsläufig dasselbe Ergebnis erzeugt. Externe APIs, Netzwerke, Berechtigungen und bestehende Infrastrukturzustände bleiben relevante Einflussfaktoren.
Polycrate konzentriert sich deshalb auf die kontrollierbaren Bestandteile: die eingesetzten Werkzeuge, die verwendeten Automatisierungsbausteine, ihre Versionen, die Konfiguration und den Ausführungskontext.
Warum die Entwicklung über klassische Softwareintegration hinausgeht
Die technische Herausforderung bei Polycrate liegt nicht darin, ein weiteres Werkzeug zur Ausführung von Ansible-Playbooks bereitzustellen.
Ansible selbst bietet bereits umfangreiche Möglichkeiten zur Automatisierung. Auch für Paketverwaltung, Containerisierung, Versionskontrolle und Secrets-Management existieren etablierte Lösungen.
Die Entwicklungsarbeit an Polycrate beschäftigt sich vielmehr mit der Frage, wie diese unterschiedlichen Konzepte in einem konsistenten Modell zusammenarbeiten können.
Ein Block muss unabhängig von einem konkreten Workspace entwickelt und versioniert werden können. Gleichzeitig benötigt seine Ausführung Zugriff auf die Konfiguration, Abhängigkeiten und gegebenenfalls sensible Informationen der jeweiligen Zielumgebung.
Die eingesetzten Werkzeuge müssen in einer definierten Umgebung verfügbar sein. Änderungen an einzelnen Komponenten sollen nachvollziehbar bleiben. Gleichzeitig muss das Modell flexibel genug sein, um unterschiedliche Infrastrukturtypen und vorhandene Automatisierungen einzubinden.
Daraus ergeben sich technische Anforderungen an die Paketierung, Abhängigkeitsverwaltung, Konfigurationsverarbeitung und Ausführung.
Diese Anforderungen lassen sich nicht allein dadurch erfüllen, dass bestehende Kommandozeilenwerkzeuge nacheinander aufgerufen werden. Entscheidend ist, wie ihre Zuständigkeiten, Eingaben, Abhängigkeiten und Ausführungsbedingungen zusammengeführt werden.
Genau an dieser Architektur und ihrer technischen Umsetzung arbeitet ayedo mit Polycrate.
Offene Standards als Grundlage
Bei der Entwicklung von Polycrate setzen wir bewusst auf vorhandene Technologien und offene Standards.
Ansible bildet die Grundlage für die Automatisierungslogik. YAML dient zur Beschreibung von Konfigurationen. OCI ermöglicht die Paketierung und Verteilung von Blocks über kompatible Registries. Git unterstützt die Versionierung und Zusammenarbeit.
Diese Entscheidungen haben praktische Gründe.
Unternehmen verfügen häufig bereits über umfangreiche Automatisierungen und Erfahrungen mit diesen Werkzeugen. Eine neue Plattform, die deren vollständige Ablösung voraussetzt, würde zusätzliche Migrationskosten und Abhängigkeiten schaffen.
Polycrate verfolgt deshalb einen anderen Ansatz: Bestehende Implementierungen sollen weiterverwendet und in ein gemeinsames Modell integriert werden können.
Das reduziert die Notwendigkeit, funktionierende Automatisierungen neu zu entwickeln, und erleichtert die schrittweise Einführung.
Offene Standards sind dabei auch eine Voraussetzung für technische Wahlfreiheit. Unternehmen können kompatible Registries, Versionsverwaltungssysteme und Infrastrukturwerkzeuge entsprechend ihren eigenen Anforderungen einsetzen.
Was die BSFZ-Anerkennung bedeutet
Die Bescheinigungsstelle Forschungszulage prüft im Rahmen des Forschungszulagengesetzes, ob beantragte Vorhaben die Voraussetzungen für Forschung und Entwicklung erfüllen.
Bei der Beurteilung spielen unter anderem die Neuartigkeit des angestrebten Erkenntnisgewinns, wissenschaftliche oder technische Unsicherheiten und das planmäßige Vorgehen eine Rolle.
Die Entwicklung von Polycrate wurde von der BSFZ als Forschungs- und Entwicklungsvorhaben im Sinne dieses Gesetzes anerkannt.
Für die eigenbetriebliche Forschungs- und Entwicklungsleistung hat ayedo das rote BSFZ-Siegel erhalten.
Diese Anerkennung bezieht sich auf die Forschungs- und Entwicklungsarbeit. Sie ist keine Zertifizierung der Produktsicherheit, keine allgemeine Qualitätsprüfung und keine Aussage darüber, dass sämtliche Funktionen von Polycrate technisch einzigartig sind.
Sie bestätigt vielmehr, dass das geprüfte Entwicklungsvorhaben die gesetzlichen Anforderungen an Forschung und Entwicklung erfüllt.
Für ayedo ist das eine wichtige Anerkennung der Arbeit, die in die Konzeption und technische Umsetzung von Polycrate eingeflossen ist.
Wie es mit Polycrate weitergeht
Polycrate ist aus konkreten Anforderungen entstanden, die uns bei der Entwicklung und beim Betrieb komplexer IT-Infrastrukturen begegnen.
Mit dem Framework verfolgen wir weiterhin das Ziel, bestehende Automatisierungstechnologien so miteinander zu verbinden, dass Infrastrukturbausteine über Projekte und Umgebungen hinweg wiederverwendet und kontrolliert betrieben werden können.
Die Weiterentwicklung orientiert sich an den technischen Anforderungen aus der Praxis: an der Verwaltung unterschiedlicher Infrastrukturen, der Integration bestehender Werkzeuge und der zuverlässigen Ausführung von Automatisierungen.
Die Anerkennung durch die BSFZ ist für uns deshalb kein Abschluss der Entwicklung, sondern eine Bestätigung der bisher geleisteten Forschungs- und Entwicklungsarbeit.
Polycrate zeigt, woran wir bei ayedo arbeiten: Wir nutzen nicht nur bestehende Open-Source-Technologien, sondern entwickeln eigene Lösungen für technische Probleme, die sich mit deren isoliertem Einsatz nicht ausreichend lösen lassen.
Dass diese Arbeit nun offiziell als Forschungs- und Entwicklungsvorhaben anerkannt wurde, ist eine gute Nachricht für unser Team.
Weiterführende Informationen