Сучасна диджитал-освіта для дітей — безоплатне заняття в GoITeens ×
Mazda CX 5
×

Що нового у світі мікросервісів. Думка System Architect

Мене звати Олег Касьян, я співпрацюю з ЕРАМ Україна у ролі System Architect. У цій статті поговоримо про мікросервіси.

Мікросервісна архітектура пройшла свій шлях становлення від перших згадок в середині 2000-х до найбільш популярної зараз реалізації сервісно-орієнтованої архітектури. Але навіть тепер деякі джерела відзначають, що єдиного визначення мікросервісів не існує. У цій статті я буду використовувати визначення, що дає автор відомої «Microservices Patterns» Кріс Річардсон.

Отже, за Крісом Річардсоном, мікросервіси, також відомі як «Мікросервісна архітектура», — це архітектурний стиль, що визначає структуру додатка як колекцію сервісів, які:

  • легко підтримувати та тестувати;
  • слабко зчеплені;
  • можна розгортати незалежно один від одного;
  • організовані навколо можливостей та вимог бізнесу;
  • розробляються та підтримуються однією командою.

Дуже багато вже сказано про мікросервіси, і я не бачу необхідності повторюватись, тому в цій статті я говоритиму про відносно нові тренди. Тим, хто бажає дізнатись більше про те, що таке мікросервіси і як використовувати їх на практиці, я рекомендую ознайомитись з «Microservice Architecture» та гайдом від CNCF.

Наскільки «мікро» мають бути мікросервіси

Однією з найбільших тем для суперечок у світі мікросервісів є їхній розмір, а саме кількість функціонала, який закладено в такий сервіс. Розгляньмо декілька питань:

  • Чи може сервіс виконувати декілька функцій, що відносяться до однієї бізнес-вимоги?
  • Чи має сервіс одночасно вміти писати та читати дані?

Відповіді на ці питання можуть бути різними в залежності від вимог. Для прикладу візьмемо REST API для роботи з даними користувача (User Service), що має наступні інтерфейси:

POST /signin

Перевірка логіну / паролю в Active Directory

POST /signup

Створення нового запису про юзера в Active Directory

GET /profile

Дані юзера з Active Directory

PUT /profile

Оновлення даних користувача

Традиційний підхід

Оскільки всі функції базуються навколо однієї бізнес-вимоги, має сенс створити один сервіс, що буде обробляти всі запити.

Контекстний вид для User Service

Як ми бачимо, доступність цього сервісу залежить від Active Directory. У випадках, коли маємо робити транзакційні зміни (оновлення даних в AD), уникнути цього можна лише відсутністю транзакційності.

З іншого боку, /profile не є транзакційним і його можна зробити слабко зчепленим з AD, використовуючи, наприклад, CQRS або Event Sourcing.

Приклад реалізації User Service з додатковою Read Replica

Nanoservices

Наносервіси (nanoservices) — це не зовсім нова ідея, а скоріше генералізація такого підходу як FaaS (function as a service). Якщо FaaS, виходячи з назви, це про те, як запускати окремі функції, не маючи необхідності налаштовувати інфраструктуру, то наносервіси — це архітектурний стиль, в якому кожна функція є окремим сервісом.

Розглядаючи попередній приклад з User Service, кожен API може бути окремим сервісом:

Наносервіси — кожний сервіс — це окрема функція

Основні переваги такого підходу:

  • Scalability — кожну функцію можна масштабувати окремо від інших.
  • Простий feature toggle — кожну функцію можна контролювати окремо від інших.
  • Незалежна розробка — кожну функцію можна розробляти та розгортати окремо, що також зменшує ефект від помилок.

Недоліки:

  • Складність розгортання — кількість таких сервісів значно більша, ніж звичайних мікросервісів, також вони можуть розроблятись різними командами, що ускладнює процес.
  • Використання ресурсів — у випадку використання FaaS-платформ це не є проблемою, у разі kubernetes / managed containers або інших PaaS-платформ буде більшим порівняно з традиційним підходом.
  • Пошук помилок — може ускладнюватись, оскільки такі сервіси створюють складні ланцюжки залежностей.

API Gateway та мікросервіси

Останнім часом дуже популярною є тема використання API Gateway разом з мікросервісами. Серед іншого також дуже добре прослідковується вплив інших патернів зі світу мікросервісів.

API Gateway дає нам можливість універсального доступу до мікросервісів без необхідності знати про їхню реалізацію. Це такий собі фасад для використання нашої системи кінцевими користувачами, наприклад фронтендом або мобільним додатком.

Edge API Gateways і використання разом з Service Mesh

Дуже цікавою є ідея використання API Gateway разом з Service Mesh, такими як istio, linkerd, consul. Як приклад, можна подивитись на такі продукти як Gloo Edge або Ambassador Edge Stack. В цьому прикладі найцікавішим є те, що сам API Gateway фактично є лише сервісом, що контролює, і задача якого — оновлювати конфігурацію Service Mesh.

Реалізація Edge Gateway на прикладі GlooEdge, з сайту docs.solo.io

Перевагами такого підходу є:

  • Просте налаштування, орієнтоване саме на можливості API Gateway (порівняно з тим самим istio або linkerd).
  • Висока продуктивність, безпосередньо сам сервіс надається Service Mesh, який націлений на продуктивність.

Основним недоліком є орієнтованість на одну платформу, ті самі Gloo та Ambassador можна використовувати лише з Kubernetes.

Microgateways

Більшість традиційних API Gateway — це моноліти, та не дуже добре масштабуються через необхідність контролювати та зберігати власний стан. Ідеєю такого підходу як microgateway є створення мікросервісів, що будуть використовуватись як API Gateway. Конфігурація компілюється разом з артефактом і є незмінною, що дозволяє горизонтально масштабувати такий сервіс. Прикладом реалізації є WSO2 Microgateway.

Приклад реалізації Microgateway з сайту wso2.com

Переваги:

— Можливість горизонтального масштабування.

— Стабільність за рахунок відсутності керування станом, та зовнішніх залежностей.

Недоліки:

  • Необхідність змінювати код та розгортати нову версію для внесення змін (можна також розглядати як перевагу, адже це більш прозорий і контрольований процес).
  • Відсутність центрального дашборду / порталу.

Мікросервіси + фронтенд = Мікрофронтенд?

Такий термін як мікрофротенд взагалі не дуже новий, але останнім часом швидко набирає популярності. Сучасний тренд для фронтенду — це SPA (Single Page Application), написані на React / Angular або схожих фреймворках. Така аплікація, найчастіше написана однією командою, з часом збільшується, стає все складнішою та повільною в розробці й згодом перетворюється у «Фронтенд Моноліт».

Ідея «мікрофронтенду» полягає саме в тому, щоб перетворити такий моноліт на декілька окремих вебаплікацій, розділяючи їх за бізнес-функціями та набором можливостей, відкриваючи таким чином можливості їх незалежно розробляти.

Приклад реалізації мікрофронтенду з сайту aws.amazon.com

Такий підхід буде мати всі недоліки та переваги мікросервісної архітектури.

Event Mesh

Event Mesh — це відносно новий патерн у світі мікросервісів. Основна його ідея в тому, щоб створити універсальний та динамічний шар інфраструктури, що дозволяє легко доставляти події (events) між брокерами, абстрагуючи при цьому деталі самих брокерів, їхнє розташування та протоколи.

Приклад реалізації Event Mesh з сайту eventmesh.apache.org

Основна ідея та властивості повторюють Service Mesh, який у світі мікросервісів не є чимось новим і навряд потребує багато пояснень. Коротко: Service Mesh — це шар інфраструктури, що контролює комунікацію між сервісами в мережі, при цьому деталі розташування самих сервісів приховані.

Event Mesh надає такі можливості:

  • Service discovery — дозволяє комунікацію з сервісом, не знаючи його деталей, при цьому, на відміну від стандартних Message Queue, можлива peer-to-peer комунікація.
  • Load balancing — балансування подій між декількома екземплярами сервісу.
  • Шифрування.
  • Авторизація та аутентифікація.
  • Protocol agnostic — протокол комунікації та фреймворк/мова програмування не має значення.
  • Телеметрія.

Завдяки своїм можливостям Event Mesh дозволяє встановлювати комунікацію між різними типами систем без необхідності змінювати код самих систем. Прикладами реалізації Event Mesh є Solace, Apache Event Mesh, SAP Event Mesh.

Підсумовуючи

Зауважу, що світ мікросервісів активно розвивається, постійно з’являються нові ідеї, а на наявні ми дивимося по-новому. Мікросервісна архітектура ще має чим здивувати, і сподіваюсь, так буде і надалі.

А яка ваша думка? Чи є майбутнє у мікросервісів або на зміну їм має прийти щось нове? Які нові тренди ви спостерігаєте у світі мікросервісів? Пишіть у коментарях.

👍ПодобаєтьсяСподобалось19
До обраногоВ обраному15
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

мда, я бачу індустрія складається з адекватних програмістів, які використовують базову логіку і загальновідомі принципи при структуруванні систем. І є купка лінивих мудаків, які ніхера толком не роблять, лише вигадують понтові назви, так щоб очевидне видавати як «геніальний винахід», строчать книги, статті по суті ні про що.
Service Mesh це походу messaging натягнутий на зоопарк API, як і все інше ново-модне гівно і базвордс — просто різні комбінації на якій межі і в якому місці узагальнювати чи ні архітектуру.
Дякую за статтю, корисно бачити короткий огляд того, що зараз відбувається. але «нових ідей» поки що не спостерігається, винайти колесо іншого кольору, або прикрутити його до чогось, що має їхати — це не нові ідеї.

