Озираючись приблизно на п’ять років назад в минуле, можна помітити, наскільки сильно з тих пір змінилося ставлення до архітектури мікросервісів. Спочатку вони були надзвичайно популярні. Після успіху Netflix, Amazon і Gilt.com розробники вирішили, що де-факто розробка мікросервісів не відрізняється від розробки додатків. Тепер же всі зрозуміли, що мікросервіси вдають із себе новий архітектурний стиль, який ефективний для вирішення певних завдань, має свої плюси і мінуси.
Щоб зрозуміти, що таке мікросервіси і в яких випадках їх слід використовувати, можна звернутися до Джеймі Буельта (Jaime Buelta), автора книги «Hands-On Docker for Microservices with Python». Він розповів про переваги цієї архітектури, а також поділився рекомендаціями для розробників, які планують перейти на неї з монолітів.
Переваги та ризики
Традиційний монолітний додаток об’єднує всі свої можливості в єдиному пов’язаному модулі. У разі мікросервісів все навпаки. Додаток ділиться на більш дрібні автономні служби, які можна незалежно розгортати, оновлювати і замінювати. Кожен мікросервіс створюється для однієї бізнес-цілі і може взаємодіяти з іншими мікросервісами за допомогою простих механізмів.
Буельта пояснює: «Мікросервісна архітектура – це спосіб структурування системи, при якій кілька незалежних сервісів спілкуються один з одним певним чином (зазвичай це відбувається за допомогою web-сервісів RESTful). Ключова особливість полягає в тому, що кожен мікросервіс здатний оновлюватися і розвиватися незалежно від інших».
Архітектура мікросервісів визначає не тільки те, як ви створюєте свій додаток, але і те, як організована ваша команда.
«Одна незалежна команда може повністю відповідати за мікросервіс. Це дозволяє організаціям рости, не зіштовхуючи розробників один з одним», – пояснює Буельта.
Одне з основних переваг мікросервісів полягає в тому, що вони дозволяють впроваджувати нововведення без особливого впливу на систему в цілому. За допомогою мікросервісів ви можете виконувати горизонтальне масштабування, мати чіткі межі модулів, використовувати різноманітні технології і вести паралельну розробку.
На питання про ризики, пов’язані з мікросервісами, Буельта відповів: «Головна складність при впровадженні архітектури (особливо при переході з моноліту) полягає в створенні дизайну, в якому сервіси дійсно будуть незалежними. Якщо цього не вдасться домогтися, то міжсервісні зв’язки стануть складніше, що призведе до додаткових витрат. Мікросервісам потрібні професіонали, які сформують напрямки розвитку в довгостроковій перспективі. Я рекомендую організаціям, які хочуть перейти на таку архітектуру, призначити когось відповідальним за «загальну картину». На мікросервіси потрібно дивитися ширше», – вважає Джеймі.
Перехід від моноліту до мікросервісів
Мартін Фаулер, відомий автор і консультант з програмного забезпечення, радить дотримуватися принципу «спочатку – моноліт». Це пов’язано з тим, що використовувати мікросервісную архітектуру з самого початку розробки ризиковано, оскільки в більшості випадків вона підходить тільки для складних систем і великих команд розробників.
«Основний критерій, який повинен спонукати вас до переходу на нову архітектуру – це чисельність вашої команди. Невеликим групам не варто цього робити. У подібних умовах розробники і так розуміють все, що відбувається з додатком, і завжди можуть задати уточнююче питання колезі. Моноліт відмінно працює в цих ситуаціях, і тому практично кожна система починається з нього», – вважає Джеймі. Це підтверджує «правило двох піц» Amazon, згідно з яким команду, відповідальну за один мікросервіс, можна прогодувати двома піцами – інакше вона занадто велика.
«У міру зростання компанії і збільшення команд розробників може знадобитися найкраща координація. Програмісти починають часто заважати один одному. Зрозуміти мету конкретного фрагменту коду стає складніше. У таких випадках перехід на мікросервіси має сенс – це допоможе розділити обов’язки і внести ясність в загальну картину системи. Кожна команда має зберігати свої власні цілі і працювати в основному самостійно, видаючи зрозумілий зовнішній інтерфейс. Однак, щоб такий перехід мав сенс, розробників повинно бути багато», – додає Буельта.
Рекомендації з переходу на мікросервіси
Відповідаючи на питання про те, які практичні рекомендації можуть використовувати розробники при переході на мікросервіси, Буельта заявив: «Ключем до успішної архітектури мікросервісів є те, що кожен сервіс має бути максимально незалежним».
Виникає питання: «Як ви можете зробити сервіси незалежними?». Кращий спосіб виявити взаємозалежність системи – подумати про нові можливості: «Якщо ви хочете додати нову функцію, чи можна буде її реалізувати, змінивши лише один сервіс? Які види функцій зажадають координації декількох мікросервісів? Вони будуть використовуватися часто або рідко? Неможливо створити ідеальний дизайн, але, принаймні, з його допомогою можна приймати правильні і обгрунтовані рішення», – пояснює Буельта.
Джеймі радить переходити на архітектуру правильно, щоб потім все не переробляти. «Після завершення переходу змінити кордони мікросервісів буде важче. Варто приділити більше часу на початкову фазу проекту», – додає він.
Перехід з одного шаблону проектування на інший – це серйозний крок. Ми запитали, з якими проблемами Джеймі і його команда стикалися під час міграції на мікросервіси, на що він відповів:
«На ділі основні труднощі пов’язані з людьми. Ці проблеми, як правило, недооцінюють, але перехід на мікросервіси фактично змінює спосіб роботи розробників. Завдання не з легких!». Він додає: «Я особисто стикався з подібними проблемами. Наприклад, мені доводилося навчати і давати поради розробникам. Особливо важливо пояснювати, чому необхідні ті чи інші зміни. Це допомагає людям зрозуміти причини впровадження всіх нововведень, які можуть припасти їм не до душі.
При переході від монолітної архітектури багато складнощів може виникнути при розгортанні додатку, який раніше випускався у вигляді єдиного модуля. Воно вимагає більш ретельного аналізу для забезпечення зворотної сумісності і мінімізації ризиків. Справитися з цим завданням часом дуже нелегко».
Причини вибору Docker, Kubernetes і Python в якості технологічного стеку
Ми запитали Буельту, які технології він вважає за краще для впровадження мікросервісів. Відносно вибору мови відповідь виявилася простою: «Python для мене – найкращий варіант. Це моя улюблена мова програмування! Ця мова добре підходить для мікросервісів. Її зручно читати і легко застосовувати. Крім того, Python має широкий функціонал для веб-розробки і динамічну екосистему сторонніх модулів для будь-яких потреб. До цих потреб належить підключення до інших систем, наприклад, до баз даних, зовнішніх API і т.д.».
Docker часто рекламується як один з найважливіших інструментів для мікросервісів. Буельта пояснив, чому:
«Docker дозволяє інкапсулювати і копіювати додаток в зручних стандартизованих пакетах. Це зменшує невизначеність і складність середовища. Також це значно спрощує перехід від розробки до виробництва додатків. Додатково до всього, зменшується час використання обладнання. Ви можете розмістити кілька контейнерів в різних середовищах (навіть в різних операційних системах) в одній фізичній коробці або віртуальній машині».
Про Kubernetes:
«Kubernetes дозволяє розгортати кілька контейнерів Docker, які працюють скоординовано. Це змушує розробників мислити кластерізовано, пам’ятаючи про виробниче середовище. Також це дозволяє визначати кластер за допомогою коду, щоб нові розгортання або зміни конфігурації визначалися в файлах. Все це робить можливими методи на кшталт GitOps, при цьому зберігаючи повну конфігурацію в системі управління версіями. Кожна зміна вноситься певним і оборотним чином, оскільки вона представляє з себе регулярне git-злиття. Завдяки цьому можна дуже легко відновлювати або дублювати інфраструктуру».
«Доведеться витратити час, щоб навчитися Docker і Kubernetes, але це того варто. Обидва інструменти дуже потужні. До того ж, вони заохочують вас працювати таким чином, щоб уникнути проблем при виробництві», – вважає Буельта.
Багатомовні мікросервіси
При розробці мікросервісів можна використовувати різноманітні технології, оскільки за кожен з них в ідеалі відповідає незалежна команда. Буельта поділився своєю думкою про багатомовні мікросервіси: «Багатомовні мікросервіси – це здорово! Це одна з основних переваг архітектури. Типовий приклад багатомовного мікросервісу – перенесення застарілого коду, написаного на одній мові, на нову. Мікросервіс може замінити собою будь-який інший, який надає той же зовнішній інтерфейс. При цьому його код буде зовсім іншим. Наприклад, я переходив зі старих додатків PHP, замінюючи їх аналогами, написаними на Python». Джеймі додав: «Робота з двома або більше платформами одночасно допоможе краще розібратися в них і розуміти, в яких випадках їх краще використовувати».
Хоча можливість використовувати багатомовні мікросервіси – це велика перевага архітектури, вона також може збільшити операційні витрати. Буельта радить: «Треба знати міру. Немає сенсу кожен раз використовувати новий інструмент і позбавляти команди можливості ділитися знаннями один з одним. Конкретні цифри можуть залежати від розміру компанії, але, як правило, немає сенсу використовувати більше двох або трьох різних мов без серйозної на те причини. Не треба роздувати стек технологій – тоді розробники зможуть ділитися знаннями і почнуть використовувати наявні інструменти найбільш ефективно».
Про автора
Джеймі Буельта (Jaime Buelta) – професійний програміст і Python-розробник, який за свою багаторічну кар’єру познайомився з безліччю різних технологій. Він розробляв програмне забезпечення для різних областей і галузей, включаючи аерокосмічну, мережеву та комунікаційну, а також промислові системи SCADA, онлайн-сервіси для відеоігор і фінансові сервіси.
У складі різних компаній він мав справу з такими функціональними областями, як маркетинг, менеджмент, продажі та геймдизайн. Джеймі є затятим прихильником автоматизації і хоче, щоб всю важку роботу виконували комп’ютери, дозволивши людям зосередитися на більш важливи речах. В даний час він живе в Дубліні і регулярно виступає на конференціях PyCon в Ірландії.
Джерело: habr.com
