Я здесь не пишу в духе «микросервисная архитектура — это лучшая практика» и, соответственно, статьи с антогонистическим посылом для меня мимо цели.
Когда я размышляю о реализации той или иной задачи, я в первую очередь думаю… о задаче: ) Не о микросервисах или монолите, ни даже о фреймворке или библиотеках, алгоритмах — а о задаче. Я может быть несколько консервативен — но, признаюсь — я даже рисую схемы бизнес-процессов: ) стараясь в первую очередь представить картину предметной области в логическом смысле.
Получив такую картину, я начинаю понимать — что и как лучше реализовать, где можно и нужно отделить, а где — нет. Отделяю я те компоненты в микросервис, где могу делегировать ответственность в независимый компонент. Это как, например, распределение задач на выполнение разным людям — они будут трудиться совместно, но у них есть свои довольно четкие зоны ответственности. Кроме того, важно, чтобы разделение не вызывало необходимости чрезмерно плотной коммуникаций — когда людям приходится постоянно у друг друга что-то выспрашивать, чтобы выполнять свою работу. Микросервисы так же не должны разделять объекты в работе — то есть нет такого, что один объект изменяется из двух разных точек, все изменения проходят только как сообщения-данные между сервисами. Сервисы принимают данные и данные же возвращают, а не модифицируют «чужие» объекты. В общем я, даже не обладая большим опытом в микросервисах — уже, пожалуй, мог бы написать объемную статью — как именно я выбираю кандидатов на микросервисы.
Придерживаясь этих своих правил я получаю весьма надежную систему из микросервисов, получаю и все преимущества микросервисности. Плачу за это — необходимостью интерфейсов между микросервисами — они должны понимать друг друга в работе.
И пока, всё что я прочел про «недостатки» микросервисов, является по моему мнению — недостатком в понимании: что именно и как следует разделять. Многое из того, что я прочел — я изначально не стал бы выделять в сервисы и для меня дальнейшие рассуждения о превратностях микросервисов уже более чем странные. Примерно как если бы кто-то написал:… и вот мы решили отправить рыбу лазить по деревьям…
А вот насчет моего примера — никакая наичистейшая архитектура мне всё равно не помогла бы — разве только в той части, где я написал о «созданные им зависимости проникли в код монолита» — но это действительно не проблема монолитности, а та самая — недостаточно чисто написано. В остальном же — и в главном — мне всё равно пришлось обновлять этот потенциальный микросервис из-за того, что обновляется сама платформа, на которой построен монолит — фреймворк. Будь у меня независимый сервис — он мог бы продолжать функционировать без изменений, несмотря на обновление других частей конгломерата сервисов, которая образовывает систему.
Кстати заметить, «Чистая архитектура» — это та же проблема, что и «Чистые микросервисы» в разработке — она требует продумывания архитектуры. А до этого тоже придется дорасти. И разработчики пишут не совсем чистые монолиты отнюдь не только потому, что не умеют писать чисто, а потому, что как раз на старте еще очень и очень многого не видно, не понятно и неясно как будет — это задним умом мы все сильны.
Вот мне довелось обновляться — и я ВЫНУЖДЕН в монолите обновлять или всё или ничего.
И то же с масштабированием — при масштабировании микросервисного конгломерата я могу масштабировать именно тот функционал, который требует масштабирования, при монолите — допинстансы поднимаются целиком, хотя вполне возможно, что производительность проседает в отдельном модуле. То же самое — с резервированием.
Никто не говорит, что микросервисы — лучшее решение во всех случаях, или что оно «бесплатное», но и появилось оно не на ровном месте, от скуки.
Вот, кстати, еще один прекрасный практический пример — в чем смысл микросервисности. Сейчас у меня на одном из проектов есть задача обновить приложение — оно отстало от текущих версий на три апдейта фреймворка. Приложение — монолитное, но есть в нём, например, такой модуль работы с соцсетями пользователя — неосновная задача приложения. И вот с ним мне пришлось повозиться, так как он и сам так же устарел относительного текущих версий фреймворка, и базируется на компонентах, которые тоже устарели. Будь это отдельный микросервис — а это вполне реализуемо в рамках проекта, я, возможно, даже и не стал бы его обновлять — работает и работает, задача его — далека от основного процесса проекта и без особой разницы как он там реализован. Но — нет, мало того, что мне по-любому пришлось его обновлять и переписывать местами, чтобы он соответствовал и работал в составе обновляемого фреймворка, так еще и созданные им зависимости проникли в код монолита (включены в модели), так что не обошлось одной лишь правкой в отдельном модуле, и пришлось обновлять все пакеты, от которых этот модуль зависит.
База в свою очередь может быть распределенной — и проблема «шины» тут всего лишь делегирована на движок БД, однако никуда не девается. И Вы в такой ситуации просто надеетесь теперь не на шину микросервисов, а на шину базы данных — что с ней всё в порядке будет и транзакции на всех узлах БД целостны и согласованы.
Вообще же — thecoder тут в нескольких постах пояснил, что работа с транзакциями — это последнее, что надо реализовывать как микросервисы, только в случае, когда уж другого выхода нет. Признак потенциального микросервиса — это насколько все плохо будет для системы в целом, если сервис откажет. Если система переживет временную потерю сервиса приемлемо — его можно вынести, а если это чревато большими проблемами — сто раз подумайте, прежде чем этот модуль отторгать.
И мне сдается, что весь негатив к микросервисной архитектуре как раз оттого, что люди не думают что творят, когда начинают выносить в микросервисы тесно связанные модули — но здесь злой Буратино не микросервисная архитектура, а сам архитектор.
Опять: проблема синхронизации данных — это не проблема микросервисов как таковых, а проблема любых распределенных систем, каковыми могут быть и монолиты — как несколько инстансов на разных узлах.
Я имел ввиду следующую мысль: если речь идет о микросервисе, работающем в составе некоторой системы сервисов, то желательно, чтобы этот микросервис не запрашивался множеством других сервисов, а запрашивался в цепочке — родитель сверху, потомок — ниже. Тогда, если что-то меняется в работе микросервиса — это (возможно) приводит к необходимости изменений лишь в двух ближайших его «родственников», а если что-то пойдет не так — то и это «не так» не расползется по связям бог знает куда, а будет влиять только на цепочку, что значительно упростит поиск и исправление бага.
Разумеется, это не про те «микросервисы», которые на самом деле уже и не «микро», а полноценные приложения, к которым обращается масса других приложений за какими-то данными.
Вообще же, надо просто понять — откуда есть пошли эти микросервисы. Они ведь появились не только лишь потому, что кому-то вздумалось «поиграть в микросервисы». Микросервисы — это логичный ответ на конкретные задачи. Я выше тут писал про свой пример — у меня есть в проекте задача обслуживания клиента, и есть задача периодического мониторинга неких данных, которые я предоставляю клиенту. Можно обе задачи решать в рамках одного монолитного приложения, но так же хорошо эти две задачи могут работать и по отдельности. У меня нет сильной связанности между двумя этими задачами: то есть сбор (обновление) данных конечно нужен, но если он не увенчался успехом в очередной итерации — клиенту допустимо предоставить на его запрос предыдущие данные. Другая особенность состоит в том, что сбор данных может меняться довольно часто из-за того, что сам источник этих данных изменяется и под него надо подстраиваться — в условиях монолита это будет означать необходимость править весь проект, прерывать обслуживание клиентов при апдейте проекта. А в условиях микросервиса — я могу править сервис более удобнее. Я могу вынести микросервис сбора данных куда угодно — это, кстати, тоже одна из задач проекта, так как наш доблестный РКН любит поиграть в модераторов. Я могу наплодить кучу одинаковых микросервисов, тем самым зарезервировав их, я могу относительно легко добавлять микросервисы с другим типом собираемых данных — конечно же тут придется и принимающую часть изменять для того, чтобы она умела эти данные принять, но вся инфраструктура уже построена — нужны лишь кастомны методы приема и обработки конкретного типа данных.
Я не являюсь ни теоретически подкованным в микросервисах, ни обладателем обширного практического опыта их применения, ни даже их почитателем — я использую то, что разумно в поставленной задаче.
Да, конечно, речь идет о понимании концепции, а часто у специалиста есть опыт работы с какой-то технологией — и он переносит его целиком на другую, из чего получается натягивание совы на глобус, а по итогу этот специалист говорит: да фигня эта «сова» ваша. Что же касается адаптации задачи к технологии… я сталкивался не раз с тем, что одна и та же задача вполне себе решается несколькими способами, вполне хорошо решается. У каждого решения — свои плюсы и минусы, и тут требуется решить — какой набор плюсов/минусов удобнее. Ну и, конечно, возможно это только если способен эти разные решения создать, чего никогда не будет, если есть предубеждения против чего-то — а по факту это неумение работать с той или иной технологией.
Это была шутка юмора. Хотя в ней и не только юмор — вы спрашиваете про проблемы в шине — но это равнозначно, что спросить: А если сервер откажет? И что ты будешь делать со своим монолитом, Илон Маск? Это же ерунда — эти отказы не следствие выбора архитектурного решения. Из-за чего шина может отказать? Из-за проблем кода самой шины? — Ну так это плохая шина, и в монолите будет проблема, если его «внутренняя шина» кривая. Или проблема связана со связью? — Ну так и монолит без сети скорее всего бесполезен как вещь в себе в современных-то реалиях, да и микросервисы городить для не сетевого приложения смысл какой?
Поэтому я бы не скидывал и ядерный взрыв как фактор в таком уж случае.
Ну, запутать можно и внутреннюю структуру вызовов внутри монолита, так что черт ногу сломит — откуда что берется, поэтому хорошо сделанный монолит — это уже по факту тесно связанная куча «микросервисов», только их интерфейсы взаимодействия не сетевые.
Отторгнуть такие квазимикросервисы из монолита вовне не составит проблемы, но есть ли в этом смысл — это зависит от контекста задачи. При отторжении мы естественно получаем необходимость выстраивания взаимодействия с «потребителями», ранее решаемое платформой, на которой крутится монолит, а как бонус — получаем возможность вынести сервис на другие серверные мощности, возможность использования сервиса другими приложениями и определенную свободу по изменению внутренних механизмов сервиса, не оказывающих влияния на интерфейс взаимодействия, а так же возможности более легкого масштабирования и резервирования сервиса.
О серебристости GraphQL речи не идет, но есть два фактора, которые позволяют его эффективно применить в ряде задач. Во-первых — это его явные преимущества, которые я перечислил выше, а если говорить коротко — то это его высокая гибкость по сравнению с тем же REST.
Второе же заключается в том, что используя graphql необходимо и мыслить в концепции graphql, попытки же сделать «как в REST, только GraphQL» к хорошему явно не приведут, что, в общем-то, справедливо для любой технологии.
Верно — graphql. Избавляет от боли модификации api, кача избыточных данных, разрастания набора эндпоинтов. Запихнул его в свой проект с микросервисами — теперь у меня свой проект с graphql и микросервисами: )))
А кроме шуток, и говоря о заметке уровнем выше про опыт с микросервисами — я полагаю, что надо еще и осторожнее быть со связями между сервисами, то есть в идеале один сервис связан не более чем с двумя другими сервисами, обеспечивая иерархическое дерево, иначе геморрой при изменениях начинает расти экспоненциально как функция от количества связей на сервис. С одной стороны такое ограничение вроде как и противоречит концепции широкого переиспользования, с другой — это продиктовано соображениями локализации и сдерживания сложности. Если в такой ограниченной микросервисной архитектуре возникает необходимость изменений какого-либо сервиса, то это хотя бы не порождает слишком много изменений, а те, что неизбежны — по-крайней мере распространяются в известном направлении — вдоль своей ветви. Но это так — интуитивные соображения безопасности, реального опыта эксплуатации пока мало.
Микросервисы иногда напрашиваются на старте — когда есть куски работы, слабо связанные по времени исполнения (имеется ввиду процессорное время) и результаты работы этих кусков допускают возможность краша. Сейчас работаю над проектом, в котором есть основной сервис со своей базой данных, и есть добытчик данных, которые основной сервис периодически запрашивает у добытчика. Оба сервиса, конечно, синхронизированы по времени обновления данных, но если у добытчика отказ, то основной процесс от этого не страдает — он работает на уже собранных данных — тут изначально напрашивалось разделение на сервисы, что и было реализовано в архитектуре. И здесь проявляются преимущества микросервисов — добытчики данных могут менять алгоритмы сбора данных как угодно без необходимости править весь проект — требуется лишь поддерживать стандарт интерфейса передачи данных между сервисами, можно балансировку и резервирование легко сделать для добычи данных — надо лишь на основном сервисе добавить адреса добытчиков. Сервисы в данном случае занимаются каждый своей работой.
Накладными расходами тут являются поддержание интерфейсов между сервисами — как в архитектурном плане (согласованность форматов), так и в физическом (доступность сети), и, конечно, мониторинг. Изначально я хотел вообще сделать основной сервис с функциями контроля над добытчиками, но лимит времени на разработку не позволил чрезмерно углубляться, будет развитие проекта — вот тогда и можно будет дальше эту тему развить.
Статья же — однобокая, но она так и задумана, наверное. Ведь действительно лучше сделать работающее приложение, которое еще сто раз поменяется, чем стараться изначально все эти сто предстоящих изменений предусмотреть — и, конечно, все равно ошибиться, ибо всего не учтешь. Но то, что изначально хорошо можно вынести в отдельный сервис — почему бы и не вынести, если есть время и ясное понимание и обоснование преимуществ такого решения.
Тут даже вопрос не про выставление статуса, а про адекватность и ответственность разработчика. Верно то, что адекватному и ответственному просто не нужен этот контроль от слова совсем — он только мешает, а вот неадекватного и безответственного человека — хоть законтролируйся — все равно в лучшем что-то ну очень посредственное получишь. В итоге вся идея контроля — не от большого ума и высокой компетенции менеджмента компании, сама цель непонятно — что хотят контролировать и чего добиться? Самоудовлетворения своей значимости (ай эм биг босс!) или поддерживать иллюзию контроля? В самом деле, вот просто житейски — какой из этого прок и кому?
И еще справедливости ради надо таки сказать, что как без повара нет ресторана, так нет его и без хорошего администратора, официантов, дяди Васи, отвечающего за закуп продуктов, даже без — прости господи — без маркетолога, который этот ресторан пропиарит хорошо и поэтому будет спрос на него… Так что это всё же общий труд и в нём нет главных. Правда высокие менеджеры порой стараются убедить всех своих сотрудников в обратном — так ими легче управлять.
Очень возможно — я не претендую на исчерпывающую полноту своего личного опыта, однако он имеет место быть, и, насколько мне известно — он у меня не уникален и довольно распространен. Соответственно здесь, в рамках обсуждения ваших методов контроля мы и делимся своими соображениями и опытом, что потенциально могло бы и вам пригодиться, если смотреть на излагаемое как на источник информации, а не попытку подорвать ваш авторитет или чего-то в этом роде.
Впрочем, я не настаиваю на обсуждении. Если же вы не против — с интересом познакомлюсь с вашим взглядом на командную работу. Я всегда рад ознакомиться с иной точкой зрения.
А на чем эти построения о «командной работе» основаны? Я, например, как человек приземленный, предпочитаю свои соображения соотносить с практикой. И мой опыт говорит, например, о том, что есть очень большие интервалы, когда никакой командной работы — не требуется, и даже сидя в офисе — ты сам в себе, в своей работе. Есть, разумеется, и напротив — интервалы, когда требуется командная работа — это особенно важно на этапе выработки концепции, на этапе тестирования большого блока, на этапе запуска и первых дней жизни проекта — тут разговора нет и никакому вменяемому разработчику не придет в голову уклоняться от этого. Но жесткая структура митапов — ежедневно, например, вне зависимости от контекста — это не более чем синдром контроля головного мозга, а не необходимость в виду реальных предпосылок. Это тот же микроменеджмент, задекорированный под благие намерения.
Если вы такая продвинутая компания, то я бы порекомендовал вам к действительности и обратиться — да вот хотя бы провести ненавязчивый опрос среди своих же сотрудников — что дают им эти ваши контролирующие рамки? Тот же Гугл с его квазианархией — по крайней мере как это преподносится — про возможность работы над своими проектами «в рабочее время», про возможность работать как удобнее и прочие плюшки — вы думаете они там просто зажрались? А я полагаю, что там умные люди просто воспользовались старым добрым тезисом: «Если не можешь прекратить безобразие — возглавь его.» И поимели профит с этого вместо затрат на контроль.
А ваша позиция уже становится чисто защитной — типа возражающий вам просто неправильный (согласно вашим правильным правилам). Ясен пень, что навязываться вам никто не навязывается и не переубеждает — мы лишь говорим о ДЕЙСТВИТЕЛЬНОСТИ, как оно на самом деле происходит, и что можно эту действительность обратить себе на пользу, а не пытаться с невеликим успехом подогнать под свои представления о правильном.
Значит вы пока не работали над проектами, где один человек уже не в силах справляться со всеми этими функциями.
Работал в команде и очень хорошо себя чувствовал — там да, мог погружаться и на более продолжительное время. Сейчас — нарабатываю опыт, и пока вся свистопляска с ролями при всех неудобствах, в целом — хороший и ценный опыт. Поднаторею — начну искать более специализированных рамок деятельности.
Уже есть мечтания, как я такой клёвый в клёвой команде, где каждый своим занят, где тесты покрывают всё, ревью кода проводят, устраивается внутренний обмен знаний на постоянной основе между сотрудниками, сеньоры доброжелательны и мегакомпетентны и т.д.: )))
Когда я размышляю о реализации той или иной задачи, я в первую очередь думаю… о задаче: ) Не о микросервисах или монолите, ни даже о фреймворке или библиотеках, алгоритмах — а о задаче. Я может быть несколько консервативен — но, признаюсь — я даже рисую схемы бизнес-процессов: ) стараясь в первую очередь представить картину предметной области в логическом смысле.
Получив такую картину, я начинаю понимать — что и как лучше реализовать, где можно и нужно отделить, а где — нет. Отделяю я те компоненты в микросервис, где могу делегировать ответственность в независимый компонент. Это как, например, распределение задач на выполнение разным людям — они будут трудиться совместно, но у них есть свои довольно четкие зоны ответственности. Кроме того, важно, чтобы разделение не вызывало необходимости чрезмерно плотной коммуникаций — когда людям приходится постоянно у друг друга что-то выспрашивать, чтобы выполнять свою работу. Микросервисы так же не должны разделять объекты в работе — то есть нет такого, что один объект изменяется из двух разных точек, все изменения проходят только как сообщения-данные между сервисами. Сервисы принимают данные и данные же возвращают, а не модифицируют «чужие» объекты. В общем я, даже не обладая большим опытом в микросервисах — уже, пожалуй, мог бы написать объемную статью — как именно я выбираю кандидатов на микросервисы.
Придерживаясь этих своих правил я получаю весьма надежную систему из микросервисов, получаю и все преимущества микросервисности. Плачу за это — необходимостью интерфейсов между микросервисами — они должны понимать друг друга в работе.
И пока, всё что я прочел про «недостатки» микросервисов, является по моему мнению — недостатком в понимании: что именно и как следует разделять. Многое из того, что я прочел — я изначально не стал бы выделять в сервисы и для меня дальнейшие рассуждения о превратностях микросервисов уже более чем странные. Примерно как если бы кто-то написал:… и вот мы решили отправить рыбу лазить по деревьям…
А вот насчет моего примера — никакая наичистейшая архитектура мне всё равно не помогла бы — разве только в той части, где я написал о «созданные им зависимости проникли в код монолита» — но это действительно не проблема монолитности, а та самая — недостаточно чисто написано. В остальном же — и в главном — мне всё равно пришлось обновлять этот потенциальный микросервис из-за того, что обновляется сама платформа, на которой построен монолит — фреймворк. Будь у меня независимый сервис — он мог бы продолжать функционировать без изменений, несмотря на обновление других частей конгломерата сервисов, которая образовывает систему.
Кстати заметить, «Чистая архитектура» — это та же проблема, что и «Чистые микросервисы» в разработке — она требует продумывания архитектуры. А до этого тоже придется дорасти. И разработчики пишут не совсем чистые монолиты отнюдь не только потому, что не умеют писать чисто, а потому, что как раз на старте еще очень и очень многого не видно, не понятно и неясно как будет — это задним умом мы все сильны.
Вот мне довелось обновляться — и я ВЫНУЖДЕН в монолите обновлять или всё или ничего.
И то же с масштабированием — при масштабировании микросервисного конгломерата я могу масштабировать именно тот функционал, который требует масштабирования, при монолите — допинстансы поднимаются целиком, хотя вполне возможно, что производительность проседает в отдельном модуле. То же самое — с резервированием.
Никто не говорит, что микросервисы — лучшее решение во всех случаях, или что оно «бесплатное», но и появилось оно не на ровном месте, от скуки.
Вообще же — thecoder тут в нескольких постах пояснил, что работа с транзакциями — это последнее, что надо реализовывать как микросервисы, только в случае, когда уж другого выхода нет. Признак потенциального микросервиса — это насколько все плохо будет для системы в целом, если сервис откажет. Если система переживет временную потерю сервиса приемлемо — его можно вынести, а если это чревато большими проблемами — сто раз подумайте, прежде чем этот модуль отторгать.
И мне сдается, что весь негатив к микросервисной архитектуре как раз оттого, что люди не думают что творят, когда начинают выносить в микросервисы тесно связанные модули — но здесь злой Буратино не микросервисная архитектура, а сам архитектор.
Разумеется, это не про те «микросервисы», которые на самом деле уже и не «микро», а полноценные приложения, к которым обращается масса других приложений за какими-то данными.
Вообще же, надо просто понять — откуда есть пошли эти микросервисы. Они ведь появились не только лишь потому, что кому-то вздумалось «поиграть в микросервисы». Микросервисы — это логичный ответ на конкретные задачи. Я выше тут писал про свой пример — у меня есть в проекте задача обслуживания клиента, и есть задача периодического мониторинга неких данных, которые я предоставляю клиенту. Можно обе задачи решать в рамках одного монолитного приложения, но так же хорошо эти две задачи могут работать и по отдельности. У меня нет сильной связанности между двумя этими задачами: то есть сбор (обновление) данных конечно нужен, но если он не увенчался успехом в очередной итерации — клиенту допустимо предоставить на его запрос предыдущие данные. Другая особенность состоит в том, что сбор данных может меняться довольно часто из-за того, что сам источник этих данных изменяется и под него надо подстраиваться — в условиях монолита это будет означать необходимость править весь проект, прерывать обслуживание клиентов при апдейте проекта. А в условиях микросервиса — я могу править сервис более удобнее. Я могу вынести микросервис сбора данных куда угодно — это, кстати, тоже одна из задач проекта, так как наш доблестный РКН любит поиграть в модераторов. Я могу наплодить кучу одинаковых микросервисов, тем самым зарезервировав их, я могу относительно легко добавлять микросервисы с другим типом собираемых данных — конечно же тут придется и принимающую часть изменять для того, чтобы она умела эти данные принять, но вся инфраструктура уже построена — нужны лишь кастомны методы приема и обработки конкретного типа данных.
Я не являюсь ни теоретически подкованным в микросервисах, ни обладателем обширного практического опыта их применения, ни даже их почитателем — я использую то, что разумно в поставленной задаче.
Поэтому я бы не скидывал и ядерный взрыв как фактор в таком уж случае.
Отторгнуть такие квазимикросервисы из монолита вовне не составит проблемы, но есть ли в этом смысл — это зависит от контекста задачи. При отторжении мы естественно получаем необходимость выстраивания взаимодействия с «потребителями», ранее решаемое платформой, на которой крутится монолит, а как бонус — получаем возможность вынести сервис на другие серверные мощности, возможность использования сервиса другими приложениями и определенную свободу по изменению внутренних механизмов сервиса, не оказывающих влияния на интерфейс взаимодействия, а так же возможности более легкого масштабирования и резервирования сервиса.
Второе же заключается в том, что используя graphql необходимо и мыслить в концепции graphql, попытки же сделать «как в REST, только GraphQL» к хорошему явно не приведут, что, в общем-то, справедливо для любой технологии.
А кроме шуток, и говоря о заметке уровнем выше про опыт с микросервисами — я полагаю, что надо еще и осторожнее быть со связями между сервисами, то есть в идеале один сервис связан не более чем с двумя другими сервисами, обеспечивая иерархическое дерево, иначе геморрой при изменениях начинает расти экспоненциально как функция от количества связей на сервис. С одной стороны такое ограничение вроде как и противоречит концепции широкого переиспользования, с другой — это продиктовано соображениями локализации и сдерживания сложности. Если в такой ограниченной микросервисной архитектуре возникает необходимость изменений какого-либо сервиса, то это хотя бы не порождает слишком много изменений, а те, что неизбежны — по-крайней мере распространяются в известном направлении — вдоль своей ветви. Но это так — интуитивные соображения безопасности, реального опыта эксплуатации пока мало.
Накладными расходами тут являются поддержание интерфейсов между сервисами — как в архитектурном плане (согласованность форматов), так и в физическом (доступность сети), и, конечно, мониторинг. Изначально я хотел вообще сделать основной сервис с функциями контроля над добытчиками, но лимит времени на разработку не позволил чрезмерно углубляться, будет развитие проекта — вот тогда и можно будет дальше эту тему развить.
Статья же — однобокая, но она так и задумана, наверное. Ведь действительно лучше сделать работающее приложение, которое еще сто раз поменяется, чем стараться изначально все эти сто предстоящих изменений предусмотреть — и, конечно, все равно ошибиться, ибо всего не учтешь. Но то, что изначально хорошо можно вынести в отдельный сервис — почему бы и не вынести, если есть время и ясное понимание и обоснование преимуществ такого решения.
И, вообще — есть в этом всём что-то такое… Novell Netware, OS/2… деревья раньше были не только большими, но и разными: ) И это было прекрасно.
И еще справедливости ради надо таки сказать, что как без повара нет ресторана, так нет его и без хорошего администратора, официантов, дяди Васи, отвечающего за закуп продуктов, даже без — прости господи — без маркетолога, который этот ресторан пропиарит хорошо и поэтому будет спрос на него… Так что это всё же общий труд и в нём нет главных. Правда высокие менеджеры порой стараются убедить всех своих сотрудников в обратном — так ими легче управлять.
Впрочем, я не настаиваю на обсуждении. Если же вы не против — с интересом познакомлюсь с вашим взглядом на командную работу. Я всегда рад ознакомиться с иной точкой зрения.
Если вы такая продвинутая компания, то я бы порекомендовал вам к действительности и обратиться — да вот хотя бы провести ненавязчивый опрос среди своих же сотрудников — что дают им эти ваши контролирующие рамки? Тот же Гугл с его квазианархией — по крайней мере как это преподносится — про возможность работы над своими проектами «в рабочее время», про возможность работать как удобнее и прочие плюшки — вы думаете они там просто зажрались? А я полагаю, что там умные люди просто воспользовались старым добрым тезисом: «Если не можешь прекратить безобразие — возглавь его.» И поимели профит с этого вместо затрат на контроль.
А ваша позиция уже становится чисто защитной — типа возражающий вам просто неправильный (согласно вашим правильным правилам). Ясен пень, что навязываться вам никто не навязывается и не переубеждает — мы лишь говорим о ДЕЙСТВИТЕЛЬНОСТИ, как оно на самом деле происходит, и что можно эту действительность обратить себе на пользу, а не пытаться с невеликим успехом подогнать под свои представления о правильном.
Работал в команде и очень хорошо себя чувствовал — там да, мог погружаться и на более продолжительное время. Сейчас — нарабатываю опыт, и пока вся свистопляска с ролями при всех неудобствах, в целом — хороший и ценный опыт. Поднаторею — начну искать более специализированных рамок деятельности.
Уже есть мечтания, как я такой клёвый в клёвой команде, где каждый своим занят, где тесты покрывают всё, ревью кода проводят, устраивается внутренний обмен знаний на постоянной основе между сотрудниками, сеньоры доброжелательны и мегакомпетентны и т.д.: )))