Kolumne: Stropek as a Service

Schnittstellen zu Kunden außerhalb der Cloud
Keine Kommentare

Da ich in meiner Cloud-Beratungsarbeit immer wieder merke, dass Azure-Neulinge bei einigen grundlegenden Problemen nur auf die üblichen Lösungsansätze zurückgreifen, die man auch außerhalb der Cloud kennt, widme ich diese Kolumne dem Thema Cloud-Schnittstellen. Die Microsoft-Azure-Cloud bietet einige interessante Dienste, die die Umsetzung solcher Schnittstellen deutlich vereinfachen kann.

Wer SaaS-Lösungen für Geschäftskunden anbietet, der steht über kurz oder lang vor der Herausforderung, Schnittstellen zu IT-Systemen bei Kunden umsetzen zu müssen, die nicht in der Cloud liegen. Vielleicht muss man Stammdaten mit einem CRM-System abgleichen, das im Netzwerk des Kunden läuft. Möglicherweise braucht es einen Datenaustausch mit einer beim Kunden betriebenen Buchhaltung. In manchen Fällen ist man eventuell sogar selbst gezwungen, aufgrund gesetzlicher Rahmenbedingungen bezüglich Cloud-Nutzung eine hybride Softwarelösung zu erstellen, die zum Teil in der Cloud und zum Teil im Rechenzentrum der Kunden ausgeführt wird. Da ich in meiner Cloud-Beratungsarbeit immer wieder merke, dass Azure-Neulinge bei einigen grundlegenden Problemen nur auf die üblichen Lösungsansätze zurückgreifen, die man auch außerhalb der Cloud kennt, widme ich diese Kolumne dem Thema Cloud-Schnittstellen. Die Microsoft-Azure-Cloud bietet einige interessante Dienste, die die Umsetzung solcher Schnittstellen deutlich vereinfachen kann.

Die offensichtlichen Lösungen

Die simpelste Lösung ist, dass der Kunde eingehende Netzwerkverbindungen (Ingress Network Traffic) aus dem Internet freischalten kann und will. Vielleicht betreibt er schon heute Server, die aus dem öffentlichen Internet erreichbar sind und hat daher die dafür notwendige Netzwerk- und Firewallinfrastruktur. In diesem Fall ist das Thema schnell vom Tisch. Das Zielsystem, mit dem die SaaS-Lösung Daten austauschen soll, über das Internet erreichbar machen – und fertig. In den vielen Jahren, in denen ich Cloud-Lösungen baue, kann ich allerdings die Anzahl an Kunden, die solche Netzwerkverbindungen von außen zulassen, an einer Hand abzählen.

Die zweite, offensichtliche Lösung wäre ein VPN. Ich gehe an dieser Stelle davon aus, dass Sie keine Selbstbaulösung in Azure auf IaaS-Basis aufbauen wollen. Das ist zwar eine interessante Übung, in der Praxis aber nur in absoluten Ausnahmefällen sinnvoll. Microsoft bietet mit dem Azure VPN Gateway ein Netzwerk-Gateway-as-a-Service, mit dem man lokale Netzwerke sicher und nahezu wartungsfrei mit virtuellen Netzwerken in Azure verbinden kann. Die Azure-Kosten für VPN-Gateways sind für reine Datenschnittstellen gering. Sie liegen meistens im zweistelligen Euro-Bereich pro Monat. Die Lösung hat aber einen Haken: Sie erfordert sorgfältige Planung mit den Netzwerkadministratorinnen des Kunden. Der Kunde muss außerdem auf seiner Seite in Netzwerkinfrastruktur investieren (siehe auch [1]). Der Prozess ist also zeit- und ressourcenraubend. Insofern empfehle ich VPN-basierende Lösungen für SaaS-Schnittstellen nur bei besonders engen Kunden-Lieferanten-Beziehungen. Vielleicht bauen Sie eine sehr spezielle Nischenlösung, die nur eine Handvoll großer Kunden einsetzen, dann ergeben VPNs je Kunde möglicherweise Sinn. Eine Lösung für die breite Masse an mittelgroßen und kleinen Kunden sind sie nicht.

