Why choose Fabric for enterprise application development?

Ethereum's smart contract development has gained traction recently. However, few enterprise-level blockchain applications choose Ethereum for development. Based on experience in actual project applications, I think Ethereum is not suitable for enterprise-level applications for three reasons: inadequate permission control; the high technical threshold and cost of checking and correcting Ethereum smart contract errors; and the uncertainty of calling Ethereum smart contracts. Fabric has a great advantage in these aspects which I will elaborate on below.

A. Multi-Dimensional Permission Control
The development of business-oriented applications is often complex. In contrast, Ethereum is very convenient. You only need to start the client wallet and then you can start developing smart contracts as shown below.

Or you can use Remix:

However, when everything is ready, the customer tells me that their business data is confidential. Only data of authorized nodes can be shared, and data of unauthorized nodes should be isolated. Then we find that there is no data isolation or permission authentication on Ethereum.

The advantage of Fabric is obvious. Fabric offers multi-dimensional certificate permission control, data isolation between nodes supported by channels, and Docker-based deployment of smart contracts. Fabric can meet customer needs and is probably already one step ahead. We can see this from the following certificate directory structure:
.
├── ordererOrganizations
│ └── example.com
│ ├── ca
│ ├── msp
│ ├── orderers
│ ├── tlsca
│ └── users
└── peerOrganizations
├── org1.example.com
│ ├── ca
│ ├── msp
│ ├── peers
│ ├── tlsca
│ └── users
└── org2.example.com
├── ca
├── msp
├── peers
├── tlsca
└── users

B. Low Troubleshooting Threshold
I wonder how Solidity developers feel when they hear about the bugs in Ethereum smart contracts. I, for one, feel like it gets my heart beating and my blood pumping.

When I was involved in business development previously, I followed the following process:

When bugs occurred, I went through the following process:

However, the reality is like so:

When bugs occurred, I went through the following process:

Since I started developing Ethereum smart contracts, my development process has been as follows:

When bugs occur, this is what I face:

On the other hand, since I started developing Fabric smart contracts, my development process has been as follows:

When bugs occurred, I went through the following process:

Now that's how it was in the good old days!

C. Calling Smart Contracts
What comes to your mind when you hear about API calls? The things that come to my mind are RESTful, HTTP, API, TCP, etc. However, since the use of Ethereum, the way of calling API has changed. First of all, you should have an API like this:
[{"constant":true,"inputs":[],"name":"name","outputs":[{"name":"","type":"string"}],"payable":false,"stateMutability":"view","type":"function"},{"constant":false,"inputs":[{"name":"_spender","type":"address"},{"name":"_value","type":"uint256"}],"name":"approve","outputs":[{"name":"","type":"bool"}],"payable":false,"stateMutability":"nonpayable","type":"function"}...
Then the call you initiate may be like this:
0x23b872dd0000000000000000000000006e80d21aa536cefdb4a6d5f879af619ef97157760000000000000000000000009f5217d4a04a10649547f5ccd835e2d69efc2a0e00000000000000000000000000000000000000000000000006f05b59d3b20000
Looking at a call like this, I feel helpless.

Let's take a look at Fabric's contract call, which is as follows:
peer chaincode query -C $CHANNEL_NAME -n mycc -c '{"Args":["query","a"]}'

Of course, it may also be like this:
var request = {targets: peerNames,chaincodeId: chaincodeName,
fcn: fcn,args: args,chainId: channelName,txId: tx_id};
let results = await channel.sendTransactionProposal(request);

Json is used for transferring parameters, so this puts me at ease.

D. Summary
Having said all of the above, in fact, enterprise-level applications focus more on permission control, data isolation, development costs, operation and maintenance costs, etc. Ethereum, as the most authoritative smart contract public chain currently, obviously does not focus on this aspect. Fabric is designed for enterprise-level blockchain platforms, and is relatively more suitable for enterprise applications than Ethereum.