О, знайшов однодумця. Прошу рев’ю циклу статей dou.ua/forums/topic/36197 де порівнюються старі та нові назви архітектур.

Спасибо, интересная статья.

Понаписывают микросервисов и уволятся, а ты потом сиди поддерживай и переписывай на монолит чтобы работало

Таке враження що деякі працівники вивчили як моноліт написати 3 шаровий як були трейні, так і не збираються далі розширювати свої уявлення про інші архітектури.

Потому что 3-слойный, а чаще желательно даже 2-слойный монолит покрывает множество 95% существующих проектов.

той хто підтримує має недостатню кваліфікацію?

на аутсорсе таких не бывает, пушто заказчик пытается сэкономить копейку и его задачи решают 23-летние сеньёры з горящими глазами и шилом в дупе
а квалифицированные с потухшими глазами играют в другой лиге

Якщо у тебе є купа мікросервісів — то зліпити з них моноліт не важко. З простого завжди можна зробити складне. Бо ти розумієш як працює кожна проста складова.
Набагато важче розібрати монолит на прості частини. Бо ти не можеш навіть запам’ятати усе, що той монолит робить і тим паче зрозуміти яка частина за що відповідає.

Якщо мікросервіси різними мовами, або з різними non-functional requirements — фіг їх зліпиш.
До речі, отут цікавинка: federated services, коли в рантаймі декілька мікросервісів збираються докупи в один бокс trmidboe.medium.com/...​icroservices-4fc0cf3df5a6

А ви думали про таке: для того, щоб системі перейти від стану А до стану Б якомусь спостерігачу потрібно зробити якійсь вибір? Якщо стан А це один момент часу, а стан Б другий момент часу, то саме функція спостерігача переводить стрілки цього годинника. Мені здається, що архитекторам систем важливо таке розуміти.

В квантовой физике это называется эффект наблюдателя. Вселенная ленива и делает функциональную развертку многомерного пространства на произвольную глубину только в той точке пространства, где есть наблюдатель.

Здавалося б, після мікросервісів нічого більш дичавого вже не зробить. Ан ніт, придумало нано, блять, сервіси.

Здавалося б, після нано... ах да блять, деплоїмо функції.

Далі підем деплоїть окремі класси, далі юнітом деплоя стануть змінні.
І все будуть знаходитись архітектори, які будуть щось казати таке ніби вумне, про те що як заібісь і ваще якщо ваш сраний
int counter;
не є окремим контейнеризованим Amszon Deployable Variables, обмазаним 5-6 ямлами, то ви лох і джун.

Далі підем деплоїть окремі класси, далі юнітом деплоя стануть змінні.
І все будуть знаходитись архітектори, які будуть щось казати таке ніби вумне, про те що як заібісь і ваще якщо ваш сраний
int counter;
не є окремим контейнеризованим Amszon Deployable Variables, обмазаним 5-6 ямлами, то ви лох і джун.

Вообще-то это правильный функциональный матаппарат, как можно больше гранулировать вычислительные возможности для их масштабирования. Другой вопрос, что все это нужно глубоко прятать под капот, да так, чтобы разработчик даже об этом не подозревал. Примерно как он не подозревает о блоке предсказаний в процессоре и не подозревает о тысячах потоках куды и вообще о всем том адовом математическом волшебстве которое там творится.

після мікросервісів нічого більш дичавого вже не зробить. Ан ніт, придумало нано, блять, сервіси

А далі будуть пікосервіси і фемтосервіси :D

пікосервіси і фемтосервіси

Все зависит от того, как это подано разработчику.
Например тот же Эксель, это яркий пример считай пикосервисов (ячеек), каждая из которых представлена уникальной формулой над сетом данных. И все они взаимодействуют между собой в реактивном стиле. Вся эта работа сложностей не вызывает, даже у детей.

Когда архитекторы, натуральные вредители, пытаются рассказать что обвязку каждого нано\пикосервиса должен писать девелопер сам лично. А потом еще в голове просчитывать все зависимости между ними, заботится о консистентности и получения\обработки пакетов — они натуральные душнилы, взявшие за основу великолепные идеи и максимально их испоганив своими потными рученками.

Ну блін, ну таке відчуття що ти робиш вигляд що не розумієщ про що мова.
Пікосервіси в екселі — це якщо кожна б ячейка хостилось в окремому докері невідомо на якій машині, і щоб обрахувати формулу — треба б було робити запити через мережу в кожну ячейку на отримання або апдейт даних. А навколо всього цього обвязувати все що відноситься до мікросервісів — полісі ретраів і сьоркетбрейкерів, дуплікати сервісів, лоад балансери, асинхронну коммунікацію, eventual consistency, і т.д.

Ну блін, ну таке відчуття що ти робиш вигляд що не розумієщ про що мова.
Пікосервіси в екселі — це якщо кожна б ячейка хостилось в окремому докері невідомо на якій машині, і щоб обрахувати формулу — треба б було робити запити через мережу в кожну ячейку на отримання або апдейт даних. А навколо всього цього обвязувати все що відноситься до мікросервісів — полісі ретраів, дуплікати, лоад балансери, асинхронну коммунікацію, eventual consistency, і т.д.

Смотри, я тебе сейчас буду обьяснять как ребенку, чтобы ты понял.
Левая рука, это представление. Это тот самый Excel sheet. Правая рука, это то, как это устроено на самом деле под капотом. Обе эти руки не взаимосвязаны между собой прямой связью. Точней то как они взаимосвязаны решает вычислитель. Если вычислитель на основе своей статистики, на основе данных и на основе своей нагрузки решает, что эти охулиард формул в ячейках должни быть вычислены на другой машине, в докерах, шмокерах, пускай вычисляет если ему так хочется. Если он опрееделяет что изменив эту ячейку, нужно теперь пересчитаеть второй охулиард ячеек, пускай это делает. Но левая рука ничего не должна об этом знать. Более того, не существует эффективных способов передать эту работу правой руки девелоперам. Девелоперам прийдется писать очень мощный реактивный вычислитель. А они этого делать не умеют и не должни уметь. Если они попробуют, они получат травму, такую как Димка Бугай. Он вон уже стонет от микросервисов, наносервисы вгонят его на кассы в Макдональдс. Мы не может быть настолько жестоки к девелоперам ! Девелоперам нужен Эксель !

Смотри, я тебе сейчас буду обьяснять как ребенку, чтобы ты понял.

Ох ти ж і Бубнотоксік :)

Справа в тому, що в данній аналогії девелопери пишуть не формули, а сам ексель. Є багато різніх фреймворків для того щоб трохи упростити життя девелоперу типу learn.microsoft.com/...​s/dotnet/orleans/overview
Але ще жоден з них не став стандартом в індустрії, для того щоб абстрагувати всю обвязку розподілених сервісів. Це питання розвитку саме технологій. Тому поки що зачасту в кожній команді самі вирішують які стороні продукти і які бібліотеки обвязувати навколо своїх рішень для вирішення всіх проблем побудови мікросервісної архитектури.

Справа в тому, що в данній аналогії девелопери пишуть не формули, а сам ексель

Если еще помнишь, в 90х все конторы повально писали свои обьектные базы данных.
И один умный мужик выдал такую фразу. Любая такая поделка обьектной базы данных, доведенная до нагруженого прода, содержит примерно 80% функциональности обычной реляционной СУБД, с асид, сабсетом языка запросов, оптимизатором запросов и тд ..
Пришли на рынок плотно реляционки и все забыли что такое велосипедировать субд в большинстве (но не всех) проектах.

Я это к чему. Сейчас микросервисы это теже обьектные субд в 2022 году. Все костыляют свои костыли, но прийдет время и каждый первый девелопер не сможет внятно обьяснить на собеседовании, что такое микро\нано сервисы, также как не расскажет тебе как работает блок предсказаний в процессоре, или оптимизатор запросов на декларативный sql, потому что он его никогда не программировал и только знаком что такое есть в общих чертах.

И это не будут душные акторные орлеансы кубернитисы кафки и прочьи бады.
А Димки и всякие Лысаки сидят тихонько, они знают что его величество Эксель приближается. И их знания по кафке скоро будут ценится не более чем, как правильно обжаривать котлетку для гамбургера или курочку в кфс.

А Димки и всякие Лысаки сидят тихонько, они знают что его величество Эксель приближается. И их знания по кафке скоро будут ценится не более чем, как правильно обжаривать котлетку для гамбургера или курочку в кфс.

Якщо більше 15 років роботи в індустріі мене і навчили, так це те що будь який розвиток технології і скривання під-капотом складності не зменьшують роботу для программістів, а тільки збільшують.
А також те, що толковий програміст все одно повинен хоча б загальних рисах розуміти як воно під тим капотом влаштовано, які задачі воно вирішує, які є технологічні особливості і обмеження. Щоб не наламати дров в якомусь ORM типу EntityFramework треба розуміти і тонкості роботи SQL і тонкості роботи самого EF.

Якщо більше 15 років роботи в індустріі мене і навчили, так це те що будь який розвиток технології і скривання під-капотом складності не зменьшують роботу для программістів, а тільки збільшують.

