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