Наверняка не все знают, что по нагрузке и числу пользователей iFunny является настоящим highload-сервисом. API обслуживает в пиках порядка 15000 запросов в секунду, система аналитики обрабатывает около 5 миллиардов событий в сутки, а для поддержки полного функционала работает до 400 инстансов EC2. Поэтому для приложения очень важно иметь сильную команду инженеров. Чтобы решать типичные проблемы высоконагруженных систем и улучшать свою работу каждый день, команда iFunny постоянно ищет новые инструменты и решения. И в этот раз невозможно было пройти мимо интервью одного из основных контрибьюторов мирового IT-сообщества — Келси Хайтауэра. Достойно перевода и вашего внимания.

Многие из вас хотя бы раз слышали термин serverless. Парадигма, которая подразумевает отсутствие необходимости поддерживать пул серверов для запуска приложения, быстро набирает популярность в мире облачных вычислений. Уже сейчас ведутся дискуссии о том, как правильно использовать платформы Function as a Service (далее — FaaS) и как меняется мир с приходом на рынок AWS Lambda и Google Cloud Functions.

На одной волне хайпа с serverless постоянно всплывают слова DevOps и Kubernetes. В сети появляются бесчисленные гайды и истории опыта, открывается всё больше и больше вакансий с их упоминанием. Но что именно из этого информационного шума будет действительно полезно для инженеров и руководителей? И как определить ценность использования появившихся технологий в своей повседневной работе?

На днях A Cloud Guru опубликовало интервью с Келси Хайтауэром, очень известной персоной в мире IT.

В настоящий момент Келси Хайтауэр является Developer Advocate в Google, а также одним из основных контрибьюторов проекта Kubernetes. В IT-сообществе он известен не только вкладом в Kubernetes, но и постоянными докладами на конференциях в США и в Европе. Выступления Келси обычно наполнены множеством забавных шуток и интересными демо-стендами.

Келси, ты ведущий эксперт по Kubernetes. Как ты попал в этот проект и что изначально вдохновило тебя на работу с Kubernetes?

— Я работал системным администратором в сфере финансов, стартапах, веб-хостингах и даже в нескольких дата-центрах. Я знаком с трудностями управления инфраструктурой, я пережил пики популярности принципа write once, run anywhere, виртуализации, управления конфигурациями и тому подобного задолго до появления контейнеров.

Когда я подался в разработчики, мне стало понятно, насколько сложно выкатить код из локальной среды, пытаясь уладить разногласия между инженерами разработки и эксплуатации.
Проходит ещё несколько лет. Я работаю в CoreOS, и на моих глазах Google запускает Kubernetes на DockerCon-2014. К тому моменту у них уже был репозиторий на GitHub, но по факту пользоваться проектом было невозможно, так как не существовало никакой документации.

Я закатал рукава и с головой окунулся в кодовую базу. В конечном итоге я написал «самый первый» пост о том, как установить и изучить Kubernetes на своём ноутбуке. Пост висел в топе на HackerNews —? даже выше, чем пресс-релиз от Google! Вот так CoreOS и нашёл своё место в сообществе Kubernetes.

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

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

Так каким образом Kubernetes облегчает жизнь прямо сейчас?

— За счёт своей согласованности. Kubernetes делает то, что мог бы делать самый лучший системный администратор. С ним становится очень просто выкатывать свой код на нужное окружение.

Уже три или четыре года назад, ещё до того как в Kubernetes появилась концепция «разделов» (англ. volumes) и всё то, что связано с сетевым стеком, было очевидно его главное достоинство: это развёртывание контейнеров и управление ими.

Скажем, у вас есть несколько контейнеров и пул машин. Через несколько строчек конфигурации в Kubernetes вы можете написать: «Запусти этот контейнер». И дальше вы просто наблюдаете, как он запускается. Если вы отключите одну машину, то Kubernetes переместит контейнер на другую. Один только факт, что сегодня не каждый человек так умеет, говорит о продвинутости Kubernetes.

И сейчас, по прошествии этих трёх-четырёх лет Kubernetes по сути поглотил мир контейнеров. Но параллельно появились serverless-технологии и FaaS, которые решают часть тех проблем в управлении инфраструктурой, о которых ты говоришь. Что ты думаешь о FaaS как о концепции?

— Впервые я столкнулся с FaaS при работе с CGI. Работало это так: писался некий код на PHP и клался под Apache. После этого Apache вызывал код при получении запроса по HTTP. Тогда существовало несколько весомых ограничений: не было ни масштабирования, ни концепции «облака», ни понятного API для того, чтобы реализовать это на любом языке.

