Разочарованы в IT? RPA как основа IT архитектуры, которая победит Микросервисы -21


AliExpress RU&CIS

RPA vs MICROSERVICES
RPA vs MICROSERVICES

Вводная

Уже прошло несколько десятилетий под эгидой развития IT технологий, но мы по-прежнему повсеместно сталкиваемся с косяками в IT системах, например: в продуктовом магазине на кассе не смогли пробить товар; в отделении почты не удалось отправить посылку; в интернет-магазине не работает форма онлайн-оплаты; в пиццерии не удается оформить онлайн-заказ и т. д.

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

Задумываетесь об этом?

  • IT задачу делают очень долго/дорого/косячно.

  • По итогу реализации не получаете ожидаемый бизнес-эффект.

  • Содержите огромный штат IT персонала.

Слышите такие фразы от коллег?

  • Давайте примем решение после получения дополнительной информации.

  • Я буду разрабатывать строго по тому, что было написано в ТЗ.

  • Я не тестировщик.

  • Я не аналитик.

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

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

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

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

История первая

Прихожу я к корпоративному архитектору, чтобы согласовать очередного робота. Бизнес-заказчик просит реализовать алгоритм, который взаимодействует с 3-мя информационными системами. Этот робот позволит сократить время отклика в несколько раз, что хорошо отразится на репутации компании. И для решения этой задачи прошу его одобрить "доступ на чтение" в БД этих систем к требуемым таблицам.

Архитектор спрашивает меня: "Почему заказчик приходит к команде роботов, а не к командам соответствующих информационных систем для реализации так называемой классической автоматизации?" Я ему отвечаю: "Они пытались занести эту задачу на классическую автоматизацию, но в силу большого количества задействованных разработчиков (от каждой системы минимум по 1-му разработчику) данная задача получается трудоемкой для такого эффекта, и не ставится в приоритет - до неё дело не дошло." На это архитектор мне говорит, что никакого подключения к БД у робота быть не должно, да и вообще роботы - это «промышленный костыль». Роботов вообще быть не должно в IT архитектуре. А если они и есть, то это должна быть временная история. На старте разработки роботы обязательно надо установить дату отключения этого робота, занести задачу на реализацию в целевой архитектуре.

Конечно, команда роботов может сделать все через UI (наша сильная сторона роботов в том-то и заключается, что мы можем исполнить любой каприз). Но мы с Вами знаем продолжение пословицы: "за Ваши деньги". Так и здесь: Реализация через UI потребует увеличенного ресурса разработки в 1.5 - 2.5 раза (для создания максимальной отказоустойчивости), и быстродействие робота упадет на порядки (так как обращение к БД в разы быстрее, чем обращение к UI). Стоит ли оно того? Архитекторы довольны, бизнес-заказчик получит робота позже, и менее производительного.

Не могу не сказать про такой комментарий от архитекторов, что роботам нельзя иметь доступ на чтение в БД, потому что "роботы положат БД своими запросами". Но, извините, при таком подходе надо тогда всем запретить доступ в БД (ну, чтобы точно не положить её), но будет ли в таком случае от неё толк? :) Ну а профессиональные навыки разработчиков никто не отменял - если программисты сильные, то программа будет качественной. Если слабые - понятно... Этот закон применим к любой области/ к любым подразделениям. Вообще к любым. Вряд ли тогда будет корректно запрещать Роботам доступ к БД, потому что они Роботы.

История вторая

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

К тому моменту у меня уже была реализована целая IT архитектура на базе технологии роботизации RPA, которая была построена в разы быстрее и потребовала гораздо меньше вычислительных ресурсов. Как следствие, данная архитектура оказалась еще и дешевле (существенно). Тут я прихожу и говорю: "Вот уже есть рабочая архитектура как бизнесу надо - берите пожалуйста и распространяйте." Дальше в ход пошла политика, потому что, как оказалось, нельзя просто так взять и поменять вектор развития - нужно отвечать за ранее выбранный тренд (особенно, если в этом были задействованы большие деньги). Далее подробности оставим за кадром.

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

История третья

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

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

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

Микросервисы или RPA? Простое объяснение

Микросервисы - это система обособленных процессов. Какую роль играет приставка "микро", почему не "сервисы"? А дело в том, что сервис-ориентированная архитектура (SOA) уже давным-давно была придумана, а Микросервисы - это одна из производных (маркетинг, реинкарнация). Хорошие статьи по этому поводу уже были написаны ранее - рекомендую почитать (1) эту или (2) эту.

SOA в свое время не стала панацеей. Стоит ли рассчитывать, что ее "микро" сервисная реинкарнация исправит это положение?

Путь к Микросервисам
Путь к Микросервисам

RPA - это технология адаптации к уже существующей (неэффективной, неоптимальной) IT архитектуре. Идеология RPA гласит, что не надо ломать то, что хорошо работает - надо улучшить то, что работает плохо.

И ведь действительно, почему мы должны вычищать мегатонны исходных кодов из-за того, что кто-то искусственно назвал все эти IT системы "legacy". Если они до сих пор выполняют свою функцию? Возникли проблемы с тем, что Вы не можете внести туда изменения в функциональность? Так робот RPA поможет это исправить, и без переделывания всего остального!

Путь к роботизации RPA
Путь к роботизации RPA

Что бы Вы выбрали: сломать всё и делать "с нуля" или улучшить то, что уже функционирует? Так вот когда Вы говорите: "хочу Микросервисы", то Вы выбираете далеко не улучшение того, что у вас уже работает.

Микросервисы или RPA? Сложное объяснение

Рассмотрим внедрение новой бизнес-функции в существующие бизнес-процессы. Внедрение попробуем провести с помощью технологических подходов (1) Микросервисов и (2) роботизации RPA.

Кейс

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

Дано

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

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

Архитектура ДО (СМЕШАННАЯ)
Архитектура ДО (СМЕШАННАЯ)

Далее поиграем в IT архитекторов и попробуем решить поставленную задачу двумя методами: через (1) Микросервисы и (2) через роботизацию RPA. Обращаю внимание на то, что данные схемы не являются абсолютно полными - в них содержится ключевая часть разработки, которую можно рассмотреть в сравнении при реализации разными методами: увидеть плюсы и минусы. Малозначимые компоненты оставлю за скобками.

Решение через Микросервисы

Преследуя подход Микросервисов мы будем вынуждены отказаться от старых добрых IT систем (признав их как legacy, если они не реализованы по принципам SOA. А они, скорее всего, по этим принципам не реализованы :) ). Отказавшись от старых IT систем потребуется восполнить все необходимые бизнес-функции в новой IT архитектуре, а значит потребуется провести масштабную разработку многочисленных Микросервисов. Перед тем как начать их разрабатывать, потребуется провести настройку всей необходимой инфраструктуры, потому что для Микросервисов, скорее всего, потребуется значительное количество вычислительных мощностей. Еще нужно будет закупить все необходимые лицензии, если в чем-то будет использоваться не open source решение.

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

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

Архитектура ПОСЛЕ (МИКРОСЕРВИСЫ)
Архитектура ПОСЛЕ (МИКРОСЕРВИСЫ)

Решение через RPA

В случае использования метода роботизации (RPA как основа IT архитектуры) мы сталкиваемся с удивительными вещами. В процессе анализа существующей смешанной IT архитектуры, вдруг, выясняется, что, оказывается, можно реализовать требуемую бизнес-функцию с использованием уже существующего зоопарка систем. Почему именно с роботизацией? А потому что именно с её помощью мы можем взаимодействовать, даже, с такими системами, с которыми никто не готов взаимодействовать. Технология RPA является тем самым ключевым связующим звеном, которое может вдохнуть второе ((третье) четвертое и т.д.) дыхание в Ваши бизнес-процессы, и дать им возможность приносить пользу еще долгое время.

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

Архитектура ПОСЛЕ (РОБОТИЗАЦИЯ RPA)
Архитектура ПОСЛЕ (РОБОТИЗАЦИЯ RPA)

RPA как основа IT автоматизации

С момента появления темы RPA стали появляться программные продукты соответствующего класса. год 2020 был ознаменован рекордным количеством платных платформ роботизации RPA (более 50). 2021 год открылся в новом качестве, а именно: на рынок резко вышли несколько open source платформ роботизации RPA, что повлияло на качественное развитие рынка технологий IT. Но именно open source платформа pyOpenRPA предоставила возможность, не просто создавать бесплатных роботов, но и внедрять данную технологию RPA в другие крупные IT проекты, что и дало возможность впервые рассматривать роботизацию RPA как основу IT архитектуры компании.

Подробнее об open source pyOpenRPA можно почитать в этой статье.

Заключение (выводы)

Хочу сказать пару слов о некоторых трендах. Уважаемые коллеги заказчики. Не верьте в то, что говорят. Доверяй, но проверяй. Один из трендов современности - это глобально переделывать существующий зоопарк систем в микроскопичную архитектуру. Скорее всего, у вас не будет того, про что вам так сладко рассказывают. Я в качестве стажера, консультанта, эксперта увидел десятки IT архитектур компаний разных сегментов и разного объёма бизнеса. Знаете, что пытается сделать практически каждый технический директор? Избавиться от архитектуры прошлого директора. А знаете, что происходит потом? Порождённое количество проблем порождает новую конфликтную ситуацию, из-за которой снова происходит смена директора - и вышеописанный процесс начинается сначала.

Самое большое заблуждение, которое я уяснил для себя после увиденного - это отказ от того, что уже работает и функционирует. Да, скорее всего оно работает не идеально. Но работает же. Так почему же не попытаться улучшить то, что есть?

PS> Немного занудства

Этот мир пытается выжать «эффект» из каждой капли. Но никто не задумывается о том, а что же будет потом, когда эти капли закончатся?

PSS>

Буду рад любой поддержке, если тема для Вас актуальна.

Буду рад прочитать конструктивные комментарии по этой теме.




Комментарии (37):

  1. mmMike
    /#22912842 / +2

    Иван Маслов Ivan_Maslov Head of RPA

    Как неожиданно! " Head of RPA" рекламирует очередную «кнопку счастья», которая снимет прямо вот все все проблемы.

    • Ivan_Maslov
      /#22912884

      Спасибо за «конструктивный» комментарий, но все-все проблемы технология RPA, конечно, не снимает.

      • mmMike
        /#22912900 / +1

        Все ваше объяснение «широко известной в узких кругах» технологии RPA сводится к
        «кнопке счастья»

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

        Что тут обсуждать?
        Ни какого то более менее внятного описания.
        А стоит ввести RPA в поиск google, то вся первая страница выдачи — реклама.
        что характерно ни одной ссылки на живые топики с вопросами. Н и ч е г о.

        Плавали… знаем. поэтому Ваша статья — это просто рекламная статья.

        • Ivan_Maslov
          /#22912918

          Буду рад прочитать Вашу историю о том, почему технология RPA хуже технологии Микросервисов!

  2. xxxcoltxxx
    /#22912886

    Так что такое RPA? Даже расшифровки не увидел и ниче не понял. На счет микросервисов — видимо, ты не понимаешь что это такое или ты видел их неправильное использование. Примеры высосаны из пальца. Особенно про переписывание продукта на микросервисы для выполнения одной небольшой задачи)

  3. onets
    /#22912896 / +1

    А можно более подробно про минусы в долгосрочной перспективе? Я представил, что несколько лет спустя будет куча роботов между основными системами. Это начнет походить на сервисы/микросервисы. И может даже начнет конфликтовать в каких-то моментах. С этой точки зрения — архитектор из первой истории предлагал довольно рациональные вещи.

    • Sano000
      /#22912930 / +1

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

  4. badmilkman
    /#22912914 / +1

    Если присмсотреться к роботу — окажется что это очередная разновидность «Микро»-сервиса. (в дополнение к предыдущему комментарию)

    • /#22912968 / +1

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

      • badmilkman
        /#22913138

        Робот не может находится «в чистом поле», ему необходимо взаимодействовать с другими (роботами, сервисами, «монолитами», гуманоидами). А для этого требуется какой-никакой API. Который необходимо поддерживать в течении жизни работа и/или связанных систем (с другой стороны этого API). А для этого необходима «инфраструктура».

        Поэтому архитектор вполне обоснованно послал. Делать работу качественно.

        К тому-же этот робот, как и любая другая программа, должны быть протестированы перед запуском в «эксплуатацию» — вроде азы разработки.
        И по этому тоже, архитектор послал.

        Да, с колокольни мегаразработчика это видится как глумление над талантами. Но иначе ваш труд несет ничего полезного для бизнеса, поскольку создает больше проблем, чем решает.

        • /#22913848

          Да, я именно про это, что такой сервис RPA теперь потребует вокруг себя всю обычную для любого сервиса инфраструктуру, которой у нового проекта взяться неоткуда и придётся её создавать, или страдать от её отсутствия. Выкатили правки без автотестов — прод прилёг => все в мыле бегают и решают инцидент (а логов и мониторинга поди тоже нет).

  5. ggo
    /#22912954 / -1

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

    • niko1aev
      /#22912996

      Вот именно! Выиграть временно. То есть RPA — это временное решение. Согласен. Но согласитесь, что называть временное решение основой архитектуры — хреновая идея. Это как сказать, что антибиотики — это основа иммунитета, что капельница с глюкозой отлично подходящая в ряде случаев — основа правильного питания.

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

      • ggo
        /#22913048

        Я там ниже привел пример, с легаси системами.
        Да, это временное решение будет работать, пока легаси системы будут эксплуатироваться. Что иногда означает — далеко за пределами горизонта планирования.

  6. niko1aev
    /#22912972

    Почитал еще несколько статей по RPA

    Сама идея хорошая:
    Что-то спарсить. Откуда-то быстро собрать данные.
    Как «сесть на трубу процесса» для его изучения и оптимизации — отличная штука.
    Шикарная штука для внедрения изменений: сели на процесс «сбоку», автоматизировали, поняли какие данные есть, каких не хватает, оптимизировали процесс, доказали бизнесу эффективность и передали в разработку.

    Но вот только не надо говорить что роботы, которые через интерфейсы как боты взаимодействуют со старым неэффективным неудобным интерфейсом — это основа хорошей архитектуры. Если текущая команда не может хорошо справиться со старой архитектурой, то старая архитектура + роботы поверх этого всего — это смерть. После появления роботов вносить изменения станет вообще невозможно. Особенно если они сядут где-то на интерфейсы, где-то на API. И судя по всему еще и будут сделаны какой-то внешней командой или под управление внешних «консультантов по RPA».

    Представим задачу:
    Маленький европейский городок, очень узкие улочки, нет железных дорог, в радиусе 1000 км нет ни одного грузовика, и надо срочно перевезти 20 тонн в 30-килограммовых мешках.
    И тут вдруг мы обнаруживаем, что в городке есть очень дружная тусовка автолюбителей. И они как раз собираются в автопробег в нужном направлении, и можно в каждый из автомобилей накидать мешков, и вся колонка отлично перевезет наш груз. Командный дух, польза для города, задача решена, не надо решать сложные вопросы с грузовиками, нет нагрузки на наш старенький мост 15 века, не будет перекрыта дорога для погрузки и вообще всё прошло на ура. Фанфары, салют, все молодцы, задача решена!!!

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

    Вот и с RPA так же. Шикарное решение, чтобы быстро собрать данные, что-то проанализировать, собрать прототип, и выкинуть. И IMHO называть это основой IT архитектуры — это уже вредительство)

    • ggo
      /#22913026

      Жизнь разнообразна.
      Представьте, бывают более прозаичные случаи.
      Есть легаси система А, которая может только писать файлы в локальный каталог.
      И легаси система Б, которая может только с GUI получать команды.
      И нужно на основе информации из системы А, что-то переносить на регулярной основе в систему Б.

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

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

      И это не означает, что подход RPA надо применять везде.

      • niko1aev
        /#22913100

        Согласитесь, что формулировка:
        «Если у вас много легаси и у вас принято решение поддерживать его, то в рамках периода этой поддержки использовать RPA может быть разумно»
        несколько отличается от
        «RPA как основа IT архитектуры, которая победит Микросервисы»

        P.S. Я вообще не сторонник микросервисов. И считаю, в 9 из 10 случаев переход на микросервисную архитектура вредит. А RPA в контексте очередной волшебной таблетки я считаю еще бОльшим злом. Сам подход RPA может быть ок, но вот подача этого подхода как «Основа архитектуры», которая «Решит вашу боль» — это откровенное вредительство и введение в заблуждение.

  7. Bedal
    /#22913148

    del

    • Ivan_Maslov
      /#22913218

      Очень конструктивно :)

      • Bedal
        /#22914330

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

  8. valis
    /#22913250

    Если честно закончил читать на истории 1. Такой взгляд и сделанные из этой истории выводы практически полностью описывают компетенцию и опыт автора.
    Да решать бизнес задачи быстро и дешево это хорошо и это то, к чему стремится любое взрослое подразделение разработки.
    И вывод один RPA это действительно на все 100% КОСТЫЛИ и по другом назвать это нельзя
    Хотите я расскажу свои истории. (извините, код пишу я лучше чем излагаю)

    И так поехали:
    История 1. Прибегает такой разработчик роботов с новой задачей — дайте доступ к БД. Мы такие — ну как же это не по канонам. И мы даже не боимся то он своими кривыми селектами или миллионом незакрытых контактов завалит нам базу, мы боимся костылей и боимся несогласованных действий (чуть по позже объясню)
    И так этот человечек с горячими глазами прожужжал бизнесу все уши о том какой он молодец и как за пару часов решит все их проблемы и естественно прогнул все ИТ подразделение и пришлось ему дать доступ на прод.
    Человечек этот решил все проблемы, ничего нам не сказав о том, как он их решил и не предоставив документацию что он делает в нашей базе.
    ИТОГ: через месяц поменялись некоторые структуры в БД и значения так, что новая автоматизация завалилась. Не хочу дальше продолжать ибо мне самому противно от этой истории, в итоге которой я остался виноватым.
    Но эпилог такой:
    1. Задумываются ли эти мальчики с горячими глазами над тем, что классические команды разработки не валяют дурака и ЕЖЕДНЕВНО выполняются десятки релизов меняющие сложную и запутанную инфраструктуру. А архитекторы и бизнес аналитики усердно трудятся над тем чтобы изменения в точке А не привели к краху точки Б (и это тоже капец работенка)
    2. Задумываются ли эти мальчики над безопасностью? Доступ к чтению из БД рандомных данных это огромная черная дыра в безопасности (у нас был инцидент когда один такой мальчик слил базу конкурентам)
    3. Задумываются ли эти мальчики об обслуживании всего этого хозяйства? Были случаи когда чудо люди из отдела инноваций (у нас они себя зовут так) хостили продуктивные приложения на тестовом окружении и обижались когда админы их грохали без предупреждения и бэкапов.

    P.s Может быть эта заметка просто порыв злости на это все дело, но и Вы должны понимать — написать код не самая трудозатратная часть разработки. Большинство проблем в согласовании требований, спецификаций API различных систем, тестировании и внедрении и эту проблему не решит ни одна роботизация

    P.p.s За годы своего существования у так называемого отдела инноваций у нас не было ни одного действительно удачного проекта

    • zazar
      /#22913498

      мальчики с горячими глазами


      Горящими. Поржал от души.

      • valis
        /#22914308

        Я умею повеселить. Писал на взводе после очередной совестной перепалки с такими вот людьми и тут на глаза эта статья

  9. zazar
    /#22913464

    История вторая

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


    Где-то заплакал Греф.

  10. Ivan_Maslov
    /#22914058 / -1

    Видимо за живое задел, раз товарищи айтишники мне так яро карму занижают :)

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

    • aktuba
      /#22914758

      Конечно «резонансная». Ведь после таких «внедренцев» it-отделу это поддерживать. Было: апи с описанной структурой, стало нечто без структуры и изменяется в любой момент. Утрирую конечно, но не сильно.


      P.S.: с каких пор парсинг ui противопоставляют архитектуре и, тем более, сервисам?

    • yaBliznyk
      /#22916326

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

  11. lair
    /#22914102 / +1

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

    Т.е. теперь у нас появился неявный контракт на фиксированный UI, про который никто нигде не знает?

    • Ivan_Maslov
      /#22914170

      Почему не знает? :)

      • lair
        /#22914172

        Потому что в каком архитектурном документе это зафиксировано и какими тестами покрыто?

        • Ivan_Maslov
          /#22914504

          Ничего не мешает фиксировать все зависимости корпоративной архитектуры в некотором едином пространстве, в том числе и Ui зависимости. И тесты/автотесты точно также делаются на все виды зависимостей.

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

          • lair
            /#22914522

            Ничего не мешает фиксировать все зависимости корпоративной архитектуры в некотором едином пространстве, в том числе и Ui зависимости. И тесты/автотесты точно также делаются на все виды зависимостей.

            И вы хотите сказать, что поддержка робота в этом случае дешевле, чем поддержка выделенного API? А за счет чего, собственно?


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

            Наибольшую по сравнению с чем?


            У меня, на самом деле, назрел вопрос: а почему вы, собственно, противопоставляете роботов традиционной IT-инфраструктуре? На основании чего вы говорите: вот это — не микросервис, и не традиционное решение, а RPA?

    • ggo
      /#22917078

      Если этот UI пилится внутри конторы, то довольно странно, использовать вообще UI, т.к. есть возможность дергать API, который дергает UI.

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

      • lair
        /#22917086

        Если этот UI пилится внутри конторы, то довольно странно, использовать вообще UI,

        Странно. Но автор статьи предлагает именно это.


        есть возможность дергать API, который дергает UI.

        … а вот это совершенно не обязательно.


        Если этот UI поставляется извне, то да, об его обновлении вы знаете заранее

        Неа, не знаете. Вы знаете об обновлении ПО. А вот содержит ли обновление ПО обновление UI — вопрос открытый.

  12. omichkun
    /#22915244

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

  13. oxidmod
    /#22915636

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

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