Если вы ориентированы на западный рынок то скорее всего AWS будет правильным выбором. А на отечественном рынке рекомендую посмотреть в сторону Yandex.Cloud.
Такой номер конечно можно провернуть, но уровень доверия к провайдеру очень сильно упадет. А доверие это очень важно для провайдера, сильно помогает продавать. Хотя конечно бывает разное.
А можно немного конкретнее, про цены на облачных администраторов? Реально хочется разобраться в этой теме, может получится приличный материальчик. Пока кажется, тут я перекрестился, что этим занимаются примерно те же люди, примерно за те же деньги.
Вообще я бы переформулировал в) реализовать спецпроект для большого подрядчика, на внешних технологиях, который может выдержать пиковые, но кратковременные нагрузки связанные с рекламной активностью.
Делитесь, хабр для того и создан. Я бы правда предложил следующий вариант: попробовать в вашем облаке возможности serverless и оформить впечатления в виде статьи на нашем хабе. Будет хороший материал с личным опытом и мнением.
СУБД (например, есть Serverless решения — YDB, скоро небольшой материальчик жахну на эту тему).
Лучше декомпозировать задачу и автоматически у вас ограничится время выполнения. Если вы возьмете приложение и реально построите его в Serverless-стиле то много памяти вам для каждой отдельной функции и не понадобиться. При этом «предрасчет» или «кеширование» дает некий результат и именно этот результат может быть входом для следующей функции.
Прям для эксперимента возьмите алгоритм, накидайте блоков, прикиньте: что каждый блок реализует некую функцию, и вот у нее вход, вот выход, вот ветвления разных вызовов функций.
Для сложных, емких задач, которых не так много, лучше использовать специализированные инструменты. Например, для ML почти у каждого взрослого облака что-то есть, например Yandex DataSphere
За пять лет активно участвовал в 98 сервисах/микросервисах.
Сейчас активно используется 25, я к ним уже не имею отношения.
Язык проекта менялся у 62.
Способ дистрибуции менялся у 97 проектов.
После запуска проекта не менялся только один проект.
Все проекты разрабатывались для запуска в облаках.
Я не показателен и нужно смотреть отрасль, окружение. Но если вы попробуете проанализировать ваше окружение то есть не нулевая вероятность что прийдете к следующим выводам. За три-пять следующих лет большая частью ваших проектов будет переписана, переделана и способ дистрибуции будет сменён. А еще есть вероятность, что и у значительной части проектов и язык разработки будет сменен.
Очень много вопросов в одном комментарии. Сразу на все не ответить. Прежде всего начнем с того что «очень платное облако» дает возможность потестировать и поучиться вполне себе бесплатно через программу free tier. Для примера, 1 000 000 вызовов функций каждый месяц бесплатно.
Реализация через стэйтлесс функции это правильный путь использования и конечно он не всем подходит. Вопрос декомпозиции приложения всегда непростой. В идеале построить бизнес-процесс, где каждым этапом является вызов небольшой функции. В сложных случаях получается развесистая схема, но она того стоит. Особенно если вы понимаете что большая часть вызовов почти никогда не дергается.
Большую часть вопросов можно обсудить в комьюнити, в нем активно участвуют разработчики сервисов и могут пояснить за нюансы.
Go с его встроенной асинхронностью отлично подходит для I/O bound задач, в том числе нашей, когда нужно уметь обрабатывать десятки и сотни гигабит трафика.
Мы отлично умеем писать высокопроизводительный код на плюсах, но поняли, что порог входа тут достаточно высок. Поэтому сделали ставку на Go, чтобы в том числе быстрее нанимать, растить команду и погружать в наши проекты.
Раньше точно была YDB сейчас возможно PostgreSQL, но это я еще уточню. Про YDB прямо сейчас в работе статья. Про шардирование тема интересная, если коллеги в коменты не прийдут, то нападу на них и сделаем статью.
На сколько я понимаю по тексту:
1. Используется стандартная утилита AWS CLI для работы с Object Storage.
2. А при работе с gatsby подключается плагин S3, в котором по умолчанию конечно AWS S3 перенастроен на использование Yandex Object Storage — storage.yandexcloud.net
Лучше декомпозировать задачу и автоматически у вас ограничится время выполнения. Если вы возьмете приложение и реально построите его в Serverless-стиле то много памяти вам для каждой отдельной функции и не понадобиться. При этом «предрасчет» или «кеширование» дает некий результат и именно этот результат может быть входом для следующей функции.
Прям для эксперимента возьмите алгоритм, накидайте блоков, прикиньте: что каждый блок реализует некую функцию, и вот у нее вход, вот выход, вот ветвления разных вызовов функций.
Для сложных, емких задач, которых не так много, лучше использовать специализированные инструменты. Например, для ML почти у каждого взрослого облака что-то есть, например Yandex DataSphere
Я не показателен и нужно смотреть отрасль, окружение. Но если вы попробуете проанализировать ваше окружение то есть не нулевая вероятность что прийдете к следующим выводам. За три-пять следующих лет большая частью ваших проектов будет переписана, переделана и способ дистрибуции будет сменён. А еще есть вероятность, что и у значительной части проектов и язык разработки будет сменен.
Реализация через стэйтлесс функции это правильный путь использования и конечно он не всем подходит. Вопрос декомпозиции приложения всегда непростой. В идеале построить бизнес-процесс, где каждым этапом является вызов небольшой функции. В сложных случаях получается развесистая схема, но она того стоит. Особенно если вы понимаете что большая часть вызовов почти никогда не дергается.
Большую часть вопросов можно обсудить в комьюнити, в нем активно участвуют разработчики сервисов и могут пояснить за нюансы.
Go с его встроенной асинхронностью отлично подходит для I/O bound задач, в том числе нашей, когда нужно уметь обрабатывать десятки и сотни гигабит трафика.
Мы отлично умеем писать высокопроизводительный код на плюсах, но поняли, что порог входа тут достаточно высок. Поэтому сделали ставку на Go, чтобы в том числе быстрее нанимать, растить команду и погружать в наши проекты.
К слову, мы нанимаем: раз, два, три.
1. Используется стандартная утилита AWS CLI для работы с Object Storage.
2. А при работе с gatsby подключается плагин S3, в котором по умолчанию конечно AWS S3 перенастроен на использование Yandex Object Storage — storage.yandexcloud.net
Все законно +)