initial content for framework #34
Conversation
Co-authored-by: Bill Mulligan <[email protected]>
Co-authored-by: Bill Mulligan <[email protected]>
Co-authored-by: Bill Mulligan <[email protected]>
Co-authored-by: Bill Mulligan <[email protected]>
Co-authored-by: Bill Mulligan <[email protected]>
Co-authored-by: Bill Mulligan <[email protected]>
doc/README.md
Outdated
| * [Hardware support](./best_cnf_dev.md#3.0) | ||
| * [Microservice](./best_cnf_dev.md#4.0) | ||
| * [Compatiblity](./best_cnf_dev.md#5.0) | ||
| * [Stateless](./best_cnf_dev.md#6.0) |
There was a problem hiding this comment.
There are CNFs that have a role in managing state such as the CHF (Charging Function) as part of a 5G Core. I certainly understand the point of developing stateless microservices but I feel we ALSO need to address how state can be managed in acceptable cloud native ways when necessary. This type of guidance would be especially valuable for those applications (CNFs) that are managing state under very high transaction volumes (10-100k's of TPS) - again think of the CHF as just one example.
There was a problem hiding this comment.
I just think we need to be clear the difference between application state and transaction / session state and so having a series of stateless microservices (which are therefore immutable) deal with stateful transactions (where that state is held in e.g. CHF) isn't necessarily a problem.
There was a problem hiding this comment.
Maybe CHF is not the best example. Let's take the CCS or UDR. Both of these are the source of state for other NFs in the 5G Core. They not only are state aware is my point, they own the state. So if you are vendor designing one of these functions (or a service provider looking to buy one of these functions) then best practices for how state should be maintained for these types of NFs is going to be very valuable/important.
There was a problem hiding this comment.
I don't disagree - but even with those applications there will be stateful components (e.g. datastore) and stateless components that simply process transactions and perform logic. But as a whole the CCS application is stateful, from the point of view of customer state. But many components within CCS will be stateless from the point of view of needing to have prior knowledge of that customer state to be able to process transactions and perform business logic - they just accept an API instruction and product a response.
taylor
requested review from
vukg,
CsatariGergely,
xmulligan,
fkautz and
electrocucaracha
|
@pgoyal01 I think your items have been addressed. Please re-review |
doc/README.md
Outdated
| <a name="intro"></a> | ||
| ## Introduction | ||
|
|
||
| The goal of this group is to define a set of practices that can be used to evaluate how [cloud native](https://github.com/cloud-native-principles/cloud-native-principles) a CNF is. CNFs can be evaluated against those best practices through test cases that are developed by other open source projects like the [CNF Test Suite](https://github.com/cncf/cnf-conformance/blob/master/README-testsuite.md) |
There was a problem hiding this comment.
The CNF Test Suite doesn't specifically set out to test the Cloud Native principles. In fact, Majority of the conformance tests are for Kubernetes rather than cloud native.
There was a problem hiding this comment.
@pgoyal01 i believe the plan is to expand the scope of cnf-conformance to implement those best practices we define here.
|
|
||
| As the telco industry transitions to cloud native ways of thinking, working, and operating, these best practices will serve as the industry gold standard of what cloud native means in practice. They can be used for a variety of purposes including in RFPs, to guide daily operations, and to do internal testing. | ||
|
|
||
| Cloud native is not set point. The industry, technology, and best practices will continually evolve with each other. Thus, being cloud native should not be seen as pass/fail, but rather a spectrum. While it may be impossible for anything to be completely cloud native, implementing even one best practice can help improve business outcomes for everyone involved. Implementing more of them can have an even greater impact. However, depending upon the type of CNF, different best practices may have a greater or smaller impact on the ultimate business outcome. |
There was a problem hiding this comment.
I think there have to be some principles designated as being required for something to be cloud native. Otherwise, anything and everything could be made out to be cloud native.
There was a problem hiding this comment.
@pgoyal01 i think the point here is as long as it proves to be best practices, backed up with data and user story, it indeed can be considered cloud native as there is no strict definition of what is cloud native.
There was a problem hiding this comment.
@rabi-abdel Agree that there is no strict definition of cloud-native and that is why it is important to not just list them and state that even if one practice is adopted that is good enough. We could have the situation with widely different CNFs for the same NF depending upon the vendor or version.
Wouldn't it be better, if a required set of practices is defined to qualify as cloud-native?
doc/README.md
Outdated
|
|
||
| The goal of this group is to define a set of practices against which CNFs can be evaluated to determine how [cloud native](https://github.com/cloud-native-principles/cloud-native-principles) a CNF is based on those best practices. CNFs can be evaluated against those best practices through test cases that are developed by other complimentary open source projects like the [CNF Test Suite](https://github.com/cncf/cnf-conformance/blob/master/README-testsuite.md) | ||
|
|
||
| The goal of CNF WG is not trying to define what cloud native for netowrk function is. CNF WG will rely on other industry inititaves (such as CNCF TUG) to define that. |
There was a problem hiding this comment.
I don't think there is a good definition of cloud native for a network function elsewhere. We've discussed in the channel among ourselves what matters and doesn't matter, and none of that is yet written down. So I don't think we can or should rule ourselves out of documenting it.
we are talking about cloud native or more specifically kube native state Co-authored-by: Bill Mulligan <[email protected]>
Co-authored-by: Ian Wells <[email protected]>
|
[Bryan] We should change it from "Stateless" to "State" because not everything is stateless and the larger discussion is around state. |
handling state in a cloud native way /kubenative way Co-authored-by: Bill Mulligan <[email protected]>
Co-authored-by: Bill Mulligan <[email protected]>
No description provided.