Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
atuldevp opened this issue Mar 7, 2020 · 1 comment
Open

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

atuldevp opened this issue Mar 7, 2020 · 1 comment

Comments

@atuldevp
Copy link

atuldevp commented Mar 7, 2020

(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.

@xmulligan
Copy link
Contributor

Do you have a PR you would like to open on this?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants