По поводу вакансии — можно нанимать тех кто знает Activiti или тех кто знает IBM BPM опыт совместимый. Или если в команде уже есть спецы по Camunda то можно разработчикам дать нужны знания довольно быстро.
Вы правы по поводу поддержки. OSS релизы не так часто как фиксы багов так что тут либо обходить либо бакпортить фиксы в последний релиз. Коммерческая версия есть с поддержкой но она стоит заметно дешевле IBM BPM и т.п. Тут ещё стоит заметить что IBM BPM это suite а Camunda и Activiti это engine.
Не совсем но на 90% буллшит. Аналитики и заказчик используют диаграммы в BPMN нотации для обсуждения и разработки новой функциональности. Но за разработчиками последнее слово в том чтобы сделать схемы исполняемыми. И дело тут не только в схемах BPMN. Мало какое изменение процесса не за трагивает доработку UI или сервисного слоя.
По поводу образов для Windows Containers. Есть еще образы в официальном репо Microsoft на Docker Hub.
Папки в Docker Toolbox (для Windows 7/8.1) лучше не подключать как volume — очень медленно выполняются операции чтения/записи.
По опыту Тулбокс не удобен при разработке из-за того, что он не биндит localhost
Можно пробросить порты с 192.168.100.99 на localhost — делается через VirtualBox интерфейс в настройках виртуальной машины default.
Для себя сделал решение — просто перейти на разработку под Linux. Нативная поддержка Docker. Весь инструментарий для разработки Java/Frontend/etc поддерживается нативно. Для чего-нибудь экзотичного VirtualBox с Windows 7.
Спасибо за расшифровку, очень многое сказано правильно, но хотелось бы прокомментировать некоторые спорные моменты.
Digital. DevOps это лишь часть Digital трансформации. И в первую очередь эта трансформация начинаться должна не в ИТ отделах, которые по хорошему не против изменений и чего-нибудь нового, а в управлении проектами и «в мозгу» у заказчика продукта. Так что Agile нужно там внедрять в первую очередь. А DevOps и остальные микросервисы сами «подъедут» когда заказчик поймет что Waterfall не работает, что изменения нужно делать постепенно, что продуктовая команда это ИТ и бизнес как единое целое.
Системный администратор/программист как DevOps инженер. Дисциплина DevOps выросла из концепции Infrastructure as a code (инфраструктура, описанная декларативной — в настройках, скриптах, коде, конфигурации). К сожалению часто сисадмины горят желанием что-нибудь быстро установить. Но установить это только часть жизненного цикла. А для правильного DevOps нужно делать по другому. Можно и нужно нанимать системных администраторов на роль DevOps, но им нужно помогать поменять мышление и иногда это может быть трудно.
Амазон реально деплоится раз в 11 секунд. Это не так конечно. Амазон это множество продуктов, слабо связанных между собой. Речь о том, что для ВСЕГО Амазона релиз новой версии какого-либо продукта в промышленную эксплуатацию происходит каждые 11 секунд. Это довольно реальная цифра если учесть что продуктов сотни и команд тоже много. Вот исходное обсуждение.
Термин DevOps. Как следует из названия DevOps это объединение разработчиков и службы эксплуатации в единую команду, призванную решать не только проблему Time2market, но и общей надежности, скорости работы и качества продукта. При этом нужно в первую очередь определить что ответственность за качество продукта и его работу лежит на всех членах группы, а не на «сисадминах». И обратная связь от эксплуатации к разработчикам на предмет улучшения инфраструктуры и, возможно, внесения изменений в код не менее важна чем новые «фичи» внедряемые в срочном порядке. Infrastructure as a code помогает этого достичь.
Команда. Важно чтобы не только DevOps инженерые понимали как оно работает в промышленной эксплутации но и разработчики. Технически помогает этого достичь концепция Dev/Prod parity — когда каждый (личный) стэнд разработчика это маленький промышленный контур и настройки промышленной версии отличаются от настроек разработчика только несколькими конфигурационными файлами. Можно и дальше цитировать 12 факторов но лучше почитать первоисточник.
Релизы раз в неделю. Есть пример из жизни когда большая, сложная система в очень крупной организации выкладывалась 2 раза, а иногда и 3 раза в неделю. И было это достигнуто только лишь потому, что разработкой и эксплутацией системы занималась одна и таже команда людей. Когда речь зашла о разделении этих обязанностей по разным отделам то даже не предполагалась такая частота релизов. Раз в неделю да и то со скрипом. Потому что при разделении у всех получаются разные цели (и KPI если уж на то пошло).
Было бы кстати очень полезно всем если бы кто-то описал как практически осуществлять Canary Releases (канареечные релизы) для стандартных стэков AWS/Kubernetes, Java/NodeJS/Python/etc..., получать метрики, делать выводы о стабильности релиза. Тут одной микросервисной инфраструктурой не обойдешься.
1) в принципе да но «прилипающая», т.е. динамически фильтрующая новые строки
2) их можно тэгировать. если с п.1) совмещено представьте себе это будет бомба! можно найти все записи везде по одному ID например
3) да. это тоже должна быть прилипающая фишка
Привет! DockStation интересный проект! То что надо т.к. нет нормального средства для работы с Docker Compose проектами!
Хотелось бы больше инструментов для работы с логами
— фильтрация
— поиск по всем логам проекта Docker Compose.
— «интеллектуальный» фильтр по дате/времени — сегодня/1 мин/5 мин/30 мин/1 час
Как в ARCSIGHT с пользовательским интерфейсом? Когда я последний раз проверял там был жутко неудобный «толстый» клиент и ограниченный в функционале веб-клиент.
Например 50 concurrent connections. Правильно ли я понимаю что учитывая KeepAlive одновременно с приложением не сможет работать больше 50 человек (в т.ч. учитывая тех кто просто открыл приложение и держит эту вкладку в браузере открытой??)
> Трудно реализовать асинхронное взаимодействие между сервисами
поясните в чем трудность?
можно делать через Callback WSDL а можно (и более правильно) через очередь + ESB
> Сложно и трудоемко реализовать ответы в «реальном времени», потому что XML дает надежность, а не скорость.
Смотря что подразумевать под «реальным временем». Если говорить про Java то проекты Axis2, Apache CXF добавляют довольно небольшие накладные расходы связанные с SOAP. Конечно все относительно и зависит от требований.
Если про REST
Проблема с REST в том что нет стандартизированного (= общепринятого) способа описания сервисов (аналога WSDL)
Кто во что горазд (например есть «раздутый» Swagger). Нет возможности создать быстро клиента на основе опубликованного сервиса.
Для каждого REST API надо писать своего клиента.
Модернизация старых решений
По моему мнению правильным является сделать так 1) «обернуть» Legacy систему в SOA 2) сделать чтобы все взаимодействие с ней было через SOA 3) заменить или переписать систему не трогая сервисы т.о. связанные системы затронуты не будут.
А можно поподробнее про картриджи?
Добавляем картридж и например Redis доступен. Наверное, если я правильно понимаю можно сразу указать порт. А доступны ли логи? Мониторинг? Настройка других параметров? Статистика?
Доступно ли это все из Web интерфейса?
Большое спасибо за полноценное решение по использованию OpenSSL + ruToken в апплете!
А есть возможность использовать eToken таким же образом?
По поводу исп. JNI в апплете есть замечания — в случае обновления странички с апплетом
может произайти ошибка «UnsatisfiedLinkError: Native Library *.dll already loaded in another classloader».
Это связано с тем что DLL может быть загружена только один раз. Надо эту ошибку как-то специально обрабатывать.
И я не совсем согласен с тем что нужно DLLки хранить как ресурсы, это увеличивает размер апплета. Апплет будет долго грузиться а этот процесс никак не контролируется, апплет в это время будет недоступен.
Скажите, почему не использовали встроенный в Camunda (его кстати также можно отдельно вызывать) движок правил DMN или Drools?
И было бы интересно узнать подход к миграции правил на другую систему, там, как опыт подсказывает, не всегда просто переехать по частям.
По поводу вакансии — можно нанимать тех кто знает Activiti или тех кто знает IBM BPM опыт совместимый. Или если в команде уже есть спецы по Camunda то можно разработчикам дать нужны знания довольно быстро.
Вы правы по поводу поддержки. OSS релизы не так часто как фиксы багов так что тут либо обходить либо бакпортить фиксы в последний релиз. Коммерческая версия есть с поддержкой но она стоит заметно дешевле IBM BPM и т.п. Тут ещё стоит заметить что IBM BPM это suite а Camunda и Activiti это engine.
Не совсем но на 90% буллшит. Аналитики и заказчик используют диаграммы в BPMN нотации для обсуждения и разработки новой функциональности. Но за разработчиками последнее слово в том чтобы сделать схемы исполняемыми. И дело тут не только в схемах BPMN. Мало какое изменение процесса не за трагивает доработку UI или сервисного слоя.
Есть REST API который можно вызывать из любой среды. Систему можно запускать как внешний сервис и загружать новые версии процессов через API.
Папки в Docker Toolbox (для Windows 7/8.1) лучше не подключать как volume — очень медленно выполняются операции чтения/записи.
Можно пробросить порты с 192.168.100.99 на localhost — делается через VirtualBox интерфейс в настройках виртуальной машины default.
Для себя сделал решение — просто перейти на разработку под Linux. Нативная поддержка Docker. Весь инструментарий для разработки Java/Frontend/etc поддерживается нативно. Для чего-нибудь экзотичного VirtualBox с Windows 7.
Было бы кстати очень полезно всем если бы кто-то описал как практически осуществлять Canary Releases (канареечные релизы) для стандартных стэков AWS/Kubernetes, Java/NodeJS/Python/etc..., получать метрики, делать выводы о стабильности релиза. Тут одной микросервисной инфраструктурой не обойдешься.
2) их можно тэгировать. если с п.1) совмещено представьте себе это будет бомба! можно найти все записи везде по одному ID например
3) да. это тоже должна быть прилипающая фишка
Хотелось бы больше инструментов для работы с логами
— фильтрация
— поиск по всем логам проекта Docker Compose.
— «интеллектуальный» фильтр по дате/времени — сегодня/1 мин/5 мин/30 мин/1 час
Декларативный стиль vs процедурный. Как забрать потом артефакты без volume mount?
Т.е. когда нужно собрать, забрать артефакты и уничтожить.
Как насчет ADHOC запросов?
Например 50 concurrent connections. Правильно ли я понимаю что учитывая KeepAlive одновременно с приложением не сможет работать больше 50 человек (в т.ч. учитывая тех кто просто открыл приложение и держит эту вкладку в браузере открытой??)
Можно поподробнее??? Как быть если фронт системка должна данные получать из других систем/пинать их?
С остальным более-менее согласен… Вот только базы данных это некая условность… А dblink и ему подобные вообще не поддерживаемое решение.
> Трудно реализовать асинхронное взаимодействие между сервисами
поясните в чем трудность?
можно делать через Callback WSDL а можно (и более правильно) через очередь + ESB
> Сложно и трудоемко реализовать ответы в «реальном времени», потому что XML дает надежность, а не скорость.
Смотря что подразумевать под «реальным временем». Если говорить про Java то проекты Axis2, Apache CXF добавляют довольно небольшие накладные расходы связанные с SOAP. Конечно все относительно и зависит от требований.
Если про REST
Проблема с REST в том что нет стандартизированного (= общепринятого) способа описания сервисов (аналога WSDL)
Кто во что горазд (например есть «раздутый» Swagger). Нет возможности создать быстро клиента на основе опубликованного сервиса.
Для каждого REST API надо писать своего клиента.
Модернизация старых решений
По моему мнению правильным является сделать так 1) «обернуть» Legacy систему в SOA 2) сделать чтобы все взаимодействие с ней было через SOA 3) заменить или переписать систему не трогая сервисы т.о. связанные системы затронуты не будут.
Добавляем картридж и например Redis доступен. Наверное, если я правильно понимаю можно сразу указать порт. А доступны ли логи? Мониторинг? Настройка других параметров? Статистика?
Доступно ли это все из Web интерфейса?
нужно попробовать iconBIT TV-HUNTER STUDIO подключить к Raspberry PI
не факт что будет работать
Странно что всего 4 тыс рублей вышло, как считали?
Подскажите какой конкретно 1in-2out HDMI splitter использовали и поддерживает ли он 1.3 HDMI 3d
А есть возможность использовать eToken таким же образом?
По поводу исп. JNI в апплете есть замечания — в случае обновления странички с апплетом
может произайти ошибка «UnsatisfiedLinkError: Native Library *.dll already loaded in another classloader».
Это связано с тем что DLL может быть загружена только один раз. Надо эту ошибку как-то специально обрабатывать.
И я не совсем согласен с тем что нужно DLLки хранить как ресурсы, это увеличивает размер апплета. Апплет будет долго грузиться а этот процесс никак не контролируется, апплет в это время будет недоступен.
Идея в том чтобы управлять датчиками и моторами напрямую из Android смартфона.