Сейчас мы видим, как Amazon пытается ещё раз воплотить в жизнь эту идею в Lambda. Они говорят, что могут взять ваш код и просто запустить его в своём облаке, предоставляя множество компонентов, необходимых для приложения, например аутентификацию, базу данных и API-шлюз.

Ещё Lambda отличается от скриптов CGI моделью расходов. Видишь ли ты в функциональном биллинге что-то, меняющее правила игры?

— Я понимаю эту модель расходов как «плати за вызов». И эта концепция проникает во многие облачные ресурсы.

Лично я рассматриваю FaaS как окружение разработки в облаке. «Как у облачного провайдера, у меня есть события, очереди сообщений и другие подобные сервисы, которые я предоставляю. Я не собираюсь брать с вас плату за SDK, с помощью которого вы пользуетесь этими сервисами. И поэтому я не хочу создавать высокий порог вхождения, так как нацелен на привлечение как можно большего числа клиентов».

Также можно запускать функции на Kubernetes-кластерах с помощью Kubeless. Видишь ли ты в этом сочетание лучшего из обоих концепций — контейнеров и serverless?

— Если ваше окружение состоит из пула виртуальных машин, то нужно проделать достаточно много работы, прежде чем запустить на нём своё приложение. Вам нужно управление конфигурациями и множество подобных инструментов до деплоя.

Kubernetes поднимает эту планку, предоставляя более гибкие абстракции?: вы просто отдаёте ему контейнер, говорите, как именно его нужно запустить? — и вы свободны! Но ему по-прежнему недостаёт некоторых критичных workflow, которые предоставляют serverless-платформы. И если они вам нужны, вы можете наложить их поверх Kubernetes, установив что-то наподобие Kubeless.

Теперь у вас есть возможность загрузить кусок кода в виде функции и сразу запустить его. Тут важно помнить, что все предложения от FaaS используют контейнеры, заточенные под свой сервис. А с Kubernetes, кроме тех же самых контейнеров, у вас есть open-source-продукт, благодаря чему вы получаете полную видимость и контроль своей платформы.

FaaS предоставляет хорошую абстракцию для определённых задач, но не для всех. Kubernetes даёт самый высокий уровень абстракции, понятный и удобный для многих (особенно для тех, кто пришёл из мира виртуальных машин). Serverless по своей сути является следующим уровнем абстракции.

Если у вас есть кластер Kubernetes, который развивается уже на протяжении нескольких лет, то почему бы не реализовать поверх него функционал, который есть у AWS Lambda? У вас уже есть все необходимые абстракции, которые делают Kubernetes фундаментом для создания новых workflow на более высоком уровне. Даже если это serverless.

Как ты считаешь, останется ли Kubernetes наиболее удобной абстракцией для большинства инженеров или многие начнут двигаться выше и разрабатывать приложения на уровне FaaS?

— Люди должны использовать правильную абстракцию для своих задач. Например, когда я пишу интеграцию с Google Assistant, единственное, что я хочу — запустить определённый кусок кода, который отвечает на пользовательские запросы. И я могу запустить это на Google Cloud Functions. Мне не нужен контейнер, не нужны хранилища для данных. Я просто хочу запустить это как функцию. И это самая лучшая абстракция для моего случая.

Сейчас, если я хочу углубиться в машинное обучение, исследовать TensorFlow, то мне нужно выделить под свой код отдельный контейнер, чтобы смонтировать к нему раздел с данными, иметь доступ к GPU, и serverless-платформа уже не будет самым лучшим местом для реализации. В целом я считаю, что люди должны идти вперёд и использовать самый высокий уровень абстракции, который будет работать в конкретной ситуации.

Мы уходим всё дальше от набора навыков, который ассоциируется с DevOps. В моём предыдущем интервью Саймон Вордли назвал DevOps пройденным шагом. Пересекается ли эта мысль с твоим опытом?

— Соглашусь с Саймоном. Когда мы начинаем изучать что-то ранее неизвестное, мы должны это как-то назвать: «Я системный администратор. Я занимаюсь DevOps. Я SRE». Речь идёт о том, что как только мы выходим за рамки известного в нашей дисциплине и открываем что-то новое, у этого нового должно появиться собственное название.

Дали имя своей дисциплине — переходим к технологии. Нет смысла заниматься DevOps-практиками 40 лет. Как только мы понимаем, как сделать правильно, наши идеи должны сформироваться в технологию.

Таким образом из DevOps родился Kubernetes. Даже несмотря на то, что его истоки восходят к Google, Kubernetes не является полной копией того, что мы делаем для внутреннего использования. Он отлично сочетается с тем, над чем трудятся разработчики Docker, Puppet и Chef.

