Игривая методика для надежных результатов
Это короткий пост о принципах, которые я применяю ко всему, что я создаю — будь то интерфейс класса, веб-API, шаблон Инфраструктура как код (IaC) или архитектурный дизайн.
Я не планировал этого; Я думал о принципах создания хороших шаблонов IaC, но быстро понял, что это общие принципы, которыми я постоянно пользуюсь. Я составил список, взял первые буквы и воспользовался WordFinder, чтобы подобрать слово. Меня позабавило, насколько хорошим было это слово:
Скромный — не желающий говорить о своих способностях или достижениях и говорить, что вы в чем-то хороши, даже если это так, — привык выказывать одобрение.
— Словарь современного английского языка Longman
Принципы таковы:
- Значимые значения по умолчанию
- Ортогональность
- Документация
- Расширяемость
- Безопасность
- Тестируемость
Итак, вот еще одна мнемоническая аббревиатура. Всегда есть место для нового.
Принципы
Начнем с рассмотрения принципов. Просто для вашего развлечения я приведу примеры из области IaC, чтобы проиллюстрировать, что они довольно общие.
Значимые значения по умолчанию
Простые вещи должны быть простыми, сложные вещи должны быть возможными.
Алан Кей
Значимые значения по умолчанию помогут вам свести к минимуму трение, необходимое для использования вашего артефакта. Как и в случае с дизайном API, рассмотрим метод sort в Python:
Обратите внимание, что по умолчанию sort возвращает элементы в порядке возрастания. Вы можете запросить порядок убывания, указав параметр, отличный от значения по умолчанию, как показано ниже:
Точно так же и в мире IaC — представьте, что у вас есть большой стек CloudFormation с десятками параметров. Ради аргумента, Jaeger Quick Start имеет более 50. Тем не менее, все параметры имеют значения по умолчанию, и вам не нужно их менять, если вы хотите попробовать Quick Start. Этот беспроблемный опыт укрепляет доверие и побуждает к дальнейшим экспериментам.
Ортогональность
Ортогональность — важный принцип проектирования программного обеспечения. Как определяет это Википедия, ортогональная операция изменяет только одну вещь, не затрагивая другие. Традиционный пример — чистые функции — чистые функции не имеют побочных эффектов, а значит, проще составить несколько функций и рассуждать о них.
Пример IaC может быть немного сложнее понять. Допустим, у нас есть большое развертывание инфраструктуры, которое предоставляет следующие возможности:
- DNS: Отключено / Частная зона хостинга / Общедоступная зона хостинга
- Серверная часть хранилища: In-Memory Storage/Elasticsearch
- Экспорт метрик: отключен/включен
Это ортогональные варианты — вы можете смешивать и сочетать их по своему усмотрению, и вы всегда будете получать правильную комбинацию:
- Нет конфигурации DNS + Хранилище в оперативной памяти + Отключенные метрики
- Общедоступный DNS + Elasticsearch + Включенные метрики
Подход к проектированию IaC с учетом ортогональности обычно приводит к решениям, которые легче тестировать и поддерживать, поскольку все функции независимы.
Документация
Документация — одна из самых забытых областей разработки программного обеспечения. Хорошая документация очень сложна, и (почти) никто не любит ее писать. Непонятно, что сложнее — создать сложный код или написать к нему содержательную документацию.
Чтобы было ясно, под документацией я не подразумеваю такие комментарии:
Тривиальные вещи не нуждаются в объяснении. Это больше о более сложных фрагментах, которые вы не можете легко понять, не зная некоторой справочной информации:
Знание того, что вам нужно документировать, приходит с практикой, как и все остальное. Вам нужно написать (и прочитать!) много документации, чтобы понять, что такое хорошее. Если вы сомневаетесь, объясните свой код воображаемому другу (или утке) и подумайте о вещах, которые могут вызвать их удивление (хотя не уверен, что у уток есть брови).
В области IaC документация также играет центральную роль. Сколько раз вы видели шаблоны с недокументированными параметрами, поэтому вам приходилось угадывать правильные значения, которые вы можете использовать? Сколько раз вы угадали неправильно?
Было бы лучше, если бы параметры были сгруппированы логически, с понятными описаниями и ссылками на веб-страницы, где клиенты могут получить дополнительную информацию?
Вспомните, когда вы в последний раз жаловались на медленное мобильное приложение, неинтуитивный пользовательский интерфейс или дерьмовое сообщение об ошибке. Именно так ваши товарищи по команде могут чувствовать себя, работая с вашим шаблоном IaC.
Сделать лучше; Они заслужили это!
Расширяемость
Независимо от того, разрабатываете ли вы класс, который будут использовать ваши товарищи по команде, или строите крупномасштабную архитектуру микросервисов, вам, вероятно, нужно подумать о расширяемости. Вероятно, вы не предусмотрели все возможные сценарии использования, поэтому создание открытого решения принесет вам пользу в долгосрочной перспективе.
Открыть здесь для O в SOLID — еще одна популярная мнемоника, которую вы, возможно, захотите запомнить для своего следующего интервью. Было бы забавно (для обеих сторон), если бы вы также поговорили о принципах СКРОМНОСТИ со своим интервьюером.
Пример из области IaC: представьте, что вы строите инфраструктуру для продукта и развертываете ресурсы, которые будут использовать другие команды — VPC, группы безопасности, роли IAM и т. д. Позже другая команда хочет развернуть микросервис в VPC. Им, вероятно, потребуется идентификатор VPC, список подсетей и, возможно, группа безопасности для подключения к их службе. Каким будет процесс для команды, чтобы получить эту информацию?
Они могут открыть консоль AWS, получить идентификаторы/ARN и жестко закодировать их в файлах конфигурации сервиса. Если у вас несколько сред (Dev/Test/Prod) — попросите их повторить процесс для каждой среды (и запустить).
Конечно, мы можем сделать лучше. Что, если в рамках вашей реализации IaC мы предоставим набор параметров SSM со всеми необходимыми идентификаторами? Затем сервисная группа может импортировать необходимые им биты, используя четко определенные имена параметров. Относитесь к этим параметрам как к вашему «общедоступному интерфейсу» IaC — после публикации вы должны поддерживать их и обеспечивать обратную совместимость.
Безопасность
Безопасность — универсальный принцип. Если не знаете, с чего начать, начните с безопасности.
А если серьезно, вам нужно подумать о безопасности, независимо от того, что вы строите. От статического анализа кода до инструментов безопасности во время выполнения контейнеров, сетевых сканеров, анализа журналов, обнаружения аномалий и инструментов безопасности IaC — спектр огромен. Thoughtworks Technology Radar — хорошее место для начала.
Тестируемость
Я думаю, что за эти годы мы добились очень хорошего прогресса — даже легендарный вопрос StackOverflow Стоит ли модульное тестирование закрыт для комментариев.
Ради последнего принципа MODEST постулируем следующее: тестирование — это хорошо, а автоматизированное тестирование — еще лучше.
Проектирование с учетом тестируемости означает, что ваш артефакт может быть эффективно протестирован либо во время разработки, либо вашими клиентами во время интеграции. Подумайте о нагрузочных/интеграционных тестах, которые клиенты могут захотеть провести для разработанного вами класса/API/IAC/архитектуры.
Продолжая наши примеры IaC, вы можете многое сделать, чтобы ваш код IaC можно было тестировать. Начните с модульных тестов для вашего поставщика IaC и рассмотрите фактические тесты развертывания для различных комбинаций параметров и целевых регионов. Это особенно ценно, если вам нужно поддерживать нестандартные регионы, такие как Китай или GovCloud. Вот пример тестового файла TaskCat (из репозитория quickstart-jaeger):
Что бы вы ни делали, есть способ проверить это.
Заключение
Быть скромным не всегда является хорошей жизненной стратегией, но проектирование и создание СКРОМНЫХ архитектур — это то, о чем вы должны подумать. Извиняюсь за эту озорную чушь. Вскоре я вернусь с более серьезными мыслями о распределенной трассировке и OpenTelemetry.
