Мікросервіси: що вони таке і чому ваш бізнес повинен піклуватися

Ландшафт програмного забезпечення підприємства всіяний гнучкими технологіями. Ми писали про багато з них, будь то блокчейн, низький розвиток коду чи інші новітні тенденції, які змінюють наш спосіб роботи. Одне нове словесне слово, про яке ви, можливо, раніше не чули, - це "мікросервіси".

Це за дизайном. Мікросервіси - це інший спосіб архітектури програмного забезпечення, заснований на наборі переплетених модульних компонентів, а не традиційна ідея "моноліту" - додатку, що складається з однієї постійно зростаючої гори коду. Програми на основі мікросервісів не відрізняються від користувальницького інтерфейсу (інтерфейсу користувача), будь то в складному додатку центру обробки даних або в Інтернеті чи мобільному додатку, розміщеному на інфраструктурі масштабованої хмари.

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

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

Що таке мікросервіси?

Hilwa автор доповіді IDC 2015 року під назвою "Поява мікросервісів як новий архітектурний підхід до створення нових програмних систем". У звіті він визначає мікросервіси як детальну архітектуру програмного забезпечення, де компоненти додатків розробляються та еволюціонують незалежно, щоб відповідати визначеним API вимогам інтероперабельності (тобто пов'язані з додатком у цілому). Хоча мікросервіси не існують у вакуумі. Нова архітектура вимагає сильної організаційної підтримки та зрушення ІТ-культури.

Мікросервіси також не визначаються жодною конкретною технологією, але як еволюція давньої концепції архітектури, орієнтованої на сервіс (SOA), посиленої появою контейнерів та підйомом автоматизації за допомогою підходів розвитку, таких як безперервна доставка (CD) та безперервна інтеграція (CI).

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

Під "внутрішньою культурою" Hilwa значною мірою має на увазі DevOps, філософію, що поєднує розробку програмного забезпечення, ІТ-операцій та забезпечення якості (QA) в єдиний, спільний робочий процес. Запуск програмного забезпечення DevOps HashiCorp та його засновники вже давно є прихильниками мікросервісів. Компанія, яка нещодавно забезпечила 24 мільйони доларів фінансування серії B, зараховує компанії, такі як Cisco, DigitalOcean, Mozilla та Stripe, серед своїх користувачів з відкритим кодом та корпоративних клієнтів.

Мікросервіси є основними для того, як HashiCorp наближається до розвитку інфраструктури DevOps та робочих процесів додатків у своїх популярних інструментах з відкритим кодом та зростаючому наборі продуктів для підприємств. Armon Dadgar, CTO та співзасновник HashiCorp, розбив різницю між монолітами та мікропослугами, використовуючи просту аналогію: Amazon та eBay.

"Подумайте про Amazon та eBay як про єдині програми. З точки зору кінцевого користувача вони виглядають схоже, але, за лаштунками, компанії застосовували протилежні підходи у тому, як вони будували та архітектурували свої програми", - сказав Дадгар. "Amazon з самого початку був набором мікросервісів; він діє як одне додаток. Але якщо взяти пошук, каталог товарів, кошик, рахунки-фактури, потоки замовлень та розділити ці функції, ці два програми працюють на різних машини ».

Аналогія Amazon також поширюється на структуру самої Amazon. Dadgar пояснює технологічні підходи, такі як мікросервіси, як інструменти для підтримки більшого руху процесу до DevOps. "Правило двох піц" Джеффа Безоса працює так, що в будь-якій команді Amazon є лише від п'яти до восьми людей. Якщо команда стає більшою, то вона розпадається на два.

Організаційна ієрархія Amazon починає відображати те, що Дадгар описав як "розкладання функціональності". Кожна команда, розділена як на організаційному, так і на модульному рівнях архітектури, має можливість розвиватися та експериментувати вільніше, без необхідності узгоджувати кожну зміну - все ще функціонуючи як частина єдиного згуртованого додатку.

"eBay застосував монолітний підхід; вони створили весь eBay як довгий 50-мільйонний рядок застосування коду", - сказав Дадгар. "Підхід до мікросервісів на початку є більш болісним, оскільки проблеми модульності та інтероперабельності - це ті, які не існують у моноліті. Але все починає руйнуватися, коли додаток стає занадто великим. У моноліті немає розкладання.

"Подумайте про сотні чи тисячі розробників, які співпрацюють над однією базою коду та намагаються координувати. Команда з контролю якості, яка додає функціональність на одній стороні програми, може переламати щось з іншого боку, оскільки немає чіткого поділу ролей та обов'язків. але вам потрібно починати потребувати все більшої координації між керівниками проектів та процесом забезпечення якості, який може зайняти тижні і вузькі місця, незалежно від того, наскільки швидко працює ця команда. На кухні занадто багато кухарів ".

Контейнери та мікросервіси у світі DevOps

Шлях, яким ваш бізнес реалізує архітектуру мікросервісів, пройде довгий шлях до визначення того, чи окупається інвестиція чи ні. Мікросервіси багато працюють наперед, особливо в інтеграції API, необхідного для того, щоб усі служби спілкувалися один з одним. Хільва пояснив, що це ще складніше при спробі інтеграції мікросервісів у існуючу систему; Він рекомендує підприємствам будувати нові системи, коли це можливо, замість того, щоб реконструювати застарілий монолітний додаток для мікропослуг.

"Традиційні системні архітектури, як правило, включають великі, складні системи запису баз даних із складними нормованими схемами", - сказала Хільва. "Факторинг таких систем на менші компоненти з власними незалежними системами вимагає великої роботи над розробкою баз даних і ефективно переписувати більшу частину основної логіки програми. У більшості випадків це, як правило, не вимагає витрат і часу".

Якщо ви реконструюєте застаріле додаток, то Hilwa радить робити це поступово. Хоча навіть важливіші за інтеграцію API, мікросервіси не працюють без культури DevOps, що стоїть за нею. Папа HashiCorp сказав, що, якщо мова йде про більшу парасольку DevOps, мікросервіси стають інструментом для сприяння більшому переходу процесу до принципової зміни робочих процесів, за допомогою яких ми постачаємо додатки. Він вказав на дао HashiCorp, викладене, коли він та співзасновник Мітчелл Хашимото заснували компанію: просту, модульну та компонуючу.

"DevOps в певному сенсі є ще більш перевантаженим терміном, ніж мікросервіси", - сказав Дадгар. "Але бізнес складається з людей з різними спеціальностями знань: розробники, оператори, співробітники служби безпеки. І тоді у вас є процес, спосіб організації цих людей. Тоді у вас є інструменти для підтримки цього процесу, де знаходяться мікросервіси та контейнери увійдіть."

Контейнери, популяризовані вибухом з відкритим кодом Докера, далеко не єдині інструменти, які підприємства можуть використовувати для полегшення мікропослуг. Хілва IDC заявив, що контейнери використовуються в сучасних додатках як частина робочих процесів CI / CD, а в деяких випадках під час розгортання у виробництві. Але він сказав, що мікросервіси можуть також використовувати віртуальні машини (VM), не потребуючи контейнерів.

Це стосується того, що мова йде про шляхи розвитку бізнес-хмар, контейнери та мікросервіси Docker - це потужна комбінація інструментів, яку охоплює бізнес будь-яких форм і розмірів - від стартапів, таких як HashiCorp, до корпоративних гігантів, як Oracle. Папа HashiCorp сказав, що контейнери є зручним засобом, за допомогою якого Dev і Ops (і, за об'єднанням, різні команди та служби) спілкуються один з одним.

"Який артефакт ми передаємо між розробниками та операторами? Що ми ретельно обтікаємо і будуємо? Контейнери - це зручна одиниця для проїзду", - сказав Тадгар. "Подумайте про глобальний товарний товар, що доставляє по всьому світу. Будь то вантажне судно, вантажний поїзд або вантажівка, це той самий блок, що проходить через всю систему".

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

Дадгар сказав, що навіть при невеликій кількості підприємств, які зараз використовують DevOps та мікросервіси, HashiCorp вже значно передплачений. Він досяг перших семизначних доходів після лише дев'яти місяців продажів підприємств, окрім спільноти з відкритим кодом на GitHub з кількох мільйонів активних користувачів щомісяця. Мікросервіси є лише частиною потокового інструментального інструменту для роботи програми HashiCorp та більшої дорожньої карти інфраструктури DevOps. Але модульність та сумісність, що базується на всьому, що будується компанією, сприяла метеорному піднесенню одного з найпопулярніших стартапів програмного забезпечення в Силіконовій долині.

"Чотири роки тому, коли ми починали, ми ходимо на зустрічі і формулюємо своє бачення того, як керуватиме інфраструктурою", - сказав Дадгар. "Ми не були так, як сміються з кімнати; ми знали, що це рано. Але тепер наші інструменти, такі як Terraform, на шляху до того, щоб стати галузевими стандартами. Що ми побачимо, це ефект доміно від конкурентного тиску і, в довгостроковій перспективі наша роль буде співпрацювати з керівниками директорами та центральними організаціями, щоб зрозуміти зрушення, яке вони потребують.

- Подумайте про Тойоту ще в той день, - продовжував Дадгар. "У вас було купу автомобільних компаній, що будують продукцію, але вартість була вищою, ніж повинна бути. Toyota не винаходила, що таке машина; вони були просто більш суворими і поступовими щодо процесу, і перейшли від сміху до електростанції, змусивши інша галузь застосовує той самий набір практик, щоб залишатися конкурентоспроможними. Зараз у нас є лідери галузі, які запитують, як вони можуть отримати перевагу в конкурентній боротьбі, і їх відповідь полягає в тому, щоб перейняти практику ринку Googles і Amazons. точка, вона вразить критичну масу ".