Feedback by Mahbouba Gharbi 20.04.2022

[aheusingfeld]

In German language:

• Die Version des Curriculums ist auf "November 2015" datiert und damit schon ca. 7 Jahre alt. Innerhalb dieser Jahre haben sich die Themen in Bezug auf flexible Architekturen verändert. Es sind neue Aspekte hinzugekommen, einige wurden noch weiter detailliert sowie Empfehlungen herausgearbeitet worden: Best practices and Do's and Dont's. Insbesondere geben andere Architekten "Richardson et al" auch die Empfehlung wieder monolithische Systeme verstärkt zu forcieren: "From Monoliths to Microservices and back again". Gerade die Ausarbeitungen und Empfehlungen aus den Microservice-Ansätzen fließen dabei wieder in die Gestaltung von monolithischen Systemen ein. Ein weiteres Thema, das in dem Curriculum nur indirekt aufgeht, ist die Betrachtung von Kontrollverlusten in zu komplexen (Microservice-)Systemen. Wie können wir dem entgegen wirken und wie spielen sämtliche Aspekte (Monitoring, CI/CD, usw.) final zusammen?

Translation: The current version of the curriculum is from Nov 2015. that's almost 7 years old. Within these years topics around flexible architectures changed. New aspects were added, some have been detailed and recommendations have been created: Best practices and Do's and Dont's. Explicitly other architects like "Richardson et al" recommend to force monolithic systems again: "From Monoliths to Microservices and back again". Especially the learnings and recommendations of microservice approaches are applied back onto the design of monolithic systems.

Another topic which is only indirectly mentioned in the Curriculum, is the aspect of loss of control in complex (Microservice-)Systems. How can we avoid these and how do all aspects (Monitoring, CI/CD, etc.) finally play together?

[aheusingfeld]

As the curstor for FLEX, here are my 2cts on this.

Upfront Disclaimer: In the iSAQB Advanced Level working group we discussed how to balance the interest of training providers and participants regarding frequency of curriculum updates to make sure the curriculum stays current and relevant. The results of this discussion have been proposed to the working group a few months ago and are about to be published. My personal summary would be: by making the curriculum version of a training more transparent, we leave the choice with the participants. More to come.

1. I'm open for a discussion which Do's and Don'ts are so impactful they should explicitly be mentioned in the curriculum. I'd like to discuss this for each concrete suggestion in a dedicated Github issue or pull-request
2. Learnings of microservice projects since 2012 are exactly what shall be shared in the trainings. The curriculum leaves room for this in every chapter but mentions a few things in "modularization" which hint at https://isa-principles.org/. I will open a dedicated issue to discuss whether the ISA learnings on modularization shall be mentioned more explicitly
3. "Loss of control" is to be addressed in trainings during the modularization chapter [1] on macro architecture decision governance. Also impact of organization architecture and Conway's Law are to be discussed here. If that is not clear, we can add it.
4. That operation of a distributed system needs proper monitoring and how that plays together with the organization (YBIYRI vs central ops team) is a topic of https://github.com/isaqb-org/curriculum-flex/blob/main/docs/05-operations/02-learning-goals.adoc#lz-5-3-unterschiedliche-betriebsmodelle

[1] https://github.com/isaqb-org/curriculum-flex/blob/main/docs/02-modularization/02-learning-goals.adoc

[mahboubagharbi]

@aheusingfeld Would we like to continue the discussion?

[svenjohann]

I would certainly upvote the ideas of “when not to use microservices” and also for “monolith to microservices” (without the going back, actually).

Why “when not to use microservices”? I had a longer conversation with Sam Newman (partially public here: https://www.youtube.com/watch?v=DFt6zTQKD08) where we discussed that many companies just slide into Microservices chasing the wrong goals and then end up in big problems. Sam actually starts consultings gigs with “convince me that you really need microservices”. I think it it vital to discuss not only the benefits but also the (growing) pains you’ll get. Besides the motivation also a section on the questions you should ask yourself. Martin Fowler has also a writing on that we could address: https://martinfowler.com/bliki/MicroservicePrerequisites.html

Why “monolith to microservices”? In the iSAQB IMPROVE training are a lot of attendees who are interested in breaking up their huge monolith. We do have answers on that, but actually FLEX and IMPROVE combined could bring a lot of benefit.