Wenn dem so ist und das jeder alles so parat haben sollte, dann frag ich mal ganz offen, ob es nur mir so geht, das ich ohne den ganzen Kram bisher sehr gut klarkomme, einiges davon zwar kenne, aber gar nichts davon für existenziell wichtig und unersetzbar halte.
Die Fragen sind eigentlich folgende:
- Sind die altbekannten Technologien wirklich gut genug für so ein Vorhaben?
- Bringen mir auf verteilte (Web- und App-) Applikationen spezialisierte Werkzeuge einen Vorteil?
- Wie lange soll das neue Produkt am Markt bleiben? (Hoffentlich mehr als nur 3-4 Jahre?)
- Finden sich dann in 5-7 Jahren noch Entwickler, die sich mit der altbekannten Technologie auskennen?
- Kann ich junge Entwickler dann noch mit meinem Technologiestack überzeugen?
- Wie wichtig ist das Produkt für mein Business?
- Kann ich es mir leisten, das Ding mittelfristig wieder weg zu werfen und neu zu machen wenn die altbekannte Technologie doch nicht fliegt?
Man sollte dabei auch noch folgendes bedenken:
Wir haben hier kein einfaches Client-Server Setup. Sobald Du Dich im Web- und App-Umfeld bewegst arbeitest Du zwangsläufig an einer verteilten Architektur. Du hast Persistenz (
DB, kann aber auch mal ne Messagequeue oder ein Eventstore sein), Du hast Services/APIs die zustandslos sein müssen (zumindest ab dem Zeitpunkt an dem Du eine einfache Basis-Ausfallsicherheit sicherstellen möchtest), Du hast Clients auf verschiedenen Plattformen und der Zustand des Gesamtsystems verteilt sich auf Persistenz, Netzwerk und Client-Anwendungen. Und nein, so ne App kann mal offline sein, Du kannst also nicht einfach alles in Transaktionen auf der
DB packen um das konsistent zu halten. Du brauchst entweder verteilte Transaktionen (guter Rat: tu's nicht), oder, besser und korrekter, Du setzt auf eventual consistency (irgendwann wird's wieder konsistent werden, nur jetzt grad in dieser Sekunde noch nicht). Und Du musst das alles im Betrieb überwachen.
Gibt es für alle diese Herausforderungen in Deinem Dir jetzt bekannten Werkzeugset Dinge, von denen Du mit Gewissheit sagen kannst dass sie auch bei zehntausenden Anfragen pro Sekunde auf Deinem System grundsolide ihre Arbeit verrichten? Bist Du Dir sicher dass die Sicherheitsschicht Deiner
API nicht durch einen Angreifer in ein paar Sekunden ausgehebelt wird (und damit meine ich: Bist Du Dir wirklich sicher? Wie viele unterschiedliche Security-Firmen hast Du mit Penetration-Tests beauftragt um die Aussage zu belegen?).
Und wenn Du Dich jetzt fragst: Ist das wirklich notwendig? Das ganze brauch ich doch nicht! Dann überlege: Du hast einen Shop mit Anbindung an ein Zahlungssystem. Welcher Schaden kann potentiell entstehen wenn jemand im Namen eines anderen bestellt, oder jemand mittels DNS-Spoofing Paypal mimt und Deinem System vorgaukelt etwas sei bezahlt dabei hat Paypal die Zahlungsinfos nie erhalten, oder jemand durch eine Lücke in der
API die Versandadresse eines Kunden ändert und alle teuren Waren an eine Paketstation gehen und der Empfänger unbekannt ist? Und das sind nur die einfachen Angriffe. Für sowas haben professionelle Täter heute Scripte die sowas ausprobieren, da sitzt keiner manuell dran und versucht Dein System zu hacken - das System übernehmen die vollautomatisiert.
Und dann sind die Antworten auf die folgende Fragen eigentlich sehr einfach:
Will ich nicht lieber mein Produkt auf eine technologische Basis setzen, die genau für diese Herausforderungen spezialisiert ist?
Sollte ich nicht für meine Webanwendung etwas benutzen, das heute State of the Art ist, und für das ich auch genau jetzt erfahrene Entwickler finden kann?
Sollte ich nicht Technologien für meine
API einsetzen, die genau dafür spezialisiert ist und mir dort massig Arbeit abnimmt?
Sollte ich mich was Security angeht nicht besser auf Armeen von Security-Engineers verlassen als zu meinen, alles selber besser zu können?