Als CEO und Mitbegründer von IOpipe arbeitet Adam Johnson sowohl mit einzelnen Entwicklern als auch mit Engineering-Teams in globalen Unternehmen zusammen, um Echtzeit-Einblicke in das detaillierte Verhalten ihrer serverlosen Anwendungen zu erhalten.

Entsprechend Das E-Book „The New Stack“ von 2018 Die Nutzung serverloser Architekturen ist seit 2017 um 75 Prozent gestiegen. Allerdings nennen Entwickler weiterhin Bedenken hinsichtlich Anwendungsleistung, Risiko und Überwachung als Nachteile beim Aufbau einer serverlosen Architektur.

Trotz der Fortschritte, die im letzten Jahr bei Observability-Tools gemacht wurden, sind Warnmeldungen bei Leistungsanomalien und Benutzerunterbrechungen eine entscheidende, aber immer noch übersehene Komponente für Entwicklungsteams, um serverlose Anwendungen zuverlässig bereitzustellen. Vor diesem Hintergrund hat Adam in diesem Q&A einige der Herausforderungen beschrieben, denen er in dieser Branche begegnet ist, sowie Best Practices und technische Tipps.

F: Inwiefern unterscheidet sich die Überwachung serverloser Anwendungen von der Überwachung herkömmlicher Architekturen?

A: Der Hauptunterschied bei der serverlosen Überwachung besteht darin, dass der Fokus stärker auf der Geschäftslogik liegt, die durch das System fließt, und weniger Wert auf die Infrastrukturseite gelegt wird. Bei serverlosen Architekturen liegen Infrastrukturprobleme größtenteils außerhalb Ihrer Kontrolle und werden von den Cloud-Anbietern behandelt, die die Function-as-a-Service (FaaS)-Plattform betreiben. Dadurch haben Unternehmen mehr Freiraum, sich auf die Auswirkungen auf das Geschäft zu konzentrieren.

Einige der großen E-Commerce-Marken, die IOpipe verwenden, erstellen beispielsweise Warnmeldungen auf Grundlage des erwarteten Bestellvolumens. Wenn es also zu einem unerwarteten Rückgang (oder Anstieg) der Bestellungen kommt, werden sie innerhalb von Sekunden benachrichtigt, wenn etwas nicht in Ordnung ist.

Obwohl die Entwicklung auf Serverless-Basis Vorteile in Bezug auf Geschwindigkeit und Kosten bietet, haben viele Entwickler immer noch Probleme, das Verhalten ihrer Serverless-Anwendungen sichtbar zu machen. Wie können Sie beispielsweise Millionen von Aufrufen verfolgen, um herauszufinden, welche Benutzer von einem Leistungsproblem betroffen waren? Wie können Sie bei einem Problem schnell die fehlerhafte(n) Funktion(en) isolieren, um Geschäftsunterbrechungen zu minimieren?

Herkömmliches Monitoring ist nicht unbedingt darauf ausgelegt, die unterschiedlichen Herausforderungen serverloser Architekturen zu bewältigen oder die Chance der Entwickler und DevOps-Teams zu maximieren, Infrastrukturmetriken in Geschäftserkenntnisse umzusetzen, wenn sie die Leistungs- und Skalierungslasten auf die Cloud-Anbieter verlagern.

F: Was sind einige der Vor- und Nachteile von serverlosen gegenüber monolithischen Anwendungen?

A: Der größte Vorteil von Serverless gegenüber monolithischen Anwendungen besteht darin, dass Entwickler sich ganz auf die Erstellung und Bereitstellung von Geschäftslogik konzentrieren können. So können Unternehmen ihren Kunden schneller einen Mehrwert bieten. Entwickler müssen keine Zeit mehr mit dem Codieren und Konfigurieren der Infrastruktur verbringen, um Skalierungsereignisse zu planen. Die Skalierung ist sofort einsatzbereit. Neben der schnelleren Bereitstellung wird Ihnen bei Serverless nur das berechnet, was Sie tatsächlich nutzen. Es gibt also in der Regel erhebliche Kostenvorteile. Unternehmen berichten von Einsparungen von bis zu 90 %, wenn sie von VMs und Containern abrücken.

