Статьи Logic BPM

Преимущества нашего Logic BPM. ServiceDesk с рождения

Мы создаём наш продукт ServiceDesk с чистого листа. У нас нет ограничений в виде устаревшего ядра, необходимости поддерживать старые конфигурации или данные, а также обязательств по сопровождению предыдущих версий и миграции клиентов на новые. Это дало нам свободу выбора: мы смогли использовать самые современные подходы и инструменты, а также выстроить эффективные процессы разработки и сопровождения.
Эта свобода позволила заложить в нашу систему качества, которые делают её более чем конкурентоспособной. О них мы и поговорим сегодня.
Если вкратце, то:
Мы разрабатываем наш продукт ServiceDesk в парадигме микросервисной архитектуры на фреймворке Quarkus, с применением механизмов event-driven архитектуры, на принципах Cloud Native, с автоматизированным размещением ключевых компонентов в контейнеризированной среде.
А теперь обо всём этом более человеческим языком :-)

Микросервисная архитектура и автономность разработки

Бэк-энд (т.е. серверная часть) нашей системы состоит из микросервисов — отдельных модулей, каждый из которых реализует определённую функцию. Приставка "микро" не должна смущать: разбиение системы на такие отдельные модули производится без фанатизма. Излишне "мельчить" неправильно. Например, в нашем SD есть "Сервис регистрации обращений", "Сервис управления IT-активами", "Сервис коммуникации с клиентом". Из названий понятно, что каждый реализует достаточно большую бизнес-функцию.
При разработке исходный код каждого такого компонента никак не зависит от исходного кода других. Более того, их можно создавать на разных языках программирования. Это позволяет легко распределять задачи между отдельными программистами или командами. Такой подход — один из ключевых принципов микросервисной архитектуры, называемый "Автономность разработки".
Чтобы микросервис выполнил какую-либо из своих функций, его нужно об этом "попросить", вызвав соответствующий метод его интерфейса - API. В этом процессе можно выделить три ключевых аспекта:
1. Транспортный протокол (например, HTTP/HTTPS или gRPC) определяет, как обращаться к компоненту на техническом уровне.
2. Подход к формированию логики интерфейса (например, REST) задаёт правила и методы, которые должны быть предусмотрены для выполнения типичных функций.
3. Стандарт описания формата данных (например, текстовые JSON и XML или бинарный ProtoBuf) определяет структуру и требования к "телу" запроса.
В современной микросервисной архитектуре используется ограниченный набор транспортных протоколов, подходов к интерфейсам и стандартов форматов данных. Такая стандартизация значительно упрощает взаимодействие между сервисами, делая их интеграцию и поддержку более эффективными.
Важно отметить, что все протоколы, используемые в микросервисной архитектуре, являются сетевыми. Это означает, что взаимодействие между микросервисами (и отдельными компонентами, из которых состоит весь микросервис) осуществляется через сеть. Благодаря этому к микросервису может обращаться как другой микросервис, работающий на том же сервере, так и компонент — будь то микросервис или элемент пользовательского интерфейса — находящийся на другом сервере, даже в другом городе.
Чтобы микросервис или его компонент могли "слушать" определённый протокол, разработчику не нужно писать сложный низкоуровневый код. Эту задачу берёт на себя так называемый "фреймворк" — инструмент, который предоставляет готовые решения для типовых задач. Мы выбрали Quarkus — один из самых современных фреймворков, обеспечивающий высокую производительность микросервисов. Он был разработан с учётом работы в контейнеризированных средах (о которых мы поговорим чуть позже).

Event-driven подход

В дополнение к традиционному способу взаимодействия с микросервисом через вызов методов его интерфейса, мы используем подход event-driven. Это значит, что отдельные микросервисы или модули системы могут генерировать "события", а другие компоненты — "подписываться" на них и автоматически реагировать на интересующие их события.
Например, "Сервис регистрации обращений" отправляет "в эфир" сообщение: "зарегистрировано новое обращение клиента, требующее обработки". Этот сервис не знает и не должен знать, какие другие модули будут обрабатывать событие и как именно они это сделают.
Когда такое событие поступает, "Сервис обработки обращений на 2-й линии" начинает процесс обработки. "Сервис оповещений клиента" формирует и отправляет сообщение в мессенджер. А "Сервис аналитики" фиксирует это событие в статистике.
Главное преимущество этого подхода — лёгкость добавления или удаления подписок на события. Это позволяет гибко изменять и настраивать бизнес-процессы, не затрагивая логику других компонентов.

Контейнеры и их удобство

Мы уже обсудили подходы к проектированию и разработке микросервисов — то, что относится к этапу design time. Теперь давайте перейдём к их работе и взаимодействию в реальной среде — этапу run time.
Итак, компоненты наших ключевых микросервисов работают внутри контейнеров. Контейнер можно представить как "коробку", в которой находятся все необходимые элементы для работы компонента.
Внутри контейнера мы размещаем:
1. Исполняемый код нашего компонента, который реализует его основную функциональность.
2. Сторонний ("не наш") исполняемый код, необходимый для работы компонента, например, интерпретатор Python, Java Virtual Machine (JVM) или другие системы исполнения программ, а также готовые библиотеки и модули.
3. Настройки и параметры, которые определяют, как именно компонент должен работать.
Пример:
Допустим, нам нужен микросервис, который переводит в текст аудиофайл с голосовым сообщением клиента.
Чтобы реализовать это, мы создаём контейнер, который включает:
1. Исполняемую среду Python нужной версии для выполнения нашего кода.
2. Библиотеку Vosk для распознавания речи, включая её компоненты для работы с нужными языками.
3. Наш код, который будет:
  • Принимать аудиофайл от других сервисов.
  • Направлять его на обработку в Vosk или внешний сервис распознавания речи.
  • Преобразовывать полученные результаты в текст в заданном формате.
4. Настройки, определяющие:
  • Какой механизм распознавания использовать (Vosk или внешний сервис)
  • Адрес внешнего сервиса, если он выбран.
Эти "слои" объединяются с помощью специальной программы-сборщика, которая формирует образ контейнера — единый компактный файл.
После создания образа он сохраняется в реестре контейнеров — специальном хранилище, где хранятся и управляются образы. Когда в систему управления контейнерами поступает запрос на запуск нового контейнера, ей передают информацию о том, из какого реестра и какой именно образ нужно использовать. Затем система загружает указанный образ, разворачивает контейнер и запускает его.

Почему контейнеры - это удобно?

1. Единообразие среды исполнения. В контейнере, сколько раз бы мы его не запускали и на каких бы стендах это не происходило, воссоздаётся ровно такая среда исполнения, которую мы описали для создания образа.
В нём собраны строго определённые версии всех компонентов:
  • Именно эта версия Python или Java.
  • Именно эти версии библиотек и модулей.
  • Именно эта версия нашего исполняемого кода.
Это избавляет нас от типичных проблем, когда на рабочей станции разработчика или на тестовом сервере используются одни версии модулей, а на промышленном — другие. Подобные расхождения могут привести к сбоям, причём иногда не сразу, а при определённых условиях. С контейнерами такой риск практически исключён. Мы можем даже передать образ контейнера партнёру или заказчику, и у них будет работать точно такой же контейнер.
2. Описание образа контейнера — это тоже программа, простая и понятная. Мы создаём небольшой текстовый файл, в котором чётко прописано, что и как должно быть собрано в образе контейнера. После того как мы всё описали и перепроверили, программа-сборщик создаёт именно тот образ, который нам нужен.
3. Удобное управление версиями образов. Каждый образ контейнера имеет уникальный номер версии, благодаря чему в реестре могут одновременно храниться образы разных версий одного и того же компонента. При запуске контейнера достаточно указать нужную версию образа или просто запросить "самую последнюю".
Такой подход значительно упрощает:
  • Тестирование: можно быстро проверить, как ваш компонент работает с разными версиями сторонних библиотек или систем.
  • Сопровождение продукта: легко поддерживать несколько версий нашего приложения, например, одну для старых клиентов, а другую для новых, с более современным функционалом.
Честно говоря, тут не всё так уж идеально, нюансы есть, но это точно намного надёжнее, чем классические скрипты установки программ на сервер, которые приходится писать без использования контейнеризованной среды.

Масштабирование

