Fast nicht funktionierende Systeme-Ideen

Fast nicht funktionierende Systemideen

• "Mach es einfach plug-and-play"

  • Die Idee besteht darin, Entwicklern zu ermöglichen, neue Implementierungen leicht hinzuzufügen, wenn eine bestehende Implementierung nicht funktioniert. In den meisten Fällen funktionieren die durch eine API bereitgestellten Funktionen jedoch nicht so einfach wie erhofft. Für echte Plug-and-Play-Fähigkeit muss eine zweite Implementierung von Anfang an mitentworfen werden.

• "Füge einfach eine API hinzu"

  • Es ist häufig üblich, eine API bereitzustellen, um eine Plattform aufzubauen und Entwickler anzulocken. Dabei ist das Bereitstellen einer API jedoch mit kontinuierlichem Aufwand für Kompatibilität und Interoperabilität verbunden, und eine API garantiert nicht automatisch, dass Nutzer dazukommen. Der Aufbau einer Plattform ist ein ernstzunehmendes Geschäftsfeld, und allein das Bereitstellen einer API schafft oft keine tragfähige wirtschaftliche Grundlage.

• "Abstrahiere eine weitere Ebene"

  • In der Informatik wird oft gesagt, dass man ein Problem durch eine weitere Ebene indirekter Referenzen lösen kann. Eine zu frühe Abstraktion kann jedoch Wartungsaufwand, Sicherheit und Performance-Optimierung erschweren. Ungeplant hinzugefügte Abstraktion macht die Codewartung schwieriger.

• "Machen wir es asynchron"

  • Asynchronität ist seit langem ein Forschungsgebiet der Informatik. Web-Frameworks abstrahieren sie gut, aber wenn man versucht, Asynchronität außerhalb eines Frameworks selbst zu steuern, entstehen leicht unvorhersehbare Fehler.

• "Zugriffskontrolle später ergänzen"

  • Systemsicherheit muss von Anfang an berücksichtigt werden, wird aber oft wegen der Markteinführungs-Geschwindigkeit erst später ergänzt. Wer Zugriffskontrolle nicht von Anfang an aus Sicht der Nutzer und aus der Sicht potenzieller Angreifer mitdenkt, muss das Produkt später häufig neu entwerfen.

• "Daten synchronisieren"

  • Datensynchronisierung ist ein äußerst schwieriges Problem mit vielen Herausforderungen, die sich vor allem durch Erfahrung bewältigen lassen. Es ist im Grunde nicht ratsam, Lösungen aufzubauen, die auf Datensynchronisierung beruhen.

• "Plattformübergreifend entwickeln"

  • Plattformübergreifende Entwicklung ist vergleichbar mit dem Aufbau eines Betriebssystems, eines Cloud-Anbieters oder eines Browsers. Es kann funktionieren, wenn die Plattform neu ist oder die Anwendung einfach ist, wird aber mit der Zeit immer schwieriger.

• "Ausweg zu nativer Umsetzung schaffen"

  • Wenn Plattformübergreifendes an Grenzen stößt, ist es üblich, einen Ausweg zu nativen Funktionen zu schaffen. Diese Methode kollidiert jedoch häufig mit dem von einem Framework verwalteten Zustand und scheitert zu 90 Prozent.

• Fazit

  • Diese Ansätze sind nicht immer zum Scheitern verurteilt, aber in den meisten Fällen gibt es bessere Alternativen. Wichtig ist, Probleme anhand der Grundprinzipien zu lösen und Softwaremuster mit hoher Ausfallwahrscheinlichkeit zu vermeiden.

[ndrgrd]

Bei einem Plug-in ist es am wichtigsten, die zwingend nötigen Aktionen so weit wie möglich zu filtern und dann das Interface zu entwerfen.
Wenn man die Schnittstelle nur grob aus dem aktuellen Code übernimmt, wird sie zwangsläufig eine unnötige Schnittstelle, die an dieser konkreten Implementierung hängt; solche Fälle kommen wirklich häufig vor...

[GN⁺]

Hacker News Kommentar

• DSLs und APIs funktionieren oft gut. Inferenz-Engines wie TensorFlow können ebenso als DSL oder als API um eine DSL herum verstanden werden.

  • SQL, Shader-Sprachen, BPF usw. sind dafür ebenfalls gute Beispiele.
  • Der Ansatz „einfach eine API hinzufügen“ ist unter Umständen nicht erfolgreich. Wie bei der Umsetzung einer UI sollte man ihn sorgfältig und gründlich angehen.

• DSLs funktionieren manchmal hervorragend. Als Referenz kann man jOOQ.org heranziehen.

• Der Elastic Load Balancer ist ein lastabhängiger Regelkreis. Das ist letztlich eine Art Produkt.

• In den meisten Branchen herrscht ein Mangel an Ressourcen. Als Referenz lassen sich erikbern.com und „Goal: Process of Ongoing Improvement“ nennen.

• Anomalie-Erkennung ist kein verteiltes-System-Problem, obwohl Menschen, die darauf gestoßen sind, es für nötig halten können.

  • Der Isolation-Forest-Algorithmus ist manchmal geradezu verblüffend. 2018 gab es mit CNN-basierten Text-Embeddings sehr gute Ergebnisse.

• Der Begriff „fast“ ist in diesem Kontext nicht hilfreich; es ist bloß Pessimismus- und Zynismusrhetorik.

• Viele suchen nach einer ausgefeilten Entscheidungsfunktion für Ausnahmen. In der Realität ist es aber ganz einfach: Wenn ich es mache, klappt es; wenn der/die Vorherige es macht, klappt es nicht.

• „Domain-Driven Design“ ist eine Katastrophen-Rezeptur, wenn man eine Anwendung anhand der Geschäftsstruktur entwirft.

  • In kleinen Unternehmen kann das unproblematisch sein, in erfolgreichen oder wachsenden Unternehmen wird es oft sofort bereut.
  • Stattdessen sollte man nach Funktionsbereichen entwerfen und so viel Geschäftslogik wie möglich in Datenbankzeilen, Nutzer-Workflows und die Systemlogik integrieren.

• Lastreaktive Regelkreise sind grundlegende und unverzichtbare Komponenten. Sie werden in vielen Systemen eingesetzt.

• Ich habe an Projekten mit mehreren DSLs, P2P-Cache und hybrider Parallelität gearbeitet, und die meisten waren erfolgreich.

  • P2P-Cache war nicht notwendig und hat keinen großen Mehrwert gebracht.
  • Es ist komplex, aber diese Komplexität liefert Funktionen, die sonst schwer erreichbar wären.

• Der Ansatz „Lass uns einfach die Daten synchronisieren“ kann Probleme verursachen.

  • Viele Systeme sind für „Internet Scale“ entworfen, liegen in der Praxis aber deutlich darunter.
  • Solche Teams sind naiv oder nutzen im schlimmsten Fall nicht-technisches Management, um das Problem mit zusätzlichem Geld zu bekämpfen.

• Mehrere Ideen wurden erfolgreich umgesetzt. Deshalb klingt das etwas merkwürdig.