Почему не стоит разрабатывать сайт под AWS и Google Cloud?

Хотим поделиться своими размышлениями, а, может, где-то и предостеречь от принятия очень популярных, но совсем невыгодных решений.Как уже очевидно из названия, речь пойдет про хостинг и выбор для размещения cloud сервера: когда лучше настраивать все самому, а когда все-таки пойти к AWS и Google Cloud.

Сперва чуть ликбеза, а затем пойдем в истории неуспеха. У наших западных клиентов крайне популярно сразу в требованиях прописывать «разработку под AWS».

AWS предоставляет огромное количество сервисов на все случаи жизни: базы данных, хранилища, различная способы вычислений. Если очень грубо описать, вы размещаете свой проект на AWS и не паритесь вообще о нагрузках. Чаще всего это Lambda, какая-нибудь БД и плюс файловое хранилище. Все автоматически масштабируется: париться, что делать в пике нагрузки, не нужно, можно спокойно забыть, что нужно увеличивать диск, если место закончится под наплывом загруженного контента. Звучит просто фантастически! Примерно по такой же схеме работает Google Cloud.

С другой стороны есть провайдеры облачных серверов, где дается голый сервер, инфраструктура, и сиди сам все делай. Мы используем DigitalOcean (да, ссылка партнерская, но мы не партнеры, просто хотим заработать 25$ за рекомендацию ✨).

Так вот давайте разовьем мифы про легкость и доступность первого варианта, и про недоступность второго.

На самом деле, ваше приложение не сможет скейлиться абсолютно автоматически при росте нагрузок без предварительной хорошей подготовки кода. Да, например, у вас выросла нагрузка, добавится + 100 серверов для выполнения кода, + 100 для БД, но чаще всего узкое горлышко во всех проектах — это БД. Вы все равно никак не сможете ускорить вычисления на стороне БД, и приложение рано или поздно умрет, если со стороны коды вы не сделали должной подготовки.

Большим минусом при размещении на AWS является то, что код целенаправленно создается для интеграции с AWS. То есть вы не пишете, например, что нужно подключиться к БД, а вместо этого пишете, что нужно подключится именно в БД на AWS. Таким образом вы уже обрекли свой проект на размещение исключительно на AWS.

И вот теперь давайте подойдем к самому интересному — цене.Один из наших проектов, который еще даже не был в продакшене, тратил на AWS в месяц 6k$. Вот обратная сторона медали для тех, кто думает, что все будет легко скейлиться.

Этому проекту повезло, — мы на ранней стадии уговорили клиента съехать с AWS. За 3 дня мы взяли серверов на 200$ на DigitalOcean, настроили все, взяли kubernetes, который позволяет скейлиться автоматически (но при этом мы можем и сами управлять процессами скейлинга), выпилили весь код, который взаимодействовал с AWS. Вуаля! 6k$ превратились в 200$ в месяц, а проект ничего не потерял в качестве. Да, мы потратили 3 дня разработчика, но возьмем, например, рейт 80$/ч и посчитаем, что уже в первом месяце все окупилось.

Забегу вперед и скажу, что у нас нет рационального ответа на вопрос, почему люди используют AWS и тратят огромные деньги на поддержку этой инфраструктуры.

Попробую сформулировать причины, почему я бы выбрал AWS, и тут же их опровергнуть:

1. Не требуются технические знания, все и так будет скейлиться. Нет, чудес не бывает. Все зависит от того, как вы напишите код. Просто, эмигрировав на AWS или свой сервер, вы с одинаковой вероятностью можете и там, и там упасть.

2. Нужен инженер, который будет поддерживать и настраивать. Он нужен в обоих вариантах. Только AWS, Google Cloud — это отдельные инфраструктуры, поэтому есть «специально обученные» люди, которые разбираются только в google cloud. Но, зачастую, эти люди совсем ничего не понимают в администрировании серверов на более низком уровне. Тот же администратор, который сделает вам kubernetes, отлично будет понимать, как все настроить, и на более низком уровне. А расходы получатся такие же, только последние специалисты на рынке представлены в большем количестве и по более низкой цене.

3. Казалось бы uptime выше. На самом деле нет, одинаково. В обоих случаях uptime серверов почти 100%, а работа вашего приложения будет зависит, скорее, от написанного кода и того, готов ли он к нагрузкам. А уж никак не от серверов.

4. Возможно, стартапам дают гранты на AWS и Google Cloud, а потом, когда твой код уже пропитан интеграцией с их сервисами, съезжать с них дорого и долго.

Есть еще неочевидный минус разработки под AWS: вы не можете поднять приложение локально. Представьте: разработчик что-то делает локально на компьютере, сам у себя поднял окружение, все проверил. Вот в истории с AWS это невозможно, требуется еще один инстанс AWS тестового окружения, очереди и БД, чтобы работать. Лично у нас бывает очень много тестовых площадок одновременно поднятых, где мы тестим разные фичи. Поэтому плюсуйте еще в расходы на AWS возможность поднятия нескольких окружений.

Делаем стартап, они подняли денег на ycombinator, все круто. Проект завершили за 3 месяца, все рады, все круто идет. И тут в конце всплывает идея, что нужно все разместить на Google Cloud. Этим будет заниматься какой-то сторонний специализированный инженер. При этом проект уже настроен на облачном сервере нашей командой, есть тестовые и продакшн площадки — все хорошо. В итоге идет третий месяц миграции проекта на Google Cloud, а запуск откладывается. Ну и где тут логика и оценка ценностей?

Наше мнение, да простят нас фанаты AWS, что на рынке это происходит просто из-за незнания способов администрирования и отсутствия возможности самому поднять сервер из Docker, Kubernetes. Лично мы не видим плюсов.

А чтобы вы не подумали, что мы какую-то ерунду прогоняем, так вот такие гиганты как basecamp, figma недавно такую же тему поднимали и решали.