Пока мы неявно исходили из того, что нам для работы всей системы нужно запустить один контейнер для каждого её компонента. Но всё становится ещё интереснее, если мы хотим их много.
На самом деле, мы можем сообщить системе запуска и управления контейнерами, что вот тот контейнер с распознаванием голосовых сообщений надо сначала запустить только один, но при этом наблюдать за его нагрузкой.
И если очередь входящих сообщений увеличится и работающий контейнер начнёт потреблять много вычислительных ресурсов, то надо запустить ещё один или несколько контейнеров с тем же образом и распределить поток сообщений между ними. А когда нагрузка спадёт, заглушить ненужные больше экземпляры.
И вот это всё работает автоматически: наша задача — только указать системе, сколько контейнеров каждого вида запускать сразу, при каких пороговых значениях запускать новые и когда остановиться, чтобы не занять все ресурсы нашего сервера.
Запуск нескольких одинаковых контейнеров также позволяет обновлять нашу систему в большинстве случаев без остановки. Мы просто говорим системе управления контейнерами: отключай контейнеры с текущей версией образа и запускай вместо них столько же, но с новой версией.
При этом можно задать условие, чтобы в любой момент времени часть контейнеров продолжала работать, обеспечивая бесперебойную работу системы. Это называется rolling update и позволяет обновлять систему "на лету", не отключая пользователей.

Изоляция

Далее поговорим про изолированное выполнение.
Каждый контейнер работает в своём собственном пространстве, как будто он — отдельный мини-компьютер. Это изолирует процессы и ресурсы контейнера от остальной системы.
Например, если в одном контейнере случится сбой или он начнёт потреблять слишком много памяти, это никак не повлияет на другие контейнеры или на хост-сервер в целом.
Решать возникшую проблему, конечно, всё равно придётся. Но, во-первых, вполне может оказаться, что остальные контейнеры того же образа продолжат нормально работать (например, один аудиофайл из очереди голосовых сообщений вызвал почему-то несварение у сервиса распознавания речи). А во-вторых, другие микросервисы точно не пострадают, и остальные функции нашего продукта не будут отключены.
Изолированное выполнение контейнеров также полезно для обеспечения безопасности. Контейнеры не имеют прямого доступа к файлам и ресурсам хост-системы, если это не настроено специально. И наоборот, контейнер не примет запрос на выполнение какого-то из методов микросервиса внутри него, если обратившийся компонент не имеет на это права. Это делает их надёжным решением для запуска приложений в облаке или на общих серверах.
Все системы управления контейнерами предоставляют API, т.е. для выставления им задач можно и нужно использовать специализированные системы автоматизации сборки, развёртывания и тестирования релизов. Это называется инструменты CI/CD (Continuous Integration / Continuous Delivery).
DevOps-инженер, без которого вся эта "магия" не заработает, настраивает так называемые "конвейеры" (или pipelines, "трубы").
Конвейер начинается с автоматической сборки компонентов нашего продукта из исходного кода, написанного разработчиками. Если сборка проходит успешно, а также успешно завершаются юнит-тесты, следующий этап конвейера автоматически вызывает инструмент для создания новых версий образов изменённых компонентов.
После успешной сборки образы размещаются в реестре, готовые к развёртыванию.
Следующим шагом конвейер размещает все компоненты продукта на тестовом сервере. Для микросервисов, упакованных в контейнеры, это делается через взаимодействие с системой управления контейнерами. Для остальных компонентов (которые почти всегда присутствуют в продукте) процесс развёртывания может быть сложнее, но его также можно автоматизировать с помощью соответствующих инструментов.
На следующем этапе конвейер запускает систему автотестирования, которая выполняет запланированный набор функциональных тестов. Если все тесты проходят успешно, конвейер может дополнительно опубликовать релиз на стенде для тестирования производительности и инициировать соответствующие автотесты. Однако такие тесты обычно не выполняются для каждой сборки, так как они требуют значительного времени и ресурсов серверов.
Автоматическое развёртывание нового релиза (а точнее, обновлённых компонентов) в "боевую" среду обычно выполняется с помощью отдельного конвейера. Более того, даже описанный ранее конвейер может быть разбит на несколько отдельных этапов или конвейеров. Это зависит от особенностей продукта и процессов, принятых в команде разработки.
Важно, что в этих процессах сводится к минимуму человеческий фактор.
Классические примеры человеческих ошибок включают:
- Забыл опубликовать какой-то компонент или выложил не ту версию. - Не скорректировал настройки компонента, которые отличаются для тестовой и боевой среды. - Проигнорировал ошибки тестов и продолжил выкатывать релиз.
Автоматизация помогает избежать таких ситуаций, делая процесс более надёжным и предсказуемым.
С другой стороны, ошибка DevOps-инженера при настройке конвейеров до промышленной среды может иметь достаточно серьёзные последствия. Чтобы снизить такие риски, хорошей практикой считается использование пред-боевого сервера (stage-стенда), конфигурация которого максимально приближена к "боевой" среде. Успешное развёртывание на этом стенде значительно повышает надёжность финальной выкатки в ПРОМ.

