As always, it's a matter of where you draw the line around what counts as part of your app, and what you count as external dependencies. The level of abstractio

As always, it's a matter of where you draw the line around what counts as part of your app, and what you count as external dependencies. The level of abstraction that is safe to use changes by use case. It wasn't all that long ago that it would be unusual for a programmer to not understand assembly code - and before that, to have an understanding of how transistors/vacuum tubes are assembled to make complex circuits. But of course, nowadays for web development everybody trusts the CPU architecture to operate efficiently, the OS to do reasonable things, TCP/IP to remain reliable, browsers to support Javascript, etc etc. In the last few years we've even seen some stabilization even around the historically churny realm of javascript UI libraries - most developers don't even need to know how React works under the hood, let alone how V8 runs. The reasonable level of abstraction has grown immensely, and the number of web developers who deeply understand the true stack is probably fewer than 10. For most use cases, a service that abstracts over the various cloud provider options is perfectly fine - and when its not, that's generally a "good problem" to have (because it means your app is having scale issues). All business models are meant to give value to the business. The successful ones also give value to the customers.