Serverless Vendor-Lock-in: So mindern Sie Ihre Bedenken

Die Serverless-Architektur ist die unvermeidliche Zukunft für IT-Verantwortliche. Die wichtigsten Akteure im Technologiesektor bewegen sich in Richtung Cloud-Plattformen. Da die Entwickler nicht mehr für eine bestimmte Betriebssystemplattform oder Hardware-Infrastruktur schreiben müssen, kann der Cloud-Anbieter wichtige Rechenressourcen bereitstellen und verwalten.

Aber es gibt einen Haken: Es besteht das Risiko des sogenannten „Vendor Lock-in“. Dies wird für Unternehmen zu einem großen Problem, da es schwierig wird, ohne erheblichen Aufwand und Kosten auf die Plattform eines anderen Anbieters zu wechseln. 

Aber ist das wirklich ein Problem, über das Sie sich Sorgen machen müssen, oder ist es nur eine von konkurrierenden Anbietern erzeugte Erzählung? Finden wir es heraus! 

Wie kommt es zu einem Serverless-Vendor-Lock-in?

Wenn ein Serverless-Computing-Dienst eingeführt wird, ist das Unternehmen an einen bestimmten Anbieter für die Technologieimplementierung gebunden und findet es schwierig, in Zukunft einfach auszusteigen. Große Hindernisse entstehen aufgrund mangelnder Standardisierung bei der Einführung von Cloud Computing. Da es fast keine Analysen oder Studien gibt, ist es schwierig, die Komplexität der Vendor-Lock-in-Probleme abzuwägen. Dies führt dazu, dass ahnungslose Kunden häufiger in die Falle tappen. Um dies zu bekämpfen, sollten Unternehmen die potenziellen Risiken eines Vendor-Lock-in im Auge behalten, bevor sie in eine Serverless-API investieren. 

Wie viele Sorgen sollten Sie sich machen?

Aufmerksame Experten haben eine andere Sicht auf diese Lock-in-Situation. Ihnen zufolge liegt das Problem derzeit nicht wirklich im Kontext von Serverless Computing. Sie stehen Giganten wie Amazon skeptisch gegenüber, da diese Probleme schüren, um neue Marktteilnehmer zu sabotieren. Zweitens hat die relativ neue und fragmentierte Technologie Serverless Computing eine unreife Kundschaft, die sich zu sehr darauf verlässt. Stattdessen sollten sich Unternehmen erst nach gründlicher Recherche und dem Einholen von Angeboten verschiedener Anbieter für eine Plattform entscheiden. Anstatt auf mehrere Clouds zu setzen, können Sie dem Lock-in entgehen, indem Sie einen Allrounder finden. 

Zweidimensionale Lösungen

Wenn Sie es dennoch geschafft haben, in der Vendor-Lock-in-Situation stecken zu bleiben, gibt es zwei Arten von Lösungen, um die Ängste zu mildern:

Opportunitätsgewinn

Wenn Ihr Unternehmen beschließt, Serverless Computing einzuführen, dient dies als Chance, Ihren „Opportunitätsgewinn“ zu maximieren. 

Unter den verschiedenen Optionen wie Serverless Framework, Apex und Claudia.js ist es entscheidend, umfassend zu prüfen, welche für Sie am besten geeignet ist. Folgen Sie nicht der Masse, denn was für andere passt, muss für Sie nicht unbedingt genauso funktionieren. 

Auch Ihre Bewertung einer bestimmten Cloud-Plattform muss in naher Zukunft nicht mehr zutreffen. Angesichts des Aufkommens rasanter Technologien ist es zu früh, um irgendwelche Urteile zu fällen. Nutzen Sie dies stattdessen zu Ihrem Vorteil und investieren Sie Ihre Maut, indem Sie einen schnelleren Time-to-Market-Ansatz unterstützen, d. h. versuchen Sie nicht, die Tools neu zu erfinden und Cloud-nativ zu werden. 

Kosten minimieren

Selbst wenn Sie sich entscheiden, zu anderen Serverless-Anbietern zu wechseln, ist es möglich, die Migrationskosten zu minimieren. Wenn Sie die potenziellen Risiken des Lock-in berücksichtigen, können Ihnen diese drei Bereiche vor Schäden bewahren, die das Dach berühren:

Wählen Sie die Programmiersprache mit Bedacht

Der clevere Ausweg aus dem Dilemma ist die Wahl einer Programmiersprache, die von mehreren Anbietern unterstützt wird. Das bedeutet, dass Sie bei der Migration auf eine Plattform, die dieselbe Sprache verwendet, keine massiven Kosten und Anstrengungen auf sich nehmen müssen. Beispielsweise werden Sprachen wie NodeJS und Python nur von der Google Cloud Function unterstützt. Achten Sie im Voraus auf solche Einschränkungen und wählen Sie eine Sprache mit Bedacht aus.   

Architekturmuster der Anwendung

Die nächste große Herausforderung nach der Sortierung der gewählten Sprache ist die Verwaltung des Ökosystems der Cloud. 

Ein gutes Architekturmuster dient als Basis, die Migrationen von Lambdas erleichtert. Wenn der Basiscode bei der Migration gleich bleibt, sinken die Werte automatisch. Das bedeutet, dass die einzige Änderung beim Schreiben und Anschließen neuer Adapter erfolgt. Unternehmen neigen dazu, die Bedeutung des Architekturmusters zu ignorieren, da sie die Tatsache übersehen, dass der Kern vom AWS-Ökosystem isoliert ist. Das macht ihn unabhängig und reduziert auch den anfallenden Wert. 

Standardisieren Sie die Technologie

Ebenso kann ein HTTP-Webserver von fast allen Anbietern unterstützt werden. Oder Sie können im schlimmsten Fall Ihren eigenen installieren. Da dies die SPA stabil macht, sinkt das Angebot für Migrationen weiter. 

Der Frontend-Code wird ebenfalls durch HTTP während der Arbeit des Backends abstrahiert. Ein häufiger Anwendungsfall ist die Übersetzung von HTTP-Ereignissen in Lambdas mithilfe des AWS API Gateway. Die meisten Anbieter unterstützen solche Prozesse und eine umfassende Kostenreduzierung wird auf ein Minimum reduziert. 

Fazit

Bei den Vendor-Lock-in-Ängsten geht es eher um die extravaganten Ausgaben, die durch die Einhaltung von Branchenpraktiken leicht vermieden werden können. Es ist kein Traum mehr, Serverless mit niedrigen Migrationskosten einzuführen. Wenn Sie diese Praktiken anwenden, sind Sie jederzeit vor Täuschungen durch die Anbieter bei einer Migration geschützt. 

Haben Sie noch weitere Vorschläge? Teilen Sie Ihre Meinung in unseren sozialen Netzwerken: Twitter, Facebook und LinkedIn. Oder kontaktieren Sie uns unter [email protected].