Zu viele Abhängigkeiten

[lestard]

Ist die Erkenntnis nicht viel mehr, dass die ganzen Dienste viel zu sehr miteinander verwoben sind und es zu viele Abhängigkeiten gibt? Und dass die Dienste offensichtlich nicht sehr resilient gegenüber Ausfällen von Dritt-Systemen sind. Also eigentlich alles Probleme, die durch den Microservices-Trend in das Blickfeld von vielen EntwicklerInnen getreten sind.

"Never change a running System" war doch eigentlich eine Weisheit, von der man wegkommen wollte hin zu einem System, wo Änderungen OK sind.

[HeroFeat]

Die Mentalität "Never Change a running System" finde ich auch ziemlich blöd. Natürlich sollte man nicht alles anfassen und ändern. Aber Admins oder Entwickler welche sich davor fürchten an ihren eigenen Systemen etwas zu ändern kann, das kann doch keine Lösung sein.

[xUser]

lestard schrieb:
--------------------------------------------------------------------------------
> Ist die Erkenntnis nicht viel mehr, dass die ganzen Dienste viel zu sehr
> miteinander verwoben sind und es zu viele Abhängigkeiten gibt? Und dass die
> Dienste offensichtlich nicht sehr resilient gegenüber Ausfällen von
> Dritt-Systemen sind. Also eigentlich alles Probleme, die durch den
> Microservices-Trend in das Blickfeld von vielen EntwicklerInnen getreten
> sind.
>
> "Never change a running System" war doch eigentlich eine Weisheit, von der
> man wegkommen wollte hin zu einem System, wo Änderungen OK sind.

Die Systeme sind ja nicht eng verworben. Aber wenn eine zentrale Komponente (messenger) ausfällt, dann gehen halt bestimmte Teile nicht mehr. Wie sähe denn eine Alternative aus?

[Memo99]

xUser schrieb:
--------------------------------------------------------------------------------
> lestard schrieb:
> ---------------------------------------------------------------------------
> -----
> > Ist die Erkenntnis nicht viel mehr, dass die ganzen Dienste viel zu sehr
> > miteinander verwoben sind und es zu viele Abhängigkeiten gibt? Und dass
> die
> > Dienste offensichtlich nicht sehr resilient gegenüber Ausfällen von
> > Dritt-Systemen sind. Also eigentlich alles Probleme, die durch den
> > Microservices-Trend in das Blickfeld von vielen EntwicklerInnen getreten
> > sind.
> >
> > "Never change a running System" war doch eigentlich eine Weisheit, von
> der
> > man wegkommen wollte hin zu einem System, wo Änderungen OK sind.
>
> Die Systeme sind ja nicht eng verworben. Aber wenn eine zentrale Komponente
> (messenger) ausfällt, dann gehen halt bestimmte Teile nicht mehr. Wie sähe
> denn eine Alternative aus?

Wiedergeburt der MainFrames !!!!!!!

[gadthrawn]

HeroFeat schrieb:
--------------------------------------------------------------------------------
> Die Mentalität "Never Change a running System" finde ich auch ziemlich
> blöd. Natürlich sollte man nicht alles anfassen und ändern. Aber Admins
> oder Entwickler welche sich davor fürchten an ihren eigenen Systemen etwas
> zu ändern kann, das kann doch keine Lösung sein.


Vor allem kam der Spruch aus einer Zeit in der Software Sekten gepatched wurde und Zugriff auf externe sehr eingeschränkt war.

Ist meines Erachtens das dümmste was in open hängengeblieben ist.

Damals waren Angriffe von außen noch nicht so verbreitet, Bugfixing braucht eben auch updates - selbst wenn es aussieht als würde etwas laufen.

[lestard]

Wie man es besser macht weiß ich auch nicht. Ist nicht mein Fachgebiet.
Aber ich fand bemerkenswert, dass die Themen Entkopplung und Resilienz ja seit einigen Jahren im Zuge der Microservices-Idee viel besprochen werden. Da wundert es eben, dass ein Tech-Unternehmen wie Amazon hier dann scheinbar doch so viel Falsch macht. Vor allem weil die ja selbst auch viel Marketing machen um ihre Dienste anzubieten und dabei auch genau diese genannten Faktoren als ihre Vorteile preisen.

[xUser]

lestard schrieb:
--------------------------------------------------------------------------------
> Wie man es besser macht weiß ich auch nicht. Ist nicht mein Fachgebiet.
> Aber ich fand bemerkenswert, dass die Themen Entkopplung und Resilienz ja
> seit einigen Jahren im Zuge der Microservices-Idee viel besprochen werden.
> Da wundert es eben, dass ein Tech-Unternehmen wie Amazon hier dann
> scheinbar doch so viel Falsch macht. Vor allem weil die ja selbst auch viel
> Marketing machen um ihre Dienste anzubieten und dabei auch genau diese
> genannten Faktoren als ihre Vorteile preisen.

Eine perfekte Architektur gibt es nicht.

Amazon weiß schon was sie tun und die allgemeine Stabilität ist um Welten besser als alles was ich on prem bisher gesehen habe. Aber auch Amazon macht manchmal Fehler.

Das man nicht immer damit rechnet, dass eine Abhängigkeit für Stunden ausfällt, sollte ja klar sein. Natürlich gibt es Möglichkeiten damit umzugehen und Amazon hat ja geschrieben was sie ändern werden, damit das so nicht nochmal passiert. Und du kannst davon ausgehen, dass sie auch bei den anderen Services mal schauen werden, was noch zu tun ist.