Открыть список
Как стать автором
Обновить
119.52
Рейтинг
Ребреин
REBRAIN: Онлайн-практикумы для Инженеров

Три года назад нужно было изучать Docker, два года назад — Kubernetes. Сейчас — Serverless

Блог компании РебреинИнтервьюServerless

Интервью с Антоном Черноусовым из Yandex.Cloud

Антон Черноусов — developer advocate — пришел в Yandex.Cloud, чтобы заниматься микросервисами, популярными в индустрии Docker и Kubernetes . Но главная его профессиональная страсть — это Serverless. Мы поговорили с Антоном, и он объяснил, почему бессерверные платформы ждет большое будущее.


Зачем изучать Serverless

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

Когда пропустил появление Docker, ругал себя, и тут же следом проморгал Kubernetes. Когда разработчик вникает в технологию на самом старте, видит, как она развивается, он становится экспертом значительно быстрее, чем окружающие. И когда новая технология переходит в мейнстрим, знания этого разработчика стоят дорого. Он увеличивает свой вес на рынке.

Docker и Kubernetes — это инструменты. Как и любой инструмент, они не вечны. У каждого инструмента есть жизненный цикл. Как только мы переходим в высокотехнологичную сферу, жизненный цикл инструмента сильно укорачивается. Под этим углом я смотрю на технологии. Именно поэтому приходится следить за тем, что будет следующим «новым молотком» на ближайшие 2-3 года. Три года назад нужно было обратить внимание на Docker. Два года назад — на Kubernetes. Сейчас нужно изучать Serverless.

15 лет назад мы делали CGI-скрипты на Перле. Это было то же самое, как сегодня написать Serverless функцию. Нам нужно было заботиться о физическом сервере, об Apache, мы постоянно лезли в конфигурацию. Теперь за сервер отвечает облако, вместо Apache у тебя есть сервер, который вызывает рантайм, и ты заботишься только о скрипте, который превратился, по сути, в отдельную функцию. Идея старая, а «молоток» новый. Мы ничего нового не придумали, просто взяли «молоток», поняли, что у нас есть новые технологии, которые позволяют сделать все более эффективно. Переложить риски на облако и заниматься только бизнес-логикой — это и есть самое крутое в Serverless! Ты занимаешься только бизнес-логикой. Это мечта для многих.

Должны ли обычные разработчики думать о Serverless

Когда мы посмотрим на то, чем занимаемся, глазами разработчика, мы увидим, что принимаем данные на вход, потом, с точки зрения бизнеса, у нас происходит какая-то магия, и затем на выходе выдаем другие данные. За эту магию бизнес дает деньги.

Если очень грубо: мы реализуем бизнес-процесс или поддержку этого бизнес-процесса, «приземляем» идеи бизнеса с учетом технических ограничений. У нас есть скорость, с которой мы должны обработать объем протекающих через нас данных. Мы задаем себе вопросы вроде — а насколько сложно нам будет написать и в дальнейшем поддерживать соответствующий процесс?

Но это все наши внутренние заморочки. Бизнес интересует стоимость конкретного процесса и скорость его реализации.

Используя Serverless, мы можем предоставить бизнесу четкий KPI, показать историю: смотрите, вот вход, вот выход, вот функция и вот ее стоимость. В бессерверных технологиях есть объем услуги, который ты потребляешь и за который ты платишь. Вызов конкретной функции стоит конкретных денег. Ты не платишь за какие-то эфемерные сервера, которые где-то находятся и требуют кеш каждый день. Все прозрачно, стоимость считать просто.

С этой точки зрения Serverless — это крутая история разработки программного обеспечения, не просто кодирования, а именно подхода к разработке. Бизнес понимает, сколько по-настоящему это будет стоить. Он понимает, как это будет масштабироваться.

Мы написали код, выкатили его на сервера. Пользователи не пришли, и мы продолжаем платить за сервер. А если пришли — как масштабироваться? Ну, надо купить еще один сервер, нужно купить еще какой-то прокси/лоадбалансер. Все эти проблемы мы начинаем на себя брать как разработчики, а с serverless — мы от них отказываемся, снимаем с себя все эти риски и не думаем о количестве серверов.

Для разработчика работа тоже становится прозрачной. Как бы он не писал код, все равно функция будет достаточно небольшой. Не нужно придумывать сложную систему, как отдебажить большое монолитное приложение.

Есть конкретный отдельный кусочек, и вся бизнес-операция происходит внутри него. Отладка и поддержка становятся проще , что снижает возможные когнитивные нагрузки на разработчика. Производительность вырастает.

Как Serverless устроен на практике

Надо понимать, что это еще достаточно молодой инструмент. И у него есть некоторые ограничения, как и у любого инструмента.

Сейчас, когда я говорю про серверлесс, я подразумеваю все подмножество технологий:

— Функция

Это некий кастомный движок, который мы создаем и который ограничен во времени. По-хорошему эта функция не должна иметь состояния. И в этом смысле она прекрасна. Ее можно масштабировать бесконечно (в рамках облака). Запускать сколько угодно вариаций и выдерживать «любую» нагрузку.

