Die parallele Verarbeitung von Anwendungen macht Köpfe frei.
Cay Jeglinski, WAY Software
Zwischen Releases zu wechseln und Tests schnell zu wiederholen klingt in heutigen Webserverfarmen wie ein Wunschtraum.
Wie wäre es mit einem Weg, der Ihre Releases parallel im Zugriff in einer konsolidierten Serverfarm hält?
Mit der Parallel Application Delivery (PAD) ist WAY einzigartig und innovativ: In einer Serverfarm sind alle Releases parallel abrufbar! Sie entscheiden welches Release zu welchem Zeitpunkt verarbeitet werden soll. WAY übernimmt die Konfiguration ins Regelwerk und aktiviert die gewünschten Releases in Echtzeit – getrennt für Entwicklung, Integrationstests und Produktion.
Wie macht WAY das?Das zentrale Regelwerk steuert, welches Release vom PAD aktiviert wird. Das PAD Gateway markiert jede Verbindung zur Anwendung und steuert die Verarbeitung in der Webserverfarm. Für jedes Segment der Anwendungsentwicklung (Entwicklung, Integrationstest und der produktiven Umgebung) entscheiden Sie, welches Release verarbeitet werden soll, ohne die sonst üblichen Tickets für die IT Infrastruktur auslösen zu müssen.
Der dynamische Lebenszyklus ist Basis für neue Releases und Patchmanagement! So lebt WAY effektives DevOps!
Heiko Schönfeldt, WAY Software
Updates und Patches zeitnah einspielen und neue Releases zu veröffentlichen sind oft genug konkurrierende Ziele und am Ende nicht erreicht.
Wie wäre es, wenn das Deployment parallel Patches und Release zulassen würde?
Der Dynamic Life Cycle (DLC) erlaubt WAY die unterbrechungsfreie Verarbeitung von Anwendungen. So können Updates der Server oder das Einspielen neuer Releases über das DLC einfach angestoßen und überwacht werden. Das DLC übernimmt die Kontrolle jedes Schritts und meldet den Erfolg in Echtzeit.
Wie macht WAY das?Die Serverfarm ist gegliedert in Gruppen von Servern: die WAY Serverpools. Für die Entwicklung und die Intergration wird bei der Installation neuer Releases jeweils ein Serverpool konfiguriert. Der WAY Deployment Prozess übernimmt die Installationsschritte und steuert diese für jeden Server eines Serverpools.
Für das produktive Segment unterscheidet das WAY zwei Life Cycle Prozesse: Business Life Cycle mit optimaler Leistung oder Industry Life Cycle mit optimaler Verfügbarkeit.
Der Business Life Cycle ist für optimale Leistung ausgelegt. Alle Server verarbeiten die Anwendungen und sind im produktiven Serverpool zusammengefasst. Bei der Installation eines neuen Release werden zyklisch Server in den staging Serverpool übernommen, geprüft und zurückgegeben.
Wie macht WAY das?Im Normalfall sind alle Server im produktiven Serverpool über den produktiven Proxy angesprochen. Zu Beginn der Installation eines neuen Release werden zyklisch Server in den staging Serverpool übernommen. Nun werden die Installationsschritte über den WAY Deployment Prozess auf den Servern parallel durchgeführt und überprüft. Beim Abschluss des Installationszyklus sind aller Server im produktiven Serverpool mit dem neuen Release ausgestattet.
Ein identischer Zyklus wird vom IT Servermanagement verwendet, um Betriebssystemupdates oder Server-Patches einzuspielen. Über die Pre-Production-Tests kann automatisch oder manuell der Erfolg des Zyklus geprüft werden.
Beim Industry Life Cycle steht die Hochverfügbarkeit der Anwendungen im Zentrum. Der produktive und der standby Serverpool sind identisch ausgestattet und können mit gleichbleibender Leistung die Anwendungen verarbeiten. Zusätzlich kann die automatische Leistungsreserve des reserve Serverpools genutzt werden.
Der WAY Deployment Prozess übernimmt die Installation und prüft den Erfolg. Die Serverpools werden zyklisch getauscht, bis alle Server über das neue Release verfügen.
Wie macht WAY das?Beim Industry Life Cycle werden vier Serverpools unterschieden. Der aktive Serverpool verarbeitet die Anwendungen. Der standby Serverpool kann mit identischer Leistung den aktiven Serverpool übernehmen, falls Probleme in der Serverfarm auftreten, beispielsweise Server ausfallen. Die Leistungsreserve ist optional und kann bei Leistungsengpässen zusätzliche Server in den aktiven und standby Serverpool übergeben.
Die Installation eines neuen Release wird über den staging Serverpool durchgeführt. Während der Installation eines neuen Release werden die Rollen der Serverpools zyklisch getauscht bis alle Server mit der neuen Release versorgt sind.
Flexible und agile Sprints der Entwicklung in stabilen Serverfarmen umsetzen zu können setzt kreatives Potenzial frei, jeden Tag!
Cay Jeglinski, WAY Software
Das Ziel: Releases über ein dynamisch konfiguriertes Regelwerk zu aktivieren und somit agile Entwicklung zu unterstützen.
Mit welchem Weg lässt sich die agile Entwicklung ohne enorme Aufwendungen in der IT Infrastruktur erreichen?
Das Regelwerk kennzeichnet die Verbindungen zu den Anwendungen. Die Active Rule Base (ARB) erlaubt, die Kennzeichnungen verschiedenen Releases zuzuweisen. Die Standardregel in der ARB aktiviert das Standard-Release jeder Anwendung. Zusätzliche Regeln prüfen die Verbindungen über weitere Markierungen und aktivieren konfigurierte Releases. So sind agile Sprints möglich und long time API verfügbar. Beide parallel über die ARB in einer Serverfarm abrufbar!
Wie macht WAY das?Die Markierungen können IP Adressen, DNS Domänen oder Benutzernamen beinhalten. Die Markierungen aktivieren im Regelwerk für jede Anwendung ein spezielles Release, das in der Serverfarm verarbeitet wird.
Die Umgebungen für die Bereiche der Anwendungsentwicklung: Intergration und Produktion identisch zu halten spart Nerven und Ressourcen!
Wie wäre es mit einem Weg, der die alle drei Segmente der Anwendungsentwicklung trennt und in einem Zyklus verbindet?
WAY unterscheidet die drei Segmente Entwicklung, Integrationstest und Produktion. Für die drei Segmente sind eigene Proxies vorgesehen. Über diese Proxies werden alle Releases Ihrer Anwendungen erreicht. Der Dynamic Life Cycle erlaubt die drei Segmente zu verbinden und die Releases über das Regelwerk kontrolliert zu verarbeiten.
Wie macht WAY das?Für Entwicklung und Test sind Teams im WAY vorgesehen, für die eigene Proxies definiert sind. So kann die ARB teamorientiert für Anwendungen oder Micro Services spezifische Releases aktivieren. Die einzelnen Teams sind im Regelwerk durch spezifische Markierungen ausgezeichnet.