BASTA! 2021

Neuerungen in .NET 6.0 – das eine .NET, sie alle zu beherrschen

mit Dr. Holger Schwichtenberg (DOTNET-DOKTOR)

C# Workshop: — was kommt Neues mit C# 10 und .NET 6?

mit Rainer Stropek (timecockpit.com)

Funktionaler Code mit C# 9

Oliver Sturm (DevExpress)

 

App Service Hybrid Connections

Viele SaaS-Lösungen nutzen Web-Apps in Azure App Service. Wenn Ihre Software dazugehört, können Sie einfacher zu einem VPN für Datenschnittstellen kommen. Der entsprechende Azure-Dienst heißt Azure App Service Hybrid Connections [2]. Wir verwenden ihn in meiner eigenen Firma mit vielen Kunden seit Jahren und sind sehr zufrieden damit. Hier muss der Kunde eine von Microsoft bereitgestellte Software, den Hybrid Connection Manager (kurz HCM), bei sich installieren. Damit kann der Kunde selbst einstellen, welcher App-Service auf welche Server und Ports im Kundennetzwerk zugreifen können soll. Wir machen es meist so, dass es für jeden Kunden eine dedizierte App-Service-Web-App oder Serverless-Function-App gibt, in der der Code der Schnittstelle läuft und die entsprechend berechtigt wird. Der HCM baut eine Verbindung vom Kundennetz zu Azure auf (das basiert technisch auf einer Relay Hybrid Connection und wird noch genauer behandelt), und der App-Service kann auf die Kundenserver zugreifen, als würden sie netzwerktechnisch direkt danebenstehen. Der Verbindungsaufbau geschieht ausgehend vom Kundennetz über den Port 443 (Egress Network Traffic aus Sicht des Kunden). Die Firewalls des Kunden können daher ohne weiteres alle eingehenden Netzwerkverbindungen aus dem Internet blockieren.

Kostenmäßig sind Hybrid Connections sehr attraktiv. Der Abstimmungs- und Einrichtungsaufwand ist minimal. Laufende Kosten fallen (außer den üblichen Kosten für den Netzwerkverkehr, der bei Datenschnittstellen fast immer vernachlässigbar gering ist) keine an. Man muss aber bedenken, dass die Anzahl an Hybrid Connections abhängig vom Preisplan des Azure App Service limitiert sind (5 bei Basic, 25 bei Standard, 200 bei Premium [3]). Bei einer größeren Anzahl an Kundenschnittstellen muss man daher eventuell die Kosten zusätzlicher App Service Plans kalkulieren. Bis vor wenigen Monaten gab es in Azure die Einschränkung, dass Hybrid Connections für Linux App Services nicht verfügbar waren. Das hat sich im Juni dieses Jahres geändert. Sie werden jetzt für Windows und Linux unterstützt.

Message-Broker-basierende Lösung

