Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

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

Pawel Gerr

April 28, 2018
Tweet

More Decks by Pawel Gerr

Other Decks in Programming

Transcript

  1. Pawel Gerr
    Softwarearchitekt bei Thinktecture AG
    @pawelgerr
    [email protected]
    https://thinktecture.com
    2

    View full-size slide

  2. ▪ Legacy Anwendungen im Kontext
    ▪ Architekturansatz
    ▪ Low Level API zum Wrappen von Legacy Anwendungen
    ▪ Kommunikation zwischen Web API und Low Level API
    3

    View full-size slide

  3. (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

    View full-size slide

  4. 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

    View full-size slide

  5. 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

    View full-size slide

  6. 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

    View full-size slide

  7. Transition in die neue Welt
    Legacy Anwendung
    Web API
    Kapselung einer Legacy Anwendung
    hinter einer Web API
    Abhängigkeiten
    Internet/Intranet
    Clients
    8

    View full-size slide

  8. Legacy Anwendung
    Web API
    Low Level API
    Kapselung der Legacy Anwendung
    9

    View full-size slide

  9. 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

    View full-size slide

  10. 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

    View full-size slide

  11. 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

    View full-size slide

  12. 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

    View full-size slide

  13. • 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

    View full-size slide

  14. • 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

    View full-size slide

  15. • 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

    View full-size slide

  16. • 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

    View full-size slide

  17. • 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

    View full-size slide

  18. Web API ⟷ Low Level API
    Web API
    Low Level API
    19

    View full-size slide

  19. • 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

    View full-size slide

  20. • 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

    View full-size slide

  21. • 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

    View full-size slide