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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Участие бесплатное ^[3].

И на десерт

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

Напоминаем, что бесплатно попробовать Microsoft Azure можно здесь ^[5].

Автор: Microsoft

Источник ^[6]