Dezentralisierte Workload-Automatisierung
Dezentrale Workload-Automatisierung spielt eine Schlüsselrolle bei der erfolgreichen digitalen Transformation. Dezentralisierung ist ein wichtiger Faktor für die Dynamik und Wachstumsfähigkeit eines Unternehmens. Zudem wirkt sich Dezentralisierung positiv auf die Agilität, Motivation und Verantwortungsbereitschaft von Teams und Managern aus. Der Trend zur Dezentralisierung in modernen Unternehmenskulturen verläuft parallel zum Trend zur Dezentralisierung in der IT: Monolithische Mainframes und Großrechner sind längst eher die Ausnahme als die Regel und werden durch effizientere Alternativen ersetzt, unter anderem durch den IT-Betrieb in der Cloud. Ist es heute noch angebracht, Automatisierung monolithisch zu gestalten? Wir meinen: Nein!
Souveränität und Best of Breed
Zur technologischen Souveränität eines Unternehmens gehört es, unterschiedliche, moderne Technologien frei nutzen zu können, ohne an einen einzigen Anbieter gebunden zu sein. Der Vorteil dieser Strategie ist nicht nur die Vermeidung des gefürchteten "Vendor Locked-in", bei dem man auf Gedeih und Verderb vom Support, der Preisgestaltung und der Zukunftsfähigkeit eines einzelnen Anbieters abhängig ist. Für die Agilität von Gruppen und Abteilungen ist es auch notwendig, dass Teams ihre Aufgaben mit den für sie am besten geeigneten Werkzeugen selbständig und sicher lösen können. Da viele moderne Werkzeuge eigene effektive Automatisierungsfunktionen beinhalten, muss die jeweils übergeordnete Automatisierungseinheit die Verantwortung abgeben können. Best of Breed ist nur möglich, wenn die vorhandenen Automatisierungstechnologien auch effektiv genutzt werden können.
Agile Teams und zufriedene Mitarbeiter
Deployments beinhalten zunehmend komplexe Zeitpläne, die die Teams nutzen wollen, um optimal arbeiten zu können. Spezialisten wollen effizient und ohne Hürden mit den für sie am besten geeigneten Werkzeugen arbeiten. Das macht es auch immer schwieriger, Personal zu rekrutieren, wenn Unternehmen ihren Mitarbeitern keine zeitgemäßen Werkzeuge anbieten oder sie mit bürokratischen Rahmenbedingungen konfrontieren. Gleichzeitig muss der Gefahr des Kontrollverlustes entgegengewirkt werden. Bei der Gestaltung der Dezentralisierung ist es notwendig, dass die Vorteile dieser Strukturen genutzt werden können, ohne mit unerwünschten Nebeneffekten wie Dateninseln oder dem mehrfachen Vorhalten gleicher Ressourcen konfrontiert zu werden. Dies kann erreicht werden, wenn die Dezentralisierung von zentralen Strukturen nicht ruckartig erfolgt, sondern als Prozess behandelt wird und die dezentralen Strukturen mit den zentralen Elementen verbunden bleiben. Idealerweise sollten die besten Eigenschaften der beiden Modelle, Dezentralisierung und Zentralisierung, je nach Bedarf kombiniert werden.
Aktuelle Entwicklungen
Obwohl die meisten Branchen und Geschäftsmodelle längst auf heterogene IT-Landschaften setzen, werden in Unternehmen aus dem Finanzsektor, der Versicherungswirtschaft und auch im öffentlichen Sektor immer noch Mainframes eingesetzt. Doch auch dort zeigt sich zunehmend, dass heterogene Netzwerke und Cloud-Lösungen effizienter, wartungsärmer und langfristig grundsätzlich kostengünstiger sind. Hinzu kommt, dass die Komplexität von Teilsystemen wie EDWH, Big Data, Analytics, DevOps, HPC und Cloud stetig zunimmt und die Lebenszyklen dank agiler Entwicklung immer kürzer werden. Infolgedessen wird es immer schwieriger, eine zunehmend dezentralisierte Umgebung mit zentralem Scheduling zu orchestrieren. Koordinationsprobleme können den Zusammenhalt und die Funktionalität von dezentralen Umgebungen massiv beeinträchtigen. Die Herausforderung: Nicht nur der Workload selbst, sondern auch das Scheduling muss dezentralisiert werden.
Dezentralisierte Planung
Verschiedene Subsysteme wie Jenkins, Cloud, EDWH, Big Data, HPC usw. erfordern oder beinhalten spezifische Best-of-Breed-Jobkontrollen. Dadurch wird es immer schwieriger, alle Job-Scheduling-Aufgaben in ein zentrales Unternehmens-Scheduling zu zwingen, ohne dass die Produktivität darunter leidet. Doch wie kann die Umstellung auf eine dezentrale Orchestrierung gelingen? Um jederzeit Stabilität, Verfügbarkeit und Sicherheit zu gewährleisten, muss der Übergang sorgfältig geplant und schrittweise durchgeführt werden. Modernisierung und Umstellung auf mehr Flexibilität durch Dezentralisierung sind keine "einmaligen Ereignisse", sondern führen zu notwendigen Transformationsprozessen. Zunächst ist es wichtig, sich den Unterschied zwischen synchroner und asynchroner Verarbeitung aus Sicht des Anwenders und aus Sicht des Scheduling-Systems bewusst zu machen.
Synchrone und asynchrone Verarbeitung aus der Sicht des Benutzers
Aus der Sicht des Benutzers sind Job-Ketten eine synchrone Verarbeitung, während Job-Netze eine asynchrone Verarbeitung darstellen.
Synchrone Verarbeitung aus der Sicht des Scheduling-Systems
Aus der Sicht des Einplanungssystems ist die Verarbeitung im Agenten eine synchrone Verarbeitung, wenn das System auf den Exit-Code des Agenten wartet, bevor es den nächsten Prozeß ausführt.
Ausführung eines Prozesses in einem externen (Einplanungs-)System
Synchrone Verarbeitung (Polling)
Eine häufig verwendete Methode, um die Verarbeitung in externen Systemen zu ermöglichen, ist das "Polling".
Beim Polling wird der externe Prozess wie ein synchroner interner Job verarbeitet. Das Einplanungssystem startet einen Job, der den Prozeß im externen System startet und dann aktiv auf die Beendigung des externen Prozesses wartet. Dazu fragt der Job in regelmäßigen Abständen beim externen System den Status des Prozesses ab und übernimmt optional vorhandene Statusinformationen. Nach Beendigung des externen Prozesses wird der Job mit einem Exit-Code beendet, der dem Ergebnis des externen Prozesses entspricht. Polling ist in manchen Fällen die einzige Möglichkeit der asynchronen Verarbeitung, aber die Methode hat Konsequenzen, über die man sich im klaren sein sollte:
- Wird das Polling mit hoher Frequenz durchgeführt, entsteht ein nicht zu vernachlässigender Overhead sowohl in den über- als auch in den untergeordneten Systemen.
- Wird dies durch eine niedrige Abfragefrequenz vermieden, entstehen unnötig lange Wartezeiten, die den Gesamtprozess verzögern können.
- Komplexe technische Probleme müssen gelöst werden. Dazu gehören der Neustart des Pollings (z.B. nach Netz- und Serverproblemen oder Ausfallzeiten) und die Unterscheidung von Fehlern im Polling-Prozess von Fehlern im externen Prozess.
Asynchrone Verarbeitung
Bei der asynchronen Verarbeitung startet das Scheduling-System einen Job, der den Prozess im externen System startet und die Credentials des Jobs an das externe System übermittelt. Bei dieser Variante wartet dieser Job nicht auf das Ende der Verarbeitung im externen System, sondern beendet sich selbst mit einem Exit-Code, der den erfolgreichen Start im externen System signalisiert.
Der Job geht in einen Schwebezustand über, der vom Scheduling-System wie ein laufender Job behandelt wird, ohne daß dieser Job aktiv ist. Es liegt nun in der Verantwortung des externen Systems, dem übergeordneten Scheduling-System am Ende des Prozesses aktiv Statusinformationen und den Exit-Status der Verarbeitung anhand der übermittelten Job Credentials zu melden. Optional können auch während des Prozesses Statusinformationen (z.B. Prozessfortschritt) an das übergeordnete Scheduling-System übermittelt werden. Diese Form der Verarbeitung bietet die folgenden Vorteile:
- Es entsteht kein Polling-Overhead durch aktives Warten.
- Unnötige Wartezeiten werden vermieden
- Die Implementierung ist weniger kompliziert und weniger fehleranfällig
Allerdings muss das entfernte System einige Anforderungen erfüllen:
- Geeignete Schnittstellen (API)
- Triggerkonzept für Fehlermeldungen
- Integration von Schnittstellenprozessen (Fehlermeldungen, Rückmeldungen am Ende und Statusinformationen während des Prozesses)
- Optimale Wiederanlauffähigkeit
Dezentrale Umsetzung mit BICsuite und schedulix
Sofern die oben beschriebenen Bedingungen erfüllt sind, sind BICsuite und schedulix in der Lage, eine echte asynchrone Verarbeitung mit einem entfernten System zu ermöglichen. BICsuite und schedulix können natürlich auch als zentrales Scheduling-System eingesetzt werden. In manchen Fällen (z.B. bei der Umstellung von on premise auf die Cloud, in großen Strukturen mit klar abgegrenzten dezentralen Einheiten oder bei der Verbindung bisher getrennter großer Einheiten zu einer übergeordneten Einheit) kann es sinnvoll sein, mit mehreren hierarchischen BICsuite- oder schedulix-Scheduling-Servern zu arbeiten. BICsuite und schedulix können aber auch als Master-System für bestehende Scheduling-Lösungen eingesetzt werden oder einem bestehenden System untergeordnet werden, um einzelne Unternehmensbereiche zu dezentralisieren. Auch eine Vermittlerfunktion ist denkbar: In einem bestehenden zentralen Dispositionssystem wird BICsuite oder schedulix als Dezentralisierungsebene und zur Steuerung von Subsystemen eingesetzt. Bitte nehmen Sie Kontakt mit uns auf, damit wir gemeinsam eine Strategie für die dezentrale Automatisierung in Ihrem Unternehmen entwickeln können.
BICsuite Höhepunkte
Mehr erfahren
Stöbern Sie in unserer wachsenden Sammlung von Artikeln, Erklärvideos und Tutorials, um praktische Einblicke und Best Practices für die Workload-Automatisierung mit Schedulix und BICsuite zu entdecken.
Mehr erfahrenHaben Sie noch Fragen?
Bitte zögern Sie nicht, sich mit uns in Verbindung zu setzen, wenn Sie irgendwelche Fragen haben oder weitere Informationen benötigen. Unser Team steht Ihnen gerne zur Verfügung.
Kontaktieren Sie uns↑ Nach oben