Curriculum Ideen #25
Unanswered
holgert0031
asked this question in
Ideas
Replies: 0 comments
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
Auf Deutsch:
Das Curriculum ist viel zu stark auf Microservice-Architekturen ausgerichtet. In meinen Trainings erkennen die TN - die mit der Ambition: Microservices machen wir schon lange in das Training kommen - dass sie eigentlich doch eher SOA machen und keine Microservices. Das mag wichtig erscheinen, wenn man wirklich Microservices machen möchte.
Das "WARUM benötigen wir Flexibilität" kommt weniger heraus. Einer der Hauptgründe ist doch ein schnelles Deployment, schnelle Releases und schnelle Feedback-Zyklen. Also sind wir wieder bei CI/CD und irgendwo - wenn man den Bogen länger spannt - bei DevOps... Gerade diese Themen kommen in den Curriculum viel zu kurz.
Auch die technologischen Möglichkeiten mit denen wir Microservices überwachen, tracken, analysieren können, sind zu schwach definiert. Klar empfehlen wir keine Tools, aber: Patterns, Infrastrukturkomponenten etc., die sich u.a. auch mit Cloudinfra decken, sind heute eher state-of-the-art als es die Ansätze in 2016 noch hergaben.
Und: Monolithische Architekturen sind wieder zunehmen gefragt - ein sehr guter Trend - Deplyoment- oder Schichten-Monolithen sauber in der Cloud zu betreiben - eine Herausforderung. Dabei werden allerdings gerade die Paradigmen, die in Microservices/SOA gelehrt werden auch auf die Monolithen angewandt. Insbesondere geht es hierbei um die Faktor der Skalierung (eine Mixtur aus mehreren Welten - Hybridsysteme) - oder das unabhängige Deployment von Schichten in einer Schichtenarchitektur uvm. Diese Aspekte gehen überhaupt nicht im Curriculum auf - aber: auch hier benötigen wir ein Flexibilität - der Kurs heißt ja nicht "Microservices". Natürlich haben wir mit den Microservices eine ungemein hohe Flexibilität, allerdings zu welchen Kosten? Die Komplexität, die wir uns damit einkaufen ist doch enorm.
Das ist ein weiteres Thema: Moderne Infrastrukturen bieten Lösungen für die Herausforderungen rund um Resilienz, Monitoring, Tracking und Security - ein sehr wichtiges Thema heutzutage. Evtl. können hier noch einige Aspekten in dem Curriculum aufgehen: Security-Engineering?
Eine Modernisierung des Curriculums sollte insbesondere in folgenden Teilen erfolgen:
Und natürlich die ganzen Cloud-Speicheroptionen werden nicht behandelt.
Wichtig hierbei - bei der Integration - ist die Frage der Kopplung: Das muss in den Fokus rücken: Wie integriere ich mit einem möglichst geringen Kopplungsgrad? => oder lasse ich bewusst Kopplung zu => wo dokumentiere ich das?
Ein Aspekt, der grundlegend noch fehlt: Eine effektive Methode eine flexible Softwarearchitektur zu dokumentieren. Muss jeder der >100+ Microservices einzeln dokumentiert werden - am Besten noch mittels arc42?
In der Motivation würde ich bei Conways-Law einige Abstriche machen - ist ja schon im FL drin. Evtl. sollte hier ein Fokus stärker auf Entscheidungen gelegt werden: Wie treffe ich die beste Entscheidung für meine Architektur - und welchen organisatorischen/umwelbedingten Einflüssen unterliege ich hier. Gerade die Umweltinformatik nimmt einen immer höheren Stellenwert ein. Wie beeinflusst mich das in meinen Entscheidungen?
Beta Was this translation helpful? Give feedback.
All reactions