Dezentrale Workload Automatisierung

Dezentrale Workload Automatisierung spielt eine Schlüsselrolle in der erfolgreichen digitalen Transformation. Dezentralisierung bildet einen wichtigen Faktor in der Dynamik und Wachstumsfähigkeit eines Unternehmens, zudem wirkt sich Dezentralität positiv auf die Agilität, Motivation und Verantwortungsbereitschaft von Teams und Führungskräften aus. Der Trend zur Dezentralisierung in modernen Unternehmenskulturen spielt sich parallel zum Trend zur Dezentralisierung in der IT ab: Schon längst bilden monolitische Großrechner und Mainframes eher die Ausnahme als die Regel und werden von leistungsfähigeren Alternativen, unter anderem durch den IT-Betrieb in der Cloud abgelöst. Ist es heute noch zeitgemäß, die Automatisierung monolitisch zu gestalten? Wir denken: Nein!

Dezentralisierte Workload Automatisierung

Souveränität und Best of Breed

Zur technologischen Souveränität eines Unternehmens gehört es, unterschiedliche, moderne Technologien frei einsetzen zu können, ohne an einen einzigen Anbieter gebunden zu sein. Der Vorteil dieser Strategie ist nicht nur die Vermeidung des Vendor Lock-In, eine gefürchtete Situation, in der man auf Gedeih und Verderb auf den Support, die Preisgestaltung und die Zukunftsfähigkeit eines einzigen Anbieters angewiesen ist. Auch für die Agilität von Gruppen und Abteilungen ist es notwendig, dass Teams ihre Aufgaben autonom und souverän mit den für sie am besten geeigneten Werkzeugen lösen können. Weil viele moderne Tools eigene, effektive Automatisierungs-Funktionen beinhalten, muss die jeweils übergeordnete Automatisierungseinheit in der Lage sein, Verantwortung abzugeben. Best of Breed ist nur möglich, wenn verfügbare Automatisierungs-Technologien auch effektiv genutzt werden können.

Workload Automatisierung für höchste Ansprüche - Jetzt individuelle, kostenlose und unverbindliche BICsuite Präsentation vereinbaren

Agile Teams und zufriedene Mitarbeiter

Deployments beinhalten immer öfter auch komplexe Schedules, die von den Teams auch genutzt werden wollen, um optimal arbeiten zu können. Spezialisten wollen mit den für sie am besten geeigneten Werkzeugen effizient und hürdenfrei arbeiten. Damit wird auch die Personalgewinnung immer schwieriger, wenn Unternehmen ihren Mitarbeiterinnen und Mitarbeitern keine zeitgemäßen Werkzeuge anbieten können, oder sie mit bürokratischen Umgebungsbedingungen konfrontieren. Gleichzeitig muss der Gefahr des Kontrollverlustes begegnet werden. Bei der Gestaltung der Dezentralisierung ist es notwendig, dass die Vorteile dieser Strukturen genutzt werden können, ohne mit unerwünschten Nebenwirkungen, wie etwa Dateninseln oder dem mehrfachen Vorhalten gleicher Ressourcen, konfrontiert zu sein. Das lässt sich erreichen, wenn die Dezentralisierung zentraler Strukturen nicht im Hauruckverfahren betrieben, sondern als Prozess behandelt wird und die dezentralen Strukturen an die zentralen Elemente angebunden bleiben. Im Idealfall sollten die besten Eigenschaften der beiden Modelle Dezentralisierung und Zentralisierung auf die eigenen Bedürfnisse zugeschnitten kombiniert werden.

Aktuelle Entwicklungen

Obwohl die meisten Branchen und Geschäftsmodelle längst auf heterogene IT-Landschaften setzen, werden in Unternehmen aus dem Finanzwesen, der Versicherungsbranche und auch im öffentlichen Sektor nach wie vor Mainframes benutzt. Doch auch in diesen Bereichen wird immer sichtbarer, dass heterogene Netzwerke und Cloud-Lösungen langfristig effizienter, wartungsärmer und grundsätzlich kostengünstiger sind. Zudem steigt die Komplexität der Subsysteme wie EDWH, Big Data, Analytics, DevOps, HPC, Cloud kontinuierlich an und die Lifecycles werden wegen dank agilem Development kürzer. Die Folge: Es wird immer schwieriger, ein zentralisiertes Scheduling zur Orchestrierung einer immer stärker dezentralisierten Umgebung zu verwenden. Koordinierungsprobleme können den Zusammenhalt und die Funktionsfähigkeit dezentralisierter Umgebungen massiv beeinträchtigen. Die Herausforderung: Nicht nur die Workload selbst, sondern auch das Scheduling muss dezentralisiert werden.

Dezentrales Scheduling

Unterschiedliche Subsysteme, wie zum Beispiel Jenkins, Cloud, EDWH, Big Data, HPC etc., erfordern bzw. beinhalten spezielle Best Of Breed Job Steuerungen. Dadurch wird es immer schwieriger, alle Job Scheduling Aufgaben in ein zentrales Enterprise Scheduling zu zwingen, ohne dass die Produktivität leidet. Wie aber kann die Transformation zur dezentralen Orchestrierung gelingen? Damit Stabilität, Verfügbarkeit und Sicherheit jederzeit gewährleistet bleiben, muss der Übergang sorgfältig geplant und stufenweise ausgeführt werden. Modernisierungen und Migrationen zu mehr Flexibilität durch Dezentralisierung sind keine „one time events“, sondern führen zu notwendigen Transformationsprozessen. Zunächst ist es wichtig, sich den Unterschied zwischen synchroner und asynchroner Verarbeitung aus der Sicht des Anwenders und aus der Sicht des Scheduling Systems bewusst zu machen.