— База для хранения состояния

Вторая часть необходима для того чтобы сделать полноценное приложение. Когда мы выдерживаем нагрузку, нам нужно место, где мы будем хранить состояние. Там есть развилка: оперативное состояние и долговременное. Для долговременного состояния подходят БД. Уже появился целый класс баз данных, который так и называется — Serverless Database.

В Yandex.Cloud это проект Yandex Database, у которого в прошлом году появился серверлесс вариант запуска. Приходит нагрузка, она автоматически масштабируется, ты платишь только за те операции, которые совершил.

— Оперативное управление данными

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

У Амазона это SQS, в Yandex.Cloud — Message Queue. Она работает именно в этой идеологии — масштабируемое Serverless решение.

— Хранилище

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

В Амазоне это S3, как прародитель, в Yandex.Cloud это Object Storage, который повторяет, по сути, протокол S3. Это возможность хранить и файлики, и статическую информацию, и долговременно хранить бекапы.

— API

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

Есть сервис API Gateway. Он позволяет заявить наружу тот самый API, которым мы управляем, предоставить доступ к функциям и связать API вызов с конкретной функцией.

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

Почему весь рынок все еще не перешел на Serverless

Вижу три момента, которые влияют на переход и толкают к нему.

Первый — возрастание волновой нагрузки. Классический пример: если взять и на неделю отключить электричество в городе, а потом резко включить, то нагрузка на сеть будет чудовищная, потому что включатся одновременно все холодильники, все поставят стирать белье. Поэтому ее включают и отключают отдельными домами и районами, чтобы размазать нагрузку на систему.

Цифровизация проникла во все сферы, как электричество. Представляете, Москва одновременно проснулась, все включили свои телефоны и посмотрели что-то в новостях.

Чем больше IT проникает во все системы, тем больше ощущается волновая нагрузка. И это будет толкать бизнес и IT использовать Serverless чисто из прагматических соображений. Мы хотим выдерживать эту волновую нагрузку, которая приходит, а потом пропадает, а потом снова возвращается.

Второй момент — это колоссальная нехватка людей на рынке труда. Чтобы разрабатывать сложные монолитные системы, надо долго этому учиться. И напротив, чтобы писать отдельно одну функцию, больших знаний не надо. Нужно какое-то количество хороших специалистов, которые запустят процесс, но дальше основной объем смогут сделать люди с более низкой квалификацией.

И третья вещь — переход начнется, когда крутые программисты реально начнут понимать, где они могут это применять. Например, сейчас serverless очень удобно использовать для рекламных компаний, которые могут быть непредсказуемыми в плане нагрузки.

Ребята поджигают пользовательскую базу с помощью рассылок и пушей. Их пользователи приходят пользоваться каким-то конкретным сервисом, и эта нагрузка, с одной стороны, прогнозируемая, а с другой — мы не знаем, насколько она завирусится и сколько внешних пользователей придет. Мы сознательно готовимся к этой нагрузке, готовы ее принимать, потому что мы высококвалифицированные программисты, мы подумали, а давайте используем Serverless в этом конкретном случае. Потому что облако отмасштабирует это за нас и примет всю нагрузку.


Большие компании только начинают разглядывать огромный потенциал Serverless подхода. Самый крупный пример, про который я могу говорить, это Genotek. Данные генетических тестов обрабатываются в облаке. Человек «плюет в пробирку», его материал изучают в лаборатории, а полученные данные заливают в облако. Поскольку это суперперсональная информация, внутри все построено на безопасности и максимальном уровне паранойи. Часть процессов реализована с использованием Serverless подхода, данные обрабатываются на функциях, и работает это все в Yandex.Cloud.

Сейчас в русскоязычном пространстве мало кейсов и практик использования Serverless — и я стараюсь это исправить в рамках Yandex Serverless Ecosystem и хаба Serverless тут на Хабре. Например, недавно я был у мамы и нашел книжку-игру. Были такая серия — «Подземелья черного замка». Это фэнтези-роман, который разыгрывается с помощью кубиков. Можно было взять в дорогу и играть в поезде. Каждый абзац книги был пронумерован и содержал действие. Ты управлял персонажем, который ходил по книге и выполнял задания — спасал принцессу, боролся с темным властелином.

Я делаю на этой основе приложение, хочу продемонстрировать некоторые особенности работы Serverless: хранение состояния, передачу и сохранение данных.

В результате, популярность Serverless — это вопрос времени и нашей тяги к саморазвитию.

А что вы думаете про Serverless? Заходите к нам в сообщество — там мы постоянно разбираем различные проблемы и задачи из сферы Devops, обсуждаем вещи, которые пригодятся и на собеседованиях, и в работе.

Теги:rebrainserverlessинтервью
Хабы: Блог компании Ребреин Интервью Serverless
Всего голосов 57: ↑33 и ↓24 +9
Просмотры30K

Похожие публикации

Лучшие публикации за сутки