ManoMano ist der größte Marktplatz für Produkte und Dienstleistungen im DIY-, Garten- und Heimwerkersektor in Europa. Unsere digitale Plattform ermöglicht es uns, Ihnen Produkte, Dienstleistungen und Ratschläge zu bieten, die genau auf Sie zugeschnitten sind. Aus diesem Grund investieren wir jeden Tag in die besten Technologien. Deshalb haben wir uns auch dazu entschieden, alles selbst zu entwickeln und ManoMano zu einem europäischen Tech-Leader zu machen.
Steigerung der Produktivität für Testingenieure
Die System Reliability Engineering (SRE) Funktion bei ManoMano ist entscheidend für unsere Fähigkeit, mit einer Geschwindigkeit zu innovieren, die es dem Unternehmen ermöglicht, sein derzeitiges Wachstum aufrechtzuerhalten.
Ein Beispiel, über das wir in diesem Beitrag sprechen werden, ist ein Entwicklungsteam bei ManoMano, das sich auf das Benchmarking und die Leistungstests des ManoMano-Stacks konzentriert. Dies umfasst die Web- und Mobile-Erfahrungen sowie Backend-Systeme. Das SRE-Team hat die Aufgabe, diesen Testentwicklern eine serverlose Event-basierte Erfahrung zu bieten, die es ihnen ermöglicht, Code auszuführen, wenn bestimmte spezifische AWS-Events auftreten. Zum Beispiel schreiben Benchmark-Tests Ergebnisse in den Amazon Simple Storage Service (AWS S3). Die Testentwickler möchten diese Ergebnisdateien mit Code verarbeiten, der in Sprachen wie Node.js geschrieben ist, sobald sie verfügbar sind.
Minimierung der Bindung an einen Anbieter und Optimierung der Ressourcennutzung
ManoMano läuft auf AWS, aber wir minimieren die Bindung an einen Anbieter, indem wir uns gegen die Verwendung von FaaS-Lösungen wie Lambda entschieden haben. Wir möchten auch eine einheitliche Art und Weise haben, um CI/CD-Workflows und damit verbundene Sicherheitsfragen zu handhaben. Durch die Verwendung von Containern für alle Anwendungen können wir dies erreichen, anstatt Workflows und Sicherheitspraktiken über verschiedene Berechnungsabstraktionen wie Container, FaaS und EC2 zu verteilen.
Neben dem oben beschriebenen Testfall hat ManoMano Hunderte von Microservices, die verschiedene geschäftliche Anforderungen erfüllen, und sie laufen alle auf AWS EKS. Viele dieser Dienste sind lang laufend und immer aktiv, aber die Frage ist, ob sie wirklich 24/7 laufen müssen. Rechtfertigt ihre Nutzung eine kontinuierliche Beanspruchung von Rechenressourcen und die damit verbundenen Kosten?
Als wir genauer nachforschten, stellten wir fest, dass viele unserer lang laufenden Dienste nur wenige Anfragen pro Tag bearbeiten. Andere verbringen die meiste Zeit ungenutzt und warten auf ein Ereignis in einem anderen System. Wir wollten die Dinge so ändern, dass die Dienste nur dann ausgeführt werden, wenn sie gebraucht werden.
Eine Event-getriebene Plattform, die alle Anforderungen erfüllt
Das SRE-Team entwickelt eine ereignisgetriebene Architektur, die Ereignisse von verschiedenen AWS-Services sammelt, in einen zentralen Broker einliest und Entwicklern ermöglicht, sich für bestimmte Ereignisse anzumelden und diese in ihrem Code zu verarbeiten. Entwickler werden nicht durch Infrastruktur- und Sicherheitsfragen belastet, die durch die Plattform abstrahiert werden. Skalierung auf null durch Knative ist ein wichtiger Teil der Lösung, der es Workloads ermöglicht, ihren Ressourcenverbrauch je nach Belastung anzupassen, einschließlich einer Belastung von 0. Dies kann erhebliche Einsparungen ermöglichen, wenn man die Anzahl der Teams berücksichtigt, die Workloads bereitstellen, die nicht rund um die Uhr laufen müssen.
Das SRE-Team von ManoMano zentralisiert AWS S3-Ereignisse in einer gemeinsamen Simple Queue Service (SQS) Warteschlange, um einen einzigen Punkt zu haben, von dem aus sie in einen Kubernetes Cluster (EKS) eingelesen werden können. Der TriggerMesh SQS-Quelle wird als Ereignisquelle verwendet, die SQS-Ereignisse in eine Reihe von Knative Brokern drückt, die nach Mandanten (Anwendungsbereichen) geroutet und organisiert werden.
Entwicklern wird eine Helm Chart-Vorlage zur Verfügung gestellt, mit der sie einige wichtige Parameter für Knative Serving und Eventing Triggers anpassen können, z.B. die gewünschten Ereignistypen, die sie konsumieren möchten, und sie können auch ihren Funktionscode bereitstellen. Derzeit werden nur AWS S3-Ereignisse als Teil dieses ersten Anwendungsfalls unterstützt.
Die CI/CD-Plattform übernimmt den Rest:
- Buildet und deployt den Entwicklercode als containerisierte Knative Services auf K8s.
- Erstellt einen Knative Eventing Trigger, um die Ereignisse an den Container zu übermitteln.
Weniger CO2 und eine bessere Entwicklererfahrung
Bei ManoMano bemühen wir uns, unsere IT-Ausgaben und unseren CO2-Fußabdruck so gering wie möglich zu halten.
Die Kombination aus Knative und TriggerMesh ermöglicht es uns, die Anzahl der ungenutzten Container zu reduzieren, die wertvolle Rechenressourcen verschwenden, und den Entwicklern gleichzeitig eine einfache Möglichkeit bieten, ihren Code bereitzustellen. Entwickler können nun serverlose, ereignisgesteuerte Anwendungen erstellen, die nur dann ausgeführt werden, wenn sie benötigt werden, als Reaktion auf Ereignisse, die in Echtzeit erfasst und geroutet werden.
Folgen Sie dem ManoMano Tech-Team auf Twitter und schauen Sie sich ihre Veröffentlichungen auf Medium an.
