🌡 - очередной пост из серии “уберите от экранов неайтишников” 😉
Быть разработчиком в найме - это когда за время работы над каким-то проектом вышло несколько новых технологий/библиотек, и у тебя руки чешутся что-нибудь из них попробовать, но начальник говорит: “будем использовать проверенный стек технологий”.
Быть самозанятым разработчиком, которые делает стартап - это когда ты также хочешь попробовать что-то новое, но разум тебе говорит: “надо использовать проверенный стек технологий”, для того, чтобы запуститься быстрее. Но иногда внутренний хипстер побеждает разум и вот ты уже находишь себя читающим мануалы “как обновить код у лямбды”.
Так вот, я лет 5 назад узнал про подход Serverless, это когда мы строим наше приложение таким образом, что для него не нужно арендовать отдельные сервера и на них устанавливать все окружение и заливать туда свой код. Вместо этого мы запаковываем свой код и необходимое для запуска окружение в пакеты (у Amazon Web Services это называется Lambda), которые хостер сам разливает по своим серверам и запускает, когда нам нужно вызвать какую-нибудь функцию из пакета.
Зачем вообще это все? Ну, главными плюсом я вижу более простое масштабирование. В случае традиционного подхода, когда мы хостимся на серверах, нам самим нужно этим всем заниматься. В случае Serverless-подхода правильно выстроенная архитектура с самого начала позволит одинаково хорошо работать и с 10 юзерами, и с 10’000 - хостер сам будет разливать твой код на свои сервера ровно настолько, насколько это нужно.
Второй плюс: в некоторых случаях этот подход позволит сэкономить денег на серверах, и кажется, это как раз мой случай.
Все эти 5 лет я хотел попробовать Serverless в деле, но все не было удобного случая и вот он нашелся. Помним, что у нас есть следующие задачи:
⁃ принять данные по заказу от пользователя с помощь телеграм-бота
⁃ осуществить покупку брони и отправить полученную бронь пользователю.
Первый пункт при желании можно было реализовать через Serverless-подход, но мне было просто лень 🙂 У меня уже были наработки в телеграм-ботах, поэтому я взял проверенные технологии и запилил все быстрее, чем я бы стал разбираться как писать serverless телеграм-бота.
Самое интересное со вторым пунктом. Для Selenium’а, который используется для оформления брони, нужно минимум 2 Гб оперативки. А что, если случится хабр-эффект, и после рекламной кампании ко мне прибежит одновременно несколько заказов, придется делать очередь, но тогда я не смогу выдержать обещанные “сделаем бронь за 2 минуты”. Ну и самое главная проблема: пока заказов нет, сервер простаивает, и за него надо платить.
Выходом стало использование AWS Lambda. Заставить работать Selenium в лямбде был тот еще квест: нужно было подобрать идеальную комбинацию Python’а, Selenium’а и других библиотек. Но в итоге все получилось и теперь я готов выполнять любое количество заказов одновременно, главное, чтобы не лег сайт авиакомпании 😂
В общем, внутренний хипстер доволен, а заодно, кажется и деньжат немного удастся сэкономить на серверах 🙂
Быть разработчиком в найме - это когда за время работы над каким-то проектом вышло несколько новых технологий/библиотек, и у тебя руки чешутся что-нибудь из них попробовать, но начальник говорит: “будем использовать проверенный стек технологий”.
Быть самозанятым разработчиком, которые делает стартап - это когда ты также хочешь попробовать что-то новое, но разум тебе говорит: “надо использовать проверенный стек технологий”, для того, чтобы запуститься быстрее. Но иногда внутренний хипстер побеждает разум и вот ты уже находишь себя читающим мануалы “как обновить код у лямбды”.
Так вот, я лет 5 назад узнал про подход Serverless, это когда мы строим наше приложение таким образом, что для него не нужно арендовать отдельные сервера и на них устанавливать все окружение и заливать туда свой код. Вместо этого мы запаковываем свой код и необходимое для запуска окружение в пакеты (у Amazon Web Services это называется Lambda), которые хостер сам разливает по своим серверам и запускает, когда нам нужно вызвать какую-нибудь функцию из пакета.
Зачем вообще это все? Ну, главными плюсом я вижу более простое масштабирование. В случае традиционного подхода, когда мы хостимся на серверах, нам самим нужно этим всем заниматься. В случае Serverless-подхода правильно выстроенная архитектура с самого начала позволит одинаково хорошо работать и с 10 юзерами, и с 10’000 - хостер сам будет разливать твой код на свои сервера ровно настолько, насколько это нужно.
Второй плюс: в некоторых случаях этот подход позволит сэкономить денег на серверах, и кажется, это как раз мой случай.
Все эти 5 лет я хотел попробовать Serverless в деле, но все не было удобного случая и вот он нашелся. Помним, что у нас есть следующие задачи:
⁃ принять данные по заказу от пользователя с помощь телеграм-бота
⁃ осуществить покупку брони и отправить полученную бронь пользователю.
Первый пункт при желании можно было реализовать через Serverless-подход, но мне было просто лень 🙂 У меня уже были наработки в телеграм-ботах, поэтому я взял проверенные технологии и запилил все быстрее, чем я бы стал разбираться как писать serverless телеграм-бота.
Самое интересное со вторым пунктом. Для Selenium’а, который используется для оформления брони, нужно минимум 2 Гб оперативки. А что, если случится хабр-эффект, и после рекламной кампании ко мне прибежит одновременно несколько заказов, придется делать очередь, но тогда я не смогу выдержать обещанные “сделаем бронь за 2 минуты”. Ну и самое главная проблема: пока заказов нет, сервер простаивает, и за него надо платить.
Выходом стало использование AWS Lambda. Заставить работать Selenium в лямбде был тот еще квест: нужно было подобрать идеальную комбинацию Python’а, Selenium’а и других библиотек. Но в итоге все получилось и теперь я готов выполнять любое количество заказов одновременно, главное, чтобы не лег сайт авиакомпании 😂
В общем, внутренний хипстер доволен, а заодно, кажется и деньжат немного удастся сэкономить на серверах 🙂
