Як обговорювати рішення Cloud Architecture англійською мовою

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

Ключовий словник

** Запис рішення щодо архітектури (ADR) ** — короткий документ, який містить важливе рішення щодо архітектури, його контекст, розглянуті варіанти і обґрунтування зробленого вибору.

• “Ми пишемо ADR для кожного головного рішення інфраструктури - це означає, що нові інженери можуть зрозуміти, чому ми обрали Kafka над SQS, не маючи необхідності реконструювати обґрунтування з пам’яті.” *

** Комбінація** — прийняття негативного наслідку для того, щоб отримати позитивний; основна концепція у кожному архітектурному рішенні. “Ключовим компромісом тут є між простотою операцій та горизонтальною масштабованістю — ми не можемо повністю оптимізувати для обох.”

** Обмеження ** — умова, яка обмежує наявні параметри проектування, наприклад, бюджет, вимоги до відповідності або набір навичок команди. “Жорстким обмеженням цього дизайну є наша вимога до SOC 2 Тип II, що виключає декілька сторонніх служб.”

** Оборотність ** — ступінь, до якого рішення щодо архітектури можна скасувати або змінити пізніше без значних витрат.

• “Це рішення має високу оборотність — ми можемо змінити постачальника об’ єктів з мінімальними змінами коду. Вибір бази даних набагато важче повернути назад.”*

** Радіус вибуху ** — обсяг систем і користувачів, на яких впливає відмова певного компонента. “Відокремивши платіжну службу в її власну VPC, ми зменшили радіус потенційного порушення.”

** Заблокованість виробником ** - ступінь, в якій вибір технології ускладнює або коштує перехід на альтернативного виробника пізніше. “Використання керованого Kubernetes зменшує залежність від постачальника в порівнянні з власною безсерверною платформою, але при цьому збільшує операційні витрати.”

** Послідовність можливих результатів** — модель послідовності, за якої система гарантує, що всі вузли з часом відображатимуть ті ж самі дані, але не обов’ язково негайно. “Ця архітектура залежить від можливої послідовності між регіонами — нам потрібно підтвердити, що команда продукту може терпіти кілька секунд затримки.”

** Функція придатності ** — метрика або тест, який вимірює, наскільки добре архітектура відповідає певному атрибуту якості протягом часу. “Ми визначили функцію придатності для затримки: час відповіді 99-го процентилю повинен залишатися нижче 200 мс у всіх регіонах.”

Використання компромісів

Використовуйте ці структури для чіткого представлення компромісів у оглядах архітектури.

• «Варіант A дає нам нижчу затримку, але за ціною більшої операційної складності»
• «Якщо ми виберемо управляні послуги тут, ми отримаємо швидкість на ринок, але приймемо певний ступінь заблокування постачальника»
• «Перший компроміс між цими двома підходами є послідовність проти доступності — ми повинні погодитися, який бізнес пріоритетний»
• «Це рішення оптимізує для швидкості запису; швидкість читання буде прийнятною, але не оптимальною»
• “Нет идеального варианта здесь. Питання в тому, з якими компромісами ми можемо жити, враховуючи наші поточні обмеження»

Обговорення обмежень

• «Ми маємо жорстке обмеження: всі дані повинні залишатися під юрисдикцією ЄС, що виключає декілька регіонів AWS»
• «Наша команда має сильний досвід в PostgreSQL, тому перехід на NoSQL рішення створить прогалини в навичках, що має реальні витрати на впровадження»
• “Бюджет - це обмеження. Повністю управляний варіант коштує втричі більше — нам потрібно це обґрунтувати з конкретною бізнес-вигодою»
• Команда безпеки має обмеження: немає незашифрованих даних в транзиті між службами, навіть в межах VPC

Реверсивна мова

• «Я б класифікував це як одностороннє рішення — як тільки ми мігруємо базу даних, повернення займе місяці і значні інженерні зусилля»
• «Це двосторонні двері: ми можемо повернути їх в рамках спринту, якщо підхід не працює»
• «Перед тим, як взяти на себе зобов’язання щодо цієї архітектури, давайте запитаємо: якщо ми помиляємося щодо цього припущення через 18 місяців, наскільки дорого буде змінити курс?»
• «Я рекомендую нам уникати прийняття необоротні рішення, поки ми не маємо більше даних з пілотного епізоду»

Виробництво і продаж АЗС

• «Контекст для цього рішення полягає в тому, що наш моноліт переживає масштабування вузьких місць під час пікового трафіку»
• «Ми оцінили три варіанти: вертикальний масштабування, горизонтальний шардинг, і вилучення вузького місця в окрему службу.»
• «Ми відкинули варіант B, тому що він вимагає переписування бази даних, що займе шість місяців — час до значення занадто низький»
• «Рішення: ми витягнемо службу пошуку як незалежну мікросервіс, за внутрішнім API-шлюзом.»
• «Наслідки: ми отримуємо незалежну розгорнутість і масштабованість для пошуку. Ми приймаємо збільшення мережевих витрат і потребу в розподільному відстеженні»

