Некоторые неочевидные преимущества Serverless для DevOps

    Перед вами, с разрешения автора, мой довольно вольный пересказ статьи DevOps-инженера Paul Hammant, в которой он очень просто описывает не очень очевидные преимущества Serverless с точки зрения DevOps, а также безопасности работы с бекендом приложения.

    42

    Для начала Пол приводит диаграмму того, как протекают процессы в Serverless и в чем принципиальное отличие этого подхода от традиционной архитектуры работы фронтенд приложений с бекендом. В диаграмме автор намекает нам на то, каким образом был получен известный ответ на «Главный вопрос жизни, вселенной и всего такого» из «Путеводителя для путешествующих автостопом по галактике» Дугласа Адамса.

    Serverless Architecture

    Порты, процессы и все такое


    Ключевой факт для автора в том, что 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
    Rusonyx
    99,00
    Компания
    Поделиться публикацией

    Комментарии 15

      +1
      >отказ от схемы имя: порт — одно и ключевых преимуществ для DevOps
      По-моему это далеко не самая большая проблема девопсов…
        +1
        Просто ключевое преимущество решает такуюсебе проблему :)
        0
        Serverless функции не имеют никаких доменных имен, никаких TCP/IP адресов и даже не слушают никакие порты.
        Автору явно никогда не приходилось создавать сабнет, чтоб организовать доступ лямбды к интернету. Оно может и правда, но только в простых случаях. А так-то и серверу IP назначить не сложно.
          0

          А где и зачем нужно делать сабнет в случае function as a service? Провайдер генерирует вам ссылку на API функции и вы ее дергаете.

            0
            Для доступа к внешним ресурсам из лямбды.
            aws.amazon.com/ru/premiumsupport/knowledge-center/internet-access-lambda-function
              0

              Это особенность именно aws lambda. В других платформах, например, гугле, ibm, в нашем swifty, такого нет.

                +1
                Это только для лямбд, которые задеплоены в VPC (например, чтобы лазить в базу). Если не требуется лазить в VPC, то не стоит функции туда деплоить, тк они медленнее работают при этом.
                +2
                Как только появится необходимость debug'a работающего сервиса, так сразу вспомните про IP, домены, URI и порты.
                  0
                  Честно говоря, не представляю ситуацию, когда для бекенда сделанного на serverless придется разделять сервисы по портам или чему-то подобному. Ну нет такого сценария. Знаете — расскажите, а мы исправимся и допилим, что нужно будет допилить!

                  У нас есть функция, которая решает конкретную задачу, например, post и get в mongodb. У нее есть одна единственная ссылка на API, которая дергает эту функцию и только ее. Если есть вторая функция, которая загружает данные в другую коллекцию или другую mongo, то у нее есть своя функция со своей ссылкой. И никаким образом вы не достучитесь к первой базе, зная ссылку только на вторую функцию.

                  А что касается трафика внутри платформы, то тут мы рулим сами и, если накосячим, то сами и будем разруливать порты.
                    0
                    Начнем с того, что у MongoDB изменилась лицензия.
                    «MongoDB ранее лицензировался под GNU AGPL v3, это означало, что компании, которые хотели запускать MongoDB как публичный сервис, должны были открыть исходный код своего ПО или получить коммерческую лицензию от MongoDB»


                    В случае сервиса API с get и post, непонятно где чекать ошибки в ДНС ресолвинге, http запросах.
                0

                Не надо ничего создавать, если вам не надо ходить к ресурсам внутри VPC.

                  0
                  А если надо? А если надо в интернет? Моя мысль в том, что с ростом требований сложность конфигурации растет.
                    0

                    Если надо в интернет, но не надо в VPC, то ничего не надо настраивать. Если надо в VPC и в интернет, то сажаете в правильную подсеть. Собственно, у лямбды из настроек только подсети.

                      0
                      Если надо в интернет, но не надо в VPC

                      Вы ошибаетесь, см. ссылку в дискуссии выше.
                        0
                        Дык по ссылке как раз про VPC-enabled речь.

              Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

              Самое читаемое