Заменят ли готовые (микро) сервисы бэкендеров и чего для этого не хватает

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

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

@Foxcool, можно еще добавить, что рынк не только на реальную сложность ориентируется. Всякие рубисты, до сих пор на рельсе шлепающие централизованное MVC могут получать сильно больше архитекторов распределенщиков. Навык самопродажи и вот этого всего никуда не делся

@Foxcool, ворвусь в тред как стоящий рядом.

Wordpress действительно никого особо не убил, еще и рынок создал. Шаг влево, шаг вправо от стандартного вида/функциональности — плагин/тема стоит ого-го. И весь этот "NoCode" люди пишут с помощью "Code".

NoCode — не всегда сторонний сервис, который сдохнет или отвалится. Есть self-hosted решения. Самое банальное — NodeRED. Правда и саппортить себе сам будешь, а это уже снижает ценность NoCode-решения :D

Если есть выбор делать монолит или микросервисы - я бы начал с монолита и двигался в сторону микросервисов только в случае ральной необходимости.

Это понятно. Я сталкивался с неуместными микросервисами несколько раз. А с неуместным монолитом, что интересно, еще не встречался.

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

Шаг влево, шаг вправо от стандартного вида/функциональности — плагин/тема стоит ого-го.

Мой пойнт в том, что сейчас ситуация меняется. По логике CMS, автогенерация кода и остальне могло решить много задач, которые по факту не решила. А сейчас, кмк, есть шансы.

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

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

@uhbif19

Понакидаю еще рассуждений и попробую копнуть глубже :)))

Я думаю, стоит упоминания такое понятие как bounded context из волшебного мира DDD :)

Почему я про него вспомнил?

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

Например, если мы делаем интернет магазин, то можно выделить например 3 (для простоты) независимых и почти непересекающихся баундед контекста:

• каталог товаров
• приём заказа с оплатой
• чат бот для саппорта

Рассмотрим подробнее:

1. Каталог товаров - самодостаточен и может работать как без приёма заказов, так и без чат-бота. Может работать как отдельный сервис со своим хранилищем.

2. Приём и обработка заказов - отельный баундед контекст. Тоже может быть отдельным микросервисом со своим хранилищем. Но зависит от каталога и требует интегрирации с внешней платёжной системой. Для успешного подтверждения заказа нам достаточно получить OK от платёжного сервиса и отметить в хранилище заказов, что заказ прошёл. Чтобы показать юзеру инвойс или историю покупок, нужно джойнить инфу о товаре из каталога товаров (из другого сервиса/хранилища) с заказом. Или копировать базовую инфу о товаре в сам заказ во время покупки, чтобы избежать джоина по сети.

3. Чат-бот - независимая фича, без которой магазин может работать. Её можно (а может даже нужно) делать отдельным (микро-) сервисом или интегрироватся с чьим-то Saas чат-ботом, чтобы не писать своего.

Инкапсуляция независимых баундед контекстов в отдельных сервисах почти не доставляет проблем.

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

Распиливание же одного баундед контекста на микросервисы ведёт к распределённости близких по смыслу данных и это добавляет много сложностей.

Например, добавим в пример выше статистику продаж. Она принадлежит контексту заказов и не может независимо работать в отрыве от приёма заказов.

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

Если статистику делать отдельным микро-сервисом с отдельным хранилищем. При оформлении заказа нужно:

• либо синхронно дёргать АПИ сервиса статистики
• либо кидать сообщения ему через очередь для асинхронности. Заказ появляется в сервисе статистики не мгновенно, а спустя какое-то время - это и есть eventual consistency.

В синхронном варианте может быть такая проблема: что если сервис статистики недоступен?
В асинхронном: что если очередь была недоступна или сервис статистики вычитал сообщение из очереди и обработал его с ошибкой?
В обоих случаях: что если сервис статистики восстановили из бэкапа?
В любом варианте распределённости есть возможность получить неучтённые заказы в сервисе статистики.

Распределённость данных из одного баундед контекста всегда ведёт к потере целостности этих данных (CAP теорема), усложнению архитекты, усложнению тестирования, более дорогой поддержке и т.п.

Целостность между баундед контекстами обычно не так критична. Наример, если товар удалили из каталога, а в заказе есть ссылка на удалённый товар - это нормально, так как мы знаем, что юзер не мог выбрать несуществующий в каталоге товар. Если товар успел закончиться и заказ еще не был обработан, включается процесс отмены заказа, возврата денег и т.п. - всё в рамках баундед контекста обработки заказов.

@hackman, Да, вы очень-очень правы, все так. В Clear Code не в таких терминах, но вроде это тоже упоминается.

Виртуализация и облака не убили bare metal фермы.

Хм. Мне кажется, что для веб-сервисов убили.

это 3ТБ данных и в целом у вас 20+ТБ данных Data warehouse которые надо