Професійні поради

1. Отдели что от чего. Любой может описать, что ты решил. Цінність АДР полягає в тому, щоб пояснити чому — контекст, альтернативи і обґрунтування.
2. ** Явно вкажіть припущення. ** Кожне рішення щодо архітектури базується на припущеннях. Зазначте їх: «Це припускає, що трафік не перевищить 10 000 запитів на секунду в наступні 12 місяців»
3. ** Коли це можливо, оцінюйте компроміси. ** «Вищий рівень вартості» не є чітким. «30% вище щомісячна вартість інфраструктури — приблизно 4000 фунтів на місяць» є корисним.
4. ** Відрізняти принципи від рішень. ** Принцип архітектури є постійним правилом (« ми віддаємо перевагу керованим службам над самостійно розміщеними»). Рішення застосовує цей принцип до конкретного контексту.

Практичні вправи

1. Ви обираєте між налаштуванням бази даних з активними- активними регіонами і налаштуванням бази даних з одним регіоном з регіоном відновлення після аварії. Напишіть 5- 6 речень, в яких буде представлено компроміси, використовуючи відповідний словник.
2. Новий інженер запитує, чому команда обрала потокове передання подій замість прямих викликів API між службами. Напишіть розділ «Рішення» АДР (4-5 речень), що містить обґрунтування.
3. Зацікавлена сторона намагається отримати конкретну технологію, яка створює значну залежність від постачальника. Напиши 3-4 речення, в яких визнай переваги, але при цьому вкажи на ризик заблокування в професійному, неконфронтационном стилі.

Національна мова: мова мовлення — мова мовлення

Ядро ефективного обговорення рішень про архітектуру хмар - як описано в цьому пості - обертається навколо ясності і співпраці. Однак, навіть якщо ви розумієте концепції за такими термінами, як «trade-off» або «обмеження», їх чітке вираження англійською мовою може бути значною перешкодою, особливо для тих, хто розвиває свій професійний словник. Це не просто використовувати правильні слова; це про передачу ваших міркувань з впевненістю і точністю, демонструючи, що ви розглядали кілька перспектив. Розглянемо деякі конкретні області, де нюансована мова є ключовою, зосередившись на тому, як носії мови, які не є рідними для себе, можуть побудувати міцніший фундамент для цих дискусій.

Одна з найчастіших проблем виникає під час перегляду коду. Уявіть, що ви отримали коментар на зразок: « Ця реалізація здається неефективною ». Хоча це технічно вірно, але в ньому немає контексту і не пояснюється, * чому * його вважають неефективним. Більш конструктивним формулюванням було б: “Чи можемо ми дослідити оптимізацію цього запиту з індексом? Поточний рівень продуктивності впливає на часи відповіді, і додавання індексу може значно поліпшити їх — давайте перевіримо зміни. » Зауважте, що у цьому розділі наведено певну термінологію (« запит », « індекс », « часи відповіді », « еталон ») і запропоновано рішення. Використання фраз на кшталт «вплинуть», а не просто сказати щось «здається поганим» піднімає розмову за межі суб’єктивних почуттів і до вимірюваних результатів. Аналогічно, замість того, щоб сказати: «Це не масштабується», розгляньте: «Враховуючи наш очікуваний ріст користувачів протягом наступного року, ця архітектура може не відповідати нашим вимогам масштабованості без подальших модифікацій; ми повинні обговорити потенційні рішення, такі як шардинг або інша технологія бази даних»

Слабкі розмови часто користуються подібним рівнем деталізації. Швидкого повідомлення на зразок « Потрібно розгорнути зміни » недостатньо. Ефективнішим підходом буде: « Розгортання нових оновлень мікросервісів на стадії розробки — будь ласка, перегляньте PR [посилання на PR] і повідомте мене, якщо ви виявите якісь регресії, перш ніж ми перейдемо до виробництва ». Це чітко описує * що * потрібно зробити, * де * це відбувається (стадія розробки), надає точку відліку (посилання на PR) і запрошує негайний зворотній зв’ язок. Використання фраз на кшталт « регресія » є стандартним технічним словником, який демонструє ваше розуміння процесу розробки. Крім того, оформлення змін як «оновлення», а не просто «зміни» підступно повідомляє більш свідомо і ретельно обдуманий підхід.

Нарешті, при створенні проектів описів PR або архітектурних записів рішень (ADR), точність є найважливішою. Замість того, щоб широко стверджувати: «Ми переходимо до AWS», вам потрібно сформулювати * чому *. «Ми мігруємо нашу інфраструктуру застосунків до AWS, щоб використовувати їхні управляні послуги - зокрема EC2 для обчислень і S3 для зберігання - зменшуючи операційні витрати і покращуючи масштабованість, дотримуючись наших бюджетних обмежень». Пам’ ятайте, ваша мета полягає у тому, щоб надати чітку картину того, * чому * було прийнято це рішення і як воно відповідає більш широким організаційним цілям.