Eine Zapier- oder Make-Automatisierung auf einen neuen Geokodierungs-Host migrieren
No-Code-Automatisierungen mit einem Geokodierungsschritt brauchen einen anderen Migrationsansatz als eigener Code. So gehen Sie bei diesem Wechsel vor.
Was die Abhängigkeit von einem einzigen kleinen Anbieter über Anbieterrisiken lehrt
Eine einzelne API-Abhängigkeit wird leicht übersehen, gerade weil sie lange Zeit still funktioniert. Ein Geokodierungsaufruf, der zwei Jahre lang jeden Tag korrekte Ergebnisse geliefert hat, fühlt sich nicht wie ein Risiko an, sondern wie ein gelöstes Problem. Sichtbar wird das Risiko erst an dem Tag, an dem sich auf der Seite des Anbieters etwas ändert, ob ein eingestellter Endpunkt, eine Umstellung der Preise, eine Übernahme des Unternehmens oder einfach ein Ausfall des Dienstes, und dann werden die Kosten dafür, keine Alternative bereitzuhaben, bereits in einer hektischen Notlösung bezahlt statt in einer geplanten Migration.
Kleinere Anbieter tragen dieses Risiko stärker als größere, nicht weil sie im Alltag weniger zuverlässig wären, sondern weil sie in ihrem eigenen Betrieb meist weniger Redundanz haben und ihr Geschäftsmodell empfindlicher auf den Weggang eines einzelnen Großkunden oder eine Änderung der Finanzierung reagiert. Das ist keine Kritik an einem bestimmten kleineren Anbieter, sondern eine strukturelle Tatsache der Unternehmensgröße, die auf viele ansonsten hervorragende Dienste zutrifft.
Die praktische Lehre ist nicht unbedingt, kleinere Anbieter zu meiden. Sie lautet, eine Architektur zu bauen, die nicht davon ausgeht, dass irgendein Anbieter dauerhaft bleibt, unabhängig von seiner Größe. Einige konkrete Gewohnheiten helfen:
- Halten Sie anbieterspezifische Logik in Ihrem eigenen Code hinter einer internen Schnittstelle, sodass eine Parsing-Funktion aus Ihrer eigenen normalisierten Datenstruktur liest statt direkt aus den über die Codebasis verstreuten Feldnamen eines bestimmten Anbieters
- Testen Sie regelmäßig, ob Ihre Integration tatsächlich wechseln könnte, auch wenn Sie keinen baldigen Wechsel planen, denn eine ungetestete Annahme der Portabilität ist nicht dasselbe wie echte Portabilität
- Halten Sie fest, was eine vollständige Migration an Entwicklungszeit kosten würde, als dauerhaftes Wissen der Organisation und nicht als etwas, das zum ersten Mal in einer Krise berechnet wird
Ein kompatibilitätsbasierter Ansatz verändert diese Rechnung etwas, weil er verringert, wie viel der Migrationskosten in Ihrem eigenen Parsing-Code steckt. My Geocode betreibt 17 Kompatibilitäts-Hosts, die die exakte Anfrage- und Antwortstruktur großer Anbieter nachbilden, darunter Google Maps Platform, Mapbox, HERE, ipstack und weitere, dokumentiert unter /compatibility/. Das bedeutet, dass der riskanteste Teil einer erzwungenen Migration, das Neuschreiben der Parsing-Logik unter Zeitdruck, oft vermeidbar ist, wenn es für den Anbieter, den Sie verlassen, bereits einen passenden Kompatibilitäts-Host gibt.
Die tiefere Lehre über Anbieterrisiken gilt jedoch unabhängig davon, welchen Anbieter oder welche Plattform Sie nutzen, auch diese hier: Am gesündesten ist die Position, in der ein Wechsel eine echte, getestete Option ist und keine theoretische. Einen kleinen Test mit einem alternativen Anbieter durchzuführen, bevor Sie ihn brauchen, selbst für einen Bruchteil Ihres Datenverkehrs, verwandelt das Anbieterrisiko von einer abstrakten Sorge in eine konkrete, eingeübte Fähigkeit. Der Test kostet vergleichsweise wenig, und der Nutzen zeigt sich erst an dem Tag, an dem Sie ihn tatsächlich brauchen.