Для деплоя приложений Kubernetes гораздо проще управления конфигурациями, т.к. он включает в себя знания и накопленный опыт. Это его рабочие механизмы по умолчанию. Вам больше не нужно изобретать велосипед.

Какими будут ваши действия в случае падения ноды? Наверняка вам пришлось бы автоматизировать свой сервис и предусмотреть аварийное переключение на другую машину из пула ресурсов. А это уже реализовано в Kubernetes.

Опыт DevOps показал, что в эксплуатации должны быть такие компоненты, как централизованное логирование и мониторинг. И в Kubernetes это всё присутствует в стандартном пакете. Мы просто взяли нужное из DevOps и перенесли в новую технологию. И когда я говорю «мы», я подразумеваю всех контрибьюторов проекта Kubernetes.

Если большинство навыков DevOps автоматизированы уже сейчас, то каким будет следующий набор навыков, который должен освоить инженер?

— Site reliability engineering. Допустим, у вас есть такая система, как Kubernetes или Lambda ?—? но кто наблюдает за наблюдателями? Даже если за меня всё делает облачный провайдер, мне нужно дважды проверить, на каком уровне сейчас задержка ответа сервиса и насколько это устраивает моих клиентов. Провайдер стремится предоставить мне как своему клиенту высокий уровень качества сервиса, но у меня будут проблемы, если этого будет недостаточно моим клиентам.

Почему такое может произойти? Возможно, я использую не ту библиотеку или неэффективно выполняю запросы к базе данных. И именно здесь работа команды SRE имеет ценность. Кого теперь беспокоят деплои? Эта проблема уже решена. Но после того как деплой завершился, как мне настроить то, что нужно клиенту?

И тут мы можем освободить себя от ушедшей рутины и заняться тем, что откладывали в долгий ящик. У каждого инженера DevOps есть такой ящик. «Однажды мы сделаем централизованное логирование. Когда-нибудь у нас будет CI/CD». И сейчас вы можете начать работать над этими идеями.

Что из того, что Google Cloud Platform делает с serverless и Kubernetes, тебя больше всего вдохновляет?

— Мы занимаемся serverless достаточно долгое время. App Engine определённо представляет из себя то, о чём говорили в AWS на последнем re:Invent?. Serverless — это не просто FaaS. Мы хотим дать людям опыт безболезненного использования платформы. Мы верим, что App Engine уже делает это на протяжении почти 8 лет. Или, например, BigQuery: ?она полностью управляема, и вы просто запускаете свои запросы и затем решаете, насколько быстро они должны выполняться.

На вычислительной стороне у нас есть Cloud Functions, FaaS-сервис, аудиторию которого мы постоянно расширяем, добавляя поддержку новых языков программирования и прочего функционала, чтобы можно было сфокусироваться на коде, а не на инфраструктуре.

Также у нас реализованы end-to-end решения, о которых не все могут знать. Например, мы интегрировали Cloud Functions с DialogFlow. Если вы хотите поработать с аналогами Alexa или соединить Google Actions с Google Assistant, то вы можете использовать DialogFlow. Когда мы создаём навыки или действия, то весь процесс ML-тренинга можно увидеть в браузере, используя GCP в фоновом режиме.

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

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

— Скажу так: у вас уже есть необходимые навыки для внедрения этих технологий. Эти навыки заработаны потом и кровью во время управления платформами, которые были до Kubernetes.

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

Но вы также должны обдумывать свои действия и понимать их ценность. И здесь, на мой взгляд, люди допускают ошибки. Только услышав о Kubernetes или serverless, они сразу хотят их внедрить. Вместо этого следует задать себе вопрос: «Что нужно моей команде или организации в целом?»

Возможно, у вас есть коллега-разработчик, который вечно жалуется на необходимость постоянно разворачивать инфраструктуру прежде, чем что-либо запустить. Предложите ему сначала попробовать. Пусть он выкатит свой код и просто наблюдает за тем, как тот разворачивается с нуля. Если ваши коллеги увидят в этом пользу, то они поддержат вас. И тогда вы им скажете, что это на самом деле был Kubernetes, Lambda или что-то другое.

Мы должны быть более сообразительными в вопросах бизнеса и думать о том, зачем нам нужна та или иная система, а не просто ходить в футболке с логотипом Kubernetes и говорить: «Эй, я был на конференции и думаю, что мы должны внедрить это прямо сейчас!»

Притормозите! Вы точно знаете, в чём проблемы вашего бизнеса. Сначала решите их и только потом начинайте говорить о Kubernetes.