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

На заре 21 века для решения этой проблемы появились многоядерные процессоры: будем не частоту увеличивать, а число ядер. Однако ядра не берутся из ниоткуда, их нужно было встраивать рядом с уже имеющимся ядром. Как этого достичь? Можно увеличивать число транзисторов на единицу площади (уменьшение техпроцесса), пытаясь обуздать физику p-n перехода и свойства полупроводников. Можно увеличивать размер кристалла, что связано с увеличением брака, или количество самих кристаллов (чиплетная архитектура).

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

Если мы говорим о написании бизнес-кода, то зачастую управление потоками любезно скрыто от нас под капотом удобного API фреймворка или библиотеки. За это хочется сказать отдельное спасибо их мейнтейнерам: при перекладывании json'а 🐵 нам почти не приходится задумываться о том, что мы работаем в многопоточной среде. Почему "почти"? К сожалению, при совместном доступе к разделяемым данным проблемы вроде race condition или data race все еще могут возникнуть. Если ваш бизнес-код взаимодействует с внешними ресурсами (БД, кэшем, файлами и т.д.), то ошибки проектирования могут проявиться даже при использовании высокоуровневых абстракций. И все же написание многопоточного кода стало довольно нишевой штукой, которая чаще всего встречается при разработке самих фреймворков и библиотек.

Разработчики начали понимать, что без базовых знаний, как работать в многопоточной среде не обойтись, хотя на собеседованиях многие все равно недоумевают от вопросов по этой теме. Но жизнь идет и настаёт время новых вызовов. Сейчас в России их два:
1️⃣ крупные компании испытывают проблемы с получением современного железа в желаемом объеме (значительно выросли цены и усложнились логистические цепочки)
2️⃣ рост трафика на внутренние сервисы (ведь доступ к зарубежным ограничен)

В этих условиях от разработчика требуется не только чтобы приложение работало быстро. Оно должно эффективно утилизировать имеющиеся ресурсы. Если говорить о CPU-intensive приложениях, то тут в первую очередь нужно будет работать над реализацией эффективных алгоритмов. Если же говорить о сервисах с большим числом интеграций, то один из способов увеличения пропускной способности — избегать любых блокировок потоков (VPN тут не поможет 😃). Блокирующие операции, такие как ожидание завершения другого потока, ответа от базы данных или очередного микросервиса, приводят к простоям приложения. Избежать этого помогают асинхронные неблокирующие подходы. Делаю предположение, что количество проектов, реализующих такую концепцию, в энтерпрайзе будет только расти.

Как с этим обстоят дела в полях? Мне довелось общаться с Java-разработчиками из разных компаний, и я часто слышал, что Reactor/WebFlux у них не прижился из-за сложности разработки и поддержки написанных на нем приложений. Понятно, почему все так полюбили Go — там асинхронный неблокирующий код относительно легко готовить. В Kotlin асинхронные цепочки спрятаны за корутинами, если вы используете библиотеку kotlinx-coroutines-reactor, что достаточно сильно упрощает бизнесовый, но не библиотечный код.

В новому году посмотрим, сбудется ли мой прогноз. По крайней мере рост числа проектов на Go уже заметен. Посмотрим, что будет с таковыми на Java и Kotlin 😎.

Кажется, на новый год мне пожелали мало здоровья — проболел все праздники 😁 ОРВИ, будь она неладна...

В мои планы на эти длинные каникулы входило разобраться наконец c Istio (Service Mesh в k8s), так как изученного в прошлом году ванильного кубера для решения рабочих задач решительно не хватает. Но, как вы понимаете, этим планам не суждено было сбыться. Вооружившись таблетками и спреями, я лежал на диване у купленного почти три месяца назад, но почти не использовавшегося, 65-дюймового ТВ.

В обычное время я сериалами не увлекаюсь, как-то не до них, но раз выдалось подходящее время, то почему бы не глянуть пару-тройку? Настроение было смотреть сериалы про времена СССР. Интересное настроение, не правда ли 😅?

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

Комитет — про хороший СССР. Бодрый и бойкий сериал о работе и жизни трех друзей КГБшников от НТВ кто бы сомневался😃. Сюжет тянется через года: начали в 1970-ые, а закончили — в нулевые. Менялись политический строй, общество, люди. На этом фоне было увлекательно наблюдать, как друзья проживали такие похожие, но в то же время такие разные судьбы.

Игры — реалистично? про СССР. Сериал про Олимпиаду 80 и события, которые ей сопутствовали. Намешали целый ворох клеше, но странным образом это сработало. Мне было увлекательно и интересно. Я этой истории поверил.

Красная королева — про плохой СССР. Сериал про советскую модель с непростой судьбой от Первого канала. Спойлер: от серии к серии жизнь главной героини становится все невыносимее, причем воспринимается все очень органично. Эту историю было морально тяжело смотреть. Без КГБшников тут не обошлось. Увы, хэппи энда не случилось. Кажется ,что такое лучше не показывать на федеральном канале. Правда, жена сказала, что она с бабушкой по ТВ в детстве только такие сериалы и смотрела .

Чтобы разбавить это историческое трио, я обратился к дуэту про Папу Римского. Тем более хотелось посмотреть что-то более жизнеутверждающее. Молодой Папа и Новый Папа — хорошо показывают, что такое церковь и какой она должна? быть. Мне оказался по душе этот микс сарказма, эпатажа и философских размышлений. Джуд Лоу в роли Пия XIII стал украшением этой работы. Даже захотелось взять себе на вооружение несколько цитат на будущее.

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

Кажется, что после предновогоднего поста можно было бы списать Java со счетов: уж больно сложно на нем писать асинхронный неблокирующий код. Встроенный CompletableFeature имеет существенные архитектурные ограничения в виде невозможности отмены асинхронной таски, а Reactor/WebFlux сложны, да и реактивность не всем нужна.

Для интереса на github выполнил два поисковых запроса: "Flux<" language:Java вернул 158k результатов, а "Mono<List" language:Java — 19k. Ни на что не намекаю 😃

Грусть, печаль и тоска. Так Java уже все или еще нет? Мы же совсем недавно заикались о Project Loom здесь. Идея проекта в том, что JVM научили переключать поток на выполнение чего-то полезного, если он заблокирован, например, IO.

Крупные ребята, вроде Netflix, уже вовсю тестируют силу виртуальных потоков, и огребают, но не по собственной вине, о чем рассказывали у себя блоге. В чем была причина? Если кратко, то виртуальные потоки пока плохо дружат с synchronized методами и блоками, что может приводить к deadlock'ам. В марте в 24-ый релиз Java должны завезти фикс. Если он все же не станет LTS, то придется ждать до сентября, если роадмап не поменяют. Так что пока нужно быть осторожнее, тем более в проде.

Как виртуальные потоки выглядят в коде?

try (var executor = Executors.newVirtualThreadPerTaskExecutor()) {
  var user = executor.submit(() -> userRepository.find(userId));
  var projects = executor.submit(() -> projectRepository.find(userId));
  return new Profile(user.get(), projects.get());
}

Вполне симпатично, почти как в Kotlin:

val Dispatchers.LoomDispatcher: CoroutineDispatcher
    get() = Executors.newVirtualThreadPerTaskExecutor().asCoroutineDispatcher()

...

suspend fun getProfile(userId: String): Profile = withContext(LoomDispatcher) {
    val userDeferred = async { userRepository.find(userId) }
    val projectsDeferred = async { projectRepository.find(userId) }

    Profile(userDeferred.await(), projectsDeferred.await())
}

Даже Structured Concurrency выглядит сносно, хотя scope.join() выглядит криво:

try (var scope = new StructuredTaskScope<>()) {
  var user = scope.fork(() -> userRepository.find(userId));
  var repositories = scope.fork(() -> projectRepository.find(userId));
  scope.join();
  return new Profile(user.get(), repositories.get());
  }
}

В общем не все так плохо. Project Loom — сильная фича, которая почти не потребует роста экспертизы разработчиков, но значительно повысит пропускную способность уже написанных проектов. Kotlin тоже выиграл, так как корутины дружат с виртуальными потоками. Так что с Go мы еще поборемся 🔫

Может я сильно придираюсь? Позвольте мне наехать на процесс восстановления пароля на сайте pochta.ru 🤣

На волне различного рода утечек на всех ресурсах, где это было возможно, я подключил двухфакторную аутентификацию (two-factor authentication, 2FA). Обычно в качестве второго фактора в дополнение к паролю используются sms- или email-коды. Эти факторы могут не сработать, если ваша почта недостаточно защищена или вы потеряете/оставите без внимания смартфон, на котором:
1️⃣не будет установлен пин-код на сим-карте (злоумышленник просто вставит ее в свой смартфон и начнет получать смски). Как его установить?
2️⃣ не настроена блокировка экрана (с паролем/FaceID и т.п.)
3️⃣ не защищены паролем приложения почты и смс-сообщений и уведомления от них

Но на этом настоящие тревожные пирожочки не останавливаются.

На волне мошеннических действий с SMS-кодами я перевел, где это было возможно, 2FA на one-time password (OTP) для лучшей защиты своих аккаунтов.

Почему это актуально? Во-первых, есть такая угроза, как SIM Swapping или SIM-jacking (замена SIM-карты через сотрудника вашего оператора). Во-вторых, я не видел ещё ни одной новости, где жертва передала OTP-код: если с смсками глаз у многих уже замылился, то к OTP пользователи относятся более внимательно.

Конечно, такие меры защиты наиболее актуальны для аккаунтов банков, Госуслуг и других государственных структур. Так вот, если вы начнёте процедуру смены пароля на сайте Почты России, то второй фактор будет выключен (о чем вам сообщит соответствующее письмо выше). Останется только один фактор в виде кода из смс. Выглядит несекурненько.

Какие варианты решения проблемы я вижу?
* использовать email как второй фактор
* использовать заранее выданные проверочные коды (такие, например, Github выдает, когда вы 2FA подключаете)
* использовать для проверки авторизацию через Госуслуги

Надеюсь, что Почта все же залатает эту брешь в нашей с вами безопасности 🎹

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

Преимущественно про Мой Офис шел разговор, но также зацепили Астру, Росу, Постгрес. Посмотрел на одном дыхании на 2x, конечно 😎. Приятного просмотра.

Весь прошлый спринт решал интересную рабочую задачу: нужно было настроить маршрутизацию в тестовом кластере k8s с Istio таким образом, что при добавлении в запрос пользователем заголовка X-MOCK трафик бы маршрутизировался на инстанс WireMock вместо своего обычного маршрута. Давайте разбираться по порядку.

Думаю, что такое k8s всем и так понятно, но что такое Istio?

Istio — расширение для k8s, которое реализует концепцию service mesh для управления взаимодействием между сервисами. Оно предоставляет такие возможности, как балансировка нагрузки, мониторинг, управление трафиком, безопасностью и политиками доступа налету, не требуя изменений в коде приложений. Service mesh реализуется как набор прокси-серверов, а именно sidecar-контейнеров с Envoy, которые размещаются рядом с каждым сервисом и перехватывают весь входящий и исходящий трафик.

Под каждым istio-proxy-сайдкаром на прикрепленной монструозной картинке (для простоты istio-proxy отображено схематично, получилось больше похоже на Istio Ambient -- sidecarless Istio) можно посмотреть конфигурацию его VirtualService.

Для чего в описанной схеме WireMock?
* сервисы смежных команд прилегли отдохнуть или вовсе еще не были подняты, но надо продолжать разработку/тестирование
* нужно смоделировать какой-то сценарий, для которого долго/дорого заводить тестовые данные в интеграционные сервисы

Схему, которую реализовал на данный момент, представлена на скрине под заголовком Как стало: для сервисов, которые должны реагировать на наличие заголовка X-MOCK, добавляем маршруты VirtualService для istio-proxy. На wiremock зашиваем нужный нам ответ, который будем отдавать по заданному шаблону запроса. WireMock также умеет проксировать запросы, если например, ни один шаблон не будет задан:

{
    "priority": 99999,
    "request": {
        "method": "ANY",
        "urlPattern": "/internal/cards"
    },
    "response": {
        "proxyBaseUrl": "http://gateway.outbound-apps"
    }
}

Для таких правил задаем низкий приоритет (большое значение priority).

На этом план-минимум выполнен 👏. В качестве задания со ⭐️ мне хочется настроить динамический выбор subset в зависимости от приходящих заголовков, чтобы не прописывать каждое правило в VirtualService явно. Здесь есть две проблемы:
1) синтаксис subset: $dynamic-subset-depend-on-x-feature не поддерживается VirtualService, subset должен быть задан литералом
2) если вычисленный subset не существует, то запрос упадет. Такое поведение возможно, но хотелось перенаправить запрос на заранее выбранный subset, например, default

В Алибабе сделали как раз то, что мне хотелось бы реализовать в целевом решении, а именно динамически вычисляемый subset + fallback для случая, когда нужный subset не найден для сервиса, в который планируем отправить запрос. Проблема в том, что в официальных релизах Istio такой функциональности нет 🤩

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

Это я, отдохнувший за выходные, сфотографировался на карту болельщика, чтобы в конце марта сходить на матч Зенит-Рубин. Оформление хоть и не очень сложное (через отдельное приложение Госуслуг), но требует отсканировать чип действующего загранпаспорта паспорта (это которые на 10 лет оформляются, в пятилетних чипа нет). Первый раз приложение зависло при считывании на 0%, но со второго раза процедура прошла успешно. Прощаю, не пришлось идти в МФЦ 🎉.

Почему недостаточно тех данных, что есть уже есть на Госуслугах — непонятно. Помнится, что взятая дистанционно 5 лет назад ипотека и то проще оформлялась 🤩.

P.S. Если еще не оформили замозапрет на взятие на вас кредитов и займов (защищаемся от мошенников, можно снять в любой момент), то можете сделать это через Госуслуги онлайн. Чувствую, что сейчас по стране прокатится волна звонков от мошенников, которые будут "помогать оформлять самозапрет".

P.P.S. Не шарьте экран своего телефона посторонним людям. Могут попытаться авторизоваться и увидят sms-код, который придет вам в уведомлении. Другие рекомендации описал тут.

P.P.P.S. Еще участились сливы ФИО коллег по работе (не моей, а в принципе). Ссылаясь на ФИО начальника или коллеги к вам могут втереться в доверие. Соблюдайте бдительность 😎

Срочные задачи — бич современного IT или как сделать так, чтобы сотрудник не спрашивал:

А эта задача просто срочная или срочная-срочная?

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

А в чем проблема проблема?
☝️Команда/сотрудник работает в состоянии хронического стресса, бесконечного аврала, постепенно выгорая,
и/или
☝️спринт команды продолжает наполняться задачами после этапа планирования, что приводит к невыполнению плана,
и/или
☝️сдвигаются сроки поставки запланированных фич.

Исходя из моего опыта, самое главное — понять, с чем мы столкнулись: искусственно созданная срочность или реально срочная задача?

Враг 1. Рили срочная задача

Бывают такие продукты и компании, которые не могут развиваться тихо, мирно, планомерно. Если ваши команда/компания/продукт должны давать молниеносные ответы на вызовы судьбы (адаптация к всплескам активности пользователей; стабилизация сервиса в ходе DDOS-атак; реализация фичи, как компенсирующая реакция на действия конкурентов и т.п.), то от срочных задач никуда не деться. Это вполне нормально, если вы заранее понимали, на что подписывались. Надеюсь, от вас этого не скрывали 😑

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

Решение:
1) Срочные задачи стали нормой уже после вашего прихода в команду (время идет — все меняется), или вы не поняли об этом на этапе собеседований (по своей вине или вине работодателя)? Это уже не так важно. Если вам не подходит такой темп работы, то лучше уволиться и не мучить себя.
2) Если увольнение — не ваш вариант, то стоит подстелить себе соломку, чтобы комфортно работать в долгосрочной перспективе. Каким образом? Если срочные неотложные задачи появляются часто, то в зависимости от используемой методологии команда при планировании должна систематически закладывать на них 10/20/...% спринта (scrum) либо сдвигать сроки по разрабатываемым фичам (kanban).

Враг 2. Искусственносрочная задача

Коллега создает ощущение срочности там, где её нет, чтобы заставить команду:
1) либо работать в ускоренном режиме
2) либо отвлечься от взятых в спринт задач

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

Решение:
1) вместе с заказчиком нужно понять, является ли прилетевшая задача, действительно, срочной. Как это сделать? Оценить профит/последствия, если мы ее сделаем/не сделаем. Может она подождет до следующего планирования?
2) не все заказчики готовы к открытому диалогу, поэтому пункт 1 не всегда сработает в моменте. В этом случае рекомендую на дистанции собрать статистику таких задач и их последствий для планов/сроков. Ее можно будет обсудить на ретро команды с заказчиком. Обычно собранная и хорошо представленная фактура действует очень отрезвляюще.

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

Разберём на примере выбора хранилища в существующем проекте под новую задачу.

1️⃣ Должна решаться поставленная задача

Если задача не решается, то мы такое решение / технологию в расчёт не берём. Сильно? Я тоже так думаю, однако на практике могут возникнуть сложности.

- Как будем работать с денормализованными данными? Возьмём наш PostgreSQL или поднимем MongoDB? Документы будут большие, в TOAST придется залезть.
- Напрашивается MongoDB. А какие нагрузки предполагаются и какой объем данных будем хранить?
- Бизнес пока не понимает.
- Нам же транзакции не нужны будут? Может Redis возьмём?
- Нужно познакомиться c его API.

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

2️⃣ Простота

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

- Изучил документацию. Redis не подойдёт, слишком бедный API. Еще бизнес с фактурой по нагрузке вернулся: клиенты — юридические лица, объем хранения данных и RPS'ы скромные будут. Самое время разобраться с MongoDB на такой простой задаче!
- Но у наших разработчиков и SRE нет компетенции в MongoDB. PostgreSQL с такой задачей легко справится.
- Научатся! Еще одна технология будет в нашем арсенале.

Готовы ли мы принять новую зависимость в проект, тем самым значительно усложнив систему? Что компенсирует негативные факторы, которые окажутся на второй чаше весов:
* усложняется найм и онбординг новых, а также требуется адаптация "старых" сотрудников (разработка/DevOps/SRE)
* требуется поддерживать в актуальном состоянии скрипты раскатки с версиями раскатываемой инфраструктуры, документацию, базу знаний, мониторинги
* усложняется обновление самих сервисов в связи с подключением новых библиотек/стартеров (привет, Spring Hell 🖕)
* больше потенциальных уязвимостей и багов в системе
* в связи с перечисленным могут страдать бизнес-метрики

3️⃣ Стандартизация

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

- Ради одной задачи разбираться с новой базой? Не перебор?
- Архитектор передал, что MongoDB одобрили для занесения в стек компании. В ближайшее время планируется значительный рост числа задач, где MongoDB будет необходима.

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

А когда новые технологии пробовать? Стандарты могут и должны пересматриваться, если это оправдано. Мы сами недавно с Prometheus на Вику мигрировали, с Mesos на k8s, с Hazelcast на Redis.

4️⃣ Гибкость

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

- А как мы события будем получать? Через Kafka?
- Тот же PostgreSQL можно использовать для простой очереди, судя по аналитике нам должно этого хватить.

PostgreSQL и Redis, например, за счет расширений и внутренней архитектуры могут хорошо справляться не только со своими "прямыми обязанностями".

P.S. последние 4 года эта логика меня не ни разу подводила, движемся дальше 🏃‍♀️

«Моей матерью был компьютер»

Сходил на выставку о том, как как искусственный интеллект меняет окружающий нас мир. Галерея Цифергауз, что в Новой Голландии, в Питере, как всегда радует качественным контентом. Для меня она стала своего рода продолжением выставки-размышления «Конструктор EGO», проходившей летом прошлого года в не менее прогрессивном Третьем месте. Она, однако, была направлена уже на изучение мира внутреннего. Горячо рекомендую посещать эти места-жемчужины 🥰

---

А что по новостям искусственного интеллекта так сказать с полей?

У нас в компании продолжают активно внедрять AI в двух направлениях:
1️⃣ для ревью PR (пока результаты удручающие)
2️⃣ для упрощения кодирования

По второму пункту, как и у всех, есть успехи. Развернули DeepSeek во внутреннем контуре и прикрутили его в IDE-плагин Continue, которому можно скармливать открытый проект для наполнения контекста. Плюсы решения в целом понятны: данные не утекают наружу + проводим донастройку под свои задачи.

От моего друга-синьора-дата-инженера знаю, что в Ozon тоже подняли свою локальную инсталляцию. Тем не менее там еще остаются команды, которые пишут код по-старинке, используя белковые мозги. Мой друг до пятницы был в их числе. Поздравил его с тем, что он теперь тоже на "игле" и сможет по скорости работы конкурировать с вчерашними джунами. Мой друг-go-разработчик из СберКлауда пока сопротивляется, удивляясь производительности своего коллеги. Друга пока не увольняют, потому что есть еще один менее продуктивный, чем он сам, разработчик. Шутка (?). Так что ИИ пока погромистов не заменил.

ИИ научился кодить.
Ожидание: вайбкодинг 👦
Реальность: бизнес дает в 10 раз больше задач 🤣

---

В YT как на дрожжах появляются видео про low‑code / no-code платформу n8n.io. Если кто еще не в курсе, то с ее помощью вы можете строить пайплайны из классических (tg, Slack, Google и т.д.) и "умных" (ChatGPT, YandexGPT, или, например, OpenRouter, если хочется бесплатно) API для автоматизации разного рода сценариев, используя визуальный интерфейс. Если не готовы платить денежку за сервис, то можно развернуть его как как self-hosted на своем VPS. На зарубежных фриланс-площадках тысячи предложений по автоматизации с помощью n8n.io, make.com. Наши умельцы на фрилансе уже готовы поднять n8n за вас за скромную сумму. Думаю, что часть исполнителей уже написала свой Ansible-плейбук, другая — использует elest.io, а третья — делает все ручками. Сам сценарий тоже разработают, но значительно дороже: тут уже "наукоемкость" какая-то появляется.

Малый, как в целом и средний и крупный, бизнес теперь может буквально за копейки получить то, на что раньше не хватило бы никаких средств. Общаюсь по этому поводу с владельцем массажной студии, куда наведываюсь еженедельно. Так вот для него идея автоматизации интересна, но начинать погружаться в эту пучину нет ни сил, ни времени. Но это я ему ценность идеи пока плохо продал. В этом контексте с удовольствием посмотрел, как дядечка настраивал чат-бот для своего сайта с пассивными балансирами для аккумуляторов 😐. Не знаю, какой у него бэкграунд в IT, но сделал он все четко!

---

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