Заменят ли готовые (микро) сервисы бэкендеров и чего для этого не хватает
Публичный пост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 (так сказали, я не уверен как это работает), от чего куча проблем.
- Замечание: Многие перечисленные мною сервисы, работают напрямую несколько с одной БД, и соответственно такой проблемы нет. Некоторые считают что это не канон микросервисов, но лично я не вижу, в чем тут проблема.
- Ограничение: чужие сервисы во внешней сети, так что кучу больших данных туда не перекачаешь. Так что внешние сервисы для многих аналитических задач вообще не подходят.
- Ограничение: не все данные можно отдавать внешним сервисам
- Сложность: жонглировать кучей сервисов может быть весьма запутанно
- Риск: доступность и продолжение работы сервиса
- Риск: стоймость при масштабировании может расти очень неприятно
Что я, собственно, хочу с вами обсудить?
- Все ли так гладко, как я вижу?
- Какие задачи непросто отдать на откуп сервисам сейчас? А какие будут создавать проблемы и в будующем, и вряд ли их можно так просто решить?
- Какие еще полезные вещи мы научились отдавать в отдельные сервисы в последние годы, которые я не упомянул?
Ох, всё в кучу свалил :)
У меня ощущение, что в посте подняты такие темы:
Попробую ответить по этим темам.
Любое решение должно драйвиться поставленной задачей.
Задача диктует то, с какими данными приложение должно работать, границы транзакций, требования к целостности, текущий и будущий характер наргрузки, масштабируемости, стоимости и т.п.
Бизнес-модель диктует также и модель развертывания: облако/необлако. В больших проектах под это все строится SDLC, процессы, CI/CD.
По темам:
Микросервисы - это распределённая система. Со всеми вытекающими геморроями распределённых систем. Нужно понимать, какие данные можно отдать на откуп eventual consistency и пожертвовать ACIDом, а какие - нет. Event driven архитектуры подразумевают eventual consistency. Мне сейчас лень перечислять всю боль, с которой приходится иметь дело. Если есть выбор делать монолит или микросервисы - я бы начал с монолита и двигался в сторону микросервисов только в случае ральной необходимости. Ещё, к слову, микросервисы - это не только про построение систем, но и про построение процессов, овеянное DevOps культурой. Когда гемор распределённости - меньшее зло по сравнению с 500 девелоперами, набрасывающими в один монолит :)
Интеграция со сторонними сервисами, например, с платёжными системами, биржами, etc. Тут ничего не поделаешь, если бизнес того требует - система становится распределённой. Гемор тут такой же как и в микросервисах. Но вынужденный, а не добровольный.
Основная идея NoCode - использоване сторонних сервисов для экономии бюджета. В принципе, это та же интеграция как и в пункте выше. Имхо, подходит для MVP и небольших проектов. Но если сторонний сервис отвалился, то все, что ты можешь сделать - названивать им в саппорт и спрашивать когда починят. Тут вопрос в управлении рисками. Практика показывает, что когда бизнес растёт, такие сервисы превращаются из экономии бюджета в дыру в бюджете. Все равно приходится переписывать бэкенд для экономии/скейлинга/контроля. У Вастрика была недавно отличная статья про NoCode. Стоит упомянуть также юридические аспекты и вытекающие риски для бизнеса. Например, не все клиенты хотят авторизоваться через OAuth.
Мораль: есть проекты, где такой подход отлично работает, а где-то - нет. Решение должно определяться поставленной задачей, оценкой рисков и ограничениями.
Вот эти все "микросервисы", "контейнеры", API и "работу с БД тоже можно генератором запилить" в комментарии выше очень интересно когда у вас маленькое приложеньейцО которое там сайты конструировать.
А когда у вас "маленькая тестовая базёнка" - это 3ТБ данных и в целом у вас 20+ТБ данных Data warehouse которые надо БЫСТРО вращать то вот иллюзия того что это всё можно заменить готовыми блоками быстро проходит.
А когда ещё из этого что-то большое и сложное надо собрать...
Телевиденье не убило радио и театр.
Виртуализация и облака не убили bare metal фермы.
Но да, в актёрах остаются только реально талантливые. А свой софт начинают писать когда это реально надо.
На опыте большой галеры вижу такие сферы, где сложность бекенд разработки существенно снизилась и где теперь (условно) сениоры не нужны, а задача решается интеграцией готовых платформ/сервисов даже в кровавые энтерпрайзы:
Без сениор-бекендеров пока можно собрать MVP для, пожалуй, любой задачи. Но ни одного реального проекта для крупного бизнеса без команды бекенд-разработиков я не видел, даже если это будет проект для очень прогрессивной компании, не обремененной легаси.
Нууу... тут могу сказать что с подобными мотивациями делали SQL. Да SQL первоначально язык запросов для простых смертных. И посмотрите теперь во что он выродился :)
Сейчас есть один интересный вариант который претендует на роль SQL это GraphQL. Да я знаю он от Facebook и страшный как смертный грех, но идея его именно в том чтобы убрать backend. Технически первый кто сможет внятно прикрутить его к СУБД получит возможность избавиться от большей части рутины в backend.
Перечитал пост дважды, но так и не понял суть новаторских идей, которые предлагает Hasura, а также при чем тут микросервисы (вроде бы хайп по ним торжественно завершился недавно с легкой руки Uber). Нельзя ли более полно раскрыть тему?
Сама по себе идея взять и отдельную неизменную функциональность (например авторизация и аутентификация пользователей, рассылки разного рода, итд итп) вынести в отдельные сервиса которые крутятся в докере - очень здравая. Заказчик в этом случае получает быструю реализацию "обвеса" за меньшие деньги, разработчик не изобретает велосипеды и больше времени тратит на решение основной задачи и вроде как это win-to-win ситуация. И вот если это опенсоурс и мы можем хостить эти микро\макро сервиса на своих мощностях - это хорошо, но как только все это уходит в облако где нужно деньги платить , становится не по себе т.к. хочется иметь контроль над своими данными, сегодня сервис бесплатный, а завтра платный, сегодня он работает , а завтра не работает (гуглостартапы сему пример), а вы уже завязались на это все и теперь как то неудобно объяснять заказчику что если мы не начнем платить система авторизации нашей системы перестанет работать....
Тем не менее я не разделяю опасения автора что разработчики теперь будут не нужны, я считаю, что при таком сценарии развития событий разработчики меньше начнут делать велосипеды (пусь и очень качественные) и начнут больше посвящать времени бизнес задачам для которых в большинстве случаев готовых решений не существует.
Я вижу примерно так: сложность и мастаб принятия решений будет уходить выше в сторону архитектора ПО: декомпозиция сервисов, проектирование АПИ, проектирование межсервисного взаимодейтсвия и вот это все.
Сами круды могут и остаться, но таких бекендеров будут ВУЗы клепать тысячами в год. Естественно, останется более хардкорная и задротская работа: написание сложной бизнес-логики, профилирование и оптимизация для всякого хайлоада, какие-то ML решения и прочие, выходящие за рамки типичного бекендера.
В целом думаю, что будет лучше: будет больше переиспользования сервисов и решений - зачем из года в год писать одни и те же АПИ шлюзы и сервисы аутентификации, если можно взять и настроить существующий? Круды даже если писать самому, то тут кодогенерация нехило ускоряет: из OpenAPI спеки сервер отлично в гошечке генерируется: добавь хэндлеры. Работу с БД тоже можно генератором запилить. Т.е. механической работы будет меньше, а работа "думать" никуда не денется. Если какая-то механическая работа и останется, то будет олично делегироваться джунам или тем, кто в ИТ пришел за бабками, а не "из любви к искусству".
А так да, один из ключевых моментов: не стоит уповать на узкую специализацию - T-shaped, soft-skills и прочее разностороннее развитие - главный залог того, что тебя не заменит индус или бездушная машина (:
Мне кажется всегда есть клиенты со своими безумными идеями(которые не очень получится реализовать на таких вот сервисах) и тут как раз таки нужны будут такие бекендщики.
Так же если учесть, где тебе нужно интегрировать n-ное количество других сервисов, то работа тоже найдется.
Микросервисы будут писать микробекендеры. В общем, я бы сильно не переживал.