Bayer Crop Science: AWS-Plattform für KI-Pflanzenschutz, 30 % weniger Wartung und 20 % weniger Bugs

Bayer Crop Science erweitert das klassische Pflanzenschutz-Portfolio um digitale Produkte. Im Crop Protection Innovation Lab steht die digitale Gelbschale MagicTrap im Fokus: eine sensorbasierte Falle erfasst Ungezieferbelastung auf dem Feld, lädt Bilder in die Cloud, lässt sie von KI-Modellen auswerten und liefert Landwirten über eine App konkrete Handlungsempfehlungen. Parallel lief bis April 2025 ein zweiter Use-Case: automatisierte Drohnen-Erfassung des Feldzustands mit KI-basierter Bildauswertung. Endkunden sind Landwirte in nahezu allen EU-Ländern, die manuelle Felderfassung automatisieren wollen. Für den Cloud- und Platform-Lead im CPIL war klar: ohne eine skalierbare, wartbare AWS-Backbone-Plattform multipliziert jeder neue Use-Case die Komplexität statt den Impact. Pexon Consulting übernimmt seit Juli 2024 die Rolle Senior Cloud plus Python Backend Engineer im 9-köpfigen Team und trägt genau diese Plattform-Vereinheitlichung.

Die Service-Landschaft war historisch gewachsen: über 30 Python-AWS-Lambdas und 12 Go-AWS-Lambdas, jeweils leicht anders aufgebaut, mit abweichenden Auth-, Logging-, Error- und Deployment-Mustern. Jede Änderung erforderte tiefes Service-Know-how statt teamweiter Standards. Veraltete Anforderungen in vielen Services entsprachen nicht mehr dem aktuellen Geschäftsmodell rund um MagicTrap und KI-Bildpipelines. Für Backend-Teams bedeutete das: Wartungszeit statt Feature-Zeit. Pexon priorisierte deshalb nicht weitere Einzellösungen, sondern die Reduktion kognitiver Last über Domain-Grenzen, Programmiersprache und API-Konventionen. Der Trade-off war bewusst: kurzfristig Migrationsaufwand, mittelfristig deutlich geringere Kosten pro Change und weniger Produktionsbugs.

Die Plattform muss globale Verfügbarkeit und extreme Lastprofile tragen: in der Feldsaison werden täglich zehntausende Bilder hochgeladen und über AI-Pipelines analysiert, dazwischen ist die Last deutlich ruhiger. Klassische, fest dimensionierte VM-Stacks wären teuer und träge. Gleichzeitig sollten neue Märkte und Funktionen ohne lineare Aufstockung der Operations-Kapazität angebunden werden können. Heterogene GraphQL-Endpoints und fehlende Domain-Trennung erschwerten klare Teamzuständigkeiten und API-Verträge. Für den Head of Platform war Skalierung damit keine reine Compute-Frage, sondern eine Architekturfrage: Serverless-First auf AWS, asynchrones Messaging und klare Bounded Contexts nach Domain-Driven Design, damit Spitzenlast und Feature-Growth denselben Backbone nutzen.

AWS DocumentDB als Persistenz trug Betriebskomplexität und Skalierungseigenschaften, die zum Serverless-Zielbild der Plattform nicht passten. Duplizierte Setup-, Auth- und Plumbing-Logik in den Lambdas erhöhte die Fehleranfälligkeit. Code-Quality hing stark von manueller Review-Disziplin ab statt von automatisierten Gates über alle Services. In einer Landschaft mit 40+ Lambdas ist das kein Cosmetik-Thema: Inkonsistente Patterns erzeugen genau die Bug- und Wartungslast, die später als 20 % bzw. 30 % Reduktion messbar wird. Pexon adressierte Persistenz, SDK-Abstraktion und CI/CD parallel, damit Architektur-Refactoring und Delivery-Geschwindigkeit sich nicht gegenseitig blockieren.