Я стал замечать, что в последнее время в программировании тоже есть своя мода, свои законодатели моды, модные течения и так далее. Вот сейчас модно рассказывать про микросервисы и контейнеры, как возможность простой реализации микросервисов. Хотя, сразу оговорюсь, микросервисы <> контейнеры. Контейнеры имеют гораздо больше сценариев применения, чем реализация микросервисных архитектур. Итак, предлагаю поговорить под катом на тему: «Почему микросервисы и почему сейчас?»
Тенденции развития технологии таковы, что сейчас мощные вычислительные ресурсы и ресурсы хранения становятся доступнее как локально, так и в облаке. Если раньше нужно было найти хотя бы какую-то вычислительную мощность, сейчас всё чаще встаёт задача не только найти, но и применить с максимальной пользой.
Очевидное применение микросервисов — повышение эффективности использования доступных вычислительных мощностей при масштабировании решения. Важно понимать, что выгода от использования микросервисной архитектуры наступает в этом случае только тогда, когда дополнительная инфраструктура, необходимая для управления микросервисным решением по сравнению с обычным монолитным (многозвенным), требует меньше вычислительных мощностей, чем мы сэкономили при переходе на неё. Таким образом, в общем случае, выгода от использования микросервисной архитектуры, не настолько очевидна, как это было в начале абзаца.
Тогда зачем всё это?
А вот здесь уже возникает следующий уровень истории. Что нам позволяет микросервисная архитектура в силу своей разъединённости? Она позволяет добавлять в систему новый функционал за значительно меньшее время, чем это требуется для монолитной системы.
Таким образом использование микросервисной архитектуры может принести вполне понятную ценность бизнесу — уменьшение времени выхода на рынок нового функционала в продукте.
Разберём классический пример
Представим себе систему онлайн-платежей. И погрузимся в пршлое, когда функционал систем онлайн-платежей измерялся возможностью осуществления разнообразных платежей: за сотовый телефон, спутниковое телевидение и так далее.
Итак нам нужно добавить нового платёжного партнёра.
В случае монолитной архитектуры мы привязаны к одному языку, фреймвоку, платформе и вынуждены разрабатывать каждый новый функционал, используя сделанный кем-то давным-давно выбор. Даже если выбор другой платформы и фреймворка сократит время разработки в несколько раз.
Плюс перед выпуском системы в боевой режим, по-хорошему, мы должны провести полный цикл релиз-тестирования всей системы.
Если наша система основана на микросервисной архитектуре, в общем случае, мы не привязаны к языку, фреймворку или платформе, а тестировать нам необходимо только связку модулей с которыми будет взаимодействовать наш новый платёжный модуль.
У вас сокращается время запуска нового функционала, а конкуренты с монолитной системой продолжают разработку и тестирование, к тому же теряют клиентов, которым позарез нужен именно этот платёжный партнёр. А мы отлично выдерживаем этот наплыв клиентов и запросов, потому что в силу выбранной архитектуры можем масштабировать этот платёжный модуль более эффективно, так как можем вместе с ним масштабировать только необходимые ему модули, а не всю систему.
Наш продукт получил преимущество, продажи растут, нашему маркетингу теперь опять есть о чём рассказать.
Директор выдаёт дополнительное финансирование технологическому подразделению.
Бессерверная организация исполнения кода
Можно было бы на этой позитивной ноте и закончить, но обратите внимание на важную часть микросервисной архитектуры — микросервисы максимально разъединены, а некоторые нужны только очень короткое время для выполнения одной задачи. И вот тут возникает история ещё одна модная сейчас история — 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
