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