Почему микросервисы лучше компонент или как деградируют идеи в IT
Рис. 1
Попробуем начать с цитаты:
При современных темпах развития индустрии программирования приложениям нельзя оставаться застывшими. Разработчики должны найти способ вдохнуть новую жизнь в программы, которые уже поставлены пользователям. Решение состоит в том, чтобы разбить монолитное приложение на отдельные части, или микросервисы (рис. 1).
…
Традиционно приложение состояло из отдельных файлов, модулей или классов, которые компилировались и компоновались в единое целое. Разработка приложений из микросервисов — так называемых приложений микросервисной архитектуры — происходит совершенно иначе. Микросервис подобен миниприложению; он поставляется пользователю как двоичный код, скомпилированный и готовый к использованию. Единого целого больше нет. Его место занимают специализированные микросервисы, которые подключаются во время выполнения к другим микросервисам, формируя приложение. Модификация или расширение приложения сводится просто к замене одного из составляющих его микросервисов новой версией.
Если интересно откуда эта цитата и что с ней не так прошу под кат.
Это цитата из книги которая написана более 25 (это не ошибка!) лет назад.Просто цитата не совсем коректная. Вот более полная версия:
При современных темпах развития индустрии программирования приложениям нельзя оставаться застывшими. Разработчики должны найти способ вдохнуть новую жизнь в программы, которые уже поставлены пользователям. Решение состоит в том, чтобы разбить монолитное приложение на отдельные части, или микросервисы (рис. 1).
Рис. 1
По мере развития технологии микросервисы, составляющие приложение, могут заменяться новыми (рис. 2). Приложение более не является статичным, обреченным устареть еще до выхода в свет. Вместо этого оно постепенно эволюционирует с заменой старых микросервисов новыми. Из существующих микросервисов легко создать и абсолютно новые приложения
Традиционно приложение состояло из отдельных файлов, модулей или классов, которые компилировались и компоновались в единое целое. Разработка приложений из микросервисов — так называемых приложений микросервисной архитектуры — происходит совершенно иначе. Микросервис подобен миниприложению; он поставляется пользователю как двоичный код, скомпилированный и готовый к использованию. Единого целого больше нет. Его место занимают специализированные микросервисы, которые подключаются во время выполнения к другим микросервисам, формируя приложение. Модификация или расширение приложения сводится просто к замене одного из составляющих его микросервисов новой версией.
Рис. 2
В чем же заключается современная идея микросервисов? Может быть в том, что сложные приложения надо поделить на простые и по возможности распределить эти простые приложения на разные компьютеры (даже на разные серверы). Казалось бы тут сразу должен возникнуть следующий вопрос: «Зачем делать именно так, ведь работа распределенной системы связана с дополнительными накладными расходами и дополнительными задержками связанными с взаимодействием по сети или даже со взаимодействием между условными сервисами в разных процессах на одной машине?». Но такой вопрос просто не принято задавать в приличном нано-технологичном обществе, в котором все издержки представляются как нано-издержки, а микросервисы это слово прогресса и просто путь в лучшее будущее. Вы же знаете, последний писк моды это взаимодействие между микросервисами через текстовый интерфейс на базе древнейшего HTTP, так называемый Rest API, а не какой нибудь SOAP например, или не дай бог CORBA. Вообще то изначально не было никакого Rest API был просто HTTP протокол предназначенный для общения браузера с сервером для навигации и управления контентом, который хранится на сервере, но прогресивная мысль не стоит на месте и продвинутые разработчики быстро смекнули, что можно писать целые куски распределенной программы, которые будут общаться с другими кусками этой распределенной программы через тот же HTTP протокол. А это круто! C таким опытом вас с руками оторвут любые эффективные менеджеры с деньгами. Конечно этот метод взаимодействия внутри одной программы (системы) несет в себе достаточно большую избыточность, создает дополнительные задержки, но кого это волнует когда придумано такое модное название для этого перформанса как RESTful веб-сервисы, когда любой программист может вам с гордостью и даже с некоторой надменностью сказать: «Я работаю через RESTful интерфейсы, разрабатываю микросервисы», попробуйте что-то возразить против такого метода работы.
Если вы еще не догадались откуда же я взял эту цитату я открою тайну, я надеюсь вас это не очень шокирует, хотя за компом обычно сидят, поэтому ничего страшного.
Источник цитат
Это цитата из перевода книги «Inside COM». by: Rogerson, Dale, 1966-. Publication date: 1997. Конечно книга была посвещена Компонентной архитектуре, а ни как не Микросервисной, я просто заменил в цитатах все однокоренные слову «компонент» слова словами производными от слова «микросервис». Но вы можете заметить, что если рассматривать слово «компонент» как противоположность слову «монолит», то замена является совершенно корректной, так как в нашей современности «микросервис» все также выступает в качестве противоположности «монолиту», в этом отношении ничего не меняется. Задача противостоять Монолиту видимо очень не простая, поэтому разработчики используют тактику замены кандидата для противостояния.
Но что же предлагалось авторами концепции деления приложений на компоненты:
возможность замены компоненты на лету в работающем приложении (например пока функция за которую отвечает компонента отключена),
повторное использование компоненты в другом приложении — в приложении с другим набором функций,
но самое главное это независимая разработка-переработка кода этой отдельной компоненты, основанная на том простом факте, что эта компонента спроектирована и включается в приложение как внешняя компонента,
но верхом совершенства древние программисты тогда считали возможность распространять-передавать пользователям части программ в виде бинарников!
Но теперь же всем понятно что это какой-то отстой, что гораздо лучше, когда пользователь программы качает исходники этой программы из репозитория, подтягивает все зависимости необходимые для компиляции этой программы, компилирует у себя эту программу и недостающие для ее компиляции библиотеки и начинает пользоваться этой программой как продвинутый и уважаемый представитель IT сообщества, выполнив некоторую специальную процедуру развертывания-конфигурации этой успешно скомпилированной программы! Возможность распространения программ и их частей в виде бинарников это просто не уважение к конечному пользователю любой программы, вы же не доверяете ему даже прикоснуться к исходному коду этой программы!
Но если серьезно, то в чем же отличие компонентной архитектуры приложения, пусть мы назовем ее микросервисной архитектурой, от монолитной? На самом деле слово в названии не так важно если мы правильно понимаем смысл и происходящие из этого смысла цели.
Так вот основной смысл какой бы то ни было сервисной архитектуры (не монолитной) заключается в том, чтобы построить архитектуру таким образом, чтобы иметь возможность передавать пользователю работающей системы усовершенствованные или исправленные части (назовем их сервисы что ли тогда) этой системы в каком-то виде (даже не обязательно бинарники, а как код какого-то класса на интерпретируемом языке, например) чтобы пользователь мог безболезненно подменить такую часть программы в своей работающей системе соблюдая какую-то простейшую и абсолютно понятную с точки зрения этого пользователя процедуру (например примитивное копирование файлов), взамен повторного полного развертывания системы при любом изменении. Если в вашем приложении или в распределенной системе можно выделить такие части, которые доступны для такой переработки и подмены, или если вы можете добавлять в свое приложение-систему такие части. которые подхватываются системой на лету и каким-то образом расширяют функциональности вашего приложения-системы, только в этом случае вы можете говорить что у вас получилась микросервисная архитектура на мой старомодный взгляд. А если нет, то возможно вы пока только на пути к микросервисной архитектуре. Кстати в свое время таким же модным словом как микросервисы было слово Плагины, которое очень нравилось IT сообществу в отличие от слова компонент, которое невольно наводит на ассоциации с организацией, которая не только пропагандировала компонентный подход, но и успешно его реализовала и до сих пор успешно использует.
К сожалению прогрессивное IT сообщество в своей попытке дистанцироваться от термина компонент также уходит в сторону от целей построения эффективно управляемой архитектуры системы, в которой изменения в одной части этой системы не ведут к перекомпановке и пересборке всей системы. В той древней книге вы можете прочитать не только что такое инкапсуляция и полиморфизм, но и за чем они нужны и как реализуются и как работают на практике и с примерами кода. Есть одна большая проблема с этой книгой — ее надо читать очень внимательно и сначала, хотя не обязательно до конца, ближе к концу начинаются очень специальные применения, которые не всем пригодятся на практике. К сожалению в наше время, во времена клипового сознания это практически не осуществимое пожелание.
Мне показалась очень интересной и поучительной следующая аналогия из этой книги:
Изучали ли Вы физику в школе? Если Вам преподавали физику, пользуясь элементами высшей математики, то знание последних было необходимым предварительным требованием. Изучая математический анализ, Вы учились применять его в разных областях. Только изучив и поняв дифференциальное исчисление как таковое, Вы смогли использовать его для решения физических задач. Такая последовательность обучения существовала не всегда. Сначала Исаак Ньютон изобрел дифференциальное исчисление как инструмент классической механики и динамики. Только позднее стало ясно, что этот мощный инструмент имеет приложения и за границами физики.
По моему, попытки придумать альтернативу компонентной архитектуре подобны попыткам изобрести другое дифференциальное исчисление, или как минимум подобны попыткам пересказать теорию дифференциального исчисления в других терминах просто потому, что сообщество как-то очень предвзято относится к автору этой исходной теории, или даже не к автору, а к организации для которой работал этот автор (на самом деле группа авторов). Поэтому закончить я хочу еще одной цитатой из этой книги:
Если Вы пишете программы для UNIX, Macintosh, Linux, VMS или какой-либо другой операционной системы, эта книга также будет Вам полезна. Концепции, заключенные в СОМ, работают не только в операционной системе Windows, СОМ — это не большой API. COM — это способ программирования, стоящий в одном ряду с такими способами, как структурное или объектно-ориентированное программирование. Вы можете использовать подход СОМ в любой операционной системе. Конечно, Windows предоставляет код, который облегчает программирование «в духе СОМ», но большую часть этого кода нетрудно реализовать на Вашей любимой платформе.
Мораль сей басни очень проста. Не стесняйтесь читать фундаментальные труды древних программистов! Только имея серьезную базу фундаментальных, проверенных временем, знаний можно рассчитывать на положительный результат в настоящем, иначе это просто лотерея с мизерными шансами на нужный результат.