Es gibt Kunden, die es generell nicht wollen, dass irgendeine Netzwerkverbindung aus der Cloud auf ihre internen Systeme zugreifen kann. Sie fürchten möglicherweise, dass die SaaS-Software oder der Schnittstellencode kompromittiert werden könnten. In diesem Fall greift man am besten auf einen Message Broker zurück, in Azure üblicherweise auf den Azure Service Bus. (Hinweis: Für hochfrequentes Messaging oder für IoT-Szenarien gibt es andere, besser geeignete Messaging-Lösungen in Azure, auf die hier nicht näher eingegangen wird.) Statt direkt von der SaaS-Lösung aus auf Kundensysteme zuzugreifen, kommuniziert man über Messages mit einer selbst zu entwickelnden Schnittstellenkomponente, die im Kundennetzwerk läuft. Wie beim zuvor erwähnten HCM braucht auch die Kontaktaufnahme vom Kundennetz zum Azure Service Bus nur ausgehende Netzwerkverbindungen (Ports 5671 für AMQP und 443). Eingehend können Firewalls den gesamten Netzwerkverkehr aus dem Internet blockieren. Der Nachteil einer Message-Broker-basierenden Lösung liegt auf der Hand: Man muss selbst Software schreiben, die im Kundennetz läuft, Nachrichten von der SaaS-Lösung entgegennimmt und sie in einer passenden Form an das Zielsystem weitergibt. Für manche Arten von Schnittstellen passt diese Kommunikationsform gut. Der Preis ist bei einer Schnittstelle über Service Bus selten ein Problem und verursacht typischerweise monatliche Kosten im ein- oder niedrigen zweistelligen Eurobereich.

Azure Relay Hybrid Connections

Ich habe oben bereits über App Service Hybrid Connections gesprochen. Es gibt in Azure einen zweiten Service, der Hybrid Connection im Namen trägt, jedoch anders funktioniert. Er heißt Azure Relay Hybrid Connections (hier kurz als Azure Relay bezeichnet). Azure Relay unterstützt die Kommunikation zwischen zwei Kommunikationspartnern – in unserem Fall einer SaaS-Lösung in Azure und einer selbst zu entwickelnden Schnittstellenkomponente im Kundennetz – über WebSockets und HTTP. Für .NET und Node.js stellt Microsoft spezielle Bibliotheken zur Verfügung, die das Programmieren mit Azure Relay besonders einfach machen. Das Protokoll ist aber offen und kann mit jeder Plattform verwendet werden, die WebSockets unterstützt. Bezüglich Firewall funktioniert Azure Relay sehr ähnlich wie App Service Hybrid Connections. Eingehend braucht der Kunde keine Ports auf seiner Firewall zu öffnen. Was den Entwicklungsaufwand betrifft, hat Azure Relay Ähnlichkeiten mit der oben erwähnten Service-Bus-basierenden Lösung, da man als SaaS-Anbieter eine eigene Schnittstellenkomponente für die Installation beim Kunden entwickeln muss. Das Kommunikationsprotokoll von Azure Relay ist jedoch ein ganz anderes als bei Service Bus. Man kann keine generelle Empfehlung für die eine oder andere Lösung abgeben. Es braucht eine projektspezifische Betrachtung der Vor- und Nachteile.

Preislich ist Azure Relay attraktiv, wenn man nur wenige Kunden anbinden will. Wenn man Schnittstellen für eine größere Anzahl an Kunden über Azure Relay abwickelt, muss man berücksichtigen, dass pro Relay-Verbindung gut 8 € pro Monat zu bezahlen sind. 5 GB Datentransfer sind darin enthalten, ein Überschreiten dieses Transfervolumens ist möglich, verursacht aber zusätzliche Kosten.

Eigenbaulösungen

Wenn man keine der oben erwähnten Varianten einsetzen will, kann man natürlich auf bidirektionale Protokolle wie gRPC oder SignalR setzen und beide Seiten der Kommunikation mit einer Plattform wie .NET entwickeln. Ich rate von diesem Weg jedoch eher ab, da das erstens eine Menge Entwicklungsaufwand nach sich zieht, und man zweitens die entsprechenden Server, die von Schnittstellenkomponenten auf Kundenseite angesprochen werden, in Azure betreiben muss. Das verursacht erst recht Kosten. Meiner Erfahrung nach sind die oben genannten fertigen PaaS- und Serverless-Dienste die bessere Wahl.

Unsere Redaktion empfiehlt:

Relevante Beiträge

Abonnieren
Benachrichtige mich bei
guest
0 Comments
Inline Feedbacks
View all comments
X
- Gib Deinen Standort ein -
- or -