Из telegram-канала Архитектура ИТ-решений
Я приступаю к этому тексту с наивным намерением сделать целую серию небольших заметок о современны архитектурах ИТ-решений и разобраться, в первую очередь для себя, является ли переход на микросервисную архитектуру путешествием в один конец. Мне довелось читать достаточное количество историй о том, как та или иная компания вернулась назад из микросервисного безумия, но ни разу я не видел подобной истории собственными глазами и даже не разговаривал с участниками или очевидцами. Предполагаю, что упомянутых выше историях есть определенное лукавство. Обратный билет из микросервисов представляется мне лженаучной фантастикой. Впрочем, безусловно, я вполне могу ошибаться. Если вам хочет поделиться со мной своим контрпримером, то обязательно это сделайте
В первой заметке мы поговорим о том, из-за чего нас постигла эта микросервисная напасть и возможно ли было, хотя бы теоретически, другое развитие событий. В чем оно состоит, где находится развилка и до какого момента времени можно свернуть в указанном направлении. И начнем мы даже не с микросервисов, а с распределенных систем – приложений, данные и код которых, не вмещались по тем или иным причинам на одном сервере. Пока приложения развертывались на одном сервере всё было неплохо. Ну, может про один я не прав. Один для базы данных, еще один для сервера приложений, плюс еще парочка для резервирования, да и всё. Даже не вдаваясь в детали реализации я замечу, что данные на экземплярах БД были одинаковыми, как и приложения на серверах бизнес-логики.
Но затем конструкция эта начала расползаться. Сначала кусочки логики отвалились на отдельные узлы, продолжая работать с общей БД. Потом данные стали вылезать из базы и раскладываться в другие системы, ну а в конечном счете от приложений стали отваливаться полноценные сервисы. И процесс этот начался не 10 и не 15 лет назад, а несколько раньше. И причин тому, кроме банального желания масштабироваться, было штук этак несколько. Подробнее о некоторых из них в следующих репликах. Сам процесс распада приложений, по крайней мере в корпоративной среде, продолжался не один год, принимая разные формы, но неизменно представляя собой головную боль для корпоративного ИТ-архитектора. И системы новые в результате этого вырастали в ИТ-ландшафте предприятия, и технологии обнаруживались и даже неучтенные сервера под столом в кабинете какого-нибудь вице-президента.
В начале десятых годов жизнь стала налаживаться. Фрагментам приложений и данных, возникшем при распаде информационных систем, эксперты дали гордое имя микросервисы и даже надавали советов как процесс этот упорядочить и проконтролировать. Но к современному моменту наблюдается заметное желание отдельных людей осколки приложений собрать и снова в один сервер запихнуть: снижение сложности, уменьшение расходов на взаимодействия и т.п.
Ну, давайте. Логику опять перепишем. Вернем её с java на PL/SQL и засунем в СУБД. Ну и сервисы, конечно, соберем, так сказать, на единой платформе и запустим в одном процессе. Или нет? Не будем спешить и в следующее заметке поговорим о том, а с чего это приложения в какой-то момент вдруг стали рассыпаться на сервисы