I was very obviously talking about interfaces, in other words “encapsulated complexity”. Note that I mention “concepts that you need to be aware of”. To be honest I almost feel a bit insulted by your response. I’m not a junior who has just learned about programming 3 months ago.
It’s the first time that I hear the words “encapsulated” and “systemic” complexity. They’re usually called “interface” and “implementation”, there’s no need to make up new fancy words for this.
Yes you don’t need to know how Heroku/Vercel work under the hood, and you don’t need to learn how Kubernetes/Docker/etc. work when using them, but that’s because Heroku/Vercel provide non-leaky abstractions.
Tanssi would be a leaky abstraction. They deploy RPC nodes for you, but you still need to know what RPC nodes are and how they work. They deploy collators for you, but you still need to know what collators are and how they work. They run servers for you, but (IIUC) it’s your job to compute the weights that are appropriate for these servers that you don’t have access to.
Using Tanssi reduces the necessity to learn about how to run a server, but does not reduce in any way the number of things (RPC nodes, weights, connectivity with the p2p network, etc.) that you have to deal with as a parachain builder. They simply can’t provide non-leaky abstractions, because “a chain” is not a precisely-defined concept at the moment.
There’s an argument to make that it’s still a good thing to use Tanssi, and I don’t disagree with that.
But in practice it’s not very difficult to recruit engineers that know how to run a software on a server, meanwhile it’s very difficult to find people who know what RPC nodes/weights/peer-to-peer networks/etc. are and how they work.
If you want to make parachain builders’ lives easier, the focus should therefore not be on making it easier to run servers, as this is common knowledge in the IT world, but on making it easier to deal with blockchain-specific stuff.