Valerina Alpha - что это такое

#1

Кинься, пожалуйста, ссылкой. Что за Валерина?

V8rmq - продукт ;-)
#2

Это собственно новый внутренний продукт, пока альфа… Как бы можно сказать что это еще один компонент для шины, но бизнес-ориентированный.

Понимаешь какая штука

Учесть всю логику интеграции невозможно… Точнее её невозможно задокументировать и стабилизировать. Интеграционные инструменты и программные интерфейсы постоянно изменяются, а если не изменяются, то рано или поздно продукты к неизменяемым API выпиливают.

Способствует этому в том числе и Agile с инженерными практиками. Релизы каждый в погоне за рынками сбыта и с целью отдачи технических долгов приводят к тому, что пока ты интегрировал API v2 продукта 1 c API v3 продукта 2, оба эти продукта уже поменяли API и старые методы которые ты надеялся использовать признали “устаревшими”. Хуже в банках - они еще только согласуют “контракты данных”, а контракты “уже протухли”.

Собственно, на мой взгляд, как ответ на вышеуказанную проблему автор который в начале 2000-ных активно “топил за ESB’ы”, в начале 10-тых начал активно “топить за микросервисы”. А IBM даже приобрёл strongloop https://strongloop.com/. Дескать мы не будем навязывать контракты - пусть эти микросервисы/микрокоманды делают свои нетленные microapi и сами там как-то договариваются, а мы им ничего навязывать не будем.

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

  • микротрансформаторы
  • микрослабосвязыватели

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

Дополнительные проблемы

Микросервисы, микросервисами, но в организациях вообще-то принято интеграционные потоки данных хранить у себя “в периметре”, а не в облаках. Помимо всего прочего любой грамотный “инфраструктурщик” напомнит вам про горизонтальное-вертикальное масштабирование и вообще отказоустойчивость, а также высокую доступность (про мониторинг и анализ аварий даже заикаться не будем).
А также - напомним, что визуальное проектирование информационные потоков которое мы знаем еще из UML (http://plantuml.com/sequence-diagram) имеет один плюс: оно позволяет выявить коллизии еще на этапе проектирования.

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

  • кодировать логику интеграции
  • иметь визуальное представление
  • поддерживать микросервисность в части
  • создания/кодирования
  • тестирования
  • развертывания
  • обеспечивать высокую скорость проверки гипотез

У на в команде есть еще несколько требований к идеальному решению

  • решение должно быть открытым - для исключения Vendor Lock и для возможности контрибьютинга
  • решение должно быть локализованным на нативный язык бизнес-пользователей - потому что наши бизнес-* * * * пользователи в Барнауле могут знать китайский в качестве иностранного языка
    решение должно быть сразу ориентировано на поддержку Docker - чтобы обеспечить работу в средах с consul.io сервисами.
  • решение должно иметь возможность обеспечить коннект к микросервисам по протоколу OData http://v8.1c.ru/o7/201312rest/index.htm

Отсюда и родилось виденье по продукту Valerina - который мы ковыряем в недрах Пули.

Он внезапно базируется на https://ballerinalang.org/

Более подробно могу показать что получается при случае когда заедешь к нам или по Скайпу