Patrick Schnell Selbstständig

„Durch die Auslagerung und Zentralisierung von Anwendungskonfigurationen sowie der gleichzeitigen Nutzung der aufgeführten Konfigurationspatterns entstehen weitreichende Möglichkeiten, um Anwendungen flexibler zu gestalten.“

Softwareumgebungen werden durch verschieden eingesetzte Techniken, wie z. B. Microservices oder die Cloud immer fragmentierter und müssen auf unterschiedlichsten Plattformen bestehen. Mittels zentraler Konfiguration der Anwendungen lässt sich das Verhalten von Anwendungen mit wenigen Klicks weltweit steuern.

In den letzten zehn Jahren hat sich das Entwickeln von Software in großem Umfang verändert. Aus einfachen Datenbank- und Clientanwendungen sind diverse einzelne Bausteine in Form von Microservices entstanden. Auf einem einzelnen Server installierte Anwendungen wurden virtualisiert, später in die Cloud verlagert und werden heute als Container gehostet. Im Verlauf dieser Entwicklung entstand zudem ein neues Projektmanagementwesen. Weg von den starren pflichten- und lastenheftgetriebenen Entwicklungswegen, hin zu dynamischen und agilen Methoden. All diese Entwicklungen haben ihre Vorteile, aber selbstverständlich auch ihre Nachteile. Mit den konventionellen Entwicklungsverfahren wurden vor der Inbetriebnahme einer Anwendung langfristige Testphasen eingeplant, und neue Releases und Funktionen kamen nur in festdefinierten Zyklen. Heute erfordert der Markt immer schnellere Anpassungen an eine Anwendung – egal ob bei einer individuellen Anwendung, einer gesamte Systemlandschaft für einen einzelnen Kunden, oder einer App oder Webanwendung für tausende Nutzer.

Genau diese Anforderungen stehen oft im Gegensatz zu dem eigentlichen Entwicklungsziel – der Inbetriebnahme. Ob in einer kleinen Softwareagentur oder einem großen IT-Konzern, der Fokus eines Projekts wird auf diesen Zeitpunkt gesetzt. Die Frage, welche Herausforderungen in der Zukunft und während des Betriebs einer Anwendung auftreten können, wird hierbei, wenn überhaupt, oft nur mit niedriger Priorität beantwortet. Das gilt auch für Mechanismen, die Regeln sollen, wie eine Anwendung konfiguriert wird. Hierbei stellt sich neben der Frage, was für eine langfristige Lebensdauer der Anwendung überhaupt konfigurierbar gestaltet werden muss, auch die Frage, wie das technisch realisiert wird.

Was ist an konventionellen Konfigurationsdateien auszusetzen?

Bei der Frage der technischen Umsetzung wird in den meisten Fällen auf Framework- oder plattformspezifische Mechanismen zurückgegriffen. Im .NET-Umfeld ist dies bekanntermaßen die typische app.config-Datei. Sie ist das schnellste Mittel zur Umsetzung einer Anwendungskonfiguration. Kurzfristig gesehen hat diese selbstverständlich ihre Vorteile, z. B. ist sie in erster Linie dynamisch erweiterbar und kann von jedem halbwegs geübten Administrator editiert werden.

Warum ist also das Verwalten von Konfigurationen als Dateien nicht unbedingt optimal und welche Alternativen existieren hierzu? Nehmen wir das Beispiel einer Geschäftsanwendung, die bei diversen Kunden in unterschiedlichsten Versionen und Ausprägungen läuft. Diese Anwendung ist weltweit verteilt und nicht in einer Infrastrukturumgebung, die man als Entwickler oder Dienstleister beeinflussen kann. Ist diese Anwendung einmal ausgerollt und entscheidet man sich dann dafür, einen Konfigurationsparameter zu ändern, ist hierfür ein weiteres Deployment notwendig. Somit kann eine zum Beispiel fehlerhafte oder nicht optimale Konfiguration bei den Kunden zu Fehlern führen, die wiederum als Supportanfragen beim Entwickler landen. Der entsprechende Benutzer oder Kunde muss sich also bemühen, die Anwendung zu aktualisieren oder lässt es durch den Entwickler bzw. den Support leisten.

Den vollständigen Artikel lesen Sie in der Ausgabe:

Windows Developer 4.19 - "Zentral zwischen Server und Cloud"

Alle Infos zum Heft
579882769Anwendungsverhalten mit Congether zentral steuern
X
- Gib Deinen Standort ein -
- or -