Это важное ограничение, добавил в пост, спасибо. Правда оно только про внешние сервисы.

очень интересно когда у вас маленькое приложеньейцО которое там сайты конструировать

Вот я и хочу обсудить такие конкретные ограничения. И какую долю рынка/реальности занимают такие задачи.

@uhbif19, надо определиться что такое "веб-сервис". Если мы о "сайт-визитка" за котороым нет почти никакого бек-енда - то да, убили.
Если мы о чём-то более-менее серьёзном (тот же Facebook чистый "веб-сервис"), то нет.
С моей колокольни (но у меня проф. деформация и предвзятое мнение) доля рынка (в деньгах) у потребителей этих микросервисов копеечная. Но всей кучей они приносят этим микросервисам некую малую денежку.
Ограничения... даже не возьмусь писать. Задач и областей в ИТ миллиарды. И у многих из них найдётся гора "почему" против этих микросервисов. Там один GDPR чего стоит. :)

@dj_kill, Вообще, как раз со всякими законами о хранении данных гораздо проще в легальном поле оставаться при сервис-ориентированной архитектуре.

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

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

Но это именно масштаб крупных проектов: неважно веб, не веб. Большой проект в монолите тоже очень сложно поддерживать, даже если там жестко применяются паттерны чистой архитектуры.

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

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

@Foxcool, мне нравиться что известная уже более 50-ти лет "модульная архитектура" (это ещё когда аж Pascal придумывали выдавали за его killer-feature) теперь называется "микросервисная". :)
С моей колокольни когда есть куча "модулей-сервисов" написанных одной командой делающей одно дело - это всё ещё монолит. Он может быть распределён как угодно и вот это всё. Но это монолит.
Микросервисы (и как я понимаю автор топика понимает это так же) - это когда бОльшая часть этих модулей написана некой другой командой и используется на тех или иных условиях. И в пределах проекта мы не можем изменить их API или метод работы.
(вот я это написал, прочитал, и понимаю что как "определение" - это прямо гавнище получилось, но, надеюсь, мысль передал).
Так вот второе применимо только в очень ограниченном наборе задач.

@dj_kill, если пишется все одной командой до 10 человек, то и разбиваться вполне необязатально.

Сервисы как раз хороши тем, что каждая часть системы при невсратом архитекторе будет максимально независимо, насколько позволяет контекст. У каждого сервиса описаны контракты, по которым он общается с другими. Это и позволяет разным командам пилить свои наборы сервисов. Или даже отдельным разрабам давать конкретные сервисы, которые они хорошо знаю, и за которые отвечают. Да хоть индусу на аутсорс - даже самый стремные и неподдерживаемый средненький (не микро) сервис можно переписать в обозримые сроки.

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

А так все сосет перед эрлангами и их акторами :D

@Foxcool, то, что описано как сервис - это прямо каноническое определение модуля которое писали ещё для Паскаля. Лет 50 назад. :)
Ну и, видимо, "высеры" от людей это не читавших или не понявших. :)
Для меня разница между "микросервисом" описанным топикстартером и "модулем" в монолите только в том, что в случае если из-за ошибки архитектора API модуля надо переделывать это переделвает команда проекта или это API сделано сторонней компанией и переделке не подлежит.

@dj_kill,

известная уже более 50-ти лет "модульная архитектура" (это ещё когда аж Pascal придумывали выдавали за его killer-feature) теперь называется "микросервисная"

Сервисная архитектура это конкретная вещь, отличная от модулей. Это подробно разбирается в "Чистой архитектуре", как одна из схем развертывания.

Но, действительно, она известна давно. В исторической справке он упоминает (емнип) использование таких схем в 70-х в приложении написанном на ассемблере. И упоминает ее популярность (емнип) с 90-х.

@uhbif19, Битва на определениях - это тухло. :)
Суть та же. Разница в нюансах, которые в приложении к этому топику не существенны.

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

Если мы о чём-то более-менее серьёзном (тот же Facebook чистый "веб-сервис"), то нет.

Не пользуюсь фейсбуком, но вот зашел я в него фейсбук, и пооткрывал пару рандомных страниц. Смотрю на сервис Вакансии. Там вижу основных четыре функции: разместить вакансию, откликнуться на нее, отфильтровать/поискать и подписаться. Первые три реализуются через CRUD и Hasura. Последняя через CRUD и scheduled job который перекидывает новые вакансии в какой-то общефейсбуковский сервис подписок на события или что-то такое.

Вот прекрасно выкинули необходимость бэка для одного примера внутри Facebook.

Вот вижу что вы поняли о чем я, почти повторяете мой пост в некоторых местах. Вы понимаете почему это все не повсеместно? Есть какие-нибудь аутсорсеры которые активно создают MVP на таких технологиях?

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

@uhbif19, Гриша, спасибо за упоминание моего коммента в шапке поста :) Попробую чуть развить тему и дать больше примеров.

1. Почему всё это неповсеместно? Тут есть куча причин, но как мне кажется, причин тут три и они вообще не технические, а бизнесовые. Ну или политические. Смотрите:

1а. Сами энтерпрайзы всё ещё готовы платить за переизобретение велосипеда, потому что у них с одной стороны нет доверия к опенсорсу (вспомните про встраивание криптомайнера в библиотеку event-stream в 2018 году), а с другой стороны — нет доверия к малым инновационным компаниям, которые предлагают крутые штуки (потому что эти малые компании могут завтра закрыться, быть купленными конкурентами, может случиться утечка данных и 100500 других бед). В итоге энтерпрайзы вынуждены писать всё сами или же покупать у других таких же энтерпрайзов.

1б. У заказчиков херовые "менеджеры среднего звена". Когда топ-менеджерами ставится задача "решить проблему бизнеса", то постановка задачи не включает вариантов решений — это в целом хорошо и правильно, так учат всех менеджеров в бизнес-школах. Соответственно, топ-менеджмент передаёт поиск решения задачи менеджерам среднего звена, которые тупо некомпетентны. Они либо коррумпированы и получают откаты за то, что отдадут тендер знакомым, вовлекут как можно больше людей в решение задачи, либо они не заинтересованы делать быстро и просто, а заинтересованы сделать из мухи слона — раздуть смету и начать рулить проектом на 1 лям баксов, в котором вовлечено 20 человек, потому что так они смогут построить свою карьеру. Увы, но с пректом на 5 человек и 100 тыщ баксов в энтерпрайзах карьеру не построишь, даже если такой проект сэкономит бизнесу 900 тыщ. Ну и наконец, даже если менеджер не корупционер и не карьерист, то он скорее всего не знает, как разобраться в вопросе, как проанализировать и выбрать верное решение. Он боится, что если выберет что-то нестандартное, то потом столкнётся с невозможностью его расширения/изменения (а бюджет уже будет подходить к концу), либо в принципе не знает что и из чего можно выбирать. Потому делает привычным способом: разработкой кастомного софта, как это делали и 5 лет назад когда он пришёл в компанию, и 25 лет назад, когда компания только начиналась.

1в. Две предыдущие проблемы усугубляются третьей: наличием дешевых программистов. Это парадоксально, я готов об этом говорить сутками — было бы только с кем и чего ради. Смотри сам: на рынке полно разрабов по цене меньше 100 баксов в день. В Индии, России, Беларуси, Украине, Мексике, Вьетнаме есть предложение от людей, готовых писать код за копейки, причём очень часто они идут по крышей уважаемого и узнаваемого вендора. А попробуй найди бизнес-консультантов (вот это всё что делает МакКинзи, Ассенчер, Бостон КГ и другие менее именитые консалтинг компании) по цене меньше 1000 баксов в день. Таких просто нет. В итоге многим клиентом тупо дешевле купить программиста в Мексике, который будет стоить им 30 000 баксов в год и напишет груду года, чем нанять на 2 недели консультанта (минус 10 000 баксов сразу же), который расскажет как добиться того же результата без программирования. Да и опять же: большинство консультантов занимаются менеджмент-консалтингом, а не технологическим брокеражем. Техноброкеров (ИТ-архитекторов-консультантов) по сути ещё меньше и они ещё дороже, чем программисты и менеджмент-консультанты вместе взятые.

@uhbif19, продолжаю отдельными комментами.

2. Есть какие-нибудь аутсорсеры которые активно создают MVP на таких технологиях?

Я не могу за всю Одессу сказать, но у меня был как раз только положительный опыт: что в «Собаке Павлова», что сейчас в ЕРАМ я видел проекты по созданию MVP из того что называют "говна и палок". Да и многие мои знакомые-стартаперы вовсю используют мешапы для создания MVP своих продуктов. Вот например: https://vc.ru/services/98412-mvp-marketpleysa-v-google-tablicah

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

В ЕРАМ же мы часто создаём MVP во время пресейла и сопутствующих ему хакатонов — как ответ на запрос потенциального клиента. Тут уже несколько другая причина для "говна и палок", но она тоже экономическая: будущий клиент не платит за MVP, потому что он ещё только выбирает вендора. Так что нам нужно сделать прототип с минимальными вложениями. А для этого используются люди, которые сейчас сидят на бенче — то есть не вовлечены в коммерческие проекты. Эти люди владеют самым разным техстеком, потому частенько может быть так, что MVP собирает какой-нибудь временно беспроектный менеджер с минимальным знанием Джаваскрипта, которому помогает UX-дизайнер вообще без навыков программирования :)

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

В больших компаниях многие программисты вообще не знают, что в компании делают MVP, потому что их подключают к проекту, когда нужно создавать полноразмерное приложение, а этап MVP уже раньше был пройден — либо внутри заказчика, либо вместе с каким-то консалтерами (UX-консалтеры, маркетологи и т.п.)

@uhbif19, за BPMN скажу так — действительно, есть проблема.

Начинается всё гладко, но на практике все изменения в BPMN вносят всё равно технари (какие-нибудь продвинутые бизнес-аналитики или бизнес-процесс-инженры, которые суть бывшие программисты / недопрограммисты), после чего изменения покрываются тестами (то есть воплощенна в BPMN бизнес-логика переносится в код, проверяющий её) — тем самым смысл как бы теряется. Но да, это всё равно дешевле выходит, чем напрограммировать — тестировщики стоят меньше, а скорость внесения изменений через BPMN выше.

Хорошо работают decision tables и всякие rule engines ещё. Причём очень часто это самописные системы на базе Экселя, которым заправляет Product Owner или какой-то бизнес-инженер.

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

Потому пришлось написать тулзу, наверху которой многостраничный Эксель-документ, на каждой странице которого Product Owner описывает форму — придумали свой DSL, структуру файла, правила форматирования. Затем эта экселина конвертируется в yaml, из которого на экране генерируется форма. Таким образом за день до релиза мы можем доработать форму без участия дорогих фронтендеров. Но опять же — на практике после доработки формы идёт тестирование, где почти всё лочится и при необходимости внести правки в форму в следующий раз тесты валятся и новую логику формы всё равно надо программировать — но уже в Селениуме. Но толк есть.

Ну я бы не стал GraphQL с SQL сравнивать. Это просто спецификация. За GraphQL все равно что-то будет, например ваш сервер который точно также будет фигачить запросы в базу или даже в другой сервис. GraphQL в плане использования лучше сравнивать в REST (отношу сюда всякие JSON API и прочее популярное в разговорах про headless), который до прихода GraphQL использовался по умолчанию.

GraphQL таки про экономию траффика, позволяя запросить именно тот набор данных который нужен а не просто все что отдал эндпоинт. Ну и да, GraphQL это не обязательно HTTP.

Ну я бы не стал GraphQL с SQL сравнивать. Это просто спецификация.

Можно подумать что SQL не спецификация :)

За GraphQL все равно что-то будет, например ваш сервер который точно также будет фигачить запросы в базу или даже в другой сервис. GraphQL в плане использования лучше сравнивать в REST

Да но нет. Обратите внимание на декларативность GraphQL и соотнесите с SQL. Да конечно в GraphQL настолько сложные выборки как в SQL строить не получится, но общая концепция ближе именно к SQL а не к REST.

Технически первый кто сможет внятно прикрутить его к СУБД получит возможность избавиться от большей части рутины в backend.

Hasura и co, с которых разговор начался, ровно это и делают.Н

Сейчас есть один интересный вариант который претендует на роль SQL это GraphQL.
идея его именно в том чтобы убрать backend

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

Тут я согласен, что это очень круто, и REST нужно выкидывать в большинстве задач.

Но вопросыс логикой приложения он никак не покрывает.

Технически первый кто сможет внятно прикрутить его к СУБД получит возможность избавиться от большей части рутины в backend.

Hasura и co, с которых разговор начался, ровно это и делают.Н

Сейчас есть один интересный вариант который претендует на роль SQL это GraphQL.
идея его именно в том чтобы убрать backend

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

Тут я согласен, что это очень круто, и REST нужно выкидывать в большинстве задач.

Но вопросы с логикой приложения он никак не покрывает.

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

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

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

Мне не очень понятно, почему эти решения должны "заменить бэкендеров". Я не до конца понимаю, кто такой "бэкендер" и чем он отличается, например, от программиста; но, во всяком случае, программистам появление новой библиотеки (а я не вижу принципиальных отличий приведенных "готовых решений" от библиотек) ничем не угрожает. Они их постоянно писали, пишут и будут писать, а также использовали, используют и будут использовать. Языки и парадигмы сменятся, попытки побороть дублирование кода останутся.

У нас в бекенде, все через openapi. В openapi определяешь метод, потом дописываешь его логику в модуль. Вуаля все работает. Тут даже не генератор. А транслятор из http REST вызова в вызов функции

@norguhtar, да, скорее всего от ЯП зависит. В го более прижился метод генерации кода. В динамических обычно фреймворк при старте что-то парсит и реализует

Я не переживаю, а надеюсь. Надеюсь, что часть бессмысленной работы программистов, eventually, устранят. Это то к чему все должны стремиться.

Добавил ссылок в пост. CRUDов правда не добавил, ибо они, по мне, все одинаковые.

@uhbif19, то бишь брать firebase?

@ganqqwerty, Я не настоящий сварщик. Но по моим требованиям Hasura больше подходит ибо GraphQL и self-hosted.