company_banner

Микросервисы: Azure Functions — скажи серверу нет

    Я стал замечать, что в последнее время в программировании тоже есть своя мода, свои законодатели моды, модные течения и так далее. Вот сейчас модно рассказывать про микросервисы и контейнеры, как возможность простой реализации микросервисов. Хотя, сразу оговорюсь, микросервисы <> контейнеры. Контейнеры имеют гораздо больше сценариев применения, чем реализация микросервисных архитектур. Итак, предлагаю поговорить под катом на тему: «Почему микросервисы и почему сейчас?»



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

    Очевидное применение микросервисов — повышение эффективности использования доступных вычислительных мощностей при масштабировании решения. Важно понимать, что выгода от использования микросервисной архитектуры наступает в этом случае только тогда, когда дополнительная инфраструктура, необходимая для управления микросервисным решением по сравнению с обычным монолитным (многозвенным), требует меньше вычислительных мощностей, чем мы сэкономили при переходе на неё. Таким образом, в общем случае, выгода от использования микросервисной архитектуры, не настолько очевидна, как это было в начале абзаца.

    Тогда зачем всё это?


    А вот здесь уже возникает следующий уровень истории. Что нам позволяет микросервисная архитектура в силу своей разъединённости? Она позволяет добавлять в систему новый функционал за значительно меньшее время, чем это требуется для монолитной системы.

    Таким образом использование микросервисной архитектуры может принести вполне понятную ценность бизнесу — уменьшение времени выхода на рынок нового функционала в продукте.

    Разберём классический пример


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

    Итак нам нужно добавить нового платёжного партнёра.

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

    Плюс перед выпуском системы в боевой режим, по-хорошему, мы должны провести полный цикл релиз-тестирования всей системы.

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

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

    Наш продукт получил преимущество, продажи растут, нашему маркетингу теперь опять есть о чём рассказать.

    Директор выдаёт дополнительное финансирование технологическому подразделению.

    Бессерверная организация исполнения кода


    Можно было бы на этой позитивной ноте и закончить, но обратите внимание на важную часть микросервисной архитектуры — микросервисы максимально разъединены, а некоторые нужны только очень короткое время для выполнения одной задачи. И вот тут возникает история ещё одна модная сейчас история — serverless — бессерверная организация исполнения кода.

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

    Результат — экономия вычислительных ресурсов, а сама технология — удобный паттерн реализации event driven архитектуры. В облаке Azure этот паттерн реализуется через Azure Functions. Функции можно писать на различных языках, включая JavaScript, C#, F#, а также с помощью Python, PHP, Bash и PowerShell. Всё это можно сделать в простом веб-интерфейсе или можно загрузить предварительно скомпилированный код, созданный, например, с помощью Visual Studio.

    Короткое введение в функции можно посмотреть ниже.



    Типовые сценарии использования и обзор технологической платформы Azure App Service


    Также приглашаю вас 16 марта в 11:00 (МСК) на вебинар, в рамках которого я буду рассказывать про типовые сценарии использования технологической платформы Azure App Service.

    Использование PaaS сервисов к которым относится набор сервисов Azure App Service может открыть новые возможности для решения бизнес и технологических задач. Самое сложное – выбрать правильный сервис из того большого списка доступных PaaS сервисов. Для этого нужно понимать, что предоставляет каждый из сервисов и какие типовые задачи решает.

    Участие бесплатное.

    И на десерт


    Сейчас идёт Azure Functions Challenge, где можно выполнять задания, разрабатывая Azure Functions, проверить свои навыки разработчика и получить за это бэйджики. :)

    Напоминаем, что бесплатно попробовать Microsoft Azure можно здесь.
    Microsoft
    404,46
    Microsoft — мировой лидер в области ПО и ИТ-услуг
    Поделиться публикацией

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

      0
      Видео спецально записывалось тем, кто плюет в микрофон? Слушать вообще не возможно. По существу: вот интересно, на сколько дороже использовать этот сервис, чем обычная виртуалка на linux в том же azure vm.
        0
        Смысл функций в том, как я понял, что их можно подвязать на события из storage. Новые записи в таблицах, очередях и т.д.
          0
          В теории да, но как работает их storage я думаю все знают — отваливается по timeout очень часто. Обязательно проверю, как работает привязка, надеюсь она получает данные не по триггеру на insert, а до вставки в таблицу или блоб. Это удобно для стриминговых проектов, когда лень писать инфраструктуру.
            0
            Нет тригера на таблицы, есть на очередь и BLOB. Работает по тестам вполне хорошо.
        0
        А что с надёжностью? Смотрю на них с беты. Вот приходит событие с queue например, а код упал (ну мало ли что) — событие пропадёт или перезапустится функция?
          0
          я так понимаю просто output не сработает именно для этого эвента и следующее обращение к функции будет уже как будто ничего не было
          0

          Читал только обзоры типа этого про serverless. Как я понял идею, по факту появления события в очереди, поднимается виртуалка/контейнер, читает событие из очереди, обрабатывает его, возможно генерируя новые и события и умирает. Красиво? Вроде. Вопрос — а насколько увеличивается время обработки события по сравнению с демоном, подписанном на ту же очередь? Запустить даже докер-контейнер может секунды занимать (


          time docker run busybox


          real 0m0.482s
          user 0m0.012s
          sys 0m0.012s
          ), не говоря о полноценной виртуалке.

            0
            Там не совсем так, нет контейнеров, поэтому время запуска в холодную меньше в любом случае. Но, в целом, правильный вопрос. Иногда возникали задержки при первом вызовые функции, когда они были в preview, обещали решить этот вопрос к релизу.

            Если интересно, как устроеные функции — это здесь https://github.com/Azure/azure-webjobs-sdk-script

            Функции, если упростить, это несколько специализированные и заточенные под некоторые типы сценариев WebJob.
              0
              Вообще-то не совсем «там не совсем так» :) Практически у всех реализаций все обернуто либо в контейнер, либо, как минимум, в неймспейсы, изолирующие одни юзерские процессы от других. Да и если рабочее окружение контейнера с файловой системой уже находится в кэше, то запуск процесса в контейнера ничем не отличается от простого запуска процесса. То есть время на запуск процесса и загрузку в него библиотек требуется по-любому.

              Где-то могут быть еще вариации, типа security manager в JVM, позволяющий в одной JVM запускать треды разных юзеров. Ну или PHP с safe_mode. Но это, честно говоря, кривая реализация и от таких нужно бежать — со всех сторон плохо: и плохо с безопасностью, и конкуренция за ресурсы, и неточный биллинг.

              В Azure не стали же делать криво?
                0
                Функции — специализированные WebJob. WebJob запускаются в изолиованом окружении на базе Kudu — https://github.com/projectkudu/kudu

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

                Вот здесь https://github.com/Azure/azure-webjobs-sdk-script/issues/298 и вот здесь https://github.com/Azure/azure-webjobs-sdk-script/issues/529 можно почитать обсуждение с разработчиками на тему холодного запуска для функций на js с большим деревом npm зависимостей, там можно и про детали реализации почитать, если нет желания смотреть в код.

                Когда я тестировал «сами в себе» C#, собранные в библиотеки функции подобных проблем не наблюдал.
              0
              А на события можно и демона повесить?
                0
                Можно, но для этого нужен/предназначен WebJob. Другой способ масштабирования и он не совсем serverless.
              0

              JVM-языки поддерживаются?

                +1
                Официально нет, но техническая возможность есть https://github.com/Azure/azure-webjobs-sdk-script/wiki/Creating-a-Java-Azure-Function
                  0

                  Спасибо. Было бы еще интересно почитать про сравнение с AWS Lambda, поскольку сервисы, по сути, конкурирующие.

                    0
                    Вот есть сравнение на StackOverflow http://stackoverflow.com/questions/40326085/compare-aws-lambda-azure-functions-and-google-cloud-function
                0
                Безсерверная — пишется через «з»
                  0
                  Согласно правилам правописания приставок русского языка, оканчивающихся на з/с, изучаемых приблизительно в 5 классе, там пишется «с».

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

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