Комментарии 11
Под оригинальной статьёй с десяток заплюсованных комментариев о том что автору не нужен AWS API Gateway и этот самый гейтвей стоит конских денег.

А вообще, мне не очень понятно почему так плюсуют статью с критикой Serverless от человека который сам же признаётся что весь его ресёрч это «решил потратить несколько часов на изучение Serverless»
Как бы понятно, что хорошо для старта но плохо для состоявшегося сервиса. Т.е. на сегодя схема экономии такая:

1. Сначала юзаете Serverless. Если пользователь пошел — переходите к п. 2. Иначе — не тратите много денег.
2. Потом лучше Kubernetes как сервис (от DO или подобных).
3. Далее арендуете сервера у типа hz, платите админу и он вам все ручками настроит + от $50 в мес. за поддержку (ну или на зарплату, если уж совсем все хорошо).
4. Новый этап — покупаете физ. сервера, ставите на колокейшн.
5. Ну и если уж совсем все хорошо — делаете свой датацентр как Google.
Я бы сказал, что на пункте 2 можно и остановится. Очень многие компании используют облака и довольны функционалом. А ещё больше компаний переезжают с физических серверов в AWS и GCP, ибо масштабирование и куча сервисов, упрощающих эксплуатацию инфраструктуры, тот же самый autoscaling, RDS, S3, BigTable, EMR и т.д.
Поддержка своего парка железных серверов, даже арендованных, сомнительное удовольствие. Когда их количество исчисляется десятками, постоянно какое-либо железо будет выходить из строя и нужен человек, который следит за всем этим на полный рабочий день. При повышении до сотни нужно искать второго человека на полную ставку. И это с учетом того, что фактическую замену сломанного железа производят сотрудники датацентра удаленно.
Ну а свои сервера, это ещё больше заморочек. Особенно интересна процедура роста инфраструктуры при росте популярности сервиса. Когда приходится сильно заранее заказывать сервера и ставить их в стойки, где они впустую простаивают до тех пор, пока их не введут в эксплуатацию, потому что вырос трафик. Но к этому времени надо уже заказать следующую партию серверов.
Ну и плюс удалённая замена деталей в таком случае стоит значительно дороже.

Моё мнение основано на опыте работы со всеми приведёнными конфигурациями.
Подскажите пожалуйста, а если уже есть небольшой парк собственных серверов (10-15) и собственный штат администраторов и оно уже работает нормально лет 5(деплои/апдейты/секьюрити), то стоит ли пробовать переносить архитектуру на Кубернетес, например в GCP?

Просто я пока что не могу ответить на главный вопрос: А оно нам вообще надо? И стоит ли менять, то что и так уже работает.
P.S. Нагрузка не супер большая, во главе угла стоит безопасность данных (работа с деньгами, но не банковское ПО).
ShadowOfClown
Kubernetes — это не серебряная пуля в инфраструктуре. Кривая обучения очень крутая и надо иметь достаточный опыт, чтобы использовать его в production. Kube тянет за собой смену всего стека: способ развёртывания серверов, обновление самого k8s, деплой приложений, pipeline для создания и поддерживание контейнеров в актуальном состоянии и тому подобное. Это может быть следующей ступенью развития вашей инфраструктуры.
Начните использовать его в dev/staging environment, но не спешите переводить прод на него, пока не набьёте руку и не получите достаточно опыта!
Самое странное что со стороны разработки все наоборот, сначала пилите монолит, а если клиент прошел то пилите на микросервисы до тех пор, пока до serverless не дойдет.
Я, честно говоря, не понимаю, зачем автор оригинальной статьи так суетится. AWS, контейнеры, балансировка нагрузки, Linux и все только для того, чтобы захостить несчастный .Net API на трех мелких инстансах для какой-то игрушки? Если бы он был чуть проще и взял три готовых Azure Cloud Services инстанса A1 v2, он уже получил бы экономию в 264$ в год, балансировку из коробки, винду, 2Гб оперативки вместо 1.75 и забыл бы о контейнерах как о страшном сне, просто заливал бы пакеты и не парился ни о каких докерах. А если реально хочется сэкономить, то может и облака не нужны? На 160 баксов в месяц он можно купить просто зверский VPS и кувыркаться там как душе угодно.
Более менее автоматическое масштабирование? (а вдруг статью на хабре выложат и все пойдут смотреть что за игра, упс). Отсутствие единой точки отказа? Модные слова в резюме?
Ну, это недостатки только последнего варианта, единственный VPS действительно был бы немасштабируемым решением. Но с другой стороны, судя по количеству часов в счете, автомасштабированием он активно не пользуется. А с точки же зрения аптайма, самым слабым звеном тут является сам владелец сервиса :)
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.