Chaincode as a service (CaaS) content

[joshhus]

@mbwhite I reviewed the 2 pages below for CaaS. This issue is for comments and questions that may be applicable to a docs update, please ignore what is not.

https://github.com/hyperledger/fabric-samples/blob/main/test-network/CHAINCODE_AS_A_SERVICE_TUTORIAL.md

https://hyperledger-fabric.readthedocs.io/en/latest/cc_service.html

Generally, the .md GitHub file above seems to be an update to the existing published content / html file below it.

[joshhus]

https://github.com/hyperledger/fabric-samples/blob/main/test-network/CHAINCODE_AS_A_SERVICE_TUTORIAL.md

• Summary - it's quite detailed as a how-to, and mentions the advantages of using CaaS. These advantages could be expanded on a bit in order to provide guidance for a decision-maker - on using CaaS vs. chaincode on channel. Likewise, any risks or drawbacks, or non-use case examples, could be included. It sounds like you have to use this in a K8s environment.
• Why for a test network specifically. Implication is it's not for production, perhaps not yet.
• What's the diff between this content and the already published - https://hyperledger-fabric.readthedocs.io/en/latest/cc_service.html ? I will be looking into this as well.
• Any performance considerations compared to chaincode on channel. Seems better for on-channel peers assuming good connectivity. Does each channel peer connect to / use the external peer, or is there a single "anchor" peer for CaaS that represents the channel.
• Any considerations for backup and restore - e.g. a reliance on a single peer (risk) and org., compared to multi-peer and org on-channel. Likewise for security of network wrt an external peer.
• Any other considerations or drawbacks to running chaincode externally. e.g. for users other than the developer - other orgs on the channel that call it.
• Are any types of chaincode or apps more appropriate for CaaS vs. on channel. Any use cases to demonstrate that. (e.g. is system chaincode still used or supported in v2.4.)
• Running with multiple peers as a new section implies that this is optional. The intro text implies otherwise, at least wrt architecture. So clearly define what this means up front - running w multiple peers - required, optional, recommended, implications/considerations, and how to decide. Are these external CaaS peers or on-channel peers?
• "However the as the" typo needs a fix.

[joshhus]

https://hyperledger-fabric.readthedocs.io/en/latest/cc_service.html

• Okay so the .md topic above seems to be updates to THIS published .html docs page "Chaincode as an external service".
• Tweak language - "2.0 supports" to - "2.0 introduced" ... i.e. support goes beyond 2.0 to 2.4 presumably, so 2.x supported.
• Chaincode (smart contracts) generally run on a channel by multiple orgs/peers, right. Are CaaS considerations, for the other on-channel orgs, explained -- i.e. one org managing external chaincode that other orgs on the channel have to clone internally, or invoke externally. This may be the external chaincode endpoint and TLS info that all other orgs/peers then call. Or covered in the External Builders and Launchers topic, tba.
• Is there an appreciable difference between "Chaincode as an external service" (current page title) and "Chaincode as a service" (.md draft title)? The former implies we also have chaincode as an internal service.
• The rest of this published page are the how-tos for setting up and running external chaincode. This seems to be updated / reflected in the .md file above, tba.

[mbwhite]

Hello - sorry @joshhus should have go to this sooner..

Why for a test network specifically. Implication is it's not for production, perhaps not yet. This is referencing the test-network in fabric samples, rather than implying that this is not for production

What's the diff between this content and the already published ? That is for go only, and also is quite dated now

Any performance considerations compared to chaincode on channel. Any chaincode will be connected over a network to the peer, irrespective of how or what started it. If you run the container yourself the biggest risk is making mistakes, eg not giving it enough resources.

Use cases etc.... Applicable in all scenarios, but especially for anything K8S based.

Terminology It was never really clear in the start sadly; I'm trying to stick to Chaincode-as-a-service to refer to the pattern of you, the user, runs you own chaincode container, and gives the peer the connection information to it where to find it.

The word external doesn't add anything - there's nothing 'internal'.

On debugging specifically

I'm adding more tutorial focussed content in this doc. https://github.com/hyperledgendary/fabric-contract-debug-scenario