У бизнесса есть задачи, он их решает.
80% задач решает на Эксель, остальные в разработку. Если бизнесс сможет решать еще 15% своих дорогостоящих задач на таком же условном Экскель, он будет только рад. А всякие зубрилки, которые хотят заниматься задротством ради задротства, должни будут или переучится или оказаться за бортом. И там решать кроссворды, раз им сложности в жизни не хватает. Шансы месить легаси тоже не так высоки, поскольку какое легаси если новое в сто раз лучше.
Грядут технологии которые полностью переворачивают понимание как можно создавать ПО, а главное с какой скоростью надежностью гибкостью и качеством.

Мені здається це травма довгих років роботи в аутсорсі, куди скидають неприоритетні задачі, від бізнеса типу металопроката, якому потрібен софт для Лідії Семеновни із відділу продажів. Якщо софт і є бізнес, то в екселі він не робиться, і гроші заробляються саме з софту.

Мені здається це травма довгих років роботи в аутсорсі, куди скидають неприоритетні задачі,

Эйнштейн проработал большую часть жизни в патентном бюро, перекладывая бумажки, Цой написал свои лучшие хиты, подбрасывая уголек в котельной. Перельман просто нигде не работал.
А ты где думал пишутся лучшие проекты ?
Главное чтобы никто не мешал своим шаблонным мышлением.

Якщо софт і є бізнес, то в екселі він не робиться, і гроші заробляються саме з софту.

Ты не поверишь. Все что имеет какое то подобие СУБД, потоков данных между узлами и какоето представление для пользователя на юай (хоть последнее и не правило) робиться в Ексель.

Але ще жоден з них не став стандартом в індустрії

Зараз він тобі розповість, що саме бубенДБ стане таким стандартом, бо вміє ваще все. З ним ваще ІТ не потрібно, просто встанови, введи номер рахунку, введи «хочу свій бізнес», і бубенДБ сам все зробить.

Ты знал !
Я тебе только что видосик записал. Пример приложения, которое содержит 9 разделов. По функциональности это джира, процентов 30% апворка, микрософт тимс, блогосфера, портал для обучения и экзаменации студентов, чаты, лайки, комментарии и тд. А да ,чуть не забыл. Приложение шатает секьюрити на несколько ролей, шифрование, нотификации всех обо всем что происходит в системе, а также разделение юай на проекты и тимы, при котором ты видишь только то, в чем участвуешь. Также приложение содержит интерфейсы для своего встроенного клауда по типу азюр, но с более скромным функционалом
Также приложение локализировано на 6 языков (русс,укр,немецкий,французкий, англ,испанский)
и содержит четыре темы (дарк вайт и еще несколько). Общая мощность проекта не менее 200 таблиц в субд и содержит больше сотни скринов.

youtu.be/N1DU2n21yXY

А теперь вишенка на тортик. Отклик этого ыНтЫрПрАйз не более чем 50-100 миллисекунд на любой (я подчеркиваю, любой) скрин в приложении.

И сейчас у Димки вообще начнется паника _всё_, я подчеркиваю ___всё___ приложение написано в 2300 строк копипасты + «днипро ди би». И могло быть написано за пару недель, с отладкой.

Подумай над этим на досуге, когда будешь смотреть на свой туду лист на кафке который обвешен прогрессбарами как с*чка блох.

=)

Ах ти ж мій невизнаний геній.
Візьми таблєточку.

Да, ты там в прошлом топике еще чтото задвигал про BPM, так вот, в рамках тестировании концепции я написал (и отладил) старую добрую игру
Любовь с первого взгляда. Не обращайте внимание на название, интересно то что она по сути моделирует не просто типичные приложение из кучи форм перемешанных с валидацией секурити локализацией и другое, а моделирует сервер с достаточно сложным флоу, который уже не так легко ложится на документоориентированные концепции.

Суть игры, сервер на игру собирает 3 девушки (но не менее 1й) и 3 парня (но не менее 1). Далее парни задают по три вопроса к девушкам, а девушки задают по три вопроса к парням. Парни отвечают на вопросы девушек. Девушки отвечают на вопросы парней. Далее участники видят ответы друг друга и на следующем этапе происходит тайное голосование, где есть возможность выбрать только одного партнера из 3х и если матч совпал то система показывает контакты и дает возможность паре поообщатся. Также игра содержит кучу нюансов, сервер обрабатывает разные таймауты, типа а что произойдет если участник отвалится по среди игры. А что если сервер (быстро) ушел в перезагрузку. А что если набежало сразу тысячу игроков. А что если участник не захочет отвечать на вопрос и другие неприятные ситуации из флоу.
Как ты понимаешь, на концепции этой игры, где игроки взаимодействуют друг с другом по сложным флоу, ложится любая карточная, да и вообще многопользовательская игра.

И да .... вся игра это 330 строк тривиального кода и была неспешно написана за 2 дня. 1 день на разработку, 1 день на отладку (всетаки там гемор для тестирования моделировать сразу трех девушек и трех парней в шести открытых окнах браузера). Но в целом, при определенной сноровке, справился бы даже ребенок.

Теперь я хочу услышать сколько написание подобных игр занимает во всяких шарагах типа Париматч ...

та я взагалі не розумію чого на цього «городского сумашедшего» реагують. давно в бан відправив, і тільки дивуюсь що досвідчені ДОУчани пробують щось відповідати :)
коли випливає у цитатах — ох матінка... унікальність є, але сам зміст — з паралельного всесвіту.

та я взагалі не розумію чого на цього «городского сумашедшего» реагують. давно в бан відправив, і тільки дивуюсь що досвідчені ДОУчани пробують щось відповідати :)
коли випливає у цитатах — ох матінка... унікальність є, але сам зміст — з паралельного всесвіту.

Поэтому пожилых архитекторов я считаю самым бесперспективным направлением для обучения. Проще детей 10 лет обучить правильно писать программы, чем эту архаичную смесь из кобола и пэхапэ. Правда некоторые из них могли в молодости на Лисп начинать, но разве ж они начинали ...

Використовуємо лямбди і це чудова штука, але малось на увазі розділення заради розділення)

А далі піде мода на AI і все, що деви будуть робити — писати датасети для тестів... І плюватися на то, що знов корнер кейс пропустили...

Іноді коли бачу що з’являється ідея дроблення мікросервісів на мілі/нано/etc одразу думка — десь там і з точки зору деплойменту/експлуатації є ускладнення. І по факту потім замість умовних 5 людей треба вже 10-15 щоб то всьо девелопати-підтримувати.

Потом компанию продают Илону Маску. Он увольняет половину людей и гасит ненужные микросервисы. А потом пользователи не могут зайти в Твиттер, потому что у них MFA а микросервис обеспечивающий MFA — погашен.

ну а хіба кубернитис манифест не є саме тим про що ви кажете?
взагалі до появи всяких докерів і клаудів розгорнутнити якийсь типовий на сьогодняшній день кубернитис кластер — це був такий собі проект для всієї infrastructure team десь так на декілька місяців.

кубернитис

технологии ради технологии

Якщо запитаю які альтернативи знову відповіси щось із теології? Чи запропонуєш всі веб продукти створювати через дніпроДБ і Бубен.ком?

Якщо запитаю які альтернативи знову відповіси щось із теології? Чи запропонуєш всі веб продукти створювати через дніпроДБ і Бубен.ком?

Не будь так катигоричен. Даже в литературе есть две категории, критики и писатели.
Хороший критик, это тоже работа, хоть и не пишет книг лучше Шекспира.
Не будь нас, писатели всякого дерьмища бесконечно купались бы в лучах славы.
Задача синхронизации она какбе сложная и мгогогранная.
И не должна сводится к полуручному зоопарку из пуляния пакетиков через шину данных.

Очень крутая статья, спасибо!

Мене останні роки не залишає думка що в ІТ ідеї ідуть циклами десь у 10 років. Тобто якщо 20 років назад вигадали COM, то через 10 років SOA, а зараз от Microservice. Кожен раз винаходять нову інкарнацію велосипеда — рішаючи ту саму задачу декомпозиції.
Чому? Я гадаю справа в тому, що ІТ — професія для молодих. Їм не дуже цікаво читати про те, що придумали 20 років назад — вони краще вигадають своє «нове». Через 10 років вони вже стануть менеджерами чи архітектами, тобто більшість вже підуть далеко від кодінгу — і нові молоді девелопери прийдуть по-новому вигадувати «велосипеди».
Якщо б кожен, хто приходить до ІТ обов’язково вивчав і розумів ООП і SOLID принципи — то не було б взагалі ніякої Microservice Architecture чи Micro-frontend.
Бо ООП з самого початку вигадали аби вирішити головну проблему програмування — проблему складності! Людина не в змозі одночасно умістити у своєму розумі багато речей (у середньому — не більше 10). Це означає що:
1) Якщо людина бачить «чорний ящик», який одночасно виконує більше 10 функцій — то їй дуже складно уявити як це усе працює.
2) Якщо відкрити «білий ящик» і показати складний механізм з більше 10 деталей — людина також заплутається як це працює.
Єдина можливість для людини вирішити складну задачу — це декомпозиція. Тобто треба розділити щось складне на декілька речей, кількістю не більше 10 і уявити як вони взаємодіють. Потім кожну з речей знов розділити і так далі.
Ось людина — дуже складне істота: але складається з: 1 — голова, 2 — тулуб, 3 — руки, 4 — ноги. Легко зрозуміти що для чого, легко запам’ятати, важко переплутати. Ну а далі там є усякі органи (1 — кістки, 2 — м’язи, 3 — шкіра, 4 — судини і т.і. ), а вони всередині теж з різних частин і так далі.
Повертаючись до ООП і SOLID — за ними кожен об’єкт має мати чіткий інтерфейс, має мати тільки одну ціль існування, має буті НЕЗМІННИМ у майбутньому. І він перевіряється юніт-тестами. Тобто є тою самою «цеглинкою», з якою будуються більші абстракції. Він одночасно втілює і COMponent, і Service (SOA), i модуль, і мікро-сервіс, і навіть serverless (якщо вважати що функція — це також об`єкт).
Якщо грамотно писати ООП код: робити декомпозицію, слабку зв’язність, агрегацію та інкапсуляцію то різниця між монолитом чи «нано-сервісами» буде виключно у тому, де будуть мешкати класи і як комунікувати: чи буде це один процес на одному комп’ютері, чи кожен клас буде мешкати у окремому процесі, у своєму контейнері (мікро-сервіси), чи взагалі як окрема функція (serverless) у клауді.

Бо ООП з самого початку вигадали аби вирішити головну проблему програмування — проблему складності!

ООП как и Микросервисы это величайшая катастрофа для современного программирования.
По крайней мере для 80% прикладных проектов.

Ось людина — дуже складне істота: але складається з: 1 — голова, 2 — тулуб, 3 — руки, 4 — ноги. Легко зрозуміти що для чого, легко запам’ятати, важко переплутати. Ну а далі там є усякі органи (1 — кістки, 2 — м’язи, 3 — шкіра, 4 — судини і т.і. ), а вони всередині теж з різних частин і так далі.

Ну хороший пример. Человеческий организм это не набор черных ящиков. Ближайшая аналогия ООП это автомобиль под подьездом, с инкапсуляцией под капотом и всякой заменой магнитол и свечек зажигания в виде полиморфизма. Человееский организм разворачивается из ДНК. Всего 10%-20% генома может говорить произойдет функциональная развертка кода в Орла, Червяка, Слона или Человека. Всратые черные ящики ООП так не умеют. Вкорячили карбюраторный 1.6 под капот жигули, так он с ним и проживет скорей всего всю жизнь. Как только заказчик захочет сделать из жигули хотябы кабриолет, так и прийдется болгаркой резать несчастное жигули, а то что получилось выдать за кабриолет. И SOLID тут не более чем маркетинговая припарка на заводе АВТОВАЗ с прицелом из жигули сделать ладу гранту в далеком будущем. Или хотябы деребанить ее по запчастям, ну там чтобы в фаре не было прошивки из фазораспределителя двигателя с привязкой к модели радиатора. Самое смешное, что ООП какбе даже неплохо работает в физическом мире что вижу то пою, ввиду естественных ограничений на модификации. Ну приборостроение там разное с их чугунием в формочках и разьемами между ними. Но мир ПО, он какбе немного шире. В этом дивном мире заказчику может потребоваться чтобы мощность жигули внезапно возрасла в тысячу раз, или на утро каждая наклейка на каждом болте была переведена на десять языков, а руль ты вообще не должен видеть если у тебя бензобак пустой. И тут выясняется что тут ООП дно донное, а микросервисы это неплохой способ это днище утопить в дефиците бюджета и сроках еще на этапе чертежа.

Эх, жаль, что то что я пишу поймут единицы. Те у кого способности глубоко и хорошо мыслить и хотябы 20-30 лет релеватного опыта, те начнут хотябы немного чтото подозревать. Остальные, вот как деды еще на мейнфреймах научили в ООПэшечку из черных ящичков, так и маслают на токарных станках. А за окном уже эпоха коллайдеров, расшифровки ДНК, квантовой теории поля и без 5 минут доказанных 11 измерений в теории струн. В айти слышали, что надо чото менять в консерватории ? Не, не слышали.

ООП как и Микросервисы это величайшая катастрофа для современного программирования.
По крайней мере для 80% прикладных проектов.

Яка альтернатива?

Наверно он имел ввиду утинную типизацию. То что крякает как утка, летает как утка и плавает как утка, скорей всего и есть утка.
Уже не плохо, но все еще далеко как это на самом деле устроено.

просто привʼязуйся до інтерфейсів замість конкретних реалізацій, і все..

Утинная типизация есть далеко не во всех ООП языках.
Тебе могут подсунуть вместо утки гуся,а у тебя уже там прописан интерфейс, что это утка. Весь смысл утинной типизации, что интерфейсы отдельно, данные отдельно и не связаны между собой в коде. Если данные подходят в рантайме под интерфейс, ок, доступен интерфейс. Если данные не подходят, ок, интерфейс недоступен, рантайм еррор.

Если данные подходят в рантайме под интерфейс, ок, доступен интерфейс. Если данные не подходят, ок, интерфейс недоступен, рантайм еррор.

Тобто замість знайти помилку на етапі розробки ми відкладаємо її на рантайм? Який у цьому сенс?
Відмова від строгої типізації — це як відмова від метричної системи! Ми тут чекаємо болти у міліметрах — а нам зробили у дюймах і вони не лізуть у гайки. «Рантайм ерор» — і що з цим робити?!

И да и нет. Так или иначе твой код покрыт тестами и ты всегда можешь проверить его математическую корректность. Это получше чем какие-то эфимерные гарантии строгой типизации. Хотя если код нужно жестко ломать и переписывать, строгая типизация да, больше помогает. Проект просто не компилируется если где-то поломались контракты.

эфимерные гарантии строгой типизации.

Дякую, поржав.

Дякую, поржав.

Я еще не видел ниодного проекта, который можно выпускать в прод без тестирования основываясь только на строгой типизации.

Вывод — лучше иметь проект на джаваскрипт который хорошо покрыт тестами, чем проект на шарпе/джаве который тестами не покрыт или покрыт плохо.

ні. анекдот є такий, про альтернативу курам

Ні, він мав на увазі старий анекдот про альтернативу і качок.

Процедурное программирование

Отказаться от плоскоземельной архитектуры на трех слонах китах ООП
uk.wikipedia.org/...​D562_The_hindoo_earth.jpg

НУ мені так здається, що останні роки від поліморфізма і наслідування вже в більшості своєму відходять. Інтерфейси + інкапсуляція замість цього. І не бачу з цим особливих проблем.
Але я хотів від тебе щось більше конкретного, ніж філософські абстракціі.
Ось ти в своєму проекті який пишеш використовуєш ООП чи якщо ні, то що використовуєш?

Інтерфейси + інкапсуляція замість цього.

Это тоже провал. Только что ради интереса глянул по коду.
На 120 тысяч строк у меня .... 6 (прописью шесть) интерфейсов. (public interface стейтмент)

Об остальном напишу как нибудь в следующий раз. В отдельной статье.

На 120 тысяч строк у меня .... 6 (прописью шесть) интерфейсов. (public interface стейтмент)

А можна поцікавитись: скільки строк юніт — тестів?

Юнит я не пишу. Они почти бесполезны.
Интеграционных гдето около 200- штук.
Плюс сейчас над лоад тестами работаю, чтобы примерно прикидывать сколько в оптимизации выиграл после изменений.

НУ мені так здається, що останні роки від поліморфізма і наслідування вже в більшості своєму відходять. Інтерфейси + інкапсуляція замість цього.

Колись була пропозиція відмовитися від if-else. Заміст цього писали case чи взагалі якийсь мепінг. Це просто мода — ні if, ні наслідування не винне якщо код написано незрозуміло. Можна навіть go to виправдати — якщо код із ним зрозумілий.

ну так, але багатошарове наслідування таки я вважаю поганою практикою. поліморфізм я взагалі ненавиджу, тому що відслідкувати це в коді майже неможливо нормально.

Колись була пропозиція відмовитися від if-else. Заміст цього писали case чи взагалі якийсь мепінг

жаба гадюку

Почекаємо твою історію про не — плоскоземельну архітектуру.
Хоча насправді більшість архітекторів таки приймають Землю плоскою при проєктуванні будинків — бо так простіше.

Хоча насправді більшість архітекторів таки приймають Землю плоскою при проєктуванні будинків — бо так простіше.

Про простише это хорошо сказано. Это я люблю.
Самая четкая бд в мире это Excel. Вдумайся. 80% всего бизнесса в мире сидит на эксель.
До млрд людей в мире каким то образом знают как с ней работать не обучаясь этому нигде специально (!). При этом Эксель это яркий пример того, как написали продукт не в плоскоземельном стиле. Там есть слой формул, есть слой отображения, есть слой валидации и есть слой хранения. А также есть реактивный обсчет формул.
Но нет ООП где это все было бы смешано в кучу в плоскоземельном стиле, типа эвентов, нотификаци, репозиториев, оповещения, конфигов ... Конечно ООПэшники добрались и до пресвятого Excel интегрировав туда не к ужину будет сказано VBA. Но что такое VBA и как с этим работать уже понимают только специально обученные люди.

нет ООП где это все было бы смешано в кучу в плоскоземельном стиле, типа эвентов, нотификаци, репозиториев, оповещения, конфигов ...

Ти от здаєшся розумним до певного моменту, поки не починаєш нести якусь космічну поєботу.
Те шо ти написав не є ооп, а є просто усталеними практиками написання ентерпрайзного коду.
Все це не випливає з ООП, а випливає з того, як людському мозку зручніше сприймати понятійні структури.

Те шо ти написав не є ооп, а є просто усталеними практиками написання ентерпрайзного коду.

Тебе не кажется это предложение странным ?
Потому что ООП и энтерпрайз это почти слова синонимы (в современных проектах, конечно, а не на Коболе)

наче на ООП не можна зробити проект

Let me fix it for you

наче на машинних кодах не можна зробити проект ...
наче на асемблері не можна зробити проект ...
наче на Сі не можна зробити проект ...
наче на С++ не можна зробити проект ...
наче на Java не можна зробити проект ...
наче на OOP не можна зробити проект ...

Смекаешь ?
Каждому кораблю своя лужа для плавания.
И лужа ООП заканчивается в системном программировании который плотненько лежит на фон неймановской архитектуре.
Или в проекте размером с один микросервис.
Тоесть около 3-5 тысяч строк оптимум, дальше начинается экспоненциальная деградация, поскольку, скорей всего, заказчик и тот кто писал ТЗ был не внук Ванги.
Большинство проектов выходят за эту метрику.

Та більшість існуючих фреймворків (Django, Laravel, Symfony, Spring) містять набагато більше рядків ООП коду.

Потому что это не прикладное ПО. Это фреймворк, или если еще обобщить аналог виртуальной машины, который тебе предоставляет удобный DSL. По хорошему такие вещи вообще должни быть написаны на чистом Си в императивном стиле, почти без вкраплений ООП, чтобы максимально их разогнать по скорости работы на типичной машинной архитектуре.

ерйозно, рахувати складність проекту за кількістю рядків коду?

Эта метрика выбрана только из расчета, сколько потом нужно будет переписать кода, как только появятся более менее серьезные требования.

А за окном уже эпоха коллайдеров, расшифровки ДНК, квантовой теории поля и без 5 минут доказанных 11 измерений в теории струн.

І скільки людей у світі розуміють ті 11 вимірів?
Можливо ООП так же примітивно як Ньотовновська механіка. Але ніхто не використовує релятивістські рівняння, чи геометрію Лобачевського на кулі, якщо треба порахувати маршрут до магазину. Так: Земля не плоска, час — відносний, але для простих задач нам треба просте рішення.

Всего 10%-20% генома может говорить произойдет функциональная развертка кода в Орла, Червяка, Слона или Человека. Всратые черные ящики ООП так не умеют.

Тому вигадали Machine Learning — якщо не знаємо що нам потрібно: слон чи орел то беремо модель і навчаємо — а вона сама «розвернеться» як треба. Але це вже не про програмування. Зазвичай програмісту потрібно зробити саме умовний «автомобіль», а не якогось трансформера щоб міг ставати ще й роботом чи літаком.

Ну приборостроение там разное с их чугунием в формочках и разьемами между ними. Но мир ПО, он какбе немного шире. В этом дивном мире заказчику может потребоваться чтобы мощность жигули внезапно возрасла в тысячу раз, или на утро каждая наклейка на каждом болте была переведена на десять языков, а руль ты вообще не должен видеть если у тебя бензобак пустой.

Світ ПО — це така ж сама інженерія, як приладо — будівництво чи авто — конструктор. Фантазії клієнта про перетворення «жигулі» на літак тут не до чого — бізнесу зазвичай потрібні реальні речі, а не фантазії.
Є ООП, є функціональне програмування. І те і інше — про декомпозицію. На жаль хоч класи, хоч функції — але навіть людина з 20 роками досвіду не взмозі тримати у свідомості 11 вимірів. Тому і не розповсюджені поки що ніякі «квантові» мови програмування із супер-позицією. А усі працюють з давно відомими бінарною логікою, структурами даних та функціями.

В айти слышали, что надо чото менять в консерватории ? Не, не слышали.

Не подобається ООП — запропонуйте щось інше: просте для розуміння і універсальне.

І скільки людей у світі розуміють ті 11 вимірів?

Не задумывался почему мозг у всех людей однопоточный ? Попытка решать сразу несколько задач параллельно вызывает боль и страдания. Знаешь откуда это в нейросети мозга ? Потому что он работает по принципах мультиверс по дефолту. Иначе и быть не может, потому что все построено по единому эскизу. Каждое измерение для него отдельный контекст. В каждом отдельном контексте мозг как рыба в воде. А когда в него пытаются впихнуть два три четыре пять смешанных контекстов одновременно, происходит сбой. Плоскоземельная ООП помойка выглядит как многомерная модель, которую попытались впихнуть в одномерное пространство. Ну типа открываешь HTML а там и скрипты и CSS и кеширование и данные и запросы к базе.... смешались люди кони. В любой ООП помойке за лесом деревьев не видно. Так выглядит современный говнокод.

Тому вигадали Machine Learning

Это отдельная узкоспециализированная область которая к делу отношения не имеет.

Світ ПО — це така ж сама інженерія, як приладо — будівництво чи авто — конструктор. Фантазії клієнта про перетворення «жигулі» на літак тут не до чого — бізнесу зазвичай потрібні реальні речі, а не фантазії.

Ну фантазии не фантазии, сам знаешь. Средний срок жизни проекта до его полного/крупного переписывания на рынке, обычно 3-5 лет. Выводы сделаешь сам.

Не подобається ООП — запропонуйте щось інше: просте для розуміння і універсальне.

Скоро.

запропонуйте щось інше: просте для розуміння і універсальне.

додам що шукати знайдене буде простим для розумінням і універсальним, якщо воно базується на тому що вже вміє мозок дорослої людини(18+) с середньою (європейською) освітою.

додам що шукати знайдене буде простим для розумінням і універсальним, якщо воно базується на тому що вже вміє мозок дорослої людини(18+) с середньою (європейською) освітою.

В идеале вообще-то дети, где-то 8-14 лет. Вот как только писать читать научились и им еще не успели загадить мозги «современными подходами» у них как раз наиболее хорошо открыт майндсет для понимания как это на самом деле должно работать. Еще есть алкоголики и наркоманы, которые словили жосткий ресет, они тоже развалили все знания, вплоть до врожденного фундамента. А фундамент это наше все.

Опять же, приведу пример пресвятого Экселя, да продлятся его годы жизни на века !
Величайшей технологии всех вермен и народов, которую осваивают от домохозяек до бизнесса, даже не обучаясь.

Ничего особенного
"О очевидных вещах люди думают реже всего"©Макс Вебер

Кожен раз винаходять нову інкарнацію велосипеда — рішаючи ту саму задачу

в мене аналогічне враження що у нас в айті — досвід не накопичується.
постійно бачу що процесс розробки — все той же, і все ж з тими ж проблемами.
про запобігання яких вже купа всього є — і монографій, і методологій, і просто — чорного гумору і мемів.

але, от новий проект, нова команда — і все с самого початку робиться так — щоб мати дикі проблеми потім. як подивитись зовні то здається що мета — збільшити терміни виконання, збільшити витрату грошей, і обов’зково щоб потім «підмітати ломом плац» «красити траву в зелене», робити весняний сніг білим (переоруванням — глибиний наверх, почорвніший від пилу бруду — вниз)

зівсно, слова змінилися, і тіпа нове — скрам і т.і.

а я з особистого досвіду бачу:
Що значить ім’я? Троянда пахне трояндою, хоч трояндою назви її, хоч ні.

правда мені замість «троянди» хочеться поставити інше слово :D

цікаво чому ви думаєте що тільку у вас в айті? Коли ви починаєте будівництво, то стикаєтеся з тим що команда будівельників інтерпретує свої знання і досвід зовсім по різному. Зявляються різні неочікувані варіації кожного етапу робіт. Кожен етап закінчується обовязковою лажею і, якщо повезе, то навіть ці спеціалісти виправлять свої помилки. І це при тому, що начебто є ДБН, стандарти, віковий досвід поколінь. Але людина все одно робить як їй зручно саме зараз.
А хіба в лікуванні не така ж сама ситуація коли людей з одним і тим же діагнозом лікують різними способами/ліками і отримують абсолютно різні результати? І це при тому, що все лікування давно прописане в схемах. По схемам прописані і ліки і алгоритм лікування. Начебто ціх людей вчать по схожій програмі. Але ніт, кожен лікар вносить свою ізюмінку в процес лікування.
Мабуть тут справа не а айті, а в результатах життедіяльності людини де потрібно щось додати «від себе» і працювати по методиці чи по схемі не цікаво. При чому що в вашому прикладі, що в моєму — вік не має значення. Досвідчені спеціалісти лажають (проявляють творчість) з ще більшим ентузіазмом ніж юні зелені подавани.

то стикаєтеся з тим що команда будівельників інтерпретує свої знання і досвід зовсім по різному.

як би вона не трактувала — властивості матеріальних об’єктів залишаються тими ж.
як і стандарти будівнивництва компанією.

А хіба в лікуванні не така ж сама ситуація коли людей з одним і тим же діагнозом лікують різними способами/ліками і отримують абсолютно різні результати?

а це взагалі дуже мимо. тому що кожна хвора людина має унікальний букет властивостей і хвороб. і лікування по схемі — неможливе в принципі. на кожному етапі схеми треба перевіряти результат, і вносити корективи у наступни крок.

Але ніт, кожен лікар вносить свою ізюмінку в процес лікування.

це його — прямий, фаховий обов’язок — пристосовувати схему лікування до лікування конкретного пацієнта. і чим більший в нього фах — тим краще лікар бачить особливості пацієнта.

Мабуть тут справа не а айті,

а в тому — з чим працює спеціаліст: будівельник, лікар, програміст.
справа у — властивостях об’єктів з якими треба працювати.
інформація — нематеріальна, тому айті — дуже далека від будівництва.
організм пацієнта — матеріальний, але рівень відповідальності набагато вищий чим в айті, та й науково — багато не визначено, та й перевірки стану організма пацієнта — не дешеві і повні — практично не можливі. тому — у медицині набагато більше емпірики, по факту, а в айті — впевнено планувати можна краще, у більшому обсязі.

Досвідчені спеціалісти лажають (проявляють творчість) з ще більшим ентузіазмом ніж юні зелені подавани.

статистично — досвідченні лажають набагато менше аніж юні подавани. Це юні подавани вигадують байки що урівнюють ймовірність лажі, нівелюють досвід.

а язика прикусити під час їжи — так, може кожен, хоча досвід користування ним — ого!

Можна як завгодно робити поки не доводиться масштабуватися. А потім виявляється що через 1 ендпоінт весь моноліт лягає. І нову фічу не виходить додати

Даже древні монолити масштабувалися через копіювання монолита на декілька серверів і потім налаштування афініті. Умовно кажучи якщо ти можешь підняти копію моноліта кожному юзеру — то вони не помітять різниці. Звичайно — це дуже не-економно.
Але якщо наш моноліт написан на правильному ООП — то у нас працюють наступні принципи:
— Реалізація повністю прихована, а кожен класс залежить тільки від інтерфейсів.
— Будь — який класс збирається через DI контейнер.
Що нам треба, аби захостити якійсь клас окремо як сервис? Інтерфейс і імплементацію вже маємо — треба тільки обрати транспорт. GRPC, REST, WCF, Message BUS — у нас есть большой вибір. Кода писати не треба — тільки конфігурація. Код клієнта також гегериться автоматично.
Таким чином будь-який класс можно витягнути з моноліта, розмістити окремо і викликати як треба! Можно розібрати наш моноліт на дрібні шматочки і кожен клас покласти у свій контейнер ак сервіс, підняти кубер, зробити авто — селинг и радіти. А можна просто розділити на 3 частини і отримати класичний 3-tier. Чи на сервіси розділити тільки бізнес-логіку, а веб-аплікейшин лишити укупі.

Точно, можна ще кожному юзеру окремий моноліт
Зазвичай напевно воно так і робиться — еволюційно. Десь стає більше контейнерів, десь контейнери злипаються у моноліт. А якщо відразу достатньо точно вгадати розбиття (або не розбиття) на частини то в подальшому буде менше роботи
Помічав ще такий фактор що наявність мікросервісів або якийсь інший спосіб розбивати додаток на частини спонукає використовувати ООП. Бо у випадку моноліта різниці майже не видно, можна підтримувати дотримання ООП тільки чиєюсь волею, ще одному розробнику здається що краще одні класи а іншому інші. А якщо не моноліт то можна не змогти реалізувати взагалі нічого без принципів ООП. Здається що ООП придумали якраз для не-монолітів, для додатків де є частини з різними контейнерами, командами розробки або життєвими циклами..

Точно, можна ще кожному юзеру окремий моноліт

WASM це воно і є.

наш моноліт написан на правильному ООП

Правильного ООП не существует. Простой пример. Допустим ты собрал монолит на ООП.
Монолит разделился как ты пишешь на кучу сервисов с помощью интерфейсов с коммуникациями по любому из протоколов. Сервисы пошли выполнятся. Сервисы разветвлились в своем выполнении. Допустим сервисы выполняются долго и я хочу кнопку Cancel (Interrupt) выполнения в UI. Другими словами гранулярный Cancellation Token в каждой точке выполнения твоего монолита. Просто убить поток меня не интересует. Я хочу Graceful shutdown. Твои предложения, чтобы не менять в ООП каждый класс.
PS: И предложения «этого не было в ТЗ» не подходят. Это вполне нормальное требование которое формулируется в одну строчку. Каждый проект состоит из десятков таких простых и понятных требований, которые вначале невозможно предсказать и которые ломают няшный мирок любого ООП приложения.

Другими словами гранулярный Cancellation Token в каждой точке выполнения твоего монолита.

Це не про ООП. Просто мати Cancellation Token — недостатньо. Хтось повинен его перевіряти і якось виходити. При цьому що робити у разі відміни — це також залежить від операції. Тобто хоч ООП, хоч ФП — код доведеться писати.

Твои предложения, чтобы не менять в ООП каждый класс.

Інше цікаве питання як прокинути Cancellation Token в усі класи. І тут є багато рішень. На мій погляд це повинно бути частиною Task Execution Context. Саме тому, що це не частина усіх класів, а частина того, як виконуються методи. Але ООП дає різні варіанти: це може бути міксін на основі інтерфейсу (інтерфейс з частковою реалізацією). Чи це може бути прив’язано до IDisposable (диспозимо об’ект = відміняємо його методи). Також це можна «навісити» як аспект на методи. Є декілька варіантів підтримки AOP у C#.

PS: И предложения «этого не было в ТЗ» не подходят. Это вполне нормальное требование которое формулируется в одну строчку. Каждый проект состоит из десятков таких простых и понятных требований, которые вначале невозможно предсказать и которые ломают няшный мирок любого ООП приложения.

Функціонал не береться невідь-звідки — його хтось або написав, або ні. Звичайно можна сказати що клієнт завжди має на увазі що аплікейшин має вміти усе: локалізуватися на усі язики, включаючи RTL ти вертикальні ієрогліфи, відкочувати будь — які зміни у разі помилки, робити аудит усіх змін і т.д. Можливо архітект чи тех-лід подумали заздалегідь і зробили це тому що знали що це колись буде нада — звичайно, якщо ПМ не порізав сороки. Але якщо цього не було у ТЗ, якщо цього ніхто не робив — то цього нема. І це нічого не ломає — а тільки додає зайвої роботи.

Мне кажется с этого поста началась эволюция плоскоземельщика. От «строителям удобно строить здания из расчет что земля плоская» до «це не про ООП». Мир не плоский и попытка впихнуть в ООП параллельные измерения (а масштабирование как и интеррапт это тоже какбе из этой оперы) приводит к жутким костылям и тотальному переписыванию кода плоскоземельщиком. И когда ООПэшники чтото там фантазируют о «гибкости архитектуры», сказать что они врут сами себе — это ничего не сказать. Вместе с тем, можно писать код в таком стиле, что любые изменения НЕ сценарного типа будут туда залетать просто играючись, без любого крупного переписывания (и это не ФП, и не АОП таким как мы знаем его сегодн яв шарпе). А кодовая база уменьшится примерно в 50-100 раз, также как и проще будет читаться и поддерживаться. И наоборот, попытка выписать все измерения в одной плоскости, приводит к жутчайшему разростанию сложности и размеров проекта.

Вот в соседней статье пишут про массовые увольнения айтишников. А на самом деле, в этой статье описана одна из прямых причин. Бизнесс просто перестал вытягивать этот «технический прогресс». Пациентам с насморком начали прописывать лучевую терапию в особо крупных радиационных дозах. Как только очередной пациент откинулся, шарлатаны бегут устраиваться к следующему пациенту, у которого есть доступ к печатному станку денежных единиц.

Ну це не правда. Наврядчи звільняють программістів бо рахунки за AWS непідйомні.
В першу чергу це результат підходу, коли дешеві гроші венчурних інвестицій плодять хронічно неприбуткові компанії чи продукти в надії, що глобальне домінування на ринку перекриє десятиріччя збитків.
Але дешеві гроші закінчилися, і далі нема бажаючих спонсорувати те що взагалі на обрії подій не поверне вкладені гроші.
Плюс ще останні 2 роки була якась скаженіла «гонка за таланти», коли компаніям треба було кудись вкладати дешеві гроші, і вони наймали всіх підряд з ринку. Їм прийшла пора платити по рахункам.

Наврядчи звільняють программістів бо рахунки за AWS непідйомні

Саме тому і звільняють.
Умовно кажучи, в нас сидить Вася.
Васі треба платити 200к в рік. А ще Вася нагородив архітектуру де потрібно найняти ще 50 Вась. Ітого маємо 51×200к в рік врєдітєльства, де в якись момент настає — нам краще відмовитись від фіч і від авс і ваапщє, краще купимо собі по новій яхті, в нас вже є функціонал, будемо краще знімати по 8 баксів за синю галочку. Це накодить нам Ваня, мідл. Ваня ти слішал чтото про мікро/нано/піко/фємто сєрвісную архітектуру ? Нєт. Атлічна, бєрьом.

Ну це не правда. Наврядчи звільняють программістів бо рахунки за AWS непідйомні.

Совпадение ? Не думаю ©
dou.ua/...​ff-employees/?from=sbnews

Salesforce скоротить 2500 співробітників
Salesforce планує скоротити тисячі робочих місць. Причина — зростання витрат на хмарні технології через проблеми у світовій економіці.

layoffs.fyi ;)
Звичайно що неоптимальні технічні рішення призводять до збільшення видатків і відповідно зменьшення прибутків. Але на мій погляд з бізнес точки зору це виглядає умовно ось так:
...
Уряди США і Європи друкують кучу боргових грошей на підтримання економіки під час пандемії. Всі зайві гроші опиняються так чи інакше на фондовому ринку.
...
В нас акціі виросли на 20 млрд баксів — треба терміново їх інвестувати в розвиток — запустити метавсесвіт — терміново найміть 1000 Вась, які будуть його піляти.
....
Війна, інфляція, санкції, ріст цін на ресурси і зниження споживання, підняття базових ставок центробанками всіх стран, удорожчання кредитів, падіння економіки Китаю, вихід грошей з бірж
....
Акціі падають на 20 млрд баксів
....
Так, терміново звільніть 1000 Вась, давайте заробляти грошей на платних синіх галочках.

Я думаю NanoVM (Unikernel) можу буди дуже корисним для Nano services, може комусь буде цікаво.

Ось тут ще прикольні думки запостив вчора минулий сто гитхабу twitter.com/...​tatus/1592227285024636928

Спасибо за статью очень интересно
а шо по нетворк оверхеду? Это ведь большая проблема?

Разбивать проект на проекты поменьше дает несколько плюсов:
— изолированный конетекст (команды могут работать паралельно)
— можно независом деплоить и поэтому можно обновлять и маштабировать независимо

Вы говорите идти дальше и рабивать дальше. Предположим мы делаем банк и у нас там уже появляется необходимость отслеживать атомарность операция на уровне всего приложение.

Я просто хотел узнать ваше мнение по поводу того если хорошо разбить кода на сервисы внутри одного приложения то можно избежать многих проблем. Я больше скланяюсь к мнение Мартина Фаулера — вначале делайте монолит, а потом уже разбивать на сервисы.

Кожна архітектура має в першу чергу вирішувати конкретну проблему, наносервісами наприклад можна ізолювати ти масштабувати окрему функцію. Звісно в цьому випадку є свої недоліки — такі як наприклад нетворк оверхед, складність системи взагалому буте значно більша.
На 100% згоден з думкою Фаулера — моноліт значно простіший і немає сенсу ускладнювати якщо на це немає конкретної причини.

Наносервіси — кожний сервіс — це окрема функція
А яка ваша думка? Які нові тренди ви спостерігаєте у світі мікросервісів?

Цей світ ***нувся :)

Я не проти мікросервісів, але моя філософія — мікросервісів повинно бути мінімальна можлива кількість, але не менше ніж потрібно.

боги cloud рішень з вами не згодні. більше сервісів і ще більше інстансів під кожний! :))

Я розумію що клауд провайдери що їм дуже вигідно продвігати наносервісну інфраструктуру. А відповідно і всякі євангелісти і «сертифіковані архітектори» теж продвігають такий підхід.

Пряма аналогія з мікросервісами — це перехід від процедурного типу программування до ООП.
Так, має сенс в великій апплікації розбивати структури на класи, які в собі містять «одну функцію». Тут придуть любітелі функціональщини і скажуть що ООП — гівно, я частково будуть праві, але в реальному світі з цими недоліками навчились жити.
Але «наносервіси» — це типу «нанокласи» — саме те за що більшість не люблять ООП — класи за ради класів, декілька рівнів беззмістовної абстракціі, паттерн патернів, фабріка фабрік.

паттерн патернів, фабріка фабрік

За те на інтерв’ю можна круто виглядати, цитувати з GoF як піп із святого письма :)))))

мікросервісів повинно бути мінімальна можлива кількість, але не менше ніж потрібно

Це круто, шановний колего :) Лишилося тільки з’ясувати скільки саме потрібно :)
І тут вмикається вже не стільки технічний, скільки організаційний фактор.

ну так я ж про філософію — тобто орієентир та принцип за яким треба намагатися приймати рішення.
Тобто коротко це так
1) переходити на мікросервіси тільки якщо є розуміння, що цей перехід вимушений.
2) створювати новий мікросервіс тільки якщо є розуміння, чому він не може бути частиною існуючого мікросервіса.
3) Дробити існуючий мікросервіс тільки якщо є розуміння чому він не може залишатися таким як є.

2) створювати новий мікросервіс тільки якщо є розуміння, чому він не може бути частиною існуючого мікросервіса.

Ще варіант великої кодової бази. Усе може бути вкупі, але швидкість розробки цієї купи ніяка, бо усе закостилєно нафіг (порушено low coupling / high cohesion). Типовий Monolithic Hell. І щоб закріпити модульність, треба зробити чіткий code ownership. Кожна команда буде займатись своїм незалежним шматком, і розробка пришвидшиться goomics.net/374

Себто, коли моноліт великий — його ліпше порізати хоч якось, аніж продовжувати копати яму, в котрій сидиш.

Усе може бути вкупі, але швидкість розробки цієї купи ніяка, бо усе закостилєно нафіг (порушено low coupling / high cohesion)

А ще існує рефакторінг.

Не встигнеш відрефакторити як воно знов стане яке було.
Та й після кожного вийнятого костиля треба прогоняти усі тести, а їх в легасі овердофіга. Тому і декостиляція повільна. Ліпше розрізати, ніж тягнути.

Не встигнеш відрефакторити як воно знов стане яке було.

Денис, ну тут же явно проблема не в молоніті чи мікросервісах, правда же? Мікросервіси як рецепт проти хуйової кодобази — завжди погане рішення.

Їх так і рекламують.
Думаю, рішення хороше — якщо неможливо встромити костиль між мікросервісами, то його там не буде. Навіть ефективний менеджер, в котрого завжди реліз пригорає, не примусить програмістів такий костиль зробити — бо фіг, воно розподілене.
Актори працюють так само ефективно, якщо кожним актором займається окрема команда (strict code ownership).

Та зробити distributed monolith.
З iншого боку я бачив доведену до абсурду hexagonal architecture в одному сервiсi, це мєрзко

distributed monolith

то гірше з двох світів. Воно ще й тормозить.
Типу там можна сусіда питати дані, і усі роблять усе (нема того, що в кожної команди свій сервіс). В результаті костилі жеруть ресурси.

то гірше з двох світів. Воно ще й тормозить.

Що називається пусти козла в огород, або людей без вiдповiдного майндсету пиляти мiкросервiси

А от ніхєра, якщо руки не криві то це навпаки краще з двох світів — нема оверхеда на деплой, нема оверхеда на комунікацію, а скалабільність є.

А чому він тоді розподілений, коли нема комунікації?

Маю на увазі, що немає оверхеду на комунікацію між окремими кусками логіки.

Наприклад, немає кафки, яка у мікросервісному сценарії деградує фактично до шини, яка імітує RPC.

Я чув означення «розподілений моноліт» як моноліт, модулі котрого рознесли на окремі сервери. Себто, SOA без формалізованої шини. Як мінімум, там сокети, і мережевий обмін даними при будь-якому сценарії. Це вносить уповільнення та нестабільність.

Можливо, ви мали на увазі щось інше.

Я чув означення «розподілений моноліт» як моноліт, модулі котрого рознесли на окремі сервери

Ну, то хто як назве )
Оце те що ти кажеш, це і є

SOA без формалізованої шини

:)
А по суті це просто SOA.

В моєму розумінні «розподілений моноліт» це класичний моноліт, який розроблений з врахуванням у логіці можливості роботи багатьох нод у паралель. Це стосується, наприклад, внутрішнього розподілення черг між нодами, розподілені локи, розподілений шедулінг і т.д. Все це, можна перекласти на плечі, накриклад, редісу. А сама аппа залишається монолітною, без необхідності прокладати слой комунікацій між шматками логіки.

Те, що ти пишеш — це шардінг. Коли купа нод, на кожній біжить цілий моноліт, і не випускає контрол- та дата-флов назовні ноди.

Те, що ти пишеш — це шардінг

Ти принципово помиляєшся.

Шардінг (від слова shard — осколок) це розбиття чогось великого на відокремлені, незалежно оброблювані шматки. Наприклад, розпилюванню єдиної БД на окремі під-бази за якимось дискримінатором.

Я от зараз погуглив що люди мають на увазі під distributed monolith, і трактування дуже різняться. Є навіть трактування, що так називається помилка розробки мікросервісів, коли на мс розпиляли, а тайт каплінг по факту залишився.

Кароче мутний термін. Але я його використував саме в значенні класичного моноліту, який архітектурно здатен до повноцінної кластеризації, і, відповідно, тримає частину даних у розподіленому стані.

Бо далеко не всі моноліти це вміють, не всім це потрібно, і не всі, кому це потрібно, цього досягають.

Є навіть трактування, що так називається помилка розробки мікросервісів, коли на мс розпиляли, а тайт каплінг по факту залишився.

Це і є основне значення — коли модулі моноліту рознесли на різні сервери, але ці модулі лишилися тісно зв’язаними.

Я мав на увазі саме шардінг, коли кожний інстанс моноліта обробляє свою підмножину даних та запитів.

Якщо існують нативно кластеризовані моноліти — цікаво розібратись, що там всередині. Чим воно відрізняється від мікросервісів чи пайплайнів? Чи SOA?
Є якісь публічні приклади?

Я мав на увазі саме шардінг, коли кожний інстанс моноліта обробляє свою підмножину даних та запитів.

Зрозумів, але ні, малось на увазі не те, а коли кожен інстанс може обробляти будь-які дані, просто параллельно з ним працюють інші N таких самих інстансів, які так само мають всі повноваження.

Якщо існують нативно кластеризовані моноліти — цікаво розібратись, що там всередині.

Ща ти маєш на увазі під «нативною кластеризацією»? Не дуже зрозуміло, що ти вкладаєш в це поняття.

Будь-яка программа, яку можно запустити, «нативно» здатна до кластеризації, бо ти раз за разом можеш запускати нові й нові екземляри її процесу. Питання чи буде ця сукупність паралельних процесів коректно обробляти дані. Якщо не приділяти цьому уваги — то ні, скоріш за все не буде.

По суті, побудова моноліта, який здатен до нормальної кластеризації це і є питання підходів до роботи з даними. Потрібно постійно тримати в голові, що будь-яка дія, будь-який процес, є НЕ унікальним, і може виконуватись паралельно з таким самим сусідом. Відповідно, потрібна розподілена структура, яка буде поєднувати обчислювальні можливості монолітів в якийсь єдиний простір пам"яті. Складно написав, але по суті це просто підключення кожного інстансу до якогось розподіленого дата гріду, який дозволяє реалізувати розподілені топіки, черги, мапи, кароче все, що дозволить кожному окремому інстансу діяти як частина єдиного цілого, а не просто один в порожнечі.

Ща ти маєш на увазі під «нативною кластеризацією»? Не дуже зрозуміло, що ти вкладаєш в це поняття.
В моєму розумінні «розподілений моноліт» це класичний моноліт, який розроблений з врахуванням у логіці можливості роботи багатьох нод у паралель. Це стосується, наприклад, внутрішнього розподілення черг між нодами, розподілені локи, розподілений шедулінг і т.д.
По суті, побудова моноліта, який здатен до нормальної кластеризації це і є питання підходів до роботи з даними. Потрібно постійно тримати в голові, що будь-яка дія, будь-який процес, є НЕ унікальним, і може виконуватись паралельно з таким самим сусідом. Відповідно, потрібна розподілена структура, яка буде поєднувати обчислювальні можливості монолітів в якийсь єдиний простір пам"яті. Складно написав, але по суті це просто підключення кожного інстансу до якогось розподіленого дата гріду, який дозволяє реалізувати розподілені топіки, черги, мапи, кароче все, що дозволить кожному окремому інстансу діяти як частина єдиного цілого, а не просто один в порожнечі.

Досить точно передана суть саме того розподіленого моноліту, котрий застряг на пів-дороги до мікросервісів. Він отримав недоліки моноліту (велика кодова база, велика зв’язність між модулями), недоліки мікросервісів (складність деплойменту, розподілені помилки), та власні недоліки (повільна робота через велику кількість розподілених операцій, низька стабільність бо відмова заліза чи мережі одного компонента призводить до зупинки усієї системи).

котрий застряг на пів-дороги до мікросервісів.

Видно що ти не зрозумів сенс і концепцію.

Він отримав недоліки моноліту (велика кодова база, велика зв’язність між модулями)

Якщо ти дивишся на моноліт так, то саме існування моноліту для тебе недолік. Про що ми тоді розмовляємо? Я з цим не погоджуюсь. Я, навпаки, розглядаю розпилювання кодової бази на якнайменші шматки як принциповий недолік мікросервісів, якого позбавлений моноліт.

недоліки мікросервісів (складність деплойменту, розподілені помилки)

Звідки ти це видумав? Складність деплойменту не підвищується взагалі. У моноліту вона апріорі в рази менша раз, по-друге, всі залежності так чи інакше є залежностями — база і редіс. Чи ти багато бачив монолітів без бази і редіса?
Розподілених помилок тут якраз немає, бо він і не працює з розподіленою логікою в класичному розумінні, як наприклад, саги в мікросервісах через кафку, де кожен відпиляний інвалід опрацьовує якусь обривчасту логіку.
Розподілені дані хендляться самим дата грідом, і для самого моноліта вони прозорі, він агностик стосовно того, що дані насправді розподілені.

повільна робота через велику кількість розподілених операцій

Працюючи з тим же редісом, у тебе повільна робота через велику кількість розподілених операцій? Серьозно?

низька стабільність бо відмова заліза чи мережі одного компонента призводить до зупинки усієї системи

Це ти вже шось видумуєш на ходу. Кожна нода може працювати повністю самостійно, бо, внєзапно, вона моноліт, і вона в кількості 1 штук повністю самодостатня. Навіть якщо у тебе кластер розвалився к єбеням, якщо балансер бачить хоч 1 ноду, то все працює. Шо за страсті ти розповідає, я не розумію.

Те, шо ти описуєш — це про якісь недомікросервіси.

Я, навпаки, розглядаю розпилювання кодової бази на якнайменші шматки як принциповий недолік мікросервісів, якого позбавлений моноліт.

Розпилювання кодової бази — це вимушений крок. Бо людина просто не здатна тримати у голові більше обмеженого обсягу коду! Як тільки моноліт переростає цей обсяг — вже ні у кого немає повного розуміння як що працює. У кожного з’являється своє розуміння, але оскільки код суспільний і сильно зв’язаний — то (цілком логічні!) змини однієї людини псують функціональність, яку вигадала інша людина (зі своїм розумінням).
«Як з’їсти слона? По шматкам»! Кращого ще не вигадали: велике та складне потрібно розділяти на невелике та зрозуміле.

людина просто не здатна тримати у голові більше обмеженого обсягу коду!

Тобто обсяг системної бібліотеки, чи фреймворку — люди тримають в голові?

велике та складне потрібно розділяти на невелике та зрозуміле.

Нє-а. Велике та складне — узагальнюється, мозок вибудовує ієрархії абстракцій.

Моноліт же стає «незрозумілим» коли тих ієрархій немає чи забагато, щоб звести до більш простих абстракцій більш високого рівня

вже ні у кого немає повного розуміння як що працює.

Тобто а як працює система з десятками типами своїх мікросервіси які використовують десяткі сервісів клауд провайдера — любий скаже?

змини однієї людини псують функціональність

Звісно як кожен чомусь лазить то в код компілятора, то системної ліби, щоб вивести Hello world — то так і буде.

Але ж чомусь рідко виникає проблема лізти зі змінами у код системної ліби. То як так виходить що кожен вимушений лізти у фундамент моноліта щоб на своєму 5ому поверху змінити кран у ванній?

То як так виходить що кожен вимушений лізти у фундамент моноліта щоб на своєму 5ому поверху змінити кран у ванній?

А чому код зветься монолітом? Бо усі частини сильно пов’язані і залежні одна від одної. Якщо цього не має — то не має і моноліту.
Наприклад кожен GUI аплікейшин використовує бібліотеку стандартних контролів. Але йому не треба в неї лізти — бо це не моноліт, а сами гнучкий фреймвок з абстракціями.
З іншого боку аби показати одне поле на класичному 3-tier монолити треба протягнути його від UI через API, бізнес-логіку, DOM-моделі, ORM і до бази. Тобто «лізти зі змінами» від підвалу до даху через усі поверхи.

Тобто а як працює система з десятками типами своїх мікросервіси які використовують десяткі сервісів клауд провайдера — любий скаже?

Як працює комп’ютер з мільярдами транзисторів? Дуже просто: є материнська плата, процесор, відео-плата і т.д. Далі на них є контролери та іньші мікросхеми. У кожній мікросхемі своя функція і свій виробник ... Аби зібрати комп’ютер треба знати про 5 — 10 деталей. Як влаштована мікросхема — знає тільки її виробник.
Так само з мікро — сервісами. Аби їх використати — не треба знати що всередині. У кожного мікросервіса є команда, яка у ньому розбирається і не знає про інші.

Розділений моноліт це вже не моноліт.
Це перетворюється або на Microkernel або на SOA або на Space-Based Architecture.

Distributed monolith добре гуглиться
scoutapm.com/...​onoliths-vs-microservices
і навіть є в Річардсона:
One challenge with using the microservice architecture is that there isn’t a concrete, well-defined algorithm for decomposing a system into services. As with much of software development, it’s something of an art. To make matters worse, if you decompose a system incorrectly, you’ll build a distributed monolith, a system consisting of coupled services that must be deployed together. A distributed monolith has the drawbacks of both the monolithic architecture and the microservice architecture.

За

Space-Based Architecture

дякую — піде в статтю. Я не знав такої назви для Blackboard.

Ось тут ще можна глянути, останній патерн спейс-бейзд
github.com/...​rns (2015) — Richards.pdf

Або якщо є доступ то тут ніби новіша версія learning.oreilly.com/...​e-patterns/9781491971437

Та ніхто не рев’ювить...(
Може, ти що скажеш?

Зате люди лайкають) Так, зараз напишу

така ж херня ваша «філософія» як і ці клоуни з наносервісами.
мікросервісів має бути не мінімально і не максимально, а оптимально — стільки, скільки має сенс робити в цьому конкретному випадку.
а клоунам які пропагують наносервіси, треба зовсім мало щоб не бути клоунами — це зауважити, де саме наносервіси використовувати корисно, а де ні.

Підписатись на коментарі