Section 1.3 (1.3.1, 1.3.2 and 1.3.3) needs attention overall!

(I earlier reported an issue about 1.3.1 of loosely coupled systems)

I noticed that section 1.3.2 (which talks about orchestration) and 1.3.3 (deployment) need attention.

Section 1.3.2, which states that loosely coupled systems (microservices) need orchestration, needs attention. Referring to microservices architecture discussion, (https://microservices.io/patterns/data/saga.html), there are two different approaches mentioned for the loosely coupled systems, esp when data consistency required among microservices, which is often the case (even in case of CNFs).

I see section 1.3.2 written based on the assumption of 1.3.1 where containers are used for deployment by default (although this is true, it needs strong reasoning before reaching to conclusion). Still, then loosely coupled system (sagas) can opt for either choreography or orchestration, for data consistency among microservices.

It is also understood that for simple systems (few microservices), going with choreography is useful. Still, complex distributed systems (i.e telco), where hundreds of microservices exist, orchestration is a better choice for data consistency.

Moreover (section 1.3.3), there are multiple ways to deploy, microservices. A single microservice, when bundled as VM image/Docker image can be deployed on single/shared VM, shared/dedicated host, single container/pod or as serverless architecture. Each deployment option as advantages/disadvantages on its own, but given the fact that container and orchestration outweigh benefits over other deployment methods, choosing containers orchestration for deploying CNF is the de-facto way forward.

In the end, the goal should be to have immutable cloud-native infra platform (e.g Container-based but not only limited to the choice of technology), which takes care of application scaling, loose coupling among microservices and deployment (LCM) on its own, without worrying about underlying intricacies.