Cloud Native

Осталось поговорить про один подход, который мы изначально поддерживаем — Cloud Native. По сути, он означает, что ИТ-продукт проектируется и разрабатывается так, чтобы его можно было эффективно, надёжно и безопасно развёртывать в облаке — публичном (например, Яндекс Облако) или своём частном, которое живёт на внутренних серверах организации.
Чтобы считаться "облачной по своей природе", разрабатываемая система должна следовать следующим принципам:
- Масштабируемость - Устойчивость - Управляемость через автоматизацию - Наблюдаемость - Безопасность
На самом деле, разные уважаемые организации и авторы предлагают несколько различающиеся наборы принципов, но мы здесь обсудим те, по которым есть консенсус.

Масштабируемость

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

Устойчивость (или отказоустойчивость)

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

Управляемость через автоматизацию

— это способность управлять всеми компонентами, работающими в облаке, не только через административную консоль, но и с помощью автоматизированных инструментов, а в идеале — чтобы всё происходило автоматически.
Мы уже обсуждали конвейеры для развёртывания и тестирования, автоматический перезапуск контейнеров при сбоях и масштабирование в зависимости от нагрузки.
Однако важным аспектом также является возможность полностью воссоздать стенд со всеми его компонентами: виртуальными серверами, их группами (кластерами), десятками контейнеров, настройками безопасного доступа и множеством других элементов.
Эта задача реализуется через подход "Infrastructure as Code" (IaC). Вся структура стенда описывается в виде текстовых файлов с конфигурацией. Эти файлы затем обрабатываются специальными инструментами, которые автоматически создают в облаке всю необходимую инфраструктуру.

Наблюдаемость

— это способность системы предоставлять информацию о своём состоянии, работе и проблемах, чтобы разработчики, администраторы и автоматизированные инструменты могли быстро обнаруживать, анализировать и устранять сбои. Это не просто мониторинг, а комплексный подход к пониманию того, что происходит внутри системы.
Ключевое понятие наблюдаемости — метрики. Это числовые данные, которые показывают состояние системы в реальном времени (например, загрузка процессора, использование памяти, количество запросов, время их обработки). В Cloud Native системах каждый компонент умеет публиковать свои метрики в стандартном формате, а специализированные инструменты собирают эти метрики и отображают их на информативных дашбордах.
Следующий аспект в обеспечении наблюдаемости — формирование журналов каждым модулем системы. Журналы — это файлы с записями о выполненных действиях или возникших ошибках. Все компоненты в облаке должны записывать такие журналы в стандартном формате, а централизованная подсистема собирает их и предоставляет удобный интерфейс для просмотра и поиска определённых записей.
Также важный инструмент наблюдаемости — алерты. Это уведомления для администраторов продукта о том, что что-то пошло не так. Неправильно заставлять администратора постоянно следить за метриками и журналами, когда можно активно оповестить его о возникновении проблемы или, что ещё удобнее, предупредить, что проблема может возникнуть в ближайшее время.

Безопасность

— это про то, как защитить приложения и данные в среде, где всё построено на микросервисах, контейнерах и облачных технологиях. Это не про отдельный этап или процесс, а про то, как встроить безопасность во всё, начиная с разработки и заканчивая эксплуатацией.
Когда речь идёт о контейнерах, важно понимать, что каждый из них изолирован. Но и их нужно защищать: использовать только проверенные образы, регулярно сканировать их на уязвимости. Например, представьте, что ваш микросервис работает в контейнере с устаревшей библиотекой. Лучше об этом узнать на этапе сборки, чем уже в продакшене, и для этого есть автоматизированные инструменты.
В Cloud Native архитектуре безопасность — это ещё и про контроль доступа. Каждый сервис должен иметь только те права, которые ему нужны. Например, зачем микросервису, отвечающему за ведение каталога лицензий на ПО, доступ к данным клиентов? Всё это регулируется через роли и политики доступа. И обязательное шифрование: все данные, что передаются между микросервисами или наружу, должны быть зашифрованы.
И, конечно, безопасность — это не только о защите компонентов, но и об управлении инфраструктурой. Представьте, что вам нужно создать полностью новый кластер. Подход "Infrastructure as Code" (IaC) позволяет описать всё — сервера, сети, доступы — в виде кода. Это и удобно, и безопасно: конфигурация хранится в одном месте, её можно проверять и версионировать.
Ещё важный момент — это мониторинг и алерты. Безопасность — это не только предотвратить взлом, но и быстро реагировать, если что-то пошло не так. Логи для аудита потенциально опасных событий, метрики, системы обнаружения аномалий — всё это позволяет вовремя поймать подозрительное поведение и не допустить проблем.
Cloud Native подход к безопасности — это не о том, чтобы закрыть всё железными замками, а о том, чтобы встроить защиту в каждую часть системы. Чем больше автоматизации, тем меньше человеческих ошибок, а значит, ваша система будет надёжнее.

