Перед вами, с разрешения автора, мой довольно вольный пересказ статьи DevOps-инженера Paul Hammant, в которой он очень просто описывает не очень очевидные преимущества Serverless с точки зрения DevOps, а также безопасности работы с бекендом приложения.
Для начала Пол приводит диаграмму того, как протекают процессы в Serverless и в чем принципиальное отличие этого подхода от традиционной архитектуры работы фронтенд приложений с бекендом. В диаграмме автор намекает нам на то, каким образом был получен известный ответ на «Главный вопрос жизни, вселенной и всего такого» из «Путеводителя для путешествующих автостопом по галактике» Дугласа Адамса.
Ключевой факт для автора в том, что Serverless функции не имеют никаких доменных имен, никаких TCP/IP адресов и даже не слушают никакие порты. Это справедливо по крайней мере для пользователей Serverless облака, тех, кто создает бекенды на основе этих функций. Внутри Serverless платформы все это определенно присутствует, но пользователям системы не видно.
Весь роутинг делается только на основе неких логических имен. Получается, что для запуска моей Serverless функции zipCodeService, которая декодирует адрес в индекс, мне нужно знать, собственно, только адрес и ссылку на ее API, который мне любезно и автоматически генерирует сама Serverless платформа. Такой красивый дизайн позволяет иметь совершенно независимые друг от друга функции для выполнения той или иной логики приложения, которые никак не пересекаются и не мешают друг другу, а стоимость каждой функциональности, каждого запроса, каждого экрана можно подсчитать отдельно. Эти функции даже могут использовать разные языки программирования. И все в рамках одного приложения!
При этом, если мы говорим про одну и ту же функцию, то Serverless позволяет нам создавать множество таких функций для каждого разработчика, отдельных CI процессов, тестирования, стейджинга, продакшена. При этом, мы четко знаем, кто, когда и в каких объемах воспользовался своей функцией и можем четко разделить наши затраты на их выполнение между отдельными потребителями. Дисциплинирует, не правда ли?
Помимо всех остальных преимуществ Serverless, отказ от схемы имя: порт — одно и ключевых преимуществ для DevOps. Хотя два процесса на одном сервере по-прежнему не могут слушать по одному и тому же порту, нам это уже не важно, так как мы разделяем эти процессы с помощью самого простого способа — по имени. А назвать функции мы можем как угодно, ограничиваясь только собственной фантазией, в отличии от портов, где есть жесткие ограничения.
Также в Serverless мы не оперируем такими вещами как сокеты, по крайней мере при обращении к Serverless функциям и обмене данными между ними.
Как и при использовании докер контейнеров, мы не задумываемся о процессах, почему они упали и как их восстановить. Но, в отличии от докера, нам не нужно думать о самих докер процессах и процессах оркестрации контейнеров. Не нужно думать о настройке и поддержке Kubernetes.
С одной стороны, очевидно, что не все становится так радужно с переходом на Serverless, да и сам переход не всегда будет простым. С другой — зачем тратить свое время и использовать промежуточные варианты в виде докера, если можно сразу переходить на следующий уровень?
Как на практике переходить на следующий уровень мы ранее описывали:
Serverless todo приложение с авторизацией и картинками
Serverless бот для Telegram
Дальше будет больше гайдов!
Make your ideas come app на нашей serverless платформе Swifty
Для начала Пол приводит диаграмму того, как протекают процессы в Serverless и в чем принципиальное отличие этого подхода от традиционной архитектуры работы фронтенд приложений с бекендом. В диаграмме автор намекает нам на то, каким образом был получен известный ответ на «Главный вопрос жизни, вселенной и всего такого» из «Путеводителя для путешествующих автостопом по галактике» Дугласа Адамса.
Порты, процессы и все такое
Ключевой факт для автора в том, что Serverless функции не имеют никаких доменных имен, никаких TCP/IP адресов и даже не слушают никакие порты. Это справедливо по крайней мере для пользователей Serverless облака, тех, кто создает бекенды на основе этих функций. Внутри Serverless платформы все это определенно присутствует, но пользователям системы не видно.
Весь роутинг делается только на основе неких логических имен. Получается, что для запуска моей Serverless функции zipCodeService, которая декодирует адрес в индекс, мне нужно знать, собственно, только адрес и ссылку на ее API, который мне любезно и автоматически генерирует сама Serverless платформа. Такой красивый дизайн позволяет иметь совершенно независимые друг от друга функции для выполнения той или иной логики приложения, которые никак не пересекаются и не мешают друг другу, а стоимость каждой функциональности, каждого запроса, каждого экрана можно подсчитать отдельно. Эти функции даже могут использовать разные языки программирования. И все в рамках одного приложения!
При этом, если мы говорим про одну и ту же функцию, то Serverless позволяет нам создавать множество таких функций для каждого разработчика, отдельных CI процессов, тестирования, стейджинга, продакшена. При этом, мы четко знаем, кто, когда и в каких объемах воспользовался своей функцией и можем четко разделить наши затраты на их выполнение между отдельными потребителями. Дисциплинирует, не правда ли?
Ключевые преимущества для DevOps
Помимо всех остальных преимуществ Serverless, отказ от схемы имя: порт — одно и ключевых преимуществ для DevOps. Хотя два процесса на одном сервере по-прежнему не могут слушать по одному и тому же порту, нам это уже не важно, так как мы разделяем эти процессы с помощью самого простого способа — по имени. А назвать функции мы можем как угодно, ограничиваясь только собственной фантазией, в отличии от портов, где есть жесткие ограничения.
Также в Serverless мы не оперируем такими вещами как сокеты, по крайней мере при обращении к Serverless функциям и обмене данными между ними.
Как и при использовании докер контейнеров, мы не задумываемся о процессах, почему они упали и как их восстановить. Но, в отличии от докера, нам не нужно думать о самих докер процессах и процессах оркестрации контейнеров. Не нужно думать о настройке и поддержке Kubernetes.
Продолжение следует
С одной стороны, очевидно, что не все становится так радужно с переходом на Serverless, да и сам переход не всегда будет простым. С другой — зачем тратить свое время и использовать промежуточные варианты в виде докера, если можно сразу переходить на следующий уровень?
Как на практике переходить на следующий уровень мы ранее описывали:
Serverless todo приложение с авторизацией и картинками
Serverless бот для Telegram
Дальше будет больше гайдов!
Make your ideas come app на нашей serverless платформе Swifty
