История изменений

1. Если твоя ЦА в России, то AWS и прочие Google сразу идут лесом, потому что закон о персональных данных, блокировки РКН и прочее веселье. Ориентируйся на Яндекс.Облако и другие местные провайдеры. Сразу скорректируется список доступных сервисов.

2. Я бы просто сделал обычное бекэнд приложение на своём любимом стеке и упаковал его в обычный Docker контейнер и его можно было бы запускать на любом облаке, а также self-hosted без модификации.

3. В качестве хранилища файлов S3 без использования vendor-specific расширений, чтобы можно было одним изменением конфига юзать хоть AWS, хоть self-hosted Minio (+ S3 не предоставляет сейчас только ленивый хостер).

3. В качестве БД надо посмотреть, что есть у выбранного хостера. Вроде как в некоторых облаках есть всякие Postgres и Redis совместимые сервисы. Соответственно, можно использовать их сохраняя возможность мигрировать на self-hosted или другое облако.

Вообще, по моему опыту работы в крупных западных компаниях, они только и делают, что мигрируют из одного облака в другое (туда где предложили льготный тариф) несколько лет, а потом повторяется (срок льготного тарифа на прежнем месте истёк, зато получилось выбить скидку у нового облака). Так и скачут между AWS/GCP/Azure, а заодно сотрудникам постоянно есть чем заняться.

Если ты маленький, то у тебя нет ресурса выбивать льготные тарифы, а также выделять несколько команд под миграцию на новое облако, так что я бы перестраховался не завязываясь на слишком vendor-specifc решения. У всех базовых компонентов должна быть self-hosted версия, даже если в итоге будет использована облачная.

Исключением может быть, если у тебя какая-то особая задача, которая решается в несколько строчек кода с помощью конкретного уникального облачного сервиса и твоя бизнес модель как раз за счёт этого быстро выйти на рынок, а потом у тебя будут миллионы долларов инвестиций и ты уже разберёшься, что делать. Или если ты нашёл облако с щедрыми бесплатными лимитами (типа как у Firebase) и надеешься долгое время в них укладываться (а если проект не взлетит, то вообще никогда платить не придётся).

1. Если твоя ЦА в России, то AWS и прочие Google сразу идут лесом, потому что закон о персональных данных, блокировки РКН и прочее веселье. Ориентируйся на Яндекс.Облако и другие местные провайдеры. Сразу скорректируется список доступных сервисов.

2. Я бы просто сделал обычное бекэнд приложение на своём любимом стеке и упаковал его в обычный Docker контейнер и его можно было бы запускать на любом облаке, а также self-hosted без модификации.

3. В качестве хранилища файлов S3 без использования vendor-specific расширений, чтобы можно было одним изменением конфига юзать хоть AWS, хоть self-hosted Minio (+ S3 не предоставляет сейчас только ленивый хостер).

3. В качестве БД надо посмотреть, что есть у выбранного хостера. Вроде как в некоторых облаках есть всякие Postgres и Redis совместимые сервисы. Соответственно, можно использовать их сохраняя возможность мигрировать на self-hosted или другое облако.

Вообще, по моему опыту работы в крупных западных компаниях, они только и делают, что мигрируют из одного облака в другое (туда где предложили льготный тариф) несколько лет, а потом повторяется (срок льготного тарифа на прежнем месте истёк, зато получилось выбить скидку у нового облака). Так и скачут между AWS/GCP/Azure, а заодно сотрудникам постоянно есть чем заняться.

Если ты маленький, то у тебя нет ресурса выбивать льготные тарифы, а также выделять несколько команд под миграцию на новое облако, так что я бы перестраховался не завязываясь на слишком vendor-specifc решения. У всех базовых компонентов должна быть self-hosted версия, даже если в итоге будет использована облачная.

Исключением может быть, если у тебя какая-то особая задача, которая решается в несколько строчек кода с помощью конкретного уникального облачного сервиса и твоя бизнес модель как раз за счёт этого быстро выйти на рынок, а потом у тебя будут миллионы долларов инвестиций и ты уже разберёшься, что делать. Или если ты нашёл облако с щедрыми бесплатными лимитами (Firebase) и надеешься долгое время в них укладываться (а если проект не взлетит, то вообще никогда платить не придётся).

