Микросервисы: что это такое и почему нужно заботиться о вашем бизнесе

Корпоративный программный ландшафт изобилует шумными технологиями. Мы писали о многих из них, будь то блокчейн, разработка низкого кода или другие новые тенденции, которые меняют нашу работу. Одно новое модное слово, о котором вы, возможно, раньше не слышали, - «микросервисы».

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

Причина, по которой предприятия должны заботиться о микросервисах, заключается в том, что закулисная архитектура может помочь вашим разработчикам и ИТ-специалистам быстрее работать и внедрять инновации, управлять инфраструктурой и снижать стоимость и сложность добавления новых функций и функций в приложение. Аль Хилва, программный директор по исследованию программного обеспечения для разработки приложений в IDC, объяснил, как он будет предлагать микросервисы руководителю, учитывая при этом как культурные, так и технические проблемы.

«При создании новых систем, вероятно, ключевым моментом является признание того, что небольшая команда должна создать единый микросервис», - сказал Хилва. «Во-вторых, допуск разнообразия в языках программирования и рабочих процессах разработчиков часто подразумевается независимым характером общей культуры микросервисов. Основной шаг для исполнительного директора заключается в постепенном создании программного обеспечения с использованием небольших групп, причем каждый из них создает согласованный модуль с опубликованным Преимущество состоит в том, что независимые модули могут развиваться гораздо быстрее независимо, если опубликованные API управляются организованно ».

Что такое микросервисы?

Хилва является автором отчета IDC за 2015 год, озаглавленного «Появление микросервисов как новый архитектурный подход к созданию новых программных систем». В отчете он определяет микросервисы как гранулированную программную архитектуру, в которой компоненты приложения разрабатываются и развиваются независимо друг от друга в соответствии с определенными API требованиями к совместимости (т.е. связаны с приложением в целом). Микросервисы не существуют в вакууме, хотя. Новая архитектура требует сильной организационной поддержки и изменения в ИТ-культуре.

Микросервисы также определяются не какой-то одной конкретной технологией, а эволюцией давней концепции сервис-ориентированной архитектуры (SOA), дополненной появлением контейнеров и ростом автоматизации благодаря таким подходам к разработке, как непрерывная доставка (CD) и непрерывная интеграция (ДИ).

«Организации, использующие микросервисы сегодня, обычно мотивированы стремлением к более быстрому развитию услуг», - сказал Хилва. «Таким образом, в большинстве таких случаев микросервисы в значительной степени используют автоматизацию CI / CD. Тем не менее, скорость фактического развертывания может быть разной для разных служб. Я думаю, что ключ заключается в том, чтобы хорошо взглянуть на внутреннюю культуру и уверен, что вы готовы терпеть большую децентрализацию и разнообразие технологий."

Под «внутренней культурой» Hilwa в значительной степени ссылается на DevOps, философию, которая объединяет разработку программного обеспечения, ИТ-операции и обеспечение качества (QA) в единый совместный рабочий процесс. Запуск программного обеспечения DevOps HashiCorp и его основатели уже давно являются сторонниками микросервисов. Компания, которая недавно получила финансирование серии B на сумму 24 млн. Долларов США, считает такие компании, как Cisco, DigitalOcean, Mozilla и Stripe, своими пользователями с открытым исходным кодом и корпоративными клиентами.

Микросервисы являются основой того, как HashiCorp подходит к разработке инфраструктуры DevOps и рабочим процессам приложений в своих популярных инструментах с открытым исходным кодом и растущем наборе корпоративных продуктов. Армон Дадгар, технический директор и соучредитель HashiCorp, преодолел разницу между монолитами и микросервисами, используя простую аналогию: Amazon и eBay.

«Думайте об Amazon и eBay как об отдельных приложениях. С точки зрения конечного пользователя они выглядят одинаково, но за кулисами компании использовали противоположные подходы в том, как они создавали и проектировали свои приложения», - сказал Дадгар. «Amazon с самого начала был набором микросервисов; он действует как единое приложение. Но если вы возьмете поиск, каталог товаров, корзину, счета-фактуры, потоки заказов и разделите эти функции, два приложения будут работать по-разному. машины «.

Аналогия с Amazon также распространяется на структуру самого Amazon. Дадгар объясняет, что такие технологические подходы, как микросервисы, являются инструментами для поддержки более масштабного процесса в направлении DevOps. «Правило двух пиццерий» Джеффа Безоса работает таким образом, что в каждой команде Amazon работает от пяти до восьми человек. Если команда становится больше, то она делится на две части.

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

«eBay придерживался монолитного подхода; они создали весь eBay как длинное приложение длиной в 50 миллионов строк кода», - сказал Дадгар. «Микросервисный подход поначалу более болезненный, потому что проблемы модульности и функциональной совместимости не существуют в монолите. Но вещи начинают разрушаться, когда приложение становится слишком большим. В монолите нет декомпозиции.

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

Контейнеры и микросервисы в мире DevOps

