Архитектура: Monolith

Monolith


Монолитная архитектура приложений, пожалуй, самая старая. В связи с бурным ростом приложений и их значительным усложнением, даже монолитные приложения начали несколько видоизменяться. Например, в них появилась модульность, а так же подключаемая компонентность, но фундамент архитектуры остается неизменным.

В настоящем, монолитными считаются приложения, работающие в качестве самодостаточного единого процесса (на уровне ОС), которые исползую мощности на одной машины, но при этом, могут быть объединены в кластер(ы). Они не должны зависеть от внешних ресурсов, например, БД или других сервисов. При этом, характерно для данного типа исполнения системы расположение данных - в монолитной реализации поток данных сконцентрирован в пространстве одной машины.

Плюсы

Монолитная архитектура, хоть и считается несколько устаревшей, она имеет ряд весомых положительных черт:

  • простота развертывания приложения;
  • простота эксплуатации и поддержки;
  • линейность разработки, которая не требует синхронизации версионности между различными элементами;
  • изолированность и компактность.

Минусы

При этом, обладает рядом существенных отрицательных сторон:

  • сложность (а иногда и невозможность) горизонтального масштабирования;
  • постепенное разрастание и доведение приложения до состояния колоссальной требовательности к ресурсам;
  • cлишком низкая мобильность приложения;
  • любое изменение в системе может повлечь катастрофические последствия;
  • Невозможность разработки на различных языках программирования (что требует специфического набора кадров).

Со временем монолитные решения могут привести к анти-паттерну - Big Ball of Mud. Это проблема характеризуется большим количеством беспорядочно “слепленных” компонентов, имеющих большое количество зависимостей друг от друга, доводящие приложение до состояния невозможности исключения части приложения (например, за ненадобностью). В результате, масштаб приложения разрастается, а доля актуального функционала в нем снижается. Иногда проще переписать приложение заново, чем заниматься рефакторингом подобных трудноподдерживаемых систем.

Литература

2002 – Martin Fowler – Patterns of Enterprise Application Architecture
2003 – Eric Evans – Domain-Driven Design: Tackling Complexity in the Heart of Software
2011 – Chris Ostrowski – Understanding Oracle SOA – Part 1 – Architecture

 Comments
Comment plugin failed to load
Loading comment plugin