Як пояснити мікросервіси нетехнічним зацікавленим сторонам
Практичні аналогії та англійські фрази для пояснення архітектури мікросервісів учасникам бізнесу, менеджерам продуктів і керівникам.
Архітектура мікросервісів має явні технічні переваги, але пояснення того, чому бізнес повинен турбуватися, або чому міграція до мікросервісів коштує часу і грошей, вимагає мови, яка з’єднує технічні концепції з результатами бізнесу. Цей посібник надає вам аналогії, фрази і стратегії спілкування, щоб вести цю розмову з впевненістю.
Основні проблеми комунікації
Коли ви кажете « мікросервіси », людина, яка не має технічних знань, може почути: « щось складне, що коштуватиме більше і триватиме довше ». Ваша робота полягає у тому, щоб переформулювати розмову навколо:
- Швидкість доставки
- Зменшення ризику та стійкість
- Автономія команди
- Гнучкість бізнесу
Аналогії, що працюють
** Аналогия кухни ресторана: **
- “Уявіть собі монолітну програму, на зразок ресторану, де кожен шеф- кухар працює на одній відкритій кухні, де всі користуються одним і тим же обладнанням. Коли один шеф-кухар створює проблему, скажімо, пожежу в гриль-станції, вся кухня відключається. Мікросервіси схожі на окремі кухні для кожної станції: печиво, гриль і підготовка. Якщо в одного з них є проблема, інші продовжують бігти.»*
** Аналогія з контейнером: **
- “В минулому вантажні судна перевозили товари в трейлах. Якщо щось зламаєш або зрушиш, це може пошкодити все інше. Транспортні контейнери змінили це - кожен блок ізольований і самодостатній. Мікросервіси роблять те ж саме для програмного забезпечення: кожна служба міститься і незалежна. ”*
** Аналогия универмага: **
- “Моноліт - це як універсальний магазин, де всім керує одна централізована система: касовий апарат, запаси, програма лояльності. Якщо система оплати не працює, то цілий магазин може зупинитися. Мікросервіси схожі на те, що кожен відділ має свою систему оплати — якщо в одного відділу виникають проблеми, інші продовжують працювати»
Пояснення бізнесових переваг
Швидша доставка:
- “З мікросервісами декілька команд можуть випускати зміни до своїх служб незалежно. Нам не потрібно координувати один великий випуск по всій системі. Це означає, що функції досягають клієнтів швидше.”*
Сила:
- “Якщо одна служба зазнає невдачі — скажімо, рушій рекомендацій — решта програми продовжує працювати. Користувачі все ще можуть переглядати і купувати; вони просто не побачать персональних рекомендацій. Порівняйте це з нашою поточною архітектурою, де помилка в одній частині може встановити всю систему»
** Масштабування: **
- “Ми можемо масштабувати частини системи, які перебувають під найбільшим навантаженням, не масштабуючи все. Якщо пошук знаходиться під тиском, ми масштабуємо тільки службу пошуку, а не всю програму. Це значно більш економічно ефективно.»*
** Автономія команди: **
- “Кожна команда має свою власну службу і може робити технологічний вибір, відповідний їх проблемі. Це зменшує координацію витрат і дозволяє командам рухатися швидше в межах власного домену. “*
Пояснення витрат і компромісів чесно
“Я хочу быть честным о компромиссах. Мікросервіси додають операційну складність — нам потрібні інструменти для керування декількома сервісами, моніторингу їх і обробки помилок через межі сервісів. Це інвестиція, яка виплачує дивіденди в масштабі.»
“Сама по собі міграція не є безкоштовною. Ми оцінили, що це займе приблизно [час] і потребує [ресурсів]. Перевагою є те, що після міграції наші команди можуть розгортатися незалежно і ми значно зменшуємо ризик повного відключення системи. ”
- “Для системи нашого поточного розміру, деякі з цих переваг є теоретичними. Найсильнішим аргументом для цієї зміни є вузьке місце, яке ми вдаряємо в поточній архітектурі, яка конкретно сповільнює нашу доставку на [спеціфічний вплив].” *
Відповідає на запитання
“Чому ми не можемо просто зберегти існуючу систему?”
- “Ми можемо, в короткостроковій перспективі. Ризик полягає в тому, що поточна архітектура все більше обмежує нашу швидкість доставки - додавання функцій вимагає торкання великої, складної спільної кодової бази, а розгортання є повільним і ризикованим. Питання в тому, коли це вузьке місце коштує більше, ніж інвестиції в міграцію. ”*
“Як ти управляєш такими рухомими частинами?”
*“Це саме правильний запит. Відповідь полягає в тому, що це вимагає інструментів: оркестрування контейнерів, розподіленого ведення журналів і моніторингу послуг. Вони існують і доросли. Але це законна операційна вартість, яку ми повинні планувати». *
** “Що станеться, якщо одна служба не працюватиме?” **
“Це одна з переваг. Ми розробляємо для невдачі з самого початку — кожна служба грациозно справляється з недоступністю інших. Система погіршується в контрольований спосіб, а не повністю провалюється.”
Основні терміни для визначення для нетехнічної аудиторії
| Technical term | Plain English explanation |
|---|---|
| microservice | A small, independently deployable piece of software that does one specific thing |
| monolith | A single, large application where all components are tightly connected |
| API | The way services communicate with each other — like a menu that lists what each service can do |
| container | A self-contained package that includes a service and everything it needs to run |
| orchestration | Automated management of many containers — starting, stopping, and monitoring them |
| service mesh | Infrastructure that manages communication between services |
Вміння пояснити технічну архітектуру нетехнічним зацікавленим сторонам без втрати точності є одним з найцінніших навичок, які може розвинути старший інженер або архітектор. Чиста аналогія, чесний компроміс і постійний зв’язок з результатами бізнесу завоює довіру в організації.
Введення в лексику: лексика для вивчення мови
Пояснення мікросервісів не просто описує архітектурний шаблон; це про передачу його * переваг * таким чином, що резонує з людьми, які не говорять технічним жаргоном. Багато розробників, особливо ті, чия перша мова не є англійською, знаходять цей виклик посилений. Це не просто переклад слів, а розуміння нюансів фразування і створення спільного словника. Давайте розглянемо деякі конкретні області, де ретельне формулювання може зробити всі відмінності.
Однією з ключових областей є використання таких термінів, як « відокремлення ». Хоча саму концепцію можна зрозуміти, спосіб її представлення часто викликає плутанину. Замість того, щоб сказати «Ми відокремлюємо послуги», що звучить абстрактно, спробуйте щось більш конкретне: «Розділяючи функціональність обробки замовлень і доставки на окремі послуги, ми *зменшуємо вплив *, якщо в одній частині системи є проблема. Якщо є проблема з доставкою - можливо, затримка доставки - це не буде автоматично припиняти обробку замовлень.” Фраза “зменшити вплив” є потужним, легко перетравлюваним терміном для нетехнічної аудиторії. Аналогічно, уникайте фраз на кшталт «можлива послідовність». Це майже гарантовано буде втрачено для будь-кого, хто не знайомий з розподіленими системами. Замість цього, сформулюйте його так: « Зміни, внесені в одну службу, з часом будуть відображені у всіх службах — це може зайняти декілька хвилин або годин, але дані зрештою будуть синхронізовані ». Підсвічування * часу * часто є більш релевантним, ніж абстрактні поняття, такі як моделі послідовності.
Іншим частим каменем спотикання є обговорення «API-шлюзів». Це звучить неймовірно технічно. Кращий підхід буде таким: “Уявіть API-шлюз як центральну точку входу для всіх запитів до нашої програми. Це як рецепціонер - він направляє запит на правильну службу, забезпечуючи ефективність і безпеку. Це спрощує речі для користувача; їм не потрібно знати, яка конкретна служба обробляє їх запит. ” Фокусування на * функції * шлюзу - направлення і спрощення - набагато більш доступне, ніж опис його технічної реалізації.
Нарешті, будьте уважні до того, як ви говорите про «масштабування». Сказати «Ми масштабуємо послуги незалежно» може звучати надто складно. Замість цього: «Оскільки кожна служба працює окремо, ми можемо налаштувати ресурси, такі як обчислювальна потужність або пам’ять, щоб задовольнити попит на * ту конкретну частину * програми. Якщо більше людей замовляють онлайн під час продажу, ми можемо автоматично збільшити потужність обробки замовлень без впливу на інші частини системи. ” Використання «потужності» і пов’язання її з «попитом» часто легше зрозуміти, ніж технічну термінологію масштабування. Пам’ятайте, чітке спілкування будує довіру; точне формулювання сприяє розумінню.