Closed aheusingfeld closed 1 year ago
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] https://github.com/isaqb-org/curriculum-flex/blob/main/docs/02-modularization/02-learning-goals.adoc
@aheusingfeld Would we like to continue the discussion?
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.
In German language:
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?