Legacy Anwendungen ver-Service-fizieren mit ASP.NET Core

Transcript

2. Pawel Gerr Softwarearchitekt bei Thinktecture AG @pawelgerr pawel.gerr@thinktecture.com https://thinktecture.com 2
3. ▪ Legacy Anwendungen im Kontext ▪ Architekturansatz ▪ Low Level API zum Wrappen von Legacy Anwendungen ▪ Kommunikation zwischen Web API und Low Level API 3
4. (wertungsfreie) Definition ☺ Eine Softwareanwendung ... • nicht selten mehrere Dekaden alt • bewährte Lösung für ein bestimmtes Problem • recht groß, komplex und monolitisch • historisch gewachsen 4
5. Probleme • Veraltete Technologie • Kein Support mehr (d.h. keine Secury Updates, Bugfixes) • Keine neuen Features • Schwieriger passende Entwickler zu finden • Softwarearchitektur nicht zeitgemäß • Schlechte Dokumentation • Wenige Mitarbeiter können die Anwendung erweitern/warten • Es sind eher genau 1 Mitarbeiter • Stehen ggf. kurz vor dem Rentenalter • Muss evtl. auf dedizierter Hardware oder Betriebssystem laufen 5
6. Gründe für die Abschaffung • Neue Betriebsabläufe und Geschäftsmodelle • Neue Anforderungen seitens der Kunden • Neue gesetzliche Vorgaben (wie Datenschutz, das Recht auf Vergessen, etc) • Interoperabilität mit anderen Systemen (bessere API) • Zeitgemäßes UI / UX • Martkanteile vergrößern • Neue Zielgruppen (bspw. kleine und mittelständische Unternehmen oder gar Endabnehmer) • Unterstützung von neue Plattformen (wie mobile Apps oder Web Anwendungen) Ist in der Regel jedoch nicht möglich, weil ... 6
7. Gründe gegen die Abschaffung • Hohe Kosten • Neues Personal und/oder Schulungen • Tools, Consulting • Hoher Zeitaufwand • Ggf. Reverse Engineering der eigenen Anwendung notwendig (da keine Doku etc) • Viele Randbedingungen, versteckte Funktionalitäten • Hohes Risiko • Keine Unit-/Integration-Tests • Keine 100% Abwärtskompatibilität (u.a. für bestehende Partner) Keine (sofortige) Abschaffung möglich, aber neue Features brauchen wir jetzt ... 7
8. Transition in die neue Welt Legacy Anwendung Web API Kapselung einer Legacy Anwendung hinter einer Web API Abhängigkeiten Internet/Intranet Clients 8
9. Legacy Anwendung Web API Low Level API Kapselung der Legacy Anwendung 9
10. Schnittstellenarten Schnittstellenarten der Legacy Anwendung • REST, SOAP, RPC • Message Queue (RabbitMQ, MSMQ, Kafka, etc) • Programmbibliothek (bspw. native Assembly geschrieben in C++) • Import der Bibliothek per Hand • .NET-Bibliothek von einem Tool, wie SWIG (http://www.swig.org), generieren lassen Legacy Web API Eigener Prozess P/Invoke [DllImport("MyNativeLib", EntryPoint = "GetNextRandomNumber")] public static extern int GetNextRandomNumber(IntPtr random); 10
11. Empfehlungen (1) • Defensive Programmierung (generell empfehlenswert, aber hier ganz besonders) • Eingabeparameter prüfen • Ausgabe prüfen • Wichtige Ereignisse (i.d.R. Fehlerfälle) im Zweifelsfall ... • Loggen reicht nicht aus • Behandeln nur wenn der Fall 100% klar ist • Ggf. an den Aufrufer zurückgeben • Das Laden der Assembly in den Hauptprozess nicht empfehlenswert • Bestimmte Exceptions können den gesamten Prozess terminieren (Corrupted State Exceptions *) • Bestimmter Typ ist nur 1 Mal pro Prozess erlaubt, d.h. nur 1 Berechnung gleichzeitig möglich * https://msdn.microsoft.com/en-us/magazine/dd419661.aspx#Four Legacy Web API 11
12. Empfehlungen (2) • Logs der Legacy Anwendung nach .NET umleiten Legacy Web API typedef void(__stdcall * ProgressCallback)(const char* message); __declspec(dllexport) void __stdcall do(ProgressCallback progressCallback); [UnmanagedFunctionPointer(CallingConvention.StdCall)] public delegate void ProgressCallback(string message); [DllImport("MyNativeLib.dll")] public static extern void do(ProgressCallback progressCallback); C++ .NET 12
13. startet pro Anfrage Prozess pro Anfrage • Hauptprozess ist sicher vor der Legacy Anwendung • Aber, langsamere Abarbeitung der Anfragen • Starten eines Prozesses • Das Laden und Initialisieren der Anwendung • Ausführen der Anfrage • Aufräumarbeiten der Anwendung • Beenden des Prozesses Optimierung der Dauer auf Kosten von Speicher möglich ... Kind-Prozess Legacy Hauptprozess Legacy Web API 13
14. • Hauptprozess hält mehrere Prozesse vor • Kostet mehr Speicher • Wird oft in Kauf genommen zwecks besserer Ausführungszeit • Schnelle Abarbeitung der Anfragen aus dem Pool • Aber, starten von neuen Prozessen belastet das System Reduzierung der Systemlast durch Wiederverwendung der Prozessen empfehlenswert ... Hält vor; startet bei Bedarf Vorhalten von Prozessen Hauptprozess Kind-Prozess Legacy Kind-Prozess Legacy Kind-Prozess Legacy Legacy Web API 14
15. • Schonung der Systemresourcen • Automatisches Load Balancing / Throttling • Aber, ggf. Probleme mit Memory Leaks • Überwachung der Kind-Prozesse • System.Diagnostics.Process • PrivateMemorySize64 • PagedMemorySize64 • TotalProcessorTime • HandleCount, etc. • System.GC.GetTotalMemory(false) • System.Diagnostics.Stopwatch Hält vor; startet bei Bedarf Wiederverwendung von Prozessen Kind-Prozess Legacy Kind-Prozess Legacy Kind-Prozess Legacy Legacy Web API Hauptprozess Prozess-Pool Manager 15
16. • Standard-Input / Standard-Output (Console.In / Console.Out) • HTTP / TCP / Sockets • Shared Memory • Reserviert eine Speicherbereich mit bestimmter Größe • Eignet sich gut für das Arbeiten an gemeinsam genutzen Objekten • Named Pipes • Eignet sich gut für Request-Response Muster • Datentransfer via Streams Interprozesskommunikation (IPC) Legacy Web API Großer Overhead 16
17. • Vollduplex-Kommunikation zw. Hauptprozess und dem Kind-Prozesse • Hauptprozess bestimmt die Namen der Pipes (bspw. neue GUID generieren) • Namen werden als Kommandozeilenargumente an Kind-Prozess übergeben • Freie Wahl des Serialisierungsmechanismus, wie z.B. • Protobuf, Message Pack (Performance) • JSON (Flexibilität) • PipeTransmissionMode.Message wird unter Linux (noch) nicht unterstützt • Eigenen Marker definieren (analog zu boundary in einer multipart Nachricht) – spart Ressourcen • Pro Nachricht wird zum Gegenpart neu verbunden – spart Implementierungsaufwand • Reactive Extensions (Rx.NET *) vereinfachen die Implementierung IPC via Named Pipes Legacy Web API 17 * https://github.com/Reactive-Extensions/Rx.NET
18. • Abstraktion für Kind-Prozesse schaffen (d.h. für System.Diagnostics.Process) • Möglichst wenig Logik im Kind-Prozess • Hauptprozess sollte Standard-Output und Standard-Error bspw. in einen Logger umleiten (Logs der Kind-Prozesse auch) • Kind-Prozesse sollen sich terminieren, wenn Hauptprozess terminiert (Event Process.Exited) • IPC/RPC- Alternativen • gRPC: https://grpc.io • MagicOnion: https://github.com/neuecc/MagicOnion Empfehlungen Legacy Web API 18
19. Web API ⟷ Low Level API Web API Low Level API 19
20. • Einfach zu Implementieren • Nicht immer möglich • Legacy Anwendung braucht ganz bestimmte Hardware (Rechenzentrum) • Web API soll auf einem anderen OS oder Hardware laufen • Aus Kostengründen • Unabhängiges Deployment gewünscht In-Process ⟷ Prozess Web API Low Level API Web API LL API 20
21. • Eigener Prozess für Low Level API (d.h. Legacy Anwendung) • Kommunikationsart wird unter anderem vom Kunden vorgegeben, ansonsten • REST • Message Queue • etc. Verteiltes System ⟷ System Web API System Low Level API Web API LL API 21
22. • Abstraktion schaffen • Ermöglicht das Umschalten zwischen In-Proc und Out-of-Proc • Einfacheres Aufsetzen der Entwicklungsumgebung bei In-Proc • Vereinfacht das Testen • Neue Guid als Korrelation zwischen Request und Response • Bei Request-Response Muster den Timeout nicht vergessen Empfehlungen ⟷ Web API LL API 22
23. pawel.gerr@thinktecture.com Kontaktdaten