Der größte Nachteil besteht darin, dass Sie ein verteiltes System ausführen, wenn Sie Ihren Parallelitätsgrad nicht auf 1 setzen. Dies kann neue Herausforderungen mit sich bringen, insbesondere wenn es darum geht, diese Systeme beobachtbar zu machen. Glücklicherweise gibt es eine Reihe von Tools der nächsten Generation, die detaillierte Einblicke in serverlose Anwendungen bieten und sogar die Sichtbarkeit älterer monolithischer Anwendungen verbessern.

F: Was sind die häufigsten Leistungsprobleme bei serverloser Architektur?

A: Eines der am meisten diskutierten Probleme im Zusammenhang mit der Leistung von Serverless-Systemen ist Kaltstarts , wenn es beim Hochfahren eines neuen Containers zu einer kleinen Verzögerung kommt. Glücklicherweise wurden die Auswirkungen von Kaltstarts bei Sprachen wie Node.js und Python in AWS Lambda drastisch auf einstellige Millisekunden reduziert. Bei anderen Sprachen wie Java können Kaltstarts immer noch erhebliche Auswirkungen auf die Leistung haben.

Serverlose Beobachtungstools wie IOpipe können jedoch Einblick in die Kaltstartleistung geben. So können Benutzer die tatsächlichen Auswirkungen besser verstehen und feststellen, ob es sich lohnt, sie zu optimieren.

F: Welche Standardwarnungen sollten Unternehmen oder Entwickler, die neu im Serverless-Bereich sind, von Anfang an implementieren?

A: Die erste Warnung, die IOpipe-Kunden normalerweise einrichten, betrifft Anwendungsfehler. Viele Kunden richten Warnungen zur Fehlerrate ihrer serverlosen Anwendungen ein, damit sie benachrichtigt werden können, sobald die Fehlerrate ihre Komfortschwelle überschreitet.

Eine weitere sehr empfehlenswerte Warnung ist die Drop-In-Aufrufung von Funktionen, die voraussichtlich eine bestimmte Anzahl von Malen pro Zeitraum ausgeführt werden. Wenn also erwartet wird, dass eine Funktion mindestens einmal pro Tag ausgeführt wird, sollten Sie eine Warnung einrichten, die Sie benachrichtigt, wenn die Funktion an diesem Tag nicht ausgeführt wird.

Bei serverlosen Anwendungen, die einen Datenstrom oder Datenstapel verarbeiten, deren Volumen relativ vorhersehbar ist, ist das Einrichten von Warnmeldungen zu oberen und unteren Schwellenwerten der Aufrufanzahl eine hilfreiche Methode, um zu erkennen, wenn in der Datenpipeline ein Problem vorliegt.

F: Wie sollten Entwickler oder DevOps-Teams mit dem Debuggen der zunehmenden Menge an Funktionsprotokollen umgehen, die bei Serverless zwangsläufig auftreten?

A: Wenn Sie Zeit in die Instrumentierung serverloser Anwendungen mit strukturierten Protokollen und Bezeichnungen investieren, müssen Sie sich nie wieder durch Protokolldateien wühlen. Ein kleiner Vorabaufwand kann bei auftretenden Problemen Stunden oder sogar Tage wertvoller Debugging-Zeit sparen.

F: Wie integrieren Entwickler serverloses Monitoring in ihr bestehendes PagerDuty -Konto?

A: IOpipe bietet eine native Integration mit PagerDuty. Mit nur wenigen Klicks können Entwickler über PagerDuty benachrichtigt werden, wenn ihre Alarme ausgelöst werden.

In Zusammenarbeit mit PagerDuty und um serverlose Beobachtung und Überwachung für Organisationen wie Rackspace, Matson und Comic Relief bereitzustellen, hat IOpipe kürzlich eine Überarbeitung seiner serverlosen Warnfunktionen für Python-, Node.JS-, Go- und Java-Laufzeiten auf AWS Lambda veröffentlicht.

Möchten Sie mehr erfahren? Schauen Sie sich die PagerDuty – IOpipe-Integrationshandbuch.