TL;DR:
Коли ваша організація досягає певного рівня зрілості та переходить до налаштування багатоконтейнерного середовища, важливо змінити підхід до мережі. Не дивіться на це з рівня одного контейнера — розглядайте мережу глобально, через кілька контейнерів.
Спочатку спроектуйте вашу мережу з розширюваністю на майбутнє. Переконайтеся, що ваш процес надання ресурсів є гнучким, але надійним, щоб справлятися з частими змінами без ризику збоїв.
Зосередьте увагу на централізованому контролі, єдиній контрольній площині, модульній архітектурі, ретельному тестуванні та надійному управлінні змінами для ефективного масштабування мережі в хмарі.
CIDR, підмережі та секрети: чи побудована ваша хмарна мережа на племенному знанні?
• Чи досі ваша хмарна мережа налаштовується вручну?
• Чи є CIDR і підмережі непослідовними чи конфліктуючими?
• Чи ламається щось щоразу, коли ви вносите зміни в мережу?
• Чи є одна людина, яка розуміє мережу, в відпустці, що призводить до простою?
• Чи зростають ваші витрати на хмарні мережі неконтрольовано?
• Чи обмежена продуктивність через мережеві «вузькі місця»?
• Чи додається новий акаунт, регіон або мульти-хмарне/локальне підключення як нескінченний процес, що затримує час виходу на ринок?
Якщо ви відповіли «так» на будь-яке з цих запитань, ви не самотні — ця стаття для вас. Давайте розглянемо уроки, які я отримав, створюючи масштабовану платформу для підключення до хмари, щоб вирішити ці проблеми раз і назавжди.
Що таке платформа підключення до хмари?
Платформа підключення до хмари — це єдина система, яка інтегрує хмарні мережеві сервіси та проксі-технології для забезпечення безпечного підключення «будь-де до будь-де».
Що означає «будь-де до будь-де» підключення?
Коли я думаю про підключення «будь-де до будь-де», я згадую сценарії, які я неодноразово зустрічав:
- Застосунки, що спілкуються з іншими застосунками.
- Застосунки, які безпечно отримують доступ до баз даних.
- Доступ до API безпечно.
- Системи, що підключаються до інтернету або з’єднуються через мульти-регіональні та мульти-хмарні середовища.
- Інтеграція локальних мереж і мереж філій з хмарною інфраструктурою.
Платформа підключення до хмари
Три рівні платформи підключення до хмари
З мого досвіду добре спроектована платформа складається з трьох основних рівнів:
- Рівень хмарних мереж
Цей рівень обробляє основну інфраструктуру — VPN, VNets та шлюзи. Це забезпечує глобальне підключення «будь-де до будь-де» і підтримує цілісність основної інфраструктури.
- Рівень мережевих підключень застосунків
Подумайте про API шлюзи, шлюзи для входу/виходу та проксі-сервіси на стороні контейнера. Цей рівень забезпечує безпеку комунікації між застосунками та абстрагує складність, щоб розробники могли зосередитися на створенні функцій, а не на налагодженні мережевих конфігурацій.
Ефективність рівня мережевих підключень застосунків цілком залежить від рівня хмарної мережі. Якщо основна мережа не оптимізована, навіть найкраще спроектований рівень мережевих підключень застосунків матиме труднощі.
Незалежно від того, чи керують цими двома рівнями одна команда чи різні, вони повинні працювати злагоджено, щоб забезпечити ефективність.
- Рівень абстракції платформи
Це «магічна соус» для того, щоб приховати складність мережі від розробників і операторів. Він надає єдиний інтерфейс, щоб командам не доводилося глибоко занурюватися в CIDR, підмережі чи таблиці маршрутів.
Спостереження та безпека є невід'ємною частиною всіх трьох рівнів, але деталі цього ми залишимо для іншої розмови. Тут ми зосередимося на мережевих аспектах.
Основні характеристики платформи підключення до хмари
Коли я згадую платформи, які я допомагав створювати і підтримувати, ось основні можливості, які роблять їх успішними:
- Підключення «будь-де до будь-де»
Платформа повинна глибоко інтегруватися з хмарними мережами, регіонами та локальними системами.
2. Абстракція платформи
Одне з уроків, які я засвоїв, це те, що простота є критично важливою. Хороша платформа абстрагує складність мережі:
- SRE (Site Reliability Engineers), які розгортають обчислювальні потужності, сховище та інші сервіси, не повинні турбуватися про підключення.
- Команди розробників не повинні навіть думати про CIDR або підмережі. Їм просто потрібно, щоб підключення працювало.
- Єдина видимість
Спостережуваність — це необхідність. Надійна платформа надає візуалізацію на кожному рівні:
- Рівень 4: Логи потоку надають інформацію для вирішення проблем з підключенням та безпекою. Ця інформація допомагає мережевим SRE зрозуміти потік даних, пояснити витрати на мережу та вдосконалити дизайн мережі для підвищення ефективності та продуктивності.
- Рівень 7: Метрики на рівні додатків, такі як логи доступу, можуть допомогти вирішити проблеми, пов'язані з підключенням на рівні 7.
- Гнучкість та тестування
Мережі постійно змінюються — нові регіони, нові акаунти, нові середовища. Масштабована платформа повинна адаптуватися без збоїв.
Тестування є ключовим. Я особисто бачив, як погано протестовані зміни можуть призвести до катастрофічних збоїв. Надійна платформа підключення включає інструменти для перевірки конфігурацій до їх розгортання.
Частина 1: Уроки зі створення масштабованої платформи підключення до хмари — Хмарні мережі
У цій статті я занурюся в основний рівень: Хмарні мережі, поділюсь основними уроками та висновками. Для уроків щодо Мережі додатків та Рівня абстракції платформи, чекайте на Частину 2 — вона з’явиться найближчим часом!
Еволюція хмарних мереж: YellaTalk — Подорож стартапу в хмарі
Давайте розглянемо подорож уявного стартапу YellaTalk, додатка для комунікації peer-to-peer, який стикається з викликами хмарних мереж.
Як стартап, який будується на хмарі, початковий фокус зазвичай полягає на доставці функцій, а не на вдосконаленні інфраструктури. Причини можуть бути такими:
- Обмежені ресурси: Стартапи часто не мають можливості створити ідеальну хмарну інфраструктуру на старті. У них може навіть не бути виділених DevOps інженерів чи SRE, залишаючи розробників відповідальними за початкове налаштування хмари.
- Ризик надмірної інженерії: Навіть з досвідченою командою SRE, впровадження архітектури найкращої практики для зони посадки з самого початку може бути непотрібним і занадто складним.
Для тих, хто не знайомий, архітектура зони посадки — це структура акаунтів, що базується на найкращих практиках, наданих хмарними провайдерами, такими як AWS, Azure та GCP. Її зазвичай використовують великі компанії або ті, хто має суворі вимоги щодо відповідності. Однак для таких стартапів, як YellaTalk, це може бути занадто складно для впровадження на початкових етапах.
Початкове налаштування YellaTalk
Щоб розпочати, інженери YellaTalk створюють два акаунти AWS у регіоні ОАЕ: один для staging і інший для продакшн. Використовуючи Terraform, вони надають ресурси VPC CIDR, підмережі та інші ресурси, такі як обчислювальні потужності та сховище.
Масштабування через Spinouts
Успіх YellaTalk призводить до створення нового підрозділу — YellaShop, платформи електронної комерції. Щоб окремо керувати бюджетами, інженери створюють нові акаунти staging та продакшн для YellaShop.
Як тільки розробники починають розгортати сервіси для YellaShop, вони розуміють необхідність доступу до платформних сервісів, таких як ідентифікація, профілі та сповіщення, розміщених на YellaTalk. Хоча вони могли б використовувати публічні API, виникають проблеми з затримкою, оскільки трафік повинен проходити через інтернет.
Простота мережі: Peering VPC
Просте рішення було реалізовано: VPC peering між YellaTalk і YellaShop. Цей підхід усуває необхідність маршрутизації трафіку через інтернет, зменшуючи затримки.
Подальший ріст: Додавання YellaPay
YellaShop росте, і це спричиняє створення YellaPay, платформи для безпечних платежів, розміщеної у власних акаунтах AWS. Сервіси в YellaTalk та YellaShop повинні мати доступ до платіжних API без використання інтернет-трафіку.
Команда реалізує кінцеві точки VPC в YellaPay для забезпечення приватного підключення.
З ростом сервісів YellaPay, їм також необхідно мати доступ до платформних сервісів, розміщених на YellaTalk. Для цього додаються кінцеві точки VPC до акаунта YellaTalk для таких сервісів, як ідентифікація та Kafka. Аналогічно, YellaPay передає логи та метрики в системи спостереження, розміщені на YellaTalk, додаючи ще більше кінцевих точок.
Початок складності
Зі збільшенням кількості сервісів та акаунтів, управління кінцевими точками VPC та міжмережевими з'єднаннями стає все складнішим. Виникають питання:
- Яка команда управляє операціями цих кінцевих точок після їх створення?
- Як управляти підключенням, якщо YellaPay потрібно розмістити в Саудівській Аравії через вимоги до розміщення даних?
- Як забезпечити підключення до GCP або Azure для аналітики даних чи AI?
Столкнення зі стіною складності
Як Yella росте, колишня проста хмарна мережа стає вузьким місцем. Те, що почалося як просте, орієнтоване на розробників рішення, вже не може впоратися з розширенням навантаження та географічною експансією.
Важливо розпізнати симптоми "столкнення зі стіною складності" на ранній стадії і вирішити проблеми з підключенням до хмари, перш ніж вони перерастуть у серйозні. Коли складність досягне певного порогу, стає важко виправдати ризики та витрати, пов'язані з великим редизайном мережі, що може включати простої та операційні ризики.
Типові проблеми при масштабуванні хмарних мереж
Масштабування хмарної мережі — це не лише про інфраструктуру, а й про людей, процеси та неминучі проблеми, які виникають з ростом. Ось три основні категорії проблем, з якими я зіткнувся при масштабуванні хмарних мереж:
1. Фрагментовані та ручні конфігурації
• Точки-точки рішення не масштабуються: Фрагментовані мережеві налаштування, такі як кілька з'єднань VPC або розкидані кінцеві точки VPC, швидко стають вузьким місцем. Підтримка десятків (а то й сотень) таких ізольованих конфігурацій є операційно складною та нестійкою.
• Відсутність чіткого процесу для змін мережі: Без чітко визначеного процесу, ручні зміни можуть призвести до відхилень між вашими файлами стану та реальною інфраструктурою. Те саме стосується невідповідностей між акаунтами, що ускладнює вирішення проблем і масштабування.
• Невідповідні практики тегування: Якщо ви не використовуєте стандартизоване тегування для ваших мережевих ресурсів, все може вийти з-під контролю. Стартапи часто пропускають цей крок на початку, оскільки у них немає спеціалізованої мережевої команди. Але коли ви масштабуєтесь, відсутність стандартизації робить майже неможливим підтримку видимості того, які ресурси були надані і чому. Централізована видимість критично важлива, щоб уникнути цього.
2. Операції після запуску
• Часозатратні та схильні до помилок зміни: Зміна конфігурацій мережі часто стає ручним, складним і трудомістким процесом. Якщо ваша команда сильно залежить від однієї чи двох ключових осіб для цих змін, ви опинитеся в скрутному становищі, якщо вони будуть відсутні — будь то відпустка або раптова відставка.
• Ненавмисні зміни: Якщо кожен у команді Infra має доступ до управління мережевими ресурсами, такими як кінцеві точки VPC, балансувальники навантаження або DNS записи, це лише питання часу, коли ненавмисна зміна порушить щось. Без належних процесів та дозволів цей ризик зростає з масштабуванням організації.
• Відсутність централізованої видимості: Без належного тегування та централізованого моніторингу ваша команда фактично працює наосліп. Ніхто не розуміє, як виглядає основна мережа, і це майже неможливо ефективно працювати.
3. Безпека та вартість
• Обмежена видимість в патерни трафіку: Якщо у вас немає уявлення про те, як трафік проходить всередині вашої інфраструктури або між вашою інфраструктурою та інтернетом, ви відкриваєте двері для ризиків безпеки.
Цей брак видимості також ускладнює оптимізацію витрат.
- Неочікувані витрати: Без ретельного моніторингу патерни трафіку — такі як трафік виходу, використання NAT шлюзів чи між-зональні передавання даних (cross-AZ) — можуть призвести до значних витрат. Ці проблеми часто непомітно виникають, особливо коли не впроваджено стратегію обізнаності про витрати.
Чому хмарна мережа має бути гнучкою?
Давайте поговоримо про те, чому гнучкість є такою ж важливою для хмарної мережі, як і для доставки застосунків. У сучасному швидкоплинному світі бізнеси ставлять пріоритет на швидкість — запуск функцій, масштабування операцій та задоволення вимог користувачів. Але ось у чому проблема: якщо ваш мережевий рівень не такий гнучкий, як інші частини вашої технологічної стеку, він стане вузьким місцем.
Хмарна мережа повинна бути адаптивною, гнучкою та надійною, щоб підтримувати такі зміни:
1. Розвиток та розширення бізнесу
Як бізнес розвивається, мережа повинна розвиватися разом з ним:
- Міжрегіональні розгортання: Розширення в нові регіони покращує користувацький досвід та забезпечує відновлення після катастроф. Ваша мережа повинна обробляти це без збоїв.
- Мульти-хмарні стратегії: Ви можете почати з AWS, але з ростом потреб — скажімо, для AI, аналітики чи вимог до відповідності — ви можете додати Azure або GCP в мікс. Ваша мережа повинна забезпечувати з'єднання між цими хмарами без затримок.
2. Придбання та злиття
Якщо ваша компанія купує інший бізнес, вам раптом доведеться інтегрувати дві окремі мережі. Це може означати:
- Підключення хмарних середовищ.
- Вирішення проблем з перекриттям діапазонів IP-адрес.
- Перебудова частин мережі для забезпечення сумісності.
Без гнучкої мережі це може значно уповільнити процес інтеграції бізнесів.
3. Оптимізація витрат
Витрати на мережу можуть вийти з-під контролю без належного планування. Наприклад:
- Передавання даних між зонами доступності (cross-AZ).
- Перевантажене використання NAT шлюзів, кінцевих точок VPC.
Гнучка мережа дозволяє вам швидко адаптуватися та оптимізувати витрати.
4. Безпека та відповідність
Як компанії розвиваються, вимоги до безпеки та відповідності стають суворішими, і мережа повинна адаптуватися. Наприклад:
- Сегрегація середовищ: Ізоляція середовищ для відповідності стандартам безпеки чи регуляторним вимогам.
- Посилена безпека: Додавання мережевих сервісів або брандмауерів для захисту трафіку в межах вашої мережі.
- Зміни у відповідності: Закони, такі як GDPR або HIPAA, можуть вимагати розміщення даних у конкретних країнах, суворих контролів доступу або аудиту.
Рішення проблем з мережею Yella Corp
Давайте відступимо на крок і розглянемо потенційне рішення для зростаючої складності мережі Yella Corp.
Впровадження центрального мережевого акаунта з Transit Gateway
Одним із ефективних підходів є впровадження центрального мережевого акаунта та використання AWS Transit Gateway для управління мережевим трафіком на глобальному рівні.
Це створює модель мережі hub-and-spoke (хаб і спиці), де центральний акаунт виступає в ролі хаба і з'єднується з кількома спицями VPC.
Модель хабу і спиць
Переваги цього підходу включають:
• Спрощене управління трафіком: Центральний хаб обробляє як вхідний (трафік, що входить у мережу), так і вихідний (трафік, що виходить з мережі), замість того, щоб керувати цими потоками в кожній спиці мережі.
• Централізована безпека: Центральний брандмауер в мережевому акаунті може перевіряти трафік з півночі на південь (ззовні всередину) та з заходу на схід (внутрішній на внутрішній), забезпечуючи єдиний шар безпеки.
• Масштабованість: Transit Gateway може розширювати з'єднання між VPC, регіонами та навіть різними хмарними постачальниками (для гібридних або мульти-хмарних налаштувань).
Для більш детальної інформації AWS надає чудове пояснення моделі hub-and-spoke у своїй документації Well-Architected Framework.
Більша картина: думайте глобально
Я хочу підкреслити, що моя мета не полягає в тому, щоб запропонувати Transit Gateway як універсальне рішення. Замість цього йдеться про зміну підходу, щоб бачити мережу глобально, а не управляти нею окремо для кожного тенанта або акаунта.
5 Уроків зі створення масштабованої хмарної мережі
На основі мого досвіду роботи з великими підприємствами, такими як Careem та SAP, ось п'ять ключових уроків для побудови масштабованої хмарної мережі:
Урок 1: Центральний контроль для управління мережею
Ресурси мережі повинні бути захищені від непередбачених змін. Невелика помилка на рівні мережі може мати великий вплив, тому централізований контроль є важливим.
- Розмежування обов'язків:
- Тримайте розгортання мережі окремо від розгортання інфраструктури.
- Це запобігає непередбаченим змінам під час регулярних розгортань.
- Контроль доступу на основі ролей (RBAC):
- Створіть окремі ролі для адміністраторів мережі та операторів контрольної площини з обмеженими, чітко визначеними правами доступу.
- Обмежте прямі зміни ресурсів мережі через портали UI або консоль керування.
- Призначте спеціальну команду Networking SRE для управління критичними компонентами, такими як VPC, підмережі, таблиці маршрутів та шлюзи.
- Обмежте доступ для інших команд, щоб уникнути випадкових змін.
- Організаційні політики:
- Встановіть політики на рівні організації для блокування руйнівних дій, таких як видалення критичних ресурсів, таких як VPC або Transit Gateway.
- Для чутливих дій вимагайте підвищення привілеїв з кількома рівнями схвалення.
- Завжди тестуйте та документуйте зміни в непроизводствених середовищах перед тим, як застосовувати їх у продукції.
Урок 2: Централізуйте хмарну підключеність з єдиною контрольованою площиною
Завжди зберігайте глобальний огляд вашої мережі, впроваджуючи централізовану контрольовану площину для конфігурації компонентів площини даних, таких як Transit Gateway.
- Опції єдиної контрольованої площини:
- Простим рішенням може бути використання потоку GitHub з Terraform для розгортання ресурсів.
- Також можна використовувати Pulumi для керування конфігураціями або інструменти, такі як Crossplane в екосистемі Kubernetes для обробки компонентів площини даних, таких як Transit Gateway.
-
Альтернативно, можна створити свою власну контрольовану площину, адаптовану до потреб вашої організації.
Гнучкі опції площини даних: -
Почніть з простого, наприклад, з Transit Gateway або VPN Gateway.
-
У міру масштабування ви можете адаптувати і комбінувати різні технології для задоволення змінюваних потреб у з'єднаності.
Ось референсна реалізація контрольованої площини, побудованої за допомогою модульних Terraform модулів: Реалізація контрольованої площини.
Проста контрольована площина
Контрольована площина, що охоплює кілька хмар
Урок 3: Модульна та складова архітектура
У розробці додатків перехід від монолітних до модульних архітектур дозволяє пришвидшити інновації та зменшити складність. Той самий принцип застосовується і до мереж: тісно пов'язані мережеві компоненти створюють вузькі місця та збільшують ризики. Модульна, складова архітектура дозволяє тестувати, вносити зміни та ізолювати проблеми без впливу на ширшу мережеву інфраструктуру.
Модульні сценарії для розгортання інфраструктури
Уявіть, що розгортання інфраструктури — це API. Напишіть модульні API для виконання конкретних завдань. Наприклад:
def create_vpc(req: VPC):
# Логіка для створення VPC
def create_tgw_attachment(req: TGWAttachment):
# Логіка для прикріплення Transit Gateway
def create_zone_attachment(req):
# Логіка для прикріплення зони
З цим підходом ви можете тестувати ці скрипти незалежно, забезпечуючи їх надійність перед інтеграцією. Використовуйте референсні шаблони модульного дизайну, такі як створення Terraform модуля.
Переваги цього підходу включають можливість незалежного тестування менших модулів і їх комбінації для створення більших компонентів, що забезпечує безшовне тестування взаємодії.
Модульний дизайн мережі
Монолітні проекти, такі як єдина велика таблиця маршрутів для всього трафіку або один VPC для всіх додатків і середовищ, ускладнюють тестування конфігурацій, ізоляцію змін чи обмеження проблем.
Замість цього застосовуйте модульний підхід:
• Розділіть монолітні акаунти або VPC: Створіть окремі акаунти або VPC для спільних послуг, моніторингу та платформ даних, щоб зменшити складність, стандартизувати конфігурації та підвищити ефективність маршрутизації.
- Ізолюйте мережеві компоненти: Керуйте підмережами, шлюзами та таблицями маршрутів як незалежними, тестованими компонентами для внесення змін без впливу на всю мережу.
Урок 4: Тестування змін у вашій мережі
Так само, як і в розробці додатків, тестування змін інфраструктури є критичним для забезпечення надійності оновлень мережі. Без належного тестування навіть незначні зміни можуть призвести до зупинки або проблем із продуктивністю. Ось як підійти до цього:
- Юніт-тестування
- Почніть з ваших скриптів розгортання мережі.
- Перевірте вхідні параметри, щоб виявити некоректні конфігурації на ранньому етапі.
- Перевірте правильне оброблення помилок у сценаріях невдач.
- Переконайтеся, що окремі функції (наприклад, створення VPC або прикріплення Transit Gateway) працюють належним чином.
Ви можете впровадити політики для планів IaC, щоб забезпечити валідацію та обмеження.
Наприклад, я використовував Conftest для блокування видалення ресурсів. Більше деталей можна знайти тут: Валідація плану.
2. Інтеграційне тестування
- Перевірте кінцеву з’єднаність між мережами.
- Тестуйте, як модулі розгортання мережі взаємодіють один з одним (наприклад, VPC до TGW, Transit Gateway до таблиць маршрутів).
- Розгортайте зміни у тестовому середовищі, щоб виявити проблеми до продукції.
У концептуальній демонстрації Traffic Platform я використав Terratest для тестування Terraform модулів.
Для отримання додаткової інформації ви можете звернутися до документації тут: Тестування Terraform модулів.
3. Тести досяжності та синтетичні тести
- Перейдіть до динамічної валідації, виходячи за межі статичного тестування.
- Автоматично генеруйте тестові випадки на основі запланованого дизайну мережі.
- Тестуйте як успішні, так і неуспішні сценарії для критичних шляхів.
- Запускайте безперервні синтетичні перевірки для моніторингу досяжності та продуктивності.
Ось референсна реалізація для автоматичного генерування тестів досяжності:
Валідація за допомогою Reachability Analyzer.
Ви можете запускати аналіз після кожного розгортання, щоб переконатися, що нічого не зламалося.
Урок 5: Процес управління змінами
Управління змінами в мережах хмарних обчислень вимагає структурованого підходу для забезпечення надійності та мінімізації перебоїв. Ось як ефективно з цим справлятися:
1. Аналіз впливу
Перед внесенням змін оцініть їх потенційний вплив на трафік, продуктивність системи та залежні компоненти. Задокументуйте ризики та створіть чіткий план для як розгортання, так і відкату змін.
2. Попереднє тестування та валідація змін
Завжди тестуйте зміни в середовищі, яке не є продуктивним.
- Перевірте процеси розгортання та відкату, щоб забезпечити плавне відновлення, якщо це необхідно.
- Використовуйте інструменти, як terraform plan або еквівалентні, щоб попередньо переглянути та перевірити зміни перед розгортанням.
3. Вікна для змін
Плануйте зміни на періоди з низьким трафіком або поза робочими годинами, щоб зменшити вплив на користувачів. Це мінімізує ймовірність перебоїв під час пікових періодів.
4. Протокол «Break-the-Glass»
Для змін високого ризику, таких як видалення прикріплення до Transit Gateway або зміна таблиць маршрутів, реалізуйте протокол ескалації привілеїв для забезпечення належного нагляду та підзвітності.
- Вимагайте погодження на рівні керівництва для ескалації привілеїв.
- Ретельно перевіряйте та документуйте всі дії для підтримки підзвітності та можливості відстеження.
У надзвичайних ситуаціях, коли необхідно внести термінові зміни в критичні ресурси, застосовуйте протокол «Break-the-Glass». Цей протокол дозволяє контролювати, тимчасовий доступ до засобів управління для вирішення важливих інцидентів. Переконайтеся, що процес добре задокументований і використовується лише як останній засіб.
Основні висновки
Коли ваша організація досягне певного рівня зрілості та переходить на налаштування з кількома акаунтами, важливо змінити підхід до мережі. Не дивіться на це з точки зору окремого орендаря — розглядайте мережу глобально через кілька орендарів.
Ваша архітектура мережі неминуче буде еволюціонувати, тому важливо з самого початку проектувати з урахуванням можливості розширення.
Оскільки дизайн вашої хмарної мережі буде еволюціонувати, ви будете впроваджувати численні зміни конфігурацій мережі. Ваш процес надання мережі повинен бути гнучким, щоб йти в ногу з іншою інфраструктурою та додатками. Водночас він повинен надавати пріоритет надійності, оскільки відмови мережі часто мають набагато більший вплив, ніж типові відмови додатків.
Прийняття централізованого контролю, об'єднаної площини управління, модульної та складової архітектури, суворих практик тестування та надійного процесу управління змінами дозволяє ефективно масштабувати хмарні мережі з обома як гнучкістю, так і надійністю.
Перекладено з: Lessons from Building a Scalable Cloud Connectivity Platform