З UnSplash

Оригінал статті доступний за посиланням https://cep.dev/posts/every-infrastructure-decision-i-endorse-or-regret-after-4-years-running-infrastructure-at-a-startup/.

Будь ласка, поширюйте оригінал.

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

AWS

Вибір AWS замість Google Cloud

🟩 Підтримую

З самого початку ми використовували як GCP, так і AWS. Тоді я не знав, хто є "менеджером облікового запису" для Google Cloud, в той час як у мене були регулярні зустрічі з нашим менеджером облікових записів AWS. Здається, що Google працює з роботами та автоматизацією, тоді як Amazon працює з фокусом на клієнта. Ця підтримка допомагала нам при оцінці нових сервісів AWS. Крім підтримки, AWS добре справився зі стабільністю та мінімізацією змін API, які порушують зворотню сумісність.

Був час, коли Google Cloud був вибором для кластерів Kubernetes, особливо коли була невизначеність стосовно того, чи буде AWS інвестувати у EKS над ECS. Однак зараз, з усіма додатковими інтеграціями Kubernetes щодо сервісів AWS (external-dns, external-secrets та ін.), це вже не є серйозною проблемою.

EKS

🟩 Підтримую

Якщо ви не ведете борги (і ваш час безкоштовний), немає причини запускати власний контрольний плейс замість використання EKS. Основна перевага використання альтернативи в AWS, як от ECS, полягає у глибокій інтеграції з сервісами AWS.

Щасливо, Kubernetes в багатьох відношеннях догнало: наприклад, використання external-dns для інтеграції з Route53.

EKS керовані додатки

🟧 Скарга

Ми почали з керованих додатків EKS, оскільки я вважав, що це "правильний" спосіб використовувати EKS. Нажаль, ми завжди опинялись у ситуації, де нам потрібно було налаштувати саму установку. Можливо, запити про CPU, теги зображення або деякий configmap. З тих пір ми перейшли до використання helm charts там, де були додатки, і робота йде значно краще з просуваннями, які відповідають нашим існуючим GitOps pipelines.

RDS

🟩Рекомендація

Дані - це найкритичніша частина вашої інфраструктури. Ви втрачаєте вашу мережу: це перерва в роботі. Ви втрачаєте ваші дані: це подія, що може завершити компанію. Вартість використання RDS (або будь-якої керованої бази даних) виправдована.

Redis ElastiCache

🟩Рекомендація

Redis працював дуже добре як кеш та загальний продукт для використання. Він швидкий, API простий та добре документований, та реалізація вже пройшла випробування в бою. На відміну від інших варіантів кешування, як Memcached, Redis має багато функцій, які роблять його корисним для більш ніж просто кешування. Це великий швейцарський ножик для "роблення швидких даних".

Частина мене сумнівається у стані підтримки Redis хмарними провайдерами, але я вважаю, що він настільки широко використовується користувачами AWS, що AWS продовжить добре його підтримувати.

ECR

🟩Рекомендація

Спочатку ми господарювали на quay.io. Це був хаотичний бардак з проблемами стабільності. З моменту переходу до ECR речі стали набагато стабільніше. Глибокі інтеграції дозволів з EKS nodes або серверами розробки також були великим плюсом.

AWS VPN

🟩Рекомендація

Існують альтернативи VPN нульового довіри від компаній, таких як CloudFlare.

Я впевнений, що ці продукти добре працюють, але VPN настільки простий у налаштуванні і зрозумінні ("простота вибору найкраща" - моя мантра). Ми використовуємо Okta для управління доступом до VPN, і це був чудовий досвід.

Преміум підтримка AWS

🟧 Скарження

Дуже дорого: майже (якщо не більше) ніж кошт іншого інженера. Я думаю, якби у нас було дуже мало власних знань AWS, то воно вийшло б варте своїх грошей.

Фабрика облікових записів Control Tower для Terraform

🟩 Рекомендація