Преимущества

Итак, мы разобрали все термины из первой фразы о технологиях и подходах, которые применяются при разработке наших продуктов. Теперь давайте подведём итог: какие именно преимущества это приносит?
Мы разрабатываем новый код продукта, внедряем улучшения и исправляем ошибки более эффективно, потому что:
  • Микросервисная архитектура позволяет хорошо распараллеливать работу между программистами, распределяя задачи по отдельным командам. Кроме того, она упрощает точечную коррекцию кода, так как изменения касаются только конкретного микросервиса, не затрагивая остальные.
  • Мы используем только стандартные протоколы и форматы взаимодействия между компонентами, которые хорошо знакомы программистам и аналитикам. Это снижает сложность интеграции и уменьшает вероятность ошибок при взаимодействии микросервисов.
  • Благодаря контейнерам разработчики могут легко "поднимать" в своих рабочих пространствах и на тестовых стендах все необходимые компоненты для отладки и тестирования. Это ускоряет процесс разработки и улучшает воспроизводимость ошибок.
  • Мы строго соблюдаем требования к разработке юнит-тестов. Автоматизированные системы проверяют их достаточность и не позволяют отправлять изменения кода на следующие этапы, если тесты не прошли успешно.
Мы проверяем качество разработанного продукта более эффективно, потому что:
  • Ставим автоматические тесты в приоритет. Мы активно используем автоматизацию, включая как функциональные, так и нагрузочные тесты. Это позволяет быстро и надёжно проверять работоспособность системы после каждого изменения.
  • Покрываем все уровни системы. Тестирование охватывает как пользовательский интерфейс (UI), так и серверную часть (бэкэнд), обеспечивая всестороннюю проверку и минимизацию рисков.
  • Автоматизируем сборку и развёртывание. Это позволяет запускать тестирование после каждого значительного изменения кода, сохраняя высокий темп разработки без ущерба для качества.
  • Активно используем инструменты наблюдаемости. Мы собираем метрики производительности и анализируем журналы, чтобы быстро находить и устранять узкие места, улучшая стабильность и производительность системы.
Мы изначально готовим продукт к высоким нагрузкам, потому что:
  • Проектируем масштабируемую архитектуру. Используем микросервисы, которые легко масштабируются независимо друг от друга. Это позволяет распределять нагрузку между несколькими экземплярами сервисов и эффективно использовать ресурсы.
  • Применяем event-driven подход, который минимизирует вероятность появления "бутылочного горлышка" в системе, способного замедлить её работу.
  • Используем фреймворк Quarkus, который на данный момент обеспечивает максимальную производительность решения.
  • Тестируем производительность на ранних этапах. Включаем нагрузочные тесты в процесс разработки, чтобы убедиться, что система выдерживает заданный уровень нагрузки ещё до выхода в продакшн.
  • Используем механизмы гибкого управления ресурсами. Наша облачная инфраструктура автоматически добавляет ресурсы (например, новые контейнеры или виртуальные машины) при росте нагрузки и уменьшает их при снижении, что обеспечивает стабильность и экономию.
  • Интегрируем системы наблюдаемости. Постоянно мониторим метрики производительности, такие как время отклика, загрузка процессора и использование памяти, чтобы оперативно реагировать на потенциальные проблемы.