Synchrone und asynchrone Verarbeitung aus Sicht des Anwenders

Aus Anwendersicht handelt es sich bei Jobketten um synchrone Verarbeitung, bei Jobnetzen um asynchrone Verarbeitung

Synchrone und asynchrone Verarbeitung aus Sicht des Anwenders mit Jobketten und Jobnetzen

Synchrone Verarbeitung aus Sicht des Scheduling Systems

Aus der Sicht des Scheduling-Systems ist die Verarbeitung im Agent eine synchrone Verarbeitung, wenn das System auf den Exit Code des Agent wartet, bevor der nächste Prozess ausgeführt wird.

Synchrone Verarbeitung aus Sicht des Scheduling Systems mit einem Agent

Ausführung eines Ablaufs in einem externen (Scheduling) System

Synchrone Verarbeitung (Polling)

Eine häufig genutzte Methode, die Verarbeitung in externen Systemen zu ermöglichen ist das „Polling“.

Synchrone Verarbeitung (Polling)

Beim Polling wird der externe Ablauf wie ein synchroner interner Job verarbeitet. Dabei startet das Scheduling-System einen Job, der den Ablauf im externen System startet und dann aktiv darauf wartet, bis der externe Ablauf vollständig aufgeführt wurde. Dafür fragt der Job in regelmäßigen Abständen beim externen System nach dem Stand der Dinge und übernimmt dabei optional verfügbare Status-Informationen. Nach vollendeter Ausführung des externen Ablaufs beendet sich der Job mit einem Exit Code, der dem Ergebnis des externen Ablaufs entspricht. Polling ist in manchen Fällen die einzige Möglichkeit der asynchronen Verarbeitung, doch die Methode hat Konsequenzen, die man sich bewusst machen sollte:

  • Wird das Polling mit hoher Frequenz durchgeführt, entsteht sowohl im über-, als auch im untergeordneten System ein nicht zu vernachlässigender Overhead.
  • Vermeidet man das durch ein Polling mit niedriger Frequenz, entstehen unnötig lange Wartezeiten, der den Gesamtablauf verzögern kann.
  • Komplexe technische Probleme müssen gelöst werden. Dazu gehören unter anderem der Wiederanlauf des Pollings (z.B. nach Netzwerk- und Serverproblemen oder Downtimes) und die Unterscheidung von Fehlern des Polling-Prozesses von Fehlern des externen Ablaufs.

Asynchrone Verarbeitung

Bei der asynchronen Verarbeitung startet das Scheduling-System einen Job, der den Ablauf im externen System startet und dabei die Credentials des Jobs an das externe System übergibt. Dieser Job wartet in dieser Variante nicht auf das Ende der Verarbeitung im externen System, sondern beendet sich mit einem Exit Code, der das erfolgreiche Starten im externen System signalisiert.

Asynchrone Verarbeitung

Der Job geht in einen Pending-State über, der vom Scheduling-System wie ein laufender Job behandelt wird, ohne dass dieser Job aktiv ist. Es ist nun in der Verantwortung des externen Systems, am Ende des Ablaufs unter Nutzung der übergebenen Job-Credentials aktiv Statusinformationen und den Exit Status der Verarbeitung an das übergeordnete Scheduling-System zurück zu melden. Optional können während des Ablaufs auch Statusinformationen (z.B. Prozessfortschritt) an das übergeordnete Scheduling-System übergeben werden.

Diese Form der Verarbeitung bietet folgende Vorteile:

  • Es entsteht kein Polling-Overhead durch aktives Warten
  • Unnötige Wartezeiten werden vermieden
  • Die Implementierung ist unkomplizierter und weniger anfällig für Fehler

Allerdings muss das Remote-System einige Anforderungen erfüllen:

  • Geeignete Schnittstellen (API)
  • Trigger-Konzept zum Melden von Fehlern
  • Einbindung von Schnittstellen-Prozessen (Fehlermeldungen, Rückmeldung am Ende und Statusinformationen während des Ablaufs)
  • Optimalerweise Restart-Fähigkeit

Dezentrale Implementierung mit BICsuite/schedulix

Vorausgesetzt, die oben beschriebenen Bedingungen sind erfüllt, sind BICsuite und schedulix in der Lage, eine echte asynchrone Verarbeitung mit einem Remote System zu gewährleisten. BICsuite und schedulix können selbstverständlich als zentrales Scheduling-System eingesetzt werden. In einigen Fällen (zum Beispiel beim Prozess der Transformation von On Premise in die Cloud, bei großen Strukturen mit klar abgegrenzten dezentralen Einheiten oder bei der Anbindung zuvor getrennter großer Einheiten in eine übergeordnete Einheit) kann es sinnvoll sein, mit mehreren hierarchischen BICsuite, bzw. schedulix Scheduling Servern zu arbeiten. BICsuite und schedulix können aber auch als Mastersystem für bestehende Scheduling-Lösungen verwendet werden oder einem vorhandenen System untergeordnet werden, um einzelne Unternehmensbereiche zu dezentralisieren. Auch eine Mittlerfunktion ist denkbar: In einem vorhandenen, zentralen Scheduling wird BICsuite, bzw. schedulix als Dezentralisierungs-Ebene und zur Steuerung von Subsystemen eingesetzt. Bitte nehmen Sie mit uns Kontakt auf, damit wir gemeinsam eine Strategie für die dezentrale Automatisierung in Ihrem Unternehmen entwickeln können.

Workload Automatisierung für höchste Ansprüche - Jetzt individuelle, kostenlose und unverbindliche BICsuite Präsentation vereinbaren