Документирование архитектуры: введение

[Color]

Что-то вроде обо всем, а по факту ни о чем.

Хочется увидеть конкретики, инструментарий и подходы, которые можно применять в работе.

[Aslamov]

Мне кажется, что если дать развёрнутый комментарий к статье, то он будет больше самого текста.
Поэтому напишу кратко:

1. Автору спасибо за затронутую тему — тема интересная и актуальная, надеюсь серия будет продолжена.
2. Согласен с тезисом, что давать читателю ту информацию, которая соответствует области его интересов наиболее корректно. Только, как мне кажется, это относится в первую очередь к специализированным stakeholders, а часто бывает запрос от топ-а или какого-нить заказчика такой «дайте, пожалуйста, информацию про систему одной картинкой, ну максимум двумя — чтобы всё ключевое было отражено» — и такая bullshit диаграмма как раз должна быть очень полезна (возможно, что делать её нужно не архитектору, а команде из архитектора, дизайнера и т.п.) — делают же инфографику по сложным всяким штукам. Так что и такие диаграммы нужны. То, что не удалось автору на первой диаграмме показать все аспекты – ну что ж, есть куда развиваться .
3. Касательно примеров. Текст примеров и вопросы, которые должны быть отражены на соответствующих диаграммах вполне понятны, тогда как сами диаграммы получения ответов на вопросы требуют усилия. Например, деплоймент — из него должно быть понятно, что, где и как размещено.
   
   Ок, что мы видим на диаграмме:
   
   • браузер
   • Протокол HTTPs
   • Google Cloud Platform
   • Регион – Европа (уже надо приложить усилия, чтобы понять – а зачем здесь регион?)
   • Сеть по-умолчанию (зачем она нужна здесь?)
   • Вычислительный узел (что это?)
   • Cloud IAM
   • И три пиктограммы – шестиугольники – два побольше, один поменьше (и опять непонятно, что это)
   
   
   А что должна показать диаграмма по мнению автора

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

   Давайте разберём:
   
   • Из диаграммы не следуют стоимость — просто потому, что там она не указана. Скорее стоимость будет указана не на диаграмме, а документедокументе с расчётом общей стоимости владения системой или стоимостью её обслуживания (именно это будет интересно спонсору, а не диаграмма развёртывания), где будут расписаны все статьи расходов — инфраструктура, лицензии, саппорт и т.п… Напротив, из самой первой диаграммы хотя бы можно понять, что это именно виртуальная машина GCP, что какие специалисты возможно потребуются для обслуживания
   • Из диаграммы не очевидно, плохо или хорошо может быть масштабируемо решение (так как не понятно, что такое вычислительный узел и что он в себя включает) и скорее всего для понимания этого, нужно указать в явном виде, что вычислительный узел только один или же наоборот их может быть несколько.
   • Из диаграммы не видно не то, что нет резервной копии БД, а даже что такая БД есть. Зато это видно из первой диаграммы, которая приведена в качестве примера «как не стоит делать».
   • Ну и уж конечно не видно (на мой, разумеется, взгляд), что решение требует перепроектирования в случае резкого увеличения нагрузки.
   
   

В общем, здорово, что статья написана, и несколько досадно, что здравая мысль ( о том, что информация должна быть адресной — каждому читателю свой срез системы) была несколько небрежно проиллюстрирован и тем самым может быть подвергнута сомнению в своей полезности. Надеюсь, в следующей статье автор сосредоточиться и приведёт более наглядные примеры и не будет без связи со статьёй упоминать свой блог.

P.S.
А причём здесь hub GCP? нет ни слова, связанного с какими-то аспектами работы GCP (с тем же успехом, здесь можно оставить любого облачного провайдера, предоставляющего IaaS).