спасибо, пойду думать! доброго вечера

Я не знаю, что вы там строите, но если это стартап и у вас все привазано к API, то это плохой знак.
Если интересно, могу вас по бизнесовым вопросам проконсультировать. Венчур, продажи и вот это вот все.

> но если это стартап и у вас все привазано к API, то это плохой знак

А можно развернуть это?

Вы каждого юзера хотите отдельно биллить и ограничивать, правильно?

Если коротко, то венчурный бизнес не любит зависимость от API. Это плохо как для привлечения инвестиций, так и для роста бизнеса.

Почему:
а) мажорные обновления могут вызывать тотальный факап всего сервиса
б) закрытие (в данном случае маловероятно, но все же) вообще ведет к краху всего бизнеса и таких примеров было много
в) отсутсиве ноу-хау 😉
г) жесткое ограничение по нагрузкам, где приходится изобретать костыли

Все эти факторы мешают расти, обслуживать клиентов и привлекать инвестиции для роста

А "привязано к API" - в этом случае, это как? Ведь, по сути, мало что сейчас никак не привязано к API.

Грубо говоря, зависимость от одного конкретного поставщика

если это стартап, им рано об этом еще

То есть - вы за исключительно мультиклауд?

пусть стартанут, может вообще не взлетит

Нет. Я не об этом.

А о чём? Один облачный провайдер - один поставщик. Или вы что-то другое имели ввиду?

Я вообще не про облачных провайдеров. Я про то, что когда бизнес зависит от конкретного API — это узкое горлышко этого бизнеса и им невозможно управлять.

Как альтернатива заказ такси. Допустим, делаем заказ такси, но он работает на API Gettaxi. Как только Gettaxi вас отключает, меняет API или вообще его ограничивает — все рушится.

То есть услуга может оказываться, пока она оказывается вам ОДНОЙ конкретной компанией

Ну так бывает, но реальность такова, что не всегда есть альтернативы.
Вот разрабатываете вы приложения для AppStore, нопремер... )

AppStore это Маркетплейс. Соответственно это товар, который прожает через маркетплейс.

Который принадлежит одной компании

до определенного размера думаю этот риск можно считать достаточно низким и маловероятным, хотя диверсифицироватся и можно но не всегда возможно и достаточно дешево

в контексте AWS  тут нет смысла рассматривать этот риск, в отличии от gcp

В случае, если вы пользуетесь сервисом AWS, я бы сказал, можно рискнуть и считать, что завтра AWS не закроется. Если закроется - будут проблемы у тех, кто даже не знает, что эта абреввиатура означает.