1. Если твоя ЦА в России, то AWS и прочие Google сразу идут лесом, потому что закон о персональных данных, блокировки РКН и прочее веселье. Ориентируйся на Яндекс.Облако и другие местные провайдеры. Сразу скорректируется список доступных сервисов.

2. Я бы просто сделал обычное бекэнд приложение на своём любимом стеке и упаковал его в обычный Docker контейнер и его можно было бы запускать на любом облаке, а также self-hosted без модификации.

3. В качестве хранилища файлов S3 без использования vendor-specific расширений, чтобы можно было одним изменением конфига юзать хоть AWS, хоть self-hosted Minio (+ S3 не предоставляет сейчас только ленивый хостер).

3. В качестве БД надо посмотреть, что есть у выбранного хостера. Вроде как в некоторых облаках есть всякие Postgres и Redis совместимые сервисы. Соответственно, можно использовать их сохраняя возможность мигрировать на self-hosted или другое облако.

Вообще, по моему опыту работы в крупных западных компаниях, они только и делают, что мигрируют из одного облака в другое (туда где предложили льготный тариф) несколько лет, а потом повторяется (срок льготного тарифа на прежнем месте истёк, зато получилось выбить скидку у нового облака). Так и скачут между AWS/GCP/Azure, а заодно сотрудникам постоянно есть чем заняться.

Если ты маленький, то у тебя нет ресурса выбивать льготные тарифы, а также выделять несколько команд под миграцию на новое облако, так что я бы перестраховался не завязываясь на слишком vendor-specifc решения. У всех базовых компонентов должна быть self-hosted версия, даже если в итоге будет использована облачная.

Исключением может быть, если у тебя какая-то особая задача, которая решается в несколько строчек кода с помощью конкретного уникального облачного сервиса и твоя бизнес модель как раз за счёт этого быстро выйти на рынок. Или если ты нашёл облако с щедрыми бесплатными лимитами (Firebase) и надеешься долгое время в них укладываться (а если проект не взлетит, то вообще никогда платить не придётся).

1. Если твоя ЦА в России, то AWS и прочие Google сразу идут лесом, потому что закон о персональных данных, блокировки РКН и прочее веселье. Ориентируйся на Яндекс.Облако и другие местные провайдеры. Сразу скорректируется список доступных сервисов.

2. Я бы просто сделал обычное бекэнд приложение на своём любимом стеке и упаковал его в обычный Docker контейнер и его можно было бы запускать на любом облаке, а также self-hosted без модификации.

3. В качестве хранилища файлов S3 без использования vendor-specific расширений, чтобы можно было одним изменением конфига юзать хоть AWS, хоть self-hosted Minio (+ S3 не предоставляет сейчас только ленивый хостер).

3. В качестве БД надо посмотреть, что есть у выбранного хостера. Вроде как в некоторых облаках есть всякие Postgres и Redis совместимые сервисы. Соответственно, можно использовать их сохраняя возможность мигрировать на self-hosted или другое облако.

Вообще, по моему опыту работы в крупных западных компаниях, они только и делают, что мигрируют из одного облака в другое (туда где предложили льготный тариф) несколько лет, а потом повторяется (срок льготного тарифа на прежнем месте истёк, зато получилось выбить скидку у нового облака). Так и скачут между AWS/GCP/Azure, а заодно сотрудникам постоянно есть чем заняться.

Если ты маленький, то у тебя нет ресурса выбивать льготные тарифы, а также выделять несколько команд под миграцию на новое облако, так что я бы перестраховался не завязываясь на слишком vendor-specifc решения. У всех базовых компонентов должна быть self-hosted версия, даже если в итоге будет использована облачная.

Исключением может быть, если у тебя какая-то особая задача, которая решается в несколько строчек кода с помощью конкретного уникального облачного сервиса и твоя бизнес модель как раз за счёт этого быстро выйти на рынок.