Обсудили с автором телеграм-канала Так говорил 2Pizza разработчиком Кирой 2Pizza идею и реальное применение Serverless. Технологические новинки часто используют просто потому, что это модно. По мнению Киры, хайп вокруг Serverless приведет к тому, что мы окажемся в добровольном рабстве у Амазона и Гугла. Компании будут забирать всю прибыль, а инженеры — сидеть на цепи без единой возможности сбежать.
Кира работает на американском рынке: помогает компаниям и стартапам, которые ищут лекарство от рака. В индустрии больше 10 лет, успел поработать на бэкенде, фулстеке, был тимлидом.
— У тебя было такое: долго мучает боль в профессии, и вдруг выходит инструмент, который её побеждает?
— Я не могу вспомнить ни одного такого инструмента.
— Ответ, которого я ждал.
— В одном почтовом сервисе было сложно собирать данные для деплоя. Я взял Докер, который должен был всё разрулить, но Докер принес с собой много новой боли. Кубернетис — такая же история. Решил проблему, принес две новых. Не существует серебряной пули, которая избавит тебя от всех проблем.
— Что думаешь о технологическом развитии индустрии?
— Иногда мне кажется, что индустрия ходит кругами. Но есть вещи, которым я рад. Майкрософт наконец-то повернулся к разработчикам лицом. Пришел Сатья Наделла, они купили Гитхаб, начали делать терминал, стали поддерживать Линукс. И в тоже время некоторые тренды вызывают недоумение. Докер — очередной виток нашей не очень длинной технологической истории. Вся эта система контейнеризации родом из 80-х. Старинная технология, которую продают нам под новым маркетинговым соусом. (История часто повторяется, раньше у нас был Internet Explorer, теперь у нас есть Google Chrome). Словом, я бы не сказал, что мы классно продвинулись. Да, в машинном обучении происходят интересные вещи. Но я так далек от этой темы. Далёкое всегда кажется интересным и магическим. Как только начинаешь разбираться —магия исчезает.
Хорошо, что айти перестает быть сакральным знанием. Тема у всех на слуху, снимаются сериалы, открываются курсы, крутят рекламу по телевизору. Уходит элитизм, и это мне нравится.
— Serverless пришел как ответ на какую-то боль?
— Я думаю, что Serverless пришел, как маркетинг. Если посмотреть на историю продуктов Амазон, это были просто виртуальные машины, которые запускаются. Всё очень похоже на развитие серверного рынка. Сначала сервера, потом маленькие виртуальные машины и спотовые инстансы в аренду. Позднее появляется Кубернетис, более простые контейнеры и Lambda. Амазон пытался заработать больше денег, но стал популярным, потому что закрыл одну из основных проблем многих стартапов.
Чтобы запустить стартап в доамазоновую эпоху нужно было найти хостинг и зарегистрироваться. Отправить письмо в компанию, которая предоставляет сервера. Через неделю-другую, наконец, получить доступ и начать настройку. Если стартап затребует еще серверов — повторить всё по новой. До получения в эксплуатацию машины проходило больше месяца. Была и другая сторона медали. Ты мог поддерживать свою виртуализацию, купив сразу 10 серверов. Но как определить, сколько тебе нужно машин? Как предугадать свой рост? А что, если ты не вырастешь, и тебе не понадобятся эти ресурсы? Потратишь миллион долларов на N-нное количество машин, а тебе потребуется только половина из них. Продать другую половину? Но это как с автомобилем. Купил новую машину, выкатил из салона, и она уже подешевела на несколько сотен.
И тут на сцену выходит Амазон, и говорит: вот кнопка. Нажимаешь на неё и получаешь виртуалку. Нажал — виртуалка, нажал — виртуалка. Восторг.
Основная идея состоит в том, чтобы убрать весь оверхед оперейшнс. Ты решил сделать стартап. Появилась классная мысль — сдавать свою надувную кровать. Налабал формочку, подключил базу. Теперь нужны сервера. Но, блин, ты не хочешь нанимать дорогих опсов, которые будут сидеть в дата-центре и настраивать сети и фаерволы, таскать железо… В этот момент появляется Амазон и берёт всё на себя. У него куплены сервера, инженеры, сетевики. У него куплено всё. Он даёт тебе простую веб-форму: накликал — получил.
Lambda — это по сути дальнейшая эволюция философии, где тебе ничего не нужно администрировать. Не нужно платить за то, что ты не используешь. Допустим, у тебя 5 лямбд, но используется только одна. При этом у тебя есть возможность запустить все. Идея просто суперская. Но ровно до того момента, пока не приходят люди, которые начинают её использовать. Классные идеи часто извращаются, вспомним Agile.
Serverless началась с прекрасной идеи, но превратилась в сплошной сюр.
Чем больше ты завяжешься на Амазон, чем больше сервисов подключишь, тем выгоднее для Амазона. Да и потом с него просто так не слезешь. И он дорогой. Я видел много стартапов, и даже больших компаний, у которых был конкретный запрос. Мол, нам нужен человек, разбирающийся в Амазоне, который поможет нам сэкономить, мы устали платить. Всё классно, когда ты стартап. Всё накликал сам. Но начинается рост, у тебя становится всё больше пользователей. Из полученных 50 тысяч долларов, 15 тысяч ты отдаешь Амазону за инфраструктуру.
Приведу еще одно интересное наблюдение. Я готовился к амазоновской сертификации. В Амазоне хитрые вопросы. Тебе говорят: спроектируй такую-то инфраструктуру. Сложно сказать, что существует один правильный ответ. Но на курсах Амазона правильный ответ есть — чем больше ты использовал сервисов Амазона, тем больше вероятность, что ты правильно ответил.
Сначала были просто лямбды. Я их начинал использовать еще в 2013 году. Уже тогда их было больно оркестрировать. Как мне их обновлять? Как трекать? Я недавно вернулся к лямбдам и понял — лучше не стало. Лямбды сейчас напоминают хранимки в базах данных. И подходы к ним очень схожи. Каждая лямбда становится отдельным приложением. Сначала был монолит, который всё в себе держал. Потом появились микросервисы, которые разделили функционал монолита на части. Потом пришли лямбды, которые вообще разделили функционал по эндпоинту. Получились такие нано-сервисы. Каждый эндпоинт — это отдельное приложение. Всё это хорошо до момента, пока не понимаешь, что тебе нужно 10 таких эндпоинтов, у тебя переиспользуются сущности, есть взаимосвязи между приложениями. Конечно, можно скопипастить всё это дело, будет 10 лямбд, которые будут повторять друг друга. А что такого? Я стартап, мне надо быстрее на рынок!
Появились Lambda-лееры, которые позволяют тебе из одной лямбды получить доступ кода к другой. Все это очень сложно масштабируется. Со стороны разработки с этим крайне трудно жить. Амазон сначала сделал простую штуку, а потом начал её усложнять. Когда у тебя простое приложение на 2 эндпоинта, с лямбды можно быстро стартануть. Потом приходит реальная жизнь, где у тебя есть общие сущности, надо пилить библиотеку. Но Амазон вместо библиотеки предлагает лееры. Lambda-леер — это Lambda, у которой есть версия и она общая на весь твой регион. Допустим у тебя есть 5 эндпоинтов и ты делаешь для одного эндпоинта небольшое изменение в сущности. Можно сразу все свои лямбды подчинить под новую сущность, можно заверсионировать. В итоге всё это растет как снежный ком. Только ты разобрался как жить с леерами, приходит заказчик из реального мира с требованием "чтобы мы могли интегрироваться", и всё, нужен другой стандарт… Открываешь док и понимаешь, что Lambda не умеет нативно поддерживать эту штуку, и её нужно пилить самому.
— Перечисленные тобой проблемы — они идеологические, или просто инструмент пока еще недостаточно хорошо сделан?
— Я всё-таки думаю, что идеологические. Лямбды — классная штука, отлично подходит, чтобы сделать экстеншн приложения. Если нужна редкая, ресурсоемкая операция, требующая хитрых манипуляций, лямбда — то, что надо. Она позволяет сохранить в целости Кубернетис кластер, виртуалку или контейнер, ты экстендишь приложение при помощи лямбд.
Есть классический пример: можно скопировать код, запустить его, и он будет работать. Когда ты начинаешь делать что-то сложное в реальной жизни, так не выходит. Ты просто зарываешься в этот уровень сложности. Появляются взаимосвязи, появляются сущности, внешние зависимости. Я прогонял cloc, который считает количество кода в кодовой базе. У нас только джейсонов было около 4 миллионов строк! Самого кода, бизнес-логики, было, дай бог, тысяч сто строк. Сделать что-то нетривиальное, становится просто героически сложно. Ты перестаешь программировать, ты становишься чертовым оператором Амазона!
Я всегда думал, классно, когда ты работаешь программистом и пишешь код. Начинаешь думать абстракциями. Ты абстрагировался от компьютера, от языка программирования, он у тебя на кончиках пальцев. Это инструмент, ты используешь его, не думая. В случае с Амазоном соображаешь, а какую же мне кнопку нажать?
Можно сказать, что уровень инструментов сейчас в зачаточном состоянии. Амазон еще просто не допилил, вот допилит и будет хорошо! Не будет хорошо, там слишком много уровней сложности.
— Скорее всего Амазону этого и не надо. Программисты должны работать операторами Амазона.
— Так будет продолжаться, пока их не сожрут конкуренты. Сейчас Амазон лидер рынка, но это не может длиться вечно.
— Как уйти к конкурентам, если у тебя на Амазоне задеплоино гигантское приложение?
— Когда пользуешься стандартным кубернетис-кластером, виртуальной машиной, С3, то перескочить на что-то другое достаточно просто. Когда у тебя код-деплой, код-формейшн — начинаются проблемы. Ты думаешь: сейчас я всех обхитрю и быстренько перейду на Гугл, подниму всё в течение часа. Но из этой затеи ничего не выйдет. Ты будешь перетаскивать приложение несколько месяцев и терять деньги.
Люди мне возразят — у нас есть замечательный терраформ, который не завязан на одного провайдера, он мультипровайдерный. Но если внимательно посмотреть на терраформ, для того, чтобы нормально поддерживать и Гугл, и Амазон, тебе нужно два терраформа.
— Раньше на бэке все кайфовали. Не было никакой кроссплатформенности, просто пишешь под один вид серверов. И что теперь: давайте сделаем кроссплатформенность, тоже принесем боль и муки выбора к какой компании привязаться.
— Сейчас если не век, то точно декада Кубернетиса. А Кубернетис как раз несет стандарт. У тебя есть Кубернетис и в Гугле, и в Амазоне, не требуется больших изменений, чтобы продолжить работу. Это не безболезненный процесс, но подвижки в сторону какого-никакого стандарта всё же есть.
— Это же не здоровая ситуация, когда девопсы и разработчики должны разбираются в сервисах Амазона?
— Чтобы пользоваться посудомоечной машиной тебе не нужно понимать, как она работает. Тебе не нужно разбираться как работает фейсбук изнутри, чтобы откомментить фоточку. Но если ты пользуешься инструментом профессионально, было бы неплохо знать, как он устроен. Эти знания тебе сильно помогут в устранении багов.
Это важный момент. Мы раньше запускали линуксовые сервера. Ты мог зайти обновить ядро, сделать всё, что угодно. А когда у тебя Lambda с ручкой “посмотреть логи”... Даже если ты знаешь наизусть каждую строчку кода движка, это не поможет. У тебя просто нет доступа. И в этот момент появляется замечательная штука, можно заплатить за премиальный саппорт, чтобы саппорт смог быстрее тебе ответить.
— Платишь Амазону за вещи, которые умеешь делать лучше.
— Да, зато ты покупаешь у него время. Ты можешь сделать всё сам: захостить, развернуть сервера. И сделаешь это круто. Но сейчас решает рыночек. Сколько мы такого видели: средненький продукт захватывает аудиторию. Он не ждёт пока выйдет хороший. Я видел гору стартапов, которым пофигу на безопасность и бэкапы. Им нужны фичи и нужно быстро деплоить: сейчас срубим бабла, найдем инвестиции, показав кому-нибудь демо-версию нашего продукта, тогда и будем думать о качестве. А потом начинается новая гонка. У нас новый роадмап, нам дали денег! Бэкапы и безопасность подождут.
Получили камаз кеша и начинается: нам не нужно лучше, нам нужно быстро. Я видел стартап, который покупал дико дорогие сервисы. Есть такая контора, называется Databricks, предоставляет что-то похожее на премиум Спарк. Databricks арендуют тачки у Амазона, накатывают туда свой кастомный “Спарк”, накидывают сверху ценник и продают пользователю. Они перепродают тачки, но добавляют туда свою интеллектуальную собственность. Вместо того, чтобы запустить дешевую линуксовую коробку, инженеры на таких кластерах (по 100 долларов в час) перекладывают файлы на С3. Доступа нет, доступ есть на кластерах. Запусти кластер, переложи файлик, заплати.
Дороговато, но если бизнесу норм, кто я такой чтобы сопротивляться?
Амазон спасает, когда тебе нужно быстро стартануть. Вопрос в другом: почему все эти выстрелившие стартапы не торопятся что-то менять?
— Потому что дорого и сложно. Это же ловушка: мы решим вашу маленькую проблему очень легко, но потом вы будете до конца дней хостится у нас, потому что переход встанет в копеечку. Представим успешный стартап, у которого всё получилось. Миллион пользователей, деньги. Да, приходиться делиться с Амазоном. Можно рискнуть успехом и переехать куда-то еще. А можно не рисковать, потому что Амазон берет все еще меньше, чем ты зарабатываешь. Чем дольше ты остаешься, тем рискованнее переходить. Получается нет момента, когда переход будет оправданным. В итоге ты всю жизнь платишь Амазону страшную кучу денег.
— У каждого бизнеса есть момент, когда он сначала стартап, а потом растёт. И это разные стадии, и даже разные люди нужны в штате. На первом этапе важен управленец, который любит рисковать, умеет принимать сложные решения. На втором нужен директор, который может жить в стабильности.
Я провел много различных миграций, и я еще не видел ни одной миграции без побочки. На время миграции ты платишь х2, потому что тебе нужны новые ресурсы, где ты будешь держать инфру. И в то же время ты не можешь убить старые. Полгода ты будешь платить за две инфраструктуры параллельно.
Если мы вернемся к лямбдам, мне не нравится маркетинг и хайп вокруг. Их пытаются тащить везде, где можно и нельзя. Но это не проблема лямбд. Это проблема людей, которые ими пользуются. Жить с этим сложно. Все эти: "у меня тимлид в одиночку сделал за неделю сервис на Lambda". Я уверен, этот же тимлид сделал бы и нормальный монолит за неделю.
— Рассказы, про то, что мне надо было 3 простеньких эндпоинта и я очень легко их зафигачил на Lambda. Но 3 простеньких эндпоинта на всем легко зафигачить.
— В защиту Амазон можно сказать, что он берёт на себя аутентификацию, API gateway. Но опять же он решает эти проблемы только на самом старте. Когда ты выростешь, тебе потребуется кастомная страница аутентификации. Получается, ты просто откладываешь этот вопрос.
Пару лет назад пришел стартап. Они собирали данные с дронов и обрабатывали на Lambda. Подключаешь дрона, у тебя все запустилось, обработало твою инфу, сложило на С3 и отключилось. Дрон не в работе — ты не тратишь деньги на инфру. Так вот, если дрон долго летал и собирал много инфы, то они упирались в лимит лямбд. Лямбда не будет работать двое суток. Она не для этого придумана, она создана для маленьких решаемых задач.
Так вот что мы сделали. Мы всё переархитектурили, и Lambda стала оркестрирующей. Дрон включается, запускается Lambda, если поступает много данных — она заводит виртуальную машину, заливает на неё данные. Машина может крутится неделю, месяц, год. Пока ты за неё платишь, она будет крутиться. Она прокрутилась, залила результаты на С3, выключилась.
Я не могу вспомнить реальные кейсы, когда без лямбд не обойтись никак. Но я знаю, где их круто использовать. Давно, когда у нас были линуксовые сервера, мы использовали крон джобы. Пишешь, что у тебя такая-то задача должна запуститься в 2 ночи, другая — в 3 ночи. Часто были джобы, которые зависели друг от друга. Бывало такое, что одна еще не успела закончится, а вторая уже стартовала. И ты садился и раздвигал их по времени. И страдал. Тогда у меня появилась мысль, что мне нужен ивент бейзд. И Lambda принесла этот ивент бейзд. Ты можешь настроить триггерку лямбд на какой-то ивент. Например, пользователь залил файл. Он залетает на С3, запускается Lambda. Это происходит моментально. Ты можешь сам генерировать ивенты, можешь слать ивенты, а Lambda будет их асинхронно обрабатывать. Больше не нужно оркестрировать эти джобы и воркеры. У тебя есть Lambda, которая просто работает. Одна задача — одна Lambda.
Я делал селф-хилинг мониторинг. (Это мониторинг, который лечит сам себя). Он мог слать алерты. Вместо того, чтобы слать их в почту, слал их через sqs-сервис. Sqs был триггером для лямбды. Приходит триггер, что у тебя неисправна нода базы данных — тут же запускается Lambda, как чинить эту ноду.
Там был кластер, он пристреливал этот инстанс, поднимал второй и всё продолжало работать. А я спокойно спал.
Lambda — хорошее решение для подобных целей. Также как и хранимки в базе данных. У тебя немного вариантов, когда они могут пригодиться. Делать всё на хранимках — это тупо, а какие-то отдельные агрегации — правильно.
— Появилось хорошее решение одной маленькой проблемы, стало хайповым, люди ринулись подгонять под него все остальные задачи.
— Нас хлебом не корми, дай новые технологии попробовать. Порекомендуй вместо микросервисов человеку старый добрый вордпресс, который закроет большинство его задач, что он тебе ответит? Бизнес не закроется, если ты всё сделал на лямбдах. Но жить будет сложно.
— И в какой-то момент обязательно Амазон выставит тебе очень хороший чек.
— Конечно, как только появится нагрузка. Бесплатного ничего не бывает. У тебя есть приложение. У него реализована функция банального логина. Сделано на лямбдах. К тебе заходит 1000 пользователей, каждый по 10 раз дернул, набежал миллион запусков лямбд в день. Сколько будет стоить месяц? Ведь кроме лямбд есть еще куча всего. Часто такое видел, когда человек говорил: "я на калькуляторе считал, что я буду должен 100 долларов, почему с меня требуют 200?" А трафик нетворк ты не посчитал? За айпи адрес тоже копеечку возьмут.
— Так в будущем мы придем к стандарту? Или всё превратится в корпоративный ад, где ты привязан к конкретной компании и платишь ей горы денег?
— Я надеюсь, что люди всё поймут и стандарт появится. Сейчас Амазон выложил опенсорсный движок лямбд для запуска легковесных виртуальных машин. По идее его можно брать и наворачивать свои интерфейсы. Прогнозировать плохая идея, это как с курсом доллара — лучше не загадывать. Верю, что все скоро наиграются и бросят. Амазон будет маркетингово тащить Serverless и дальше, потому что в реализацию вложено много денег. Но если люди приходят и платят — почему бы не тащить?
А я вижу лишь одно назначение Serverless — возможность быстро собрать на старте прототип и тут же пристрелить его.
От редакции Rebrain
А что вы думаете про Serverless? Заходите к нам в сообщество — там мы постоянно проводим открытые практикумы, на которых решаем кейсы и задачи из сферы IT-инфраструктуры, обсуждаем вещи, которые пригодятся и на собеседованиях, и в работе.