Раз уж я говорю, что я full-stack manager, то буду иногда писать и про те проекты, которые делаю своими руками, а также те проблемы, с которыми сталкиваюсь, или те наблюдения, которые делаю в процессе их разработки. На этих выходных переносил из Яндекс.Облака в AWS python-функцию, которая крутилась в serverless-режиме, собирала с нескольких сайтов и отправляла объявления в канал про сдачу в аренду недвижимости в Белграде.

Я написал её в октябре прошлого года, когда мы искали квартиру сами. В Сербии есть несколько классифайдов недвижимости с интерфейсами разной степени дружелюбности, и нам надо было максимально быстро находить на них новые объявления, чтобы быть в числе первых людей, которые их посмотрят. Рынок был такой, что если ты не посмотрел квартиру первым, то с большой вероятностью, ты её уже не снимешь. Так как у меня уже был довольно немаленький опыт написания парсеров (когда-нибудь я расскажу здесь, как записывался в итальянский визовый центр в Москве в 22 году и как парсил сайты производителей резины), я быстро проверил, что с 4 основных сайтов, которые нам нужны, можно довольно легко достать всю нужную нам информацию. Тогда передо мной встал вопрос, где и как поднять этот скрипт, чтобы он работал не у меня на ноуте, а регулярно отрабатывал независимо от обстоятельств.

Мой выбор пал на Яндекс.Облако. К тому моменту у меня уже был опыт разворачивания serverless-functions в Azure, AWS и Yandex.Cloud и именно у Яндекса это было делать удобнее всего. Честно говоря, я уже не помню на каком языке я поднимал что-то в Azure, но если речь идёт про python и функция требует установки зависимостей, то в AWS сначала придётся разобраться с тем, как собрать layer с этими зависимостями, чтобы его подключить. Когда ты занимаешься такими развёртываниями достаточно редко, а один layer используется только в одной функции, решение от Яндекса выглядит гораздо более понятным любому python-разработчику - просто положи файлик requirements.txt и при деплое система сама подтянет всё, что тебе нужно.

Второй момент, который в Яндекс.Облаке сделан в разы удобнее, чем в AWS - это поиск поднятых сервисов. В Амазоне реально сложно понять, какие конкретно сервисы ты используешь прямо сейчас и в каком объёме. Единственный интерфейс, который я для этого знаю - это биллинг. Но как бы биллинг это то, что обычно используется не для дискавери запущенных сервисов, а для того, чтобы постфактум разобраться в том, что же сожрало в предыдущем месяце столько денег. И это я ещё не говорю о том, что если вы, например, зашли в интерфейс управляния Lambda, а у вас оказался выбран какой-то левый регион, вы свои функции из другого региона тупо не увидите. В Яндексовом же Облаке все поднятые сервисы аккуратно собираются на дашбордик и очень просто понять, что ещё надо перенести в AWS и отключить.

Наверное, у вас сейчас возник логичный вопрос - если в Яндекс.Облаке всё так удобно, зачем же переносить всё в Amazon? И у меня на него есть два ответа. Первый более стратегический - да, в Амазоне многое не понятно интуитивно из интерфейса так, как понятно у Яндекса, но проблема в том, что если уж у Яндекса будет что-то не понятно, то шансы, что вы найдёте ответ на stackoverflow очень низкие. А Амазон, который годами используется миллионами разработчиками по всему миру - идеальная среда для stackoverflow-driven разработки. Второй момент наоборот очень тактический. В Амазоне мои скрипты вместе с развернутой для них MariaDB ещё долгое время смогут работать бесплатно, а в Яндексе всё это было бесплатно для меня только в рамках программы грантов для сотрудников, а когда я перестал быть сотрудником Яндекса, этот проект начал бы мне обходиться примерно в 6000 рублей в месяц.