Перед інтеграцією AFT використання Control Tower було стресовим, в основному через складнощі автоматизації. Після того, як ми інтегрували AFT у наш стек, створення облікових записів працювало добре. Ще одне, що робить AFT простішим, - це стандартизація тегів для наших облікових записів. Наприклад, у наших продукційних облікових записів є тег, через який можемо приймати рішення про peer-підключення. Теги працюють краще, ніж організації для нас, оскільки рішення "які властивості описують цей обліковий запис" не завжди є структурою дерева.

Процес

Автоматизація процесу післявипробувальної обробки за допомогою Slack бота

🟩 Рекомендація

Усі завжди зайняті. Це може виглядати так, що ви стаєте "поганим хлопцем", нагадуючи людям заповнити післявипробувальну обробку. Зробити робота "поганим хлопцем" було чудово. Це спрощує процес, натискуючи людей дотримуватися процедур СЕВ та післявипробувальної обробки.

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

Використання шаблонів інцидентів в PagerDuty

🟩 Рекомендація

Чому вигадувати щось заново? PagerDuty публікує шаблон того, що робити під час інциденту. Ми трохи його налаштували, і тут на допомогу приходить гнучкість Notion, але це був чудовий стартовий пункт.

Перегляд заявок на пейджер дьюті регулярно

🟩Підтримка

Система оповіщень для компанії працює наступним чином:

1. Початково взагалі немає жодних оповіщень. Нам потрібні оповіщення.
2. Є оповіщення, але їх занадто багато, тому ми їх ігноруємо.
3. Ми визначили пріоритети для оповіщень. Тепер лише критичні збуджують нас.
4. Ми ігноруємо не критичні оповіщення.

У нас є двоступінчасте налаштування оповіщень: критичні та не критичні. Критичні оповіщення будять людей. Не критичні оповіщення очікуються, що будуть отримані для on-call асинхронно (по електронній пошті). Проблема полягає в тому, що не критичні оповіщення часто ігноруються. Щоб вирішити це, ми регулярно (зазвичай раз на 2 тижні) проводимо зустрічі з перегляду PagerDuty, на яких ми проходимо всі наші оповіщення. Щодо критичних оповіщень ми обговорюємо, чи воно має залишатися критичним. Потім ми переглядаємо не критичні оповіщення (зазвичай вибираючи декілька на кожній зустрічі) і обговорюємо, що ми можемо зробити для їх вирішення (зазвичай налаштовуємо поріг або створюємо деяку автоматизацію).

Щомісячні зустрічі для відстеження витрат

🟩Підтримка

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

Наприклад, з AWS ми групуємо елементи за тегами та розділяємо їх за облікові записи. Ці дві виміри, спільно зі загальною назвою служби (EC2, RDS і т. д.), дають нам хорошу уяву про те, де знаходяться основні джерела витрат. Деякі дії, які ми робимо з цими даними, - докладніше досліджуємо використання миттєвих екземплярів або які облікові записи найбільше сприяють витратам на мережу. Але не зупиняйтеся лише на AWS: перейдіть до всіх основних витратних статей, які має ваша компанія.

Обробка післямортем у Datadog або PagerDuty

🟥Регрет

Кожен має робити післямортеми.

Both DataDog and PagerDuty have integrations to manage writing post-mortems and we tried each. Unfortunately, they both make it hard to customize the post-mortem process. Given how powerful wiki-ish tools like Notion are, I think it’s better to use a tool like that to manage post-mortems.

Недостатнє використання Функції як Сервісу(FaaS)

🟥Скарга

На жаль, для виконання роботи з графічними процесами немає чудових варіантів FaaS, тому ми ніколи не могли повністю перейти на FaaS. Однак багато процесів з використанням процесора можуть бути FaaS (наприклад, lambda). Найбільш важливий аргумент, який висувають люди, - це вартість. Вони кажуть щось на кшталт: "Цей тип екземпляра EC2, що працює цілодобово на повну потужність, коштує набагато менше, ніж виконання Lambda". Це правда, але це також хибне порівняння. Ніхто не працює з сервісом на 100% використання потужності ЦП і далі живе своїм життям. Завжди існує якийсь механізм, який каже: "Ніколи не досягайте 100%. При 70% збільшуйте". І завжди невідомо, коли потрібно зменшити масштаб, замість цього це евристика типу "Якщо ми були на рівні 10% протягом 10 хвилин, зменште до рівня нижче". Потім люди припускають існування обчислювальних ресурсів при відсутності їх на ринку.

