Pull to refresh

Comments 15

После прочтения первой части статьи осталась одна мысль. Это не ты такой умный и сам изучаешь новые технологии в ИТ. А это объективные экономические законы ведения бизнеса и накопления капитала вынуждают тебя это делать. Просеивают через сито. Тех, кто не прошел отбор, просто съедают.
Вторая часть сильно напомнила прохождение этапов становления производства. И описанный сейчас этап и правда сильно напоминает переход от мануфактуры к фабрике и замену человеческого труда машинами.
Изменяются принципы проектирования программного обеспечения, удобство для использования в стандартизованных (на предыдущем этапе!) технологических и процессиях стеках становится обязательной основой в архитектуре и дизайне программного обеспечения.

К сожалению, пока что разработка stateful микросервиса, не рассчитанного на запуск в облаке в более чем одном экземпляре, обходится в разы дешевле (и для многих проектов реальной необходимости в поддержке HA и/или масштабирования для этого сервиса просто нет). Что сильно осложняет автоматическое управление этим сервисом в стиле AWS ECS.


Я к тому, что необходимые принципы проектирования уже есть, и давно (напр. https://12factor.net/ru/), но пока они не станут выгодны экономически описанного будущего нам не видать.

Какие факторы наиболее сильно влияют на экономическую составляющую вопроса? Скорость разработки? Оверхед гиперконвергентной среды? Еще что-то?

Сложность реализации. Скорость и стоимость разработки страдают как следствие увеличившейся сложности.


Когда у сервиса собственная БД под боком и он запущен в единственном экземпляре — открывается масса возможностей как написать его проще, быстрее и эффективнее:


  • сервис может использовать любой подходящий под его данные формат БД (от подключения к сторонней SQL/NoSQL СУБД до бинарных или json-файликов у себя на диске), что упрощает реализацию сервиса и позволяет сделать его более производительным
  • сервис может работать со своими данными не беспокоясь о блокировках, а транзакции используя только там, где это необходимо для сохранения целостности БД (напр. подменяя изменённые json-файлы атомарной операцией перемещения файла)
  • сервис может кешировать в памяти всё, что хочет, включая держать вообще всю БД в памяти если влазит (а она часто влазит — у "микро"сервисов зачастую и данных тоже "микро") и в этом есть смысл (a-la "memcached inside") и этот кеш очень легко поддерживать в актуальном состоянии
  • нет необходимости реализовывать одновременную поддержку двух версий структуры БД в одной версии сервиса — ведь миграцию БД можно делать между отключением старой версии сервиса и запуском новой
  • etc.

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


Учитывая, что обычно микросервисы достаточно мелкие, объёмной и сложной бизнес-логики в них обычно нет, то основное время на их реализацию тратится именно на такого рода "служебные" задачи. И когда сложность этих служебных задач настолько увеличивается — скорость и стоимость разработки и тестирования сервиса ухудшаются в разы.

Совершенно верно "стейт" — это сложно и затратно. Но набив руку вы не сядите в лужу…
Если вы строите чтп-то новое, то все карты в руки.
Задача сводится к отдалению "стейта" например туда где эго мэнджмент уже решон, например нормально настроеная NoSQL.
Есть мног итнересных паттернов… и возможностей избежать сейта или жить с его не синхроными копийми или или или..


П.С. за последний год переписал часть одной легаси системы. Около 10 новых микросервисов, пока только один со стейтом и не скалируется, то такой мощный что его хватит на 100% рот нашего лоада…
а главнео мы когда этотот 100% лоад достигнем и стнем лиллионерами :) просто заменим этот сервис за пру спринтов.

Если данные тупо оторвать от сервиса переместив их в СУБД — stateless сервис мы не получим. Мы получим сервис, состоящий из двух сильно связанных частей, одна в виде как-бэ stateless сервиса, вторая в виде данных в БД.


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


P.S. Что касается "набивания руки" и "луж" — я микросервисы пишу примерно с 2009 (да, этого термина тогда ещё не было). Так что рука уже давно отбита напрочь. Но описанную проблему это не решило.

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


Я поясню и так. Мы написали олколо 10 новых сервисов, делающих тоже самое что старый монолит, но посколько мы изначально думали о том что такое "shared state".
Все они имеют кой-то стейт и это не проблема. Проблема возникает если вы вдруг водите "shared state" и считаете что именно так и никак иначе в вашей архитектуре быть не может.
Конечно это зависит от задачь, но я в работл во многих индустриях и проблемы на самом деле обысчно очень похоже… И я почти уверен что распределенный стейт можно локализировать и особо к нему подойти. В этом то и ошибка многих команд, что к нему не достаточно внимания.


Давайте конкретенее… Вот раньше сесси на стороне сервиса/сервера были проблемой, сечас сессионый статус держит клиент — и это очень элегантный выход из моних ситуаций…
Мы используем еще внешние системы которы звонятнаам по колбэкам. В одном случае мы встроили наш ключ в callback url в данном случает хэто позволяет полностью избежать знание о друг други или общис стейт между звонящим и принимающим звонок сервис.
Хорошо вы скажете а как же вы будете скалировать ваш User data сервис… ну очень надо 10 инстанций… Тут вот и есть вопрос загнанного в угл "shared state".
И тут вы может епринять решения.


Ответьте себе на впрос вам дейтвительно нужно ACID или вполне достачно BASE.
Вообще-то в реальная жизнь тоже поххоже на BASE и на событийную архитектуру…
Если каждая инстанция сервиса имеет свою наиболее актуальную версию стейта, но без гарантии — это BASE и это отлично скалиерует. С паттернами Event Sourcing и CQRS вообще открываются очень интересные возможности.
А если вы уверены что вам нуже только ACID и только он — ну да это не скалирует…


Но может вы говорите о кластере сервисов которы в волатильной памяти должны держать "shared state", бывает и такие задачи, но тут возникаакуут вопрос, что именно это за стейт? Может это просто кэш? возмите что-то готовое, есть кучу решений…
Я вот очень сильно хотел бы прочитать о вашем примере…
Но и на это случай полно очень продуманых штук от навароченых библиотек Apache Ignite до простых распределенных примитивом или реализаций протоколов выбора лидера… — Но оно вам надо? моя практика показвыет что обычно это идет в бой когда девелоперы хотят поробовать новые штуки а не когда это действительно нужно и без это-го никак.

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


Я же говорю о том, что всё это усложняет реализацию и в 2-3 раза увеличивает время (и, соответственно, стоимость) разработки среднего микросервиса. И поэтому в проектах, в которых нет необходимости масштабирования и/или HA для этого stateful сервиса — бизнесу не выгодно тратить в разы больше ресурсов на то, чтобы сделать этот сервис stateless.


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

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

Внезапно, в тренде сейчас DevOps. 10% рост за три года — это очень круто

Не-а, это просто мышкофтыкатели не спят — как было с админами в свое время, но теперь они пишут(на том же hh тонны их), что они таки уже не просто админы, а девопсы и точно также утягивают на дно теперь и это понятие :)
Так, что я просто вангую через годик на самом деле уже есть будет куча вакансий типа *нужен инженер девопс с навыками замены печек в принтерах и протяжкой видеонаблюдения*
судя по описанию, к работе SRE или process automation scientist aka «человек-девопс» это вакансия вообще никакого отношения не имеет

либо имеет, но они не смогли выразить свои желания в тексте

может, стоит оказать им платную консультацию, и объяснить суть проблемы? :)
Рискну предположить, что суть комментария была в том, что пункт «10% за три года — это очень круто» некорректен из-за большого количества мусорных вакансий, не имеющих никакого отношения к этой теме.
простите, а «от 60 000 до 80 000 руб.» — это в месяц или в год?
Ну так хрюши начали вставлять модные слова в вакансии — и соискатели подтягиваются.
Важно тут концентрироваться не на конкретных именах продуктов или компаний (типа Jenkins и Ansible), а на потребностях наших команд (например, возможности быстрой интеграции изменений), чтобы развивать доверие к самому девопсу в целом.

Вот. Потребности команд. «Золотые слова Юрий Венедиктович» ©
Решать проблему, а не стремиться вкрутить еще больше сложновыдуманных нетривиальных инструментов.
Лучи ненависти в сторону PowerShell и DSC, которые, на мой взгляд, созданы без оглядки на прошлый опыт и скорее с желанием придумать нечто новое прикольное, чем решить досадные ограничения bat-скриптов.
Sign up to leave a comment.