То, как ваш бизнес реализует архитектуру микросервисов, будет иметь большое значение для определения того, окупаются ли инвестиции. Микросервисы требуют много работы, особенно в интеграции API, которая необходима для того, чтобы все сервисы общались друг с другом. Хилва объяснил, что это еще сложнее при попытке интегрировать микросервисы в существующую систему; он рекомендует предприятиям создавать новые системы всякий раз, когда это возможно, а не реструктурировать устаревшее монолитное приложение для микросервисов.

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

Если вы реорганизуете устаревшее приложение, то Hilwa рекомендует делать это постепенно. Хотя микросервисы даже важнее интеграции API, они не работают без культуры DevOps. Дадгар из HashiCorp сказал, что, когда речь заходит о большем зонте DevOps, микросервисы становятся инструментом, способствующим более значительному переходу процессов в сторону фундаментального изменения рабочих процессов, с помощью которых мы доставляем приложения. Он указал на Дао HashiCorp, изложенное, когда он и соучредитель Митчелл Хасимото основали компанию: простой, модульный и составной.

«DevOps в некотором смысле является еще более перегруженным термином, чем микросервисы», - сказал Дадгар. «Но бизнес состоит из людей с различными специальностями знаний: разработчики, операторы, сотрудники службы безопасности. И затем у вас есть процесс, способ организации этих людей. Затем у вас есть инструменты для поддержки этого процесса, где микросервисы и контейнеры заходи."

Контейнеры, популяризированные взрывом Docker с открытым исходным кодом, далеко не единственные инструменты, которые предприятия могут использовать для упрощения работы с микросервисами. По словам Хилвы из IDC, контейнеры используются в современных приложениях как часть рабочих процессов CI / CD и, в некоторых случаях, при развертывании на производстве. Но он сказал, что микросервисы также могут использовать виртуальные машины (ВМ) без необходимости использования контейнеров.

Тем не менее, когда речь идет о путях развития бизнес-облаков, контейнеры и микросервисы Docker представляют собой мощную комбинацию инструментов, которую используют предприятия всех форм и размеров - от стартапов, таких как HashiCorp, до корпоративных гигантов, таких как Oracle. Дадгар из HashiCorp сказал, что контейнеры - это удобное средство, с помощью которого Dev и Ops (и, по ассоциации, разные команды и сервисы) общаются друг с другом.

«Какой артефакт мы передаем между разработчиками и операторами? Что мы тщательно обдумываем и строим вокруг? Контейнеры - это удобная единица, которую нужно обойти», - сказал Дадгар. «Подумайте о глобальном корпоративном судоходном продукте по всему миру. Будь то грузовое судно, грузовой поезд или грузовик, это одна и та же единица, проходящая через всю систему».

DevOps и микросервисы все еще далеки от широкого распространения на предприятиях, но рынок только растет. Согласно отчету IDC, архитектура микросервисов вступит в фазу созревания в течение следующих пяти лет. Эта зрелость наступит вслед за культурой DevOps, которая к 2020 году охватит 50 процентов организаций, дальнейшее развитие инструментов автоматизации программного обеспечения и доминирование дешевой масштабируемой облачной инфраструктуры, предоставляемой такими сервисами, как Amazon Web Services (AWS) и Microsoft Azure.

Дадгар сказал, что, несмотря на небольшую долю предприятий, которые в настоящее время используют DevOps и микросервисы, HashiCorp уже значительно переподписан. Он достиг своего первого семизначного дохода после девяти месяцев корпоративных продаж, благодаря сообществу open source на GitHub, состоящему из нескольких миллионов активных пользователей в месяц. Микросервисы являются лишь частью конвейера инструментов приложений HashiCorp и более широкой схемы инфраструктуры DevOps. Но модульность и функциональная совместимость, лежащая в основе всего, что создает компания, способствовали стремительному росту одного из самых горячих стартапов программного обеспечения в Силиконовой долине.

«Четыре года назад, когда мы начинали, мы собирались на встречи и представляли, как будет управляться инфраструктура», - сказал Дадгар. «Мы не смеялись точно из зала; мы знали, что это было рано. Но теперь наши инструменты, такие как Terraform, находятся на пути к тому, чтобы стать отраслевыми стандартами. Мы увидим эффект домино от конкурентного давления и, в В долгосрочной перспективе наша роль будет заключаться в сотрудничестве с ИТ-директорами и ИТ-директорами, чтобы понять, какой сдвиг процесса им необходим.

«Подумайте о Тойоте в те времена, - продолжил Дадгар. «У вас была куча автомобильных компаний, производящих продукцию, но стоимость была выше, чем должна быть. Toyota не изобретала автомобиль заново; они были более строгими и последовательными в этом процессе и перешли от посмешища к электростанции, заставив остальная часть отрасли должна принять тот же набор практик, чтобы оставаться конкурентоспособными. Сейчас у нас есть лидеры отрасли, спрашивающие, как они могут получить конкурентное преимущество, и их ответ заключается в том, чтобы перенять практики Google и амазонок на рынке. Дело в том, что оно достигнет критической массы."