Ще одною схованою вигодою Lambda є те, що дуже легко відслідковувати витрати з високою точністю. При розгортанні сервісів в Kubernetes вартість може бути прихована за іншими об'єктами на вузлі або іншими сервісами, які працюють на цьому вузлі.

GitOps

🟩Підтримка

GitOps досить добре масштабується, і ми використовуємо його для багатьох частин нашої інфраструктури: сервісів, terraform, конфігурації, щоб згадати лише деякі. Основний недолік полягає в тому, що робочі процеси, спрямовані на конвеєр, надають чітке уявлення про "ось цей бокс, що означає ваш коміт, і ось стрілки, що йдуть від цього бокса до кінця конвеєра". З GitOps нам довелося інвестувати в інструменти, щоб допомогти людям відповісти на питання "Я зробив коміт: чому він ще не розгорнутий".

Навіть у такому випадку, гнучкість GitOps була великою перемогою, і я настійно рекомендую впровадити її в вашій компанії.

Перевага ефективності команди над зовнішніми вимогами

🟩Підтримка

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

Декілька додатків, які діляться базою даних

🟥Шкода

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

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

Найбільші проблеми з використанням спільної бази даних:

• В базі даних накопичується зайва інформація, і невідомо, чи можна її видалити.
• Якщо виникають проблеми з продуктивністю, інфраструктурі (без глибоких знань про продукт) доводиться вирішувати проблеми бази даних і визначати, на кого перенаправляти.
• Користувачі бази даних можуть впроваджувати поганий код, що робить погані речі з базою даних. Ці погані речі можуть викликати сигнал тривоги в PagerDuty для команди інфраструктури (оскільки вони володіють базою даних). Неприємно прокидати одну команду через проблему іншої команди. У випадку баз даних, які володіються додатками, команда додатків - перша, хто реагує.

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

SaaS

Не прийняти платформу ідентифікації відразу

🟥Скарги

На початку я залишився з Google Workspace, використовуючи його для створення груп для співробітників як спосіб призначення дозволів. Просто виявилося, що воно не дуже гнучке. У своїй перспективі, я бажав, щоб ми взяли Okta набагато раніше. Це дуже добре працює, має інтеграції з майже усім, і вирішує багато аспектів відповідності/безпеки. Просто вкладіть рано в платформу ідентифікації і приймайте лише постачальників SaaS, які інтегруються з нею.

Notion

🟩Підтримка

Кожній компанії потрібно місце для розміщення документації. Notion був чудовим вибором і працював набагато простіше, ніж те, що я використовував раніше (вікі, Google Docs, Confluence та інше). Їх концепція баз даних для організації сторінок також дозволила мені створювати досить складні структури сторінок.

Slack

🟩Підтримка

Дякуємо, що мені більше не потрібно використовувати HipChat. Slack - чудовий інструмент для комунікації за умовчанням, але щоб зменшити стрес і шум, я рекомендую:

• Використовувати нитки для упорядкування комунікації
• Повідомлення про очікування, що люди можуть не відповісти швидко на повідомлення
• Надихати на використання публічних каналів та відступати від приватних повідомлень.

Перехід з JIRA на linear

🟩Підтримка

JIRA такий наростений, що я маю страх, що використання його у компанії зі штучним інтелектом робить його повністю самосвідомим. Коли я користуюся Linear, я часто думаю "Цікаво, чи можу я зробити X", і потім я спробую, і мені вдається!

Не використання Terraform Cloud

🟩 Без скарг

На початку я спробував перенести наш Terraform на Terraform Cloud. Найбільшим недоліком було те, що я не міг виправдати витрати. З тих пір я перейшов на Atlantis, і він працював достатньо добре. Де Atlantis дещо відстає, ми написали трохи автоматизації в нашій CI/CD практиці, щоб компенсувати це.

Дії GitHub

com/ua/actions) для CI / CD

🟧Підтримка

Ми, як більшість компаній, зберігаємо наш код на GitHub. Починаючи з використання CircleCI, ми перейшли на Github actions для CI / CD. Ринок доступних дій для вашого робочого процесу великий, а синтаксис легко читається. Основним недоліком дій Github є обмежена підтримка для самостійних робочих процесів. Ми використовуємо EKS та actions-runner-controller для наших самостійних ранерів, що розміщені в EKS, але інтеграція часто працює нестабільно (але нічого, з чим ми не можемо впоратися). Сподіваюсь, що GitHub ставить серйозно самостійне хостування на Kubernetes у майбутньому.

Datadog

🟥Скарга

Datadog - чудовий продукт, але він дорогий. Більше, ніж просто дорогий, мене турбує те, що їхня модель вартості особливо погана для кластерів Kubernetes та для компаній зі штучним інтелектом. Кластери Kubernetes найбільш ефективні за вартістю, коли ви можливо швидко вмикаєте та вимикаєте багато вузлів, а також використовуєте диспетчерії. Модель ціноутворення Datadog базується на кількості екземплярів, які ви маєте, і це означає, що навіть якщо у нас в один момент часу не більше 10 екземплярів, якщо ми вмикаємо та вимикаємо 20 екземплярів за цей час, ми платимо за 20 екземплярів. Так само компанії з штучним інтелектом, на відміну від CPU-вузлів, які можуть мати десятки служб, виконуючися одночасно, розподіляючи вартість Datadog між багатьма випадками використання, вузол з GPU ймовірно, матиме лише один сервіс, і це робить вартість Datadog на один сервіс набагато вищою.

Pagerduty

🟩 Підтримка

Pagerduty - чудовий продукт і добре ціновою. Ми ніколи не шкодували, що обрали його.

Програмне забезпечення

Міграція схеми за допомогою Diff

🟧Підтримка

Керування схемою складне незалежно від того, як ви це робите, головним чином через те, наскільки це страшно. Дані важливі, і погана міграція схеми може призвести до видалення даних.

Страшні але ефективні шляхи вирішення складної проблеми

З усіх лякаючих способів вирішення цієї складної проблеми, я дуже задоволений ідеєю завантаження всієї схеми в git, а потім використанням інструменту для генерації SQL запитів для синхронізації бази даних зі схемою.

Ubuntu для серверів розробки

🟩Рекомендую

Спочатку я намагався зробити сервери розробки на тій самій базовій операційній системі, на якій працювали наші вузли Kubernetes, думаючи, що це наблизить середовище розробки до продакшну. Однак, на мою думку, зусилля вартістю не виправдані. Я задоволений тим, що ми залишаємося при Ubuntu для серверів розробки. Це добре підтримувана операційна система і містить більшість пакунків, які нам потрібні.

AppSmith

🟩Рекомендую

Ми часто повинні автоматизувати деякі процеси для внутрішнього інженера: перезапустити/підняти/діагностувати/тощо. Нам досить легко створювати API для вирішення цих проблем, проте дещо надоїдливо налагоджувати встановлення конкретного інженера, включаючи CLI/os/залежності, тощо. Можливість створювати простий користувацький інтерфейс для інженерів для взаємодії з нашими скриптами є дуже корисною.

Ми самі господарюємо наш AppSmith. Він працює ... достатньо добре. Звичайно, є речі, які ми б змінили, але наразі цього досить для "безкоштовного" рівня обслуговування. Спочатку я досліджував глибшу інтеграцію з retool, але я не міг виправдати ціну за те, що тоді було лише кілька інтеграцій.

helm

🟩Рекомендую

Helm v2 отримав погану репутацію (з доброї причини), але helm v3 працює ... досить добре. Є проблеми з розгортанням CRDs та навчання розробників, чому їх helm-шаблон не розгортається належним чином. Оглядово helm працює достатньо добре як спосіб упаковування та розгортання версіонованих об'єктів Kubernetes, та мова шаблонізації Go складна для налагодження, але потужна.

helm-шаблони в ECR(oci)

🟩Рекомендую

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

Ми пізніше перейшли на збереження графіків helm в OCI і не мали жодних проблем з цією настройкою.

bazel

🟧Не впевнений

Справедливо визнати, що багато розумних людей віддають перевагу bazel, так що впевнений, що це не погана вибір.

При розгортанні служб Go, bazel особисто мені здається зайвим. Я вважаю, що Bazel - це великий вибір, якщо ваша попередня компанія використовувала bazel, і ви відчуваєте ностальгію. В іншому випадку у нас є система збірки, в яку можуть глибоко погрузитися лише кілька інженерів, порівняно з GitHub Actions, де, здається, кожен знає, як зацікавитися.

Не почати використання відкритого телеметрії рано

🟥Пошкодження

Ми почали надсилати метрики безпосередньо в DataDog, використовуючи API DataDog. Це значно ускладнило процес їх видалення.

Open telemetry був не такий вже стабільний 4 роки тому, але він значно покращився. Я вважаю, що телеметрія метрик ще трохи не досить зріла, але трасування - велика річ. Я рекомендую використовувати його з самого початку для будь-якої компанії.

Вибір renovatebot над dependabot

🟩Підтримка

Я щиро бажаю, щоб ми раніше подумали про "підтримку вашої залежності в актуальному стані". Коли ви занадто довго це відкладаєте, ви отримуєте такі застарілі версії, процес оновлення яких є довгим і невід'ємно помилковим. Renovatebot добре працював з можливістю налаштування під ваші потреби. Найбільша, і досить серйозна, недоліка в тому, що у нього ДУЖЕ складно налаштувати та відлагоджувати. Можливо, це кращий варіант серед усіх поганих.

Kubernetes

🟩Підтримка

Вам потрібна якась система для розміщення ваших служб, що працюють довго. Kubernetes - популярний вибір, і він працював добре для нас. Спільнота Kubernetes вдало інтегрувала сервіси AWS (наприклад, балансувальники навантаження, DNS тощо) в екосистему Kubernetes. Головний недолік будь-якої гнучкої системи полягає в тому, що є багато способів її використання, та в будь-якій системі з багатьма способами використання є багато способів використання помилково.

будь-яка система з багатьма способами використання має багато способів використання неправильно

• Джек Ліндамуд

Покупка власних IP-адрес

🟩Рекомендую

Якщо ви працюєте з зовнішніми партнерами, вам часто доведеться публікувати білий список ваших IP-адрес для них. Нещасливим образом, в майбутньому ви можете розробити більше систем, які потребують власних IP-адрес. Покупка власного блоку IP-адрес - відмінний спосіб уникнути цього, надавши зовнішньому партнеру більший блок CIDR для білого списку.

Вибір Flux для GitOps в Kubernetes

🟩Без сумнівів

На початковому етапі вибору GitOps для Kubernetes довелося вибрати між ArgoCD і Flux: я обрав Flux (v1 на той момент). Це працювало дуже добре. Зараз ми використовуємо Flux 2. Єдиний недолік полягає в тому, що нам довелося розробити власні інструменти, щоб допомогти людям зрозуміти стан їх розгорток.

Я чув багато позитивних відгуків про ArgoCD, тому я впевнений, що якщо ви вибрали його, ви також у безпеці.

Karpenter для керування вузлами

🟩Рекомендую

Якщо ви використовуєте EKS (і не повністю на Fargate), вам слід використовувати Karpenter. Це на 100% повний зупин. Ми використовували інші автошкалери, включаючи стандартний автошкалер Kubernetes та SpotInst. Серед усіх них Karpenter був найбільш надійним і найбільш ефективним з точки зору вартості.

Використання SealedSecrets для керування секретами в Kubernetes

🟥Пошкодження

Моїм початковим принципом було перенести керування секретами до чогось у стилі GitOps. Двома головними недоліками використання sealed-secrets були:

• Для менше кваліфікованих розробників було складніше створювати/оновлювати секрети
• Ми втратили всі існуючі автоматизації, які є у AWS щодо ротації секретів (наприклад)

Використання ExternalSecrets для керування секретами в Kubernetes

🟩 Рекомендую

ExternalSecrets дуже добре працює для синхронізації секретів AWS -> Kubernetes.

Процес досить простий для розробників зрозуміти і дозволяє нам використовувати Terraform як спосіб легко створювати/оновлювати секрети всередині AWS, а також надавати користувачам інтерфейс користувача для створення/оновлення секретів.

Використання ExternalDNS для управління DNS

🟩Рекомендуємо

ExternalDNS - відмінний продукт. Він синхронізує наші DNS-записи Kubernetes -> Route53 і протягом останніх 4 років майже не викликав проблем.

Використання cert-manager для управління SSL-сертифікатами

🟩Рекомендуємо

Дуже легко налаштовується і працює без проблем. Дуже рекомендується використовувати для створення ваших сертифікатів Let’s Encrypt для Kubernetes. Єдиний недолік - іноді у нас є клієнти з ДАВНІМИ (проблеми з SaaS, виправдано?) стеками технологій, які не довіряють Let’s Encrypt, і вам доведеться отримати платний сертифікат для них.

Bottlerocket для EKS

🟥Шкодуємо

Наш кластер EKS раніше працював на Bottlerocket. Основним недоліком було те, що ми часто зіткнулися з мережевими проблемами CSI і відлагодження образів Bottlerocket було набагато важче, ніж відлагодження стандартних образів EKS AMI. Використання оптимізованих версій EKS (https://docs.aws.amazon.com/eks/latest/userguide/eks-optimized-ami.html) для наших вузлів не завдало нам проблем, і ми все ще маємо можливість відлагоджувати вузол самостійно, коли виникають дивні мережеві проблеми.

Вибір Terraform над Cloudformation

🟩 Рекомендуємо

Використання Інфраструктури як коду - обов'язково для будь-якої компанії. Будучи в AWS, дві основні вибори - Cloudformation і Terraform. Я використовував обидва і не шкодую, що залишилася при Terraform. Це було легко розширити для інших постачальників SaaS (наприклад, Pagerduty), синтаксис легше читати, ніж у CloudFormation, і не був перешкодою або сповільненням для нас.

Не використовувати більше кодові підходи розв'язання проблем (Pulumi, [CDK](https://aws.amazon.

markdown

Немає скарг

Поки Terraform та CloudFormation є файлами даних (HCL та YAML/JSON), які описують вашу інфраструктуру, рішення, такі як Pulumi або CDK, дозволяють вам писати код, який робить те ж саме. Звичайно, код потужний, але я знайшов корисність обмежувальної природи HCL Terraform у зменшенні складності. Не те, щоб було неможливо писати складний Terraform: просто стає більш очевидно, коли це відбувається.

Деякі з цих рішень, такі як Pulumi, були винайдені багато років тому, коли в Terraform бракувало багатьох функцій, які ми можемо використовувати для зменшення складності. Новіші версії Terraform інтегрували багато функцій, які ми можемо використати для зменшення складності. Замість цього ми використовуємо підходи, які генерують основні скелети нашого коду Terraform для частин, які ми хочемо забезпечити абстрагування.

Не використовування мережевої сітки (Service Mesh) (істіо/линкерд тощо) (Event Listener)

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

Nginx як балансувальник навантаження для входу в EKS

Нгінкс є старим, стабільним і пройшов випробування в боях.

Homebrew для сценаріїв компанії

Вашій компанії, швидше за все, знадобиться спосіб розповсюдження сценаріїв та виконуваних файлів для ваших інженерів. Homebrew працював досить добре як спосіб розповсюдження сценаріїв та виконуваних файлів як для користувачів linux, так і для Mac.

Go для сервісів

Go був легким для нових інженерів для оволодіння та загалом є чудовим вибором. Для сервісів, які не використовують GPU та в основному обмежені мережевим ЧЕКОМ, Go повинна бути вашим типовим вибором мови.

Перекладено з: (Almost) Every infrastructure decision I endorse or regret after 4 years running infrastructure at a startup