Комментарии 6
Приятно почитать, спасибо!
А никто не заметил, что несмотря на присутствие ссылок на трёх гигантов: Amazon, Microsoft, Google, все примеры и описания говорят только про AWS? Хотелось уже увидеть какое-то обобщение, или разнообразие примеров - статья выглядела бы заметно лучше.
Поставил лайк статье. Но каждый раз наблюдая фразы типа: "Если же архитектура подразумевает сложную логику в базе данных, то на бесшовном обновлении можно поставить крест - сохранение обратной совместимости будет дороже изменений, ради которых происходит обновление." я морщусь, так как, по моему мнению, такое заблуждение исходит исключительно из поверхностного подхода к работе с базами данных. Если вы можете заменить бд на key-value хранилище, то логики в БД у вас действительно нет. Но если не можете, то вы лукавите, и логика в бд у вас есть.
Попробуйте рассмотреть базы данных как отдельный независимый сервис. Причины его отделения обычно технологические. Но всё же это отдельный сервис со своим интерфейсом (внешним контрактом)
Архитектура - набор ключевых решений при проектировании системы, удовлетворяющих следующим критериям:
Проблема уже в самом начале статьи: Вы путаете понятие "архитектура" и характеристику "хорошая архитектура". О критериях "хорошей" можно рассуждать долго, но и плохая архитектура приложения - тоже архитектура.
все так хорошо шло
а потом мысль автора скатилась: в узкую область - облака, потом в вендор лок, а потом в прямую рекламу
Хорошо бы в названии статьи сразу указывать о КАКОЙ именно архитектуре пойдет речь.
TOGAF говорит нам, что бывают разные архитектуры: Enterprise Architecture, Business Architecture, Data Architecture, Solution Architecture, Infrastructure Architecture
Если у вас на схема есть надписи База данных это уже не архетуктура, а проектное решение. На схеме архетуктуры должно находиться хранилище, вдруг вы при реализации решите сделать его на Redis или в Ексель файле или вообще необходимо обращаться в удалённый сервис для получения данных.
Что такое Архитектура