Hi Jorge,
what have changed in the microservices landscape, apart from deployment techniques, in the last 5 years
I think the biggest change is maturity. 5 years ago, microservices were primarily an architectural approach where only big tech companies (Amazon, Netflix, Google...) had a known record of success; now, it's achievable, with much less cost, by companies operating at a much smaller scale.
As you say, deployment technique maturity - containers, schedulers, even FaaS - have played a huge part. Microservices aren't feasible if you can't deploy and operate many services independently and rapidly!
But I think it's also the availability of mature microservice frameworks in multiple languages; tracing and monitoring tools that can cope with the scale of microservice data; wider understanding of design techniques and failure modes in distributed systems...
when would you say that it's necessary to start talking about to change the team's dynamic to build microservices? In terms of the size or the type of the project/system?
The two things that change the dynamic the most are:
1. having more than one team building services
2. having multiple services in production - let's say, exceeding more services than engineers ;)
I think these are two crucial starting points to consider your team dynamic. However, you might not see actual dysfunctions or reduced effectiveness until much later; so it's always good to change iteratively - adjust the behaviour, review how that works, and repeat - until you have a model that works well and drives a healthy culture in your team(s).