new Account()
Banned
- Registriert
- Mai 2018
- Beiträge
- 7.198
Nicht wirklich...[ChAoZ] schrieb:
Welche Sprache für Website?
- Ersteller maloz
- Erstellt am
![[ChAoZ]](https://pics.computerbase.de/forum/avatars/m/491/491529.jpg?1618073566){kind=avatar}
new Account()
Banned
- Registriert
- Mai 2018
- Beiträge
- 7.198
Wie kommst du darauf?
Joshinator
Commander
- Registriert
- Dez. 2017
- Beiträge
- 2.337
Ganz nach dem Motto "wenn man einen Hammer hat sieht alles wie ein Nagel aus".
Nur weil die großen Techfirmen wie Netflix & Co auf Microservices setzen heißt das noch lange nicht dass das jeder 0815 Entwickler macht und machen sollte. Die meisten Entwickler stehen dann nämlich vor so Situationen:
Und Node ist bei weitem nicht so weit verbreitet wie du denkst, Rust/Actix, .NET, Go und selbst PHP sind weiterhin noch stark vertreten. Node und auch Deno werden da nix dran ändern.
Richtiges Tool für den richtigen Job wählen, nicht jede Seite im Internet muss ne 2MB SPA mit 20 Microservices, Blockchain & Co sein.
Nur weil die großen Techfirmen wie Netflix & Co auf Microservices setzen heißt das noch lange nicht dass das jeder 0815 Entwickler macht und machen sollte. Die meisten Entwickler stehen dann nämlich vor so Situationen:
Und Node ist bei weitem nicht so weit verbreitet wie du denkst, Rust/Actix, .NET, Go und selbst PHP sind weiterhin noch stark vertreten. Node und auch Deno werden da nix dran ändern.
Richtiges Tool für den richtigen Job wählen, nicht jede Seite im Internet muss ne 2MB SPA mit 20 Microservices, Blockchain & Co sein.
mental.dIseASe
Lieutenant
- Registriert
- Dez. 2008
- Beiträge
- 665
Hammer Video. 
new Account()
Banned
- Registriert
- Mai 2018
- Beiträge
- 7.198
Okay, wo ist das Problem?Joshinator schrieb:
In jedes Projekt muss man sich einarbeiten, und ob man die Logik nun auf Microservices aufteilt, dürfte keinen großen Unterschied machen.
Abhängigkeiten und sequentielle Anforderungen hat man so und so - egal ob das Programm in einer ausführbaren Datei liegt oder nicht.
Was anders ist, ist die Art der Aufteilung in Module und die APIs.
Joshinator
Commander
- Registriert
- Dez. 2017
- Beiträge
- 2.337
Das Video ist natürlich überspitzt dargestellt. Meine Aussage war auch nicht "Microservices sind zu 100% unnötig".
Microservices ist nicht nur "ich packe einzelne Aufgaben meines Monolith einfach in eigene Services und läuft".
Man führt immer neue Tools ein um Probleme zu lösen die "Stack XYZ" mitbringt, und da ist immer die Frage ob der Mehrwert die Komplexität rechtfertigt.
Die Masse der Webseiten (besonders Leute die im Forum nach Hilfe für ein Mini-Projekt suchen) arbeiten nicht auf einem Level wo man an Microservices denken muss.
Alles bringt Komplexität mit sich, ob es nun ein Frontend-Framework ist oder eben Microservices.Joshinator schrieb:
Microservices ist nicht nur "ich packe einzelne Aufgaben meines Monolith einfach in eigene Services und läuft".
Man führt immer neue Tools ein um Probleme zu lösen die "Stack XYZ" mitbringt, und da ist immer die Frage ob der Mehrwert die Komplexität rechtfertigt.
Die Masse der Webseiten (besonders Leute die im Forum nach Hilfe für ein Mini-Projekt suchen) arbeiten nicht auf einem Level wo man an Microservices denken muss.
new Account() schrieb:
Verteilte Systeme sind viel, viel komplexer als eine "altmodischer" Monolith. Die möglichen Fehlerquellen sind deutlich vielfältiger wenn an allen Stellen das übers Netzwerk geht, und Probleme debuggen ist viel schwieriger in einem verteilten System.
Und in diesem Thread reden wir von einer einzelnen Person mit einem privaten Projekt, Microservices sind einfach irrelevant in diesem Kontext. Und für relativ einfache Projekte ohne enorme Ansprüche an Performance ist es jetzt nicht so wichtig ob das PHP, Python, NodeJS, Java, Go oder C# ist. Das geht in allen
[ChAoZ] schrieb:
Geschwindigkeit ist nicht alles, und NodeJS ist jetzt auch nicht so wahnsinnig schnell. Ich habe keine Erfahrung mit modernem PHP, aber das scheint gar nicht so langsam zu sein (laut Techempower Benchmarks, die aber auch nur begrenzt aussagekräftig sind).
chris221177
Cadet 3rd Year
- Registriert
- Jan. 2015
- Beiträge
- 48
Insgesamt ist der PHP 7 Runtime Compiler deutlich performanter als zu PHP 5 Zeiten. Die Runtime Kompilierung ist für schnelle, kleine Entwicklungen was tolles. Man kommt da einfach um einen Buildprozess drum rum.
Die Runtime Kompilierung ist natürlich nichts, was es nur in PHP gibt.
Und zum Thema Microservices kann ich nur sagen: Da haben sich schon viele Unternehmen eine blutige Nase geholt.
Die Runtime Kompilierung ist natürlich nichts, was es nur in PHP gibt.
Und zum Thema Microservices kann ich nur sagen: Da haben sich schon viele Unternehmen eine blutige Nase geholt.
ayngush
Lt. Commander
- Registriert
- Okt. 2007
- Beiträge
- 1.986
Im Sicherheitskontext gesellt sich dann noch dazu, dass je komplexer ein Code ist, desto fehleranfälliger ist ein Code und je fehleranfälliger ein Code ist, desto unsicherer ist die Ausführung solchen Codes.
Nicht umsonst und nicht aus Spaß bestehen die Kernsysteme von Banken zum Teil immer noch aus Cobol-Monolithen. Da will zwar niemand mehr bei, das läuft aber.
Mit Microservices begibt man sich, häufig unnötigerweise, auf einen Pfad der Komplexität und Dependency Hell. Da brechen die von außen deinen Code und du weißt nicht waurm. Das nervt schon im kleinen aber bei der Kombination Node.js, NPM und Microservices treibt man das einfach auf eine Spitze, auf der man keine Software entwerfen solle. Das ist ganz übles Design. Man muss also einen Designansatz finden, wie Monorepo, der es einen ermöglicht die Dependency Hell zu umschiffen - und dadurch hat man neben den irrsinnig hohen Aufwand, der durch Microservices ohnehin schon entsteht, auch noch einen irrsinnig hohen Aufwand bei der Entwicklung. Hoffentlich hat man dann mit einen irrsinnig hohen Aufwand das Testen und das Deployment wenigstens weitestgehend automatisiert.
Und das alles für eine Internetseite die zwei "Excellisten" ins Web bringen soll?
Ganz ehrlich: Das wäre ganz großer Blödsinn das mit Microservices aufzubauen.
Heutzutage baut man immer noch kleine Webprojekte in PHP / Python / Java / Asp.net und komplexe, große Webanwendungen mit einen Mix aus diversen Frontend und Backendsystemen. Wenn man horizontal skalieren muss wie Amazon oder Netflix, dann gerne auch mit Microservices. Aber bedenke, dass Netflix mehrere hundert Entwickler hat und nicht nur einen.
Wie man also Webseiten baut, wenn man sie alleine baut: Überschaubar und in einer Sprache, die einen gefällt und die mit sehr wenig Abhängigkeiten und architektonischen Overhead auskommt. Damit das ganze überhaupt Wartbar bleibt.
Nicht umsonst und nicht aus Spaß bestehen die Kernsysteme von Banken zum Teil immer noch aus Cobol-Monolithen. Da will zwar niemand mehr bei, das läuft aber.
Mit Microservices begibt man sich, häufig unnötigerweise, auf einen Pfad der Komplexität und Dependency Hell. Da brechen die von außen deinen Code und du weißt nicht waurm. Das nervt schon im kleinen aber bei der Kombination Node.js, NPM und Microservices treibt man das einfach auf eine Spitze, auf der man keine Software entwerfen solle. Das ist ganz übles Design. Man muss also einen Designansatz finden, wie Monorepo, der es einen ermöglicht die Dependency Hell zu umschiffen - und dadurch hat man neben den irrsinnig hohen Aufwand, der durch Microservices ohnehin schon entsteht, auch noch einen irrsinnig hohen Aufwand bei der Entwicklung. Hoffentlich hat man dann mit einen irrsinnig hohen Aufwand das Testen und das Deployment wenigstens weitestgehend automatisiert.
Und das alles für eine Internetseite die zwei "Excellisten" ins Web bringen soll?
Ganz ehrlich: Das wäre ganz großer Blödsinn das mit Microservices aufzubauen.
Heutzutage baut man immer noch kleine Webprojekte in PHP / Python / Java / Asp.net und komplexe, große Webanwendungen mit einen Mix aus diversen Frontend und Backendsystemen. Wenn man horizontal skalieren muss wie Amazon oder Netflix, dann gerne auch mit Microservices. Aber bedenke, dass Netflix mehrere hundert Entwickler hat und nicht nur einen.
Wie man also Webseiten baut, wenn man sie alleine baut: Überschaubar und in einer Sprache, die einen gefällt und die mit sehr wenig Abhängigkeiten und architektonischen Overhead auskommt. Damit das ganze überhaupt Wartbar bleibt.
Zuletzt bearbeitet:
Zu dem Microservice-Zeugs:
https://changelog.com/posts/monoliths-are-the-future
Man beachte, von wem der Artikel ist...
(Einem der "Urväter" der Microservices, für die die nicht googlen wollen)
https://changelog.com/posts/monoliths-are-the-future
Man beachte, von wem der Artikel ist...
(Einem der "Urväter" der Microservices, für die die nicht googlen wollen)
new Account()
Banned
- Registriert
- Mai 2018
- Beiträge
- 7.198
Dort steht ja auch keine Überraschung:
Das ist eigentlich der ganze Inhalt des Posts.
Der Titel is absolut irreführend, weil er nichts mit dem Text zu tun hat.
Schlechter Code bleibt schlechter Code, hat eigentlich wenig mit MS zu tun.
Das ist eigentlich der ganze Inhalt des Posts.
Der Titel is absolut irreführend, weil er nichts mit dem Text zu tun hat.
ayngush
Lt. Commander
- Registriert
- Okt. 2007
- Beiträge
- 1.986
Ich finde die pauschale Kategorisierung in "good" und "bad" an der Stelle einfach mega verkehrt.
Code, der als Programm konkrete Anforderungen eines Geschäftsprozesses löst und dabei auch funktioniert (Performance, Stabilität, usw.) ist ja nicht "bad" im Sinne von "schlecht", nur weil ein Mensch im Internet mal behauptet hat, dass jetzt Programme mit einer monolithischen Architektur "bad" sind.
Edit: Code wird "bad", wenn man ihn nicht mehr warten kann und wenn er die funktionalen Anforderungen und Qualitätsvorgaben nicht oder nicht mehr erfüllt und man ihn dann nicht mit einen vernünftigen Aufwand erweitern kann. Das hat aber mit der Architektur erst mal nichts zu tun. Die Architektur ist immer im Kontext der Anforderungen zu evaluieren.
Natürlich wäre eine zentrale, relationale Datenbank für alle Youtube-Kommentare ein "bad Design". Aber mal Hand aufs Herz: Wer plant damit, wenn er ein CRM für seine Firma schreibt, dass man das mal auf Youtube-Größe hochskalieren muss? Und warum soll man sich am Anfang mit 100 Kunden darüber den Kopf zerbrechen? Wenn man annähernd so groß wie Youtube wächst hat man ganze Abteilungen die sich damit beschäftigen können -> sinnvolle Verwendung von Ressourcen.
Code, der als Programm konkrete Anforderungen eines Geschäftsprozesses löst und dabei auch funktioniert (Performance, Stabilität, usw.) ist ja nicht "bad" im Sinne von "schlecht", nur weil ein Mensch im Internet mal behauptet hat, dass jetzt Programme mit einer monolithischen Architektur "bad" sind.
Edit: Code wird "bad", wenn man ihn nicht mehr warten kann und wenn er die funktionalen Anforderungen und Qualitätsvorgaben nicht oder nicht mehr erfüllt und man ihn dann nicht mit einen vernünftigen Aufwand erweitern kann. Das hat aber mit der Architektur erst mal nichts zu tun. Die Architektur ist immer im Kontext der Anforderungen zu evaluieren.
Natürlich wäre eine zentrale, relationale Datenbank für alle Youtube-Kommentare ein "bad Design". Aber mal Hand aufs Herz: Wer plant damit, wenn er ein CRM für seine Firma schreibt, dass man das mal auf Youtube-Größe hochskalieren muss? Und warum soll man sich am Anfang mit 100 Kunden darüber den Kopf zerbrechen? Wenn man annähernd so groß wie Youtube wächst hat man ganze Abteilungen die sich damit beschäftigen können -> sinnvolle Verwendung von Ressourcen.
Zuletzt bearbeitet:
ayngush schrieb:
Und man kann mit einer relationalen Datenbank auch sehr hoch skalieren, wenn auch vielleicht nicht ganz bis zu Youtube Größe. Das beste Beispiel ist Stackoverflow, das sind ~50 Millionen Posts, ~75 Millionen Kommentare und 1.3 Milliarden Seitenaufrufe pro Monat (https://stackexchange.com/performance). Das ganze läuft mit einer relationalen Datenbank ohne Probleme. Sind zwar 2 Server, aber das ist soweit ich weiß nur für Redundanz, nicht für Performance notwendig.
Wenn man seine Probleme genau versteht, kann man natürlich mit spezifischen Lösungen sehr viel Performance und Skalierung rausholen. Aber wenn man anfängt ist ein Standardframework mit relationaler DB sicher eine gute Wahl die auch in den meisten Fällen völlig ausreichende Performance bietet.
new Account()
Banned
- Registriert
- Mai 2018
- Beiträge
- 7.198
+ 2 Redis-Server + 3 Server für Tags + 3 Elastiquesearch welche jeweils auch Abfragen entgegennehmen...Dalek schrieb:
So viel zu relationaler Datenbank.
Und das alles für "lediglich" Frage-Antworten Spiele.
Ergänzung ()
Wenn man erwartet schnell zu wachsen, oder allgemein zu wachsen - wieso nicht gleich richtig?ayngush schrieb:
Von vornherein das nicht zu bedenken, kann schnell zu Problemen kommen, bei welchen man ggf. in einer kompletten Neuentwicklung landet (die Herangehensweisen bei verteilter Entwicklung sind durch das andere Setup sehr verschieden).
Beispielsweise hat Vector für Matrix einen monolithischen Server ("Synapse") entwickelt. Leider kam dieser den exponentiell wachsenden Anforderungen gar nicht nach, sodass nun 1) der Server gesplittet werden muss, damit er überhaupt brauchbar ist, 2) Migrationen zwischen den ständigen Splits durchgeführt werden müssen, 3) eine komplette Neuentwicklung auf golang Basis ("Dendrite") geschaffen wird, und 4) alle gerade kommenden Änderungen/Features doppelt entwickelt werden müssen.
Und das zieht sich jetzt hin: Vor 3 Jahren wurde die Neuentwicklung gestartet, und quasi jeder Matrixnutzer, der seinen Account auf matrix.org hat, weiß Bescheid 😂
In dem Fall eine Verschwendung von Ressourcen statt sinnvolle Verwendung jener (obgleich man Vector zugestehen muss, dass sie auf Grund von Entwicklungsresourcen und der Neuheit der Technologie in der Anfangszeit einfach keine Wahl hatten).
Kann einem aber egal sein, wenn man von vornherein weiß, dass das nicht notwendig sein wird. Stichwort nicht funktionale Anforderungen.
PS: Für good und bad gibts deutsche Wörter: gut und schlecht
Zuletzt bearbeitet:
ayngush schrieb:RAM: 1.5 TB • DB size: 2.8 TB Das ist auch ziemlich gesund gesized
Ist sehr ordentliche Hardware, aber noch deutlich in dem Bereich den man einfach von der Stange bekommt.
new Account() schrieb:
Mein Punkt hier war das auch ein Monolith sehr hoch skalieren kann auf relativ wenig Hardware. Da braucht man nicht unbeding Microservices und NoSQL Datenbanken. Das man Sachen wie Caching und Suche auf separate Server auslagert ist doch Standard. Und die Server sind bei so 5% CPU, das würde auch auf weniger Servern Laufen wenn man die Redundanz und den zusätzlichen Spielraum nicht braucht.
new Account()
Banned
- Registriert
- Mai 2018
- Beiträge
- 7.198
Aber wie soll denn hier SO als Beispiel dienen?
SO ist durch das Auslagern kein wirklicher Monolith mehr und nutzt durch Redis auch NoSQL Datenbanken.
SO ist durch das Auslagern kein wirklicher Monolith mehr und nutzt durch Redis auch NoSQL Datenbanken.
Zuletzt bearbeitet:
ayngush
Lt. Commander
- Registriert
- Okt. 2007
- Beiträge
- 1.986
Aber keine Microsoervices...
Es spricht ja nichts dagegen eine zur Größe und Skalierung und geplanten Größe und geplante Skalierung passende Technologie und Architektur auszuwählen?!?
Der Ursprung hier war jedoch mal zwei Exceltabellen als Webanwendung darzustellen. Und da hieß es, dass man heute ohne Node.js und Microservices nichts mehr fürs Web baut. Diese Aussage ist aber Unfug und es gibt kein "gut" oder "schlecht" sondern "passend" und "unpassend". Das ist halt ein Unterschied, denn auch gute Architektur und gute Programme, die als guter Code monolitisch verfasst sind können unpassend sein. Genau so gut können auch Microsvervices unpassend sein. Oder eben genau richtig. Das kommt halt einfach drauf an. Für zwei Exceltabellen im Web sind Microservices und Redis einfach sowas von Hart übertrieben...
Und da ich ich in meinem Requirements Engineering Modul gelernt habe, dass "nicht funktionale Anforderungen" Qualitätsvorgaben sind und man diese durch das Kano-Modell betracht und wir hier über Leiastungsfaktoren und Begeisterungsfaktoren reden... die nichts mit den Basisfaktoren zu tun haben aber teilweise die Basiosfaktoren tangieren (Sichreheit <=> Komplexität) sollte man da schon eine ordentliche Evaluation durchführen und nicht einfach pauschal sagen: Microservice, gut. Monolith, böse.
Es spricht ja nichts dagegen eine zur Größe und Skalierung und geplanten Größe und geplante Skalierung passende Technologie und Architektur auszuwählen?!?
Der Ursprung hier war jedoch mal zwei Exceltabellen als Webanwendung darzustellen. Und da hieß es, dass man heute ohne Node.js und Microservices nichts mehr fürs Web baut. Diese Aussage ist aber Unfug und es gibt kein "gut" oder "schlecht" sondern "passend" und "unpassend". Das ist halt ein Unterschied, denn auch gute Architektur und gute Programme, die als guter Code monolitisch verfasst sind können unpassend sein. Genau so gut können auch Microsvervices unpassend sein. Oder eben genau richtig. Das kommt halt einfach drauf an. Für zwei Exceltabellen im Web sind Microservices und Redis einfach sowas von Hart übertrieben...
Und da ich ich in meinem Requirements Engineering Modul gelernt habe, dass "nicht funktionale Anforderungen" Qualitätsvorgaben sind und man diese durch das Kano-Modell betracht und wir hier über Leiastungsfaktoren und Begeisterungsfaktoren reden... die nichts mit den Basisfaktoren zu tun haben aber teilweise die Basiosfaktoren tangieren (Sichreheit <=> Komplexität) sollte man da schon eine ordentliche Evaluation durchführen und nicht einfach pauschal sagen: Microservice, gut. Monolith, böse.
Zuletzt bearbeitet:
