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

UPD 24.06.2020: добавил примеры в первую секцию, добавил секции "В чем разница с предыдущей историей" и "Важные проблемы затронутые в комментах"
UPD 26.07.2020: вот коммент, человека который хорошо понял мой запрос. Возможно кому-то он будет понятнее моего поста.

Почему я об этом задумался

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

Но узнав про штуки типа Hasura или разных headless CMS, я начал задумываться, насколько они могут повлиять на деятельность бэкендеров. Я подумал и понял, что если бы я подключал такие решения в нескольких из моих последних проектов,
то существенную часть задач и модулей приложения можно было бы просто выкинуть.

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

Еще пример. Я видел как заказчики делали статическую часть сайта, чатботов и аналитику сами через сервисы, паралельно основному бэку. Я даже не заметил как это все произошло. Мне кажется еще несколько лет назад подобная ситуация была бы довольно необычной. Аналогично с постом Вастрика про NoCode.

В чем разница с предыдущей историей

Раньше уже были попытки убрать всю рутину с помощью CMS, DSL, автогенерации кода, просто MVC фреймворков и других решений. В комментах, справедливо заметили, что все это не убрало программистов. Люди по прежнему В чем разница сейчас?

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

Почему все меняется? Возможно дело в том, что сервисная модель добавляет поддержку разных ЯП и этим увеличивает рынок. Возможно такие решения проще внедрить. Может меньше проблем с кастомизацией. Так же возможно, что раньше просто было некое разочарование, а сейчас снова поверили, что "все проблемы можно решить".

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

Какие уже бывают готовые решения

Есть несколько решений типа Hasura, которые создают готовое CRUD API. Те что я смотрел связываются с вашей логикой через веб-хуки дергающиеся при операции с ресурсом. Получается такой CQRS и архитектура на событиях, короче.

Есть микросервисы для управления пользователями: авторизации, прав, OAuth. Примеры: https://www.keycloak.org/, https://keratin.github.io/authn-server/

Для админки есть отдельный Godmode2 (не уверен, не тыкал, но вроде это оно), и облачный Retool. Для дашбоардов еще https://redash.io/.

Для кастомных workflow есть zeebe.io, Cadence, Conductor и другие.

Статические страницы и лендинги можно делать отдельными сервисами, с удобной админкой и аналитикой.

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

Что остается?

Похоже что заниматься "переупаковкой одних JSON в другие", скоро можно будет перестать?

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

Важные проблемы затронутые в комментах

  • Ограничение: Event Source дает Eventual Consistency (так сказали, я не уверен как это работает), от чего куча проблем.
    • Замечание: Многие перечисленные мною сервисы, работают напрямую несколько с одной БД, и соответственно такой проблемы нет. Некоторые считают что это не канон микросервисов, но лично я не вижу, в чем тут проблема.
  • Ограничение: чужие сервисы во внешней сети, так что кучу больших данных туда не перекачаешь. Так что внешние сервисы для многих аналитических задач вообще не подходят.
  • Ограничение: не все данные можно отдавать внешним сервисам
  • Сложность: жонглировать кучей сервисов может быть весьма запутанно
  • Риск: доступность и продолжение работы сервиса
  • Риск: стоймость при масштабировании может расти очень неприятно

Что я, собственно, хочу с вами обсудить?

  • Все ли так гладко, как я вижу?
  • Какие задачи непросто отдать на откуп сервисам сейчас? А какие будут создавать проблемы и в будующем, и вряд ли их можно так просто решить?
  • Какие еще полезные вещи мы научились отдавать в отдельные сервисы в последние годы, которые я не упомянул?
42 комментария 👇
Dmitry Gurinovich, Синьор Быкендер 15 июня 2020

Ох, всё в кучу свалил :)

У меня ощущение, что в посте подняты такие темы:

  • микросервисы vs монолиты
  • интеграция
  • NoCode vs InHouse development

Попробую ответить по этим темам.

Любое решение должно драйвиться поставленной задачей.

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

Бизнес-модель диктует также и модель развертывания: облако/необлако. В больших проектах под это все строится SDLC, процессы, CI/CD.

По темам:

  1. Микросервисы - это распределённая система. Со всеми вытекающими геморроями распределённых систем. Нужно понимать, какие данные можно отдать на откуп eventual consistency и пожертвовать ACIDом, а какие - нет. Event driven архитектуры подразумевают eventual consistency. Мне сейчас лень перечислять всю боль, с которой приходится иметь дело. Если есть выбор делать монолит или микросервисы - я бы начал с монолита и двигался в сторону микросервисов только в случае ральной необходимости. Ещё, к слову, микросервисы - это не только про построение систем, но и про построение процессов, овеянное DevOps культурой. Когда гемор распределённости - меньшее зло по сравнению с 500 девелоперами, набрасывающими в один монолит :)

  2. Интеграция со сторонними сервисами, например, с платёжными системами, биржами, etc. Тут ничего не поделаешь, если бизнес того требует - система становится распределённой. Гемор тут такой же как и в микросервисах. Но вынужденный, а не добровольный.

  3. Основная идея NoCode - использоване сторонних сервисов для экономии бюджета. В принципе, это та же интеграция как и в пункте выше. Имхо, подходит для MVP и небольших проектов. Но если сторонний сервис отвалился, то все, что ты можешь сделать - названивать им в саппорт и спрашивать когда починят. Тут вопрос в управлении рисками. Практика показывает, что когда бизнес растёт, такие сервисы превращаются из экономии бюджета в дыру в бюджете. Все равно приходится переписывать бэкенд для экономии/скейлинга/контроля. У Вастрика была недавно отличная статья про NoCode. Стоит упомянуть также юридические аспекты и вытекающие риски для бизнеса. Например, не все клиенты хотят авторизоваться через OAuth.

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

  Развернуть 1 комментарий

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

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

  Развернуть 1 комментарий

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

  Развернуть 1 комментарий

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

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

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

  Развернуть 1 комментарий

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

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

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

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

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

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

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

  Развернуть 1 комментарий

@uhbif19

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  Развернуть 1 комментарий

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

  Развернуть 1 комментарий
Kirill Nikitin, ИТ консалтинг 15 июня 2020

Вот эти все "микросервисы", "контейнеры", API и "работу с БД тоже можно генератором запилить" в комментарии выше очень интересно когда у вас маленькое приложеньейцО которое там сайты конструировать.
А когда у вас "маленькая тестовая базёнка" - это 3ТБ данных и в целом у вас 20+ТБ данных Data warehouse которые надо БЫСТРО вращать то вот иллюзия того что это всё можно заменить готовыми блоками быстро проходит.
А когда ещё из этого что-то большое и сложное надо собрать...

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

  Развернуть 1 комментарий

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

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

  Развернуть 1 комментарий

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

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

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

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

  Развернуть 1 комментарий

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

  Развернуть 1 комментарий

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

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

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

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

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

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

  Развернуть 1 комментарий

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

  Развернуть 1 комментарий

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

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

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

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

  Развернуть 1 комментарий

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

  Развернуть 1 комментарий

@dj_kill,

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

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

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

  Развернуть 1 комментарий

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

  Развернуть 1 комментарий

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

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

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

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

  Развернуть 1 комментарий

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

  • авторизация/аутентикация - интегрируешь сразу OKTA/DUO/Auth0 или разворачиваешь докер с KeyCloak в Azure или вообще используешь Azure AD вместо программирования своего бека авторизации с OpenID и JWT. Причём решения стандартные, если при скалировании та же OKTA станет слишком дорогой, то можно с неё перебраться на другой OpenID. Небесплатно и не без проблем, но в целом это реальная задача.
  • развёртывание и мониторинг инфраструктуры - всевозможные Prometheus/Influx/Greylog, сервисы типа DataDog/NewRelic решают.
  • workflow automation - это какие-нибудь BPMN-движки типа Camunda, Flowable и что там ещё бывает позволяют энкапсулировать тривиальную бизнес-логику (например там, где json-payload надо прогнать через некую систему правил и принять/отвергнуть/модифицировать/передать дальше)
  • аналитика самая разная - зыкрывается интеграцией Google Analytics, Application Insights, Tableau, PowerBI и кучей всего, что уже даёт и дешборды, и элементы ML/BigData прямо из коробки;
  • messaging и коммуникации (от email-рассылок до видеоконференций) - тоже сегодня мало кому придёт в голову писать что-то своё даже в большом старом бизнесе; все начнут с условного Mailchimpa и вебхуков в Slack, Teams и что там у них ещё есть.

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

  Развернуть 1 комментарий

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

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

  Развернуть 1 комментарий

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

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

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

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

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

  Развернуть 1 комментарий

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

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

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

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

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

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

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

  Развернуть 1 комментарий

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

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

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

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

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

  Развернуть 1 комментарий
Anatoly Shipitsin, Специалист по НЕХ 15 июня 2020

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

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

  Развернуть 1 комментарий

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

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

  Развернуть 1 комментарий

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

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

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

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

  Развернуть 1 комментарий

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

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

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

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

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

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

  Развернуть 1 комментарий

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

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

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

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

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

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

  Развернуть 1 комментарий

Перечитал пост дважды, но так и не понял суть новаторских идей, которые предлагает Hasura, а также при чем тут микросервисы (вроде бы хайп по ним торжественно завершился недавно с легкой руки Uber). Нельзя ли более полно раскрыть тему?

  Развернуть 1 комментарий

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

  Развернуть 1 комментарий

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

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

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

  Развернуть 1 комментарий
Semen Starostin, Руководитель ЦК .Net 24 июня 2020

Сама по себе идея взять и отдельную неизменную функциональность (например авторизация и аутентификация пользователей, рассылки разного рода, итд итп) вынести в отдельные сервиса которые крутятся в докере - очень здравая. Заказчик в этом случае получает быструю реализацию "обвеса" за меньшие деньги, разработчик не изобретает велосипеды и больше времени тратит на решение основной задачи и вроде как это win-to-win ситуация. И вот если это опенсоурс и мы можем хостить эти микро\макро сервиса на своих мощностях - это хорошо, но как только все это уходит в облако где нужно деньги платить , становится не по себе т.к. хочется иметь контроль над своими данными, сегодня сервис бесплатный, а завтра платный, сегодня он работает , а завтра не работает (гуглостартапы сему пример), а вы уже завязались на это все и теперь как то неудобно объяснять заказчику что если мы не начнем платить система авторизации нашей системы перестанет работать....

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

  Развернуть 1 комментарий
Alexander Babenko, Либертарианец, блогер, архитектор ПО 15 июня 2020

Я вижу примерно так: сложность и мастаб принятия решений будет уходить выше в сторону архитектора ПО: декомпозиция сервисов, проектирование АПИ, проектирование межсервисного взаимодейтсвия и вот это все.

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

В целом думаю, что будет лучше: будет больше переиспользования сервисов и решений - зачем из года в год писать одни и те же АПИ шлюзы и сервисы аутентификации, если можно взять и настроить существующий? Круды даже если писать самому, то тут кодогенерация нехило ускоряет: из OpenAPI спеки сервер отлично в гошечке генерируется: добавь хэндлеры. Работу с БД тоже можно генератором запилить. Т.е. механической работы будет меньше, а работа "думать" никуда не денется. Если какая-то механическая работа и останется, то будет олично делегироваться джунам или тем, кто в ИТ пришел за бабками, а не "из любви к искусству".

А так да, один из ключевых моментов: не стоит уповать на узкую специализацию - T-shaped, soft-skills и прочее разностороннее развитие - главный залог того, что тебя не заменит индус или бездушная машина (:

  Развернуть 1 комментарий

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

  Развернуть 1 комментарий

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

  Развернуть 1 комментарий
Artem Danilov, покоряю змеиный язык 15 июня 2020

Мне кажется всегда есть клиенты со своими безумными идеями(которые не очень получится реализовать на таких вот сервисах) и тут как раз таки нужны будут такие бекендщики.
Так же если учесть, где тебе нужно интегрировать n-ное количество других сервисов, то работа тоже найдется.

  Развернуть 1 комментарий
Anton Lebedev, программирую 16 июня 2020

Микросервисы будут писать микробекендеры. В общем, я бы сильно не переживал.

  Развернуть 1 комментарий

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

  Развернуть 1 комментарий
Yury Katkov, миддл формошлёп 19 июня 2020

Очень интересно было бы почитать про эти готовые круды, очереди и прочее, дайте ссылок для вхождения в тему?

  Развернуть 1 комментарий

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

  Развернуть 1 комментарий

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

  Развернуть 1 комментарий

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

  Развернуть 1 комментарий

😎

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

Что вообще здесь происходит?


Войти  или  Вступить в Клуб