Я люблю читать технические книги, но мне всегда сложно решить, читать книгу или нет. А когда я читаю техническую книгу, мне трудно удержать в памяти многое из того, что я прочитал. Итак, я экспериментирую с написанием резюме технических книг - как способ помочь другим решить, хотят ли они их читать, и как способ заставить себя понять / удержать в себе концепции.

Моим первым кратким обзором будет книга Кифа Морриса Инфраструктура как код.

Это отличная «окончательная» книга о концепции «Инфраструктура как код» (IaC). IaC - это набор принципов и шаблонов для управления инфраструктурой в облаке. Эта книга больше сфокусирована на общих принципах и идеях, чем на инструментах, но в ней есть несколько наглядных примеров.

Книга разделена на три раздела: «Основы», «Паттерны» и «Практики». Я потрачу больше времени на подведение итогов Части I и, в частности, первой главы, поскольку именно здесь рассматриваются высокоуровневые принципы, чтобы дать вам обзор, но если вам это интересно, вам действительно стоит купить книгу! < br />
В части I (Основы) Моррис сосредотачивается на основных принципах, лежащих в основе IaC. Можно увидеть, что IaC выросла из движения DevOps и перехода к облаку и X-as-a-Service. По сути, аргумент состоит в том, что барьер для предоставления новой инфраструктуры исчез так быстро, но принципы, лежащие в основе управления инфраструктурой, не соблюдаются. IaC - это подход к решению этих проблем путем подхода к автоматизации инфраструктуры с использованием практик разработки программного обеспечения. Другими словами, с инфраструктурой следует обращаться как с программным обеспечением и данными, применяя такие принципы, как контроль версий, автоматическое тестирование, а также непрерывную интеграцию и доставку.

Предпосылка состоит в том, что современные инструменты могут рассматривать инфраструктуру как программное обеспечение и данные.

Глава 1 начинается с изучения некоторых проблем, которые могут возникнуть у организаций, не применяющих надлежащие принципы. Некоторые из этих проблем включают в себя такие вещи, как разрастание серверов (большое количество серверов, которые не обслуживаются в хорошем состоянии), дрейф конфигурации (неизвестные несоответствия между серверами из-за ручных исправлений и настроек) и серверы Snowflake («специальные» серверы, которые не могут легко воспроизводится). Последствиями являются опасения по поводу хрупкой инфраструктуры и автоматизации, которые подпитывают друг друга в цикле (хрупкая инфраструктура приводит к боязни автоматизации, что приводит к более хрупкой инфраструктуре).

Кроме того, Моррис представляет основные принципы, лежащие в основе Инфраструктура как код. Во-первых, системы должны быть легко воспроизводимыми. Во-вторых, системы должны быть одноразовыми («серверы должны быть как скот, а не домашние животные»). Далее, они должны быть согласованными (в частности, системы, предоставляющие аналогичные услуги, должны быть почти идентичными). Кроме того, любые действия, выполняемые с инфраструктурой, должны быть простыми, дешевыми и повторяемыми, чтобы соответствовать изменяющимся проектам.

Должна быть возможность легко и надежно восстановить любой элемент инфраструктуры.

В последнем разделе главы представлены высокоуровневые практики для достижения этих принципов. Во-первых, IaC выступает за использование файлов определений для определения инфраструктуры и конфигурации - отсюда и произошло название «Инфраструктура как код». Многие другие практики могут быть включены только посредством декларативного использования таких файлов.

Краеугольным камнем практики инфраструктуры как кода является использование файлов определений.

Определение системы как инфраструктуры как кода и построение ее с помощью инструментов не улучшает качество ... То, что делает инфраструктура как код, смещает акцент качества на определения и системы инструментов. Очень важно структурировать автоматизацию и управлять ею так, чтобы она обладала достоинствами качественного кода: простой для понимания, простой в изменении, с быстрой обратной связью по проблемам. Если определения качества и инструменты, используемые для создания и изменения инфраструктуры, высоки, то качество, надежность и стабильность самой инфраструктуры должны быть высокими.

Глава 11 описывает стратегии тестирования, а Глава 12 объединяет оба этих опыта в «конвейер управления изменениями» или «непрерывное обеспечение». Глава 13 обсуждает «рабочие процессы», что по сути означает попытку все автоматизировать и избегать ручных или специальных изменений. Здесь также обсуждаются советы по организации кодовых баз. Глава 14 посвящена достижению «непрерывности», что, по сути, является универсальным термином, который в книге используется для обозначения надежности (например, без простоев изменений), доступности / согласованности данных, восстановления и безопасности. Наконец, в главе 15 обсуждаются организационные методы реализации принципов, изложенных в книге, например, как перейти от старой архитектуры, как измерить эффективность и как лучше всего структурировать команды и обязанности.

Стоит отметить, что Часть III (кроме глав 14 и 15) показалась мне слишком «идеалогической». Обсуждения в оставшейся части книги представляли принципы или шаблоны с компромиссами, но какие из них работают как практики для той или иной конкретной команды, могут отличаться. И хотя Моррис намеренно пытался быть независимым от инструментов, это также означает, что главы не имеют такой практической ценности. Они по-прежнему очень информативны, я просто чувствую, что если бы я применял остальную часть книги, я мог бы использовать практики из последнего раздела с недоверием.

В противном случае это было бы неплохо. отличная книга, независимо от того, создаете ли вы, эксплуатируете или используете инфраструктуру в облаке. Поскольку он также исходит из ThoughtWorks, многие идеи здесь согласуются с другими идеями и книгами ThoughtWorks по архитектуре, такими как «Эволюционная архитектура» и «Создание микросервисов».

Краткое содержание книги Кифа Морриса Инфраструктура как код