28 сентября на конференции RubyRussia Николай Сверчков выступит с докладом Serverless is Ruby Future. Иван Соловьев обсудил в интервью, чем же интересно это направление, и почему рубистам стоит обратить на него внимание.
Расскажи, как ты пришел в Ruby?
Программировать начал в университете. Вся практика была на C++, но последние курсовые и дипломную работу делал на Ruby. Почему выбрал именно Ruby я точно не скажу, наверное потому, что язык в то время был на волне хайпа. В университете Ruby никто не знал и уж тем более не преподавал. Но после окончания учебы я хотел писать на Java. Тогда мне казалось, что Java это особые, самые крутые разработчики, некая высшая каста программистов, и я хотел быть одним из них. Первое собеседование в жизни было на Java junior, и я его успешно провалил. Зато смог устроиться в компанию, где был нужен Ruby. Может это и к лучшему! Только на пару лет отходил в сторону Elixir. Сейчас работаю в Evil Martians, занимаюсь бэкендом.
Твой доклад о serverless. Как ты начал работать в этом направлении, сложен ли вход в технологию?
Начинал изучать в свободное время. У меня была реальная, но не связанная с основной работой задача. Потом начал применять serverless в проектах компании. Порог входа достаточно низкий, думаю, что лишь немного выше, чем у Heroku. Написать свой первый «Hello, world!» будет очень просто – существует куча статей, туториалов, крайне богатая документация у Amazon. А вот потом, конечно, потом будут и сложности. Есть свои подводные камни, о части из них я буду рассказывать в докладе.
Стоит ли новичкам погружаться в serverless и использовать его в продакшене?
Думаю, что да! Но не нужно бросаться реализовывать все с помощью serverless. Для начала можно посмотреть на свое приложение и найти в нем небольшой кусок бизнес логики, который вы можете вынести в отдельный сервис. Если этот новый микросервис имеет простой интерфейс общения, то с 99% вероятностью вы сможете реализовать его с использованием той же AWS Lambda. В идеале, если это будет stateless кусок бизнес-логики, тогда вам не придется думать о том, как сохранять результаты, думать об артефактах выполнения вашей лямбда функции. Как пример, хорошей первой задачей может быть рассылка писем. В своем докладе я отдельно буду поднимать вопрос о том, для какого спектра задач лучше всего подходит бессерверная модель вычислений.
Основная рекомендация – отделяйте код бизнес логики от самих лямбд. Это вариация до боли знакомого правила «тонкие контроллеры, толстые модели». Во-первых, так будет проще тестировать. Во-вторых, если в процессе вы поймете, что serverless плохо подходит для вашей задачи, то сможете легко мигрировать на проверенное решение, например, заменить входной слой serverless обычным веб-сервером. В этом плане очень хорош Jets. Это Ruby Serverless фреймворк, позволяющий вам писать приложение, которое из коробки можно деплоить как на AWS Lambda, так и на обычный EC2 инстанс Amazon.
Расскажи подробнее про этот Ruby фреймворк?
Jets уникален в своем роде. Несмотря на то, что существуют другие serverless фреймворки, заточенные под определенные языки, Jets самый функциональный. Сейчас у него более 2500 коммитов в мастере. Фреймворк использует очень много знакомых конвенций для Ruby разработчика, это такой «Ruby on Rails on Serverless». Но в этом есть и свои минусы. Поскольку при бессерверной модели вычислений вы платите за время выполнения кода, то инициализация и подгрузка большого количества тяжелых зависимостей дорого вам обходится в прямом смысле этого слова. Раскрытию этой теме тоже будет уделено время в моем докладе.
Какие платформы сейчас наиболее распространены для serverless, в чем их отличия, какую из них лучше выбирать? Как я понял, ты сейчас топишь за Amazon Web Services, так как большую часть времени ты говоришь про нее.
Ты спрашиваешь почему я чаще всего использую слово «лямбда» в нашем разговоре? Я думаю история как с «Karcher» или «Xerox». Есть бренды по имени которых принято называть целую нишу продуктов. В 2014 году Amazon первым предоставил публичный доступ к бессерверной модели вычислений – AWS Lambda. Все остальные: Microsoft с Azure Functions, Google c Cloud Function, IBM c IBM Cloud Functions, до сих пор ментально в роли догоняющих. Хотя рынок serverless быстро развивающийся, а цены на услуги у AWS чаще выше конкурентов. Так что новые релизы, такие как Google Cloud Run, могут перевернуть игру в одночасье. Если же проводить более детальный анализ сравнения платформ, то я бы порекомендовал посмотреть видео Руслана Серкина из DataArt с конференции DUMP 2019.
Как ты думаешь, к каком направлении будет развиваться serverless?
О, это самая интересная часть моего доклада! Обойдусь без спойлеров — приходите послушать! Вместо этого могу рассказать про serveless и production. В апреле этого года я был на конференции RubyConfBy в Минске, на которой выступал автор того самого Jets. На афтепати мы обсуждали вопрос развития serverless и почему, при наличии поддержки от крупных игроков индустрии, мы не видим массового распространения лямбда функций. Плюсы модели очевидны, экосистема прозрачна, но широкого доверия со стороны IT-комьюнити нет. В итоге мы пришли к выводу, что сейчас serverless это некий теневой игрок и ситуация чем-то напоминает ту, что была в свое время с Docker. Долго ходили мнения, что Docker в продакшене – это самоубийство. Сейчас же мы видим, что контейнеризация это главный инструмент для дистрибьюции ПО. Я думаю, что в будущем тоже самое ожидает serverless. Все больше и больше людей будут ему доверять.
Убьёт ли serverless монолиты?
Этот вопрос можно перефразировать как «Убьет ли микросервисная архитектура монолиты?». Потому что serverless это идеальный микросервер – он маленький, он stateless и имеет минимальный интерфейс общения с внешним миром. Так же, как микросервисы не убьют монолиты, так и лямбды не убьют монолиты. Все три архитектуры имеют определенный спектр задач, к которым они идеально подходят. И наоборот – есть задачи, где, например, serverless использовать нецелесообразно. Подробности ищите в моем докладе.
Что делать с vendor lock? Например, ты разработал лямбду для Amazon, но решил переехать на Google.
Миграция между платформами болезненна, если вы не используете какой-то фреймворк, например, serverless, который предоставляет абстрактный API над облачными провайдерами и позволяет вам одну и ту же функцию задеплоить и в Amazon и в Google. Если вы, грубо говоря, все делаете руками, то да, будет немного болезненно.
Что делать с общими частями лямбд при использовании кода? Например, каким-то common компонентами, каким-то утилитарными функциями и так далее.
На эту тему до сих пор нет best practices. И вопрос снова можно переформулировать в «Как шарить общий код между микросервисами?», потому что смысл тот же. Есть вариант, когда вы держите реиспользуемую логику где-то в shared, а в самих функция подключаете ее. Такой подход хорошо сработает, например, с Go, где на выходе у вас получается один исполняемый файл. Другой вариант – избавиться от связности компонент и допустить дублирование. Наверное, стоит пробовать и смотреть, что больше подойдет. Единственное, что я могу посоветовать – не пытаться делать лямбда функции универсальными. В какой-то момент вам может показаться, что идеальным решением проблемы дублирования кода будет сделать одну убер-функцию. Но со временем вы поймете, что это путь в никуда. Вы получите некую «монолитную версию serverless» со всеми проблемами и первой, и второй архитектуры.
Подробнее обсудим после доклада на RubyRussia!
Приходите и вы, регистрация еще открыта, конференция состоится в следующую субботу, 28 сентября.
Будут не только доклады, но и стенды лучших компаний:
Организатор — Evrone
Генеральный партнер — Toptal
Золотой партнер — Gett
Серебряные партнеры — Валарм, JetBrains, Bookmate и Cashwagon
Бронзовый партнер — InSales
Расскажи, как ты пришел в Ruby?
Программировать начал в университете. Вся практика была на C++, но последние курсовые и дипломную работу делал на Ruby. Почему выбрал именно Ruby я точно не скажу, наверное потому, что язык в то время был на волне хайпа. В университете Ruby никто не знал и уж тем более не преподавал. Но после окончания учебы я хотел писать на Java. Тогда мне казалось, что Java это особые, самые крутые разработчики, некая высшая каста программистов, и я хотел быть одним из них. Первое собеседование в жизни было на Java junior, и я его успешно провалил. Зато смог устроиться в компанию, где был нужен Ruby. Может это и к лучшему! Только на пару лет отходил в сторону Elixir. Сейчас работаю в Evil Martians, занимаюсь бэкендом.
Твой доклад о serverless. Как ты начал работать в этом направлении, сложен ли вход в технологию?
Начинал изучать в свободное время. У меня была реальная, но не связанная с основной работой задача. Потом начал применять serverless в проектах компании. Порог входа достаточно низкий, думаю, что лишь немного выше, чем у Heroku. Написать свой первый «Hello, world!» будет очень просто – существует куча статей, туториалов, крайне богатая документация у Amazon. А вот потом, конечно, потом будут и сложности. Есть свои подводные камни, о части из них я буду рассказывать в докладе.
Стоит ли новичкам погружаться в serverless и использовать его в продакшене?
Думаю, что да! Но не нужно бросаться реализовывать все с помощью serverless. Для начала можно посмотреть на свое приложение и найти в нем небольшой кусок бизнес логики, который вы можете вынести в отдельный сервис. Если этот новый микросервис имеет простой интерфейс общения, то с 99% вероятностью вы сможете реализовать его с использованием той же AWS Lambda. В идеале, если это будет stateless кусок бизнес-логики, тогда вам не придется думать о том, как сохранять результаты, думать об артефактах выполнения вашей лямбда функции. Как пример, хорошей первой задачей может быть рассылка писем. В своем докладе я отдельно буду поднимать вопрос о том, для какого спектра задач лучше всего подходит бессерверная модель вычислений.
Основная рекомендация – отделяйте код бизнес логики от самих лямбд. Это вариация до боли знакомого правила «тонкие контроллеры, толстые модели». Во-первых, так будет проще тестировать. Во-вторых, если в процессе вы поймете, что serverless плохо подходит для вашей задачи, то сможете легко мигрировать на проверенное решение, например, заменить входной слой serverless обычным веб-сервером. В этом плане очень хорош Jets. Это Ruby Serverless фреймворк, позволяющий вам писать приложение, которое из коробки можно деплоить как на AWS Lambda, так и на обычный EC2 инстанс Amazon.
Расскажи подробнее про этот Ruby фреймворк?
Jets уникален в своем роде. Несмотря на то, что существуют другие serverless фреймворки, заточенные под определенные языки, Jets самый функциональный. Сейчас у него более 2500 коммитов в мастере. Фреймворк использует очень много знакомых конвенций для Ruby разработчика, это такой «Ruby on Rails on Serverless». Но в этом есть и свои минусы. Поскольку при бессерверной модели вычислений вы платите за время выполнения кода, то инициализация и подгрузка большого количества тяжелых зависимостей дорого вам обходится в прямом смысле этого слова. Раскрытию этой теме тоже будет уделено время в моем докладе.
Какие платформы сейчас наиболее распространены для serverless, в чем их отличия, какую из них лучше выбирать? Как я понял, ты сейчас топишь за Amazon Web Services, так как большую часть времени ты говоришь про нее.
Ты спрашиваешь почему я чаще всего использую слово «лямбда» в нашем разговоре? Я думаю история как с «Karcher» или «Xerox». Есть бренды по имени которых принято называть целую нишу продуктов. В 2014 году Amazon первым предоставил публичный доступ к бессерверной модели вычислений – AWS Lambda. Все остальные: Microsoft с Azure Functions, Google c Cloud Function, IBM c IBM Cloud Functions, до сих пор ментально в роли догоняющих. Хотя рынок serverless быстро развивающийся, а цены на услуги у AWS чаще выше конкурентов. Так что новые релизы, такие как Google Cloud Run, могут перевернуть игру в одночасье. Если же проводить более детальный анализ сравнения платформ, то я бы порекомендовал посмотреть видео Руслана Серкина из DataArt с конференции DUMP 2019.
Как ты думаешь, к каком направлении будет развиваться serverless?
О, это самая интересная часть моего доклада! Обойдусь без спойлеров — приходите послушать! Вместо этого могу рассказать про serveless и production. В апреле этого года я был на конференции RubyConfBy в Минске, на которой выступал автор того самого Jets. На афтепати мы обсуждали вопрос развития serverless и почему, при наличии поддержки от крупных игроков индустрии, мы не видим массового распространения лямбда функций. Плюсы модели очевидны, экосистема прозрачна, но широкого доверия со стороны IT-комьюнити нет. В итоге мы пришли к выводу, что сейчас serverless это некий теневой игрок и ситуация чем-то напоминает ту, что была в свое время с Docker. Долго ходили мнения, что Docker в продакшене – это самоубийство. Сейчас же мы видим, что контейнеризация это главный инструмент для дистрибьюции ПО. Я думаю, что в будущем тоже самое ожидает serverless. Все больше и больше людей будут ему доверять.
Убьёт ли serverless монолиты?
Этот вопрос можно перефразировать как «Убьет ли микросервисная архитектура монолиты?». Потому что serverless это идеальный микросервер – он маленький, он stateless и имеет минимальный интерфейс общения с внешним миром. Так же, как микросервисы не убьют монолиты, так и лямбды не убьют монолиты. Все три архитектуры имеют определенный спектр задач, к которым они идеально подходят. И наоборот – есть задачи, где, например, serverless использовать нецелесообразно. Подробности ищите в моем докладе.
Что делать с vendor lock? Например, ты разработал лямбду для Amazon, но решил переехать на Google.
Миграция между платформами болезненна, если вы не используете какой-то фреймворк, например, serverless, который предоставляет абстрактный API над облачными провайдерами и позволяет вам одну и ту же функцию задеплоить и в Amazon и в Google. Если вы, грубо говоря, все делаете руками, то да, будет немного болезненно.
Что делать с общими частями лямбд при использовании кода? Например, каким-то common компонентами, каким-то утилитарными функциями и так далее.
На эту тему до сих пор нет best practices. И вопрос снова можно переформулировать в «Как шарить общий код между микросервисами?», потому что смысл тот же. Есть вариант, когда вы держите реиспользуемую логику где-то в shared, а в самих функция подключаете ее. Такой подход хорошо сработает, например, с Go, где на выходе у вас получается один исполняемый файл. Другой вариант – избавиться от связности компонент и допустить дублирование. Наверное, стоит пробовать и смотреть, что больше подойдет. Единственное, что я могу посоветовать – не пытаться делать лямбда функции универсальными. В какой-то момент вам может показаться, что идеальным решением проблемы дублирования кода будет сделать одну убер-функцию. Но со временем вы поймете, что это путь в никуда. Вы получите некую «монолитную версию serverless» со всеми проблемами и первой, и второй архитектуры.
Подробнее обсудим после доклада на RubyRussia!
Приходите и вы, регистрация еще открыта, конференция состоится в следующую субботу, 28 сентября.
Будут не только доклады, но и стенды лучших компаний:
Организатор — Evrone
Генеральный партнер — Toptal
Золотой партнер — Gett
Серебряные партнеры — Валарм, JetBrains, Bookmate и Cashwagon
Бронзовый партнер — InSales