Мы создаём продукт, хорошо защищённый от угроз кибербезопасности, потому что:
  • Автоматические проверки безопасности собственного кода и сторонних компонентов встроены в конвейер сборки. Это позволяет находить и устранять уязвимости ещё на этапе разработки.
  • Применяем технологии изоляции компонентов и контроля доступа. Контейнеризация изолирует микросервисы друг от друга и от хост-системы, а каждый компонент системы выполняет только строго разрешённые действия, что минимизирует риски компрометации.
  • Используем общепринятые безопасные протоколы как для внутреннего взаимодействия компонентов, так и для работы с внешними системами. Это предотвращает несанкционированный доступ и защищает данные от утечек.
  • Встроили систему управления доступом. Доступ пользователей и сервисов организован на принципе предоставления минимально необходимых прав, что исключает избыточные привилегии и снижает потенциальные риски.
Мы изначально обеспечиваем удобство внедрения и сопровождения продукта, потому что:
  • Применяем стандартные централизованные системы сбора и визуализации метрик и журналов. Все компоненты решения предоставляют данные, понятные этим системам, что упрощает мониторинг и анализ работы.
  • Максимально автоматизируем процессы настройки и развертывания. Создание необходимой конфигурации в публичном облаке или собственной инфраструктуре, а также первичное развертывание продукта осуществляется с использованием подхода IaaS, системы управления контейнерами и автоматических конвейеров.
  • Обеспечиваем возможность обновления компонентов без остановки системы. Благодаря микросервисной архитектуре и контейнеризации продукт поддерживает обновление или откат компонентов в промышленной среде "на лету", что обеспечивает стабильность работы для пользователей.
  • Реализовали интеграцию с распространённой системой управления пользователями Active Directory, что упрощает аутентификацию, авторизацию и управление доступом в корпоративной среде.
Мы создаём продукт, который бережно использует ресурсы инфраструктуры, потому что:
  • Системы управления контейнерами и облачными ресурсами позволяют максимально эффективно использовать доступные мощности. Вычислительные ресурсы, такие как процессорная мощность и объём памяти, выделенные для группы микросервисов, используются по мере необходимости — в зависимости от запросов активных или вновь создаваемых контейнеров. Таким образом, нет необходимости сразу выделять каждому модулю ресурсы с запасом на возможный рост его потребностей.
  • Реализуем мультитенантность. Это подход, который позволяет одному и тому же системному компоненту (например, базе данных или системе очередей сообщений) обслуживать сразу нескольких заказчиков. При этом их данные надёжно изолированы друг от друга, исключая возможность перемешивания. Благодаря этому мы можем предлагать заказчикам более экономичное решение на старте работы с нашей SaaS-версией продукта: нет необходимости оплачивать отдельную инфраструктуру, а можно для начала жить в общем кластере.

Что дальше

Длинные статьи и короткие новости о нашем продукте — о его устройстве, ходе разработки и эксплуатации — это лишь один из способов познакомиться с его возможностями.
По мере развития продукта мы планируем организовывать демонстрации, которые подтвердят те преимущества, о которых мы сегодня рассказали. А в идеале — предоставить стенды, где самые любознательные смогут самостоятельно всё проверить.
Не переключайтесь :-)
P.S.
Тем, кто интересуется историей развития компонентных моделей программного обеспечения, рекомендуем ознакомиться с технологиями CORBA и COM/DCOM. Хотя они не достигли того уровня успеха, на который рассчитывали их создатели, их влияние на последующие разработки невозможно переоценить — именно благодаря им появились современные технологии, которые мы активно используем сегодня.
P.P.S.
Мы пока не упомянули ещё один важный аспект: наш продукт Service Desk основан на современной и высокопроизводительной BPMS-платформе. Однако это отдельная тема, которая заслуживает отдельной статьи.
P.P.P.S.
Многие тезисы, озвученные в этой статье как преимущества нашего продукта, заявляют примерно все производители ПО: высокая скорость работы системы, готовность к высоким нагрузкам, удобство сопровождения, а иногда и микросервисная архитектура. Однако что из этого действительно правда, а что лишь маркетинг, нередко можно определить по косвенным признакам.
Например, если каждое обновление системы требует технологического окна, во время которого работа с ней невозможна, это уже ставит под сомнение микросервисную архитектуру. Или, если в составе решения присутствует "главная" база данных, это вряд ли свидетельствует о готовности системы поддерживать высокую скорость работы при любом масштабе вашего бизнеса.
2025-03-03 21:04 Продукты