[Микросервисы] Deutsche Telecom: Разделение монолита c Camunda (перевод)
Автор
Сообщение
news_bot ®
Стаж: 6 лет 9 месяцев
Сообщений: 27286
Узнайте, как Deutsche Telecom перешла от каскадной разработки монолитного приложения к гибкой архитектуре на основе микросервисов.
Запуск 10-летней монолитной системы Oracle BPEL оказался кошмаром (см.примечание*) для компании Deutsche Telekom IT GmbH. В связи с тем, что время на реализацию идей (time-to-market) превышало один год, а поставщик ограничил внедрение новых функций, компании Deutsche Telekom IT потребовалось быстро измениться. Узнайте, как этот ведущий поставщик IT-услуг всего за восемь месяцев полностью перешел от каскадной разработки (waterfall) монолитного приложения в архитектуру на основе микросервисов, работая с Camunda и гибкой методологией (agile).
На сегодня компания Telekom IT полностью обновила свои системы и теперь:
- Визуализирует сложную логику в одном месте
- Легко согласует задания для сотрудников и автоматизированные задачи
- Использует один и тот же язык для бизнеса и разработки, включая нативную поддержку Java
- Легко встраивает движок Camunda в различные микросервисы
- Визуализирует операции в реальном времени с помощью Camunda Cockpit, с первого взгляда понимая прогресс любого процесса
- Обеспечивает «безопасность по умолчанию» («compliance-by-default») для глобальных распределенных групп, различных поставщиков и конфиденциальных данных
Монолитные проблемы
Deutsche Telekom IT GmbH является внутренним поставщиком IT-услуг компании Deutsche Telekom AG. Компания насчитывает около 9 700 сотрудников по всему миру и располагает общим бюджетом около 1,9 млрд. евро. Она отвечает за проектирование, разработку и эксплуатацию всех собственных и переданных ей IT-систем для поддержки бизнес-процессов Deutsche Telekom и ее дочерних компаний.
В 2007 году компания Deutsche Telekom IT начала использовать движок Oracle BPEL для построения и запуска рабочих процессов BPM и автоматизации процессов. Но этот монолит создал ряд проблем, которые повлияли как на бизнес, так и на пользовательский опыт:
- Длительный срок выхода идеи на рынок (time-to-market), длившийся более 12 месяцев
- Привязка к поставщику ограничивала внедрение новых функций — на настройку или внесение изменений в среду уходило пять дней
- Релизы занимали в среднем 1000 человеко-дней или около трех месяцев
- Регрессионное тестирование занимало около двух дней для выполнение всех тест-кейсов
«Мы должны быть вовремя, мы не можем ждать семь дней, чтобы обработать заказ, мы не можем ждать семь дней, чтобы ответить на что-то, мы должны всегда быть впереди и всегда ответственными», — объяснил Willm Tüting, управляющий директор компании Conology GmbH, которая работает с Deutsche Telekom IT уже более 10 лет.
Частичная гибкость — это бессмыслица
В 2017 году, запустив 10-летнюю монолитную систему, компания Deutsche Telekom IT сделала первые шаги на пути к модернизации своих процессов, приняв «частично гибкий» подход к разработке, работая в трехмесячном спринте.
«Мы создали несколько процессов для более быстрой доставки мелких исправлений, но это значительно усложнило жизнь», — сказал Willm Tüting.
Все исправления должны были быть доставлены с более крупными запросами на изменения, на что уходило значительное количество рабочих часов. Кроме того, мы упирались в монолитную систему BPEL, которая не обеспечивала настоящей гибкости.
Создание основ для перемен
В 2017 году Deutsche Telekom начала инвестировать в оптоволоконные кабели, чтобы улучшить сервис для пользователей. Благодаря этому существенному обновлению оборудования появилась возможность произвести революцию в устаревших системах Deutsche Telekom IT. Это привело к полному изменению как операционной системы, так и подхода DevOps, руководствуясь тремя целями:
- Ускорение: перевод разработки с BPEL на Java и методов работы с каскадного на гибкий
- Межфункциональные команды: переход от команд, основанных на навыках, к международным кросс-функциональным командам
- Эффективность: повышение эффективности разработки с помощью Camunda, SPRING и других современных технологий
От одного поставщика до 43 платформ
Помня о трех целях, Deutsche Telekom IT реализовала архитектуру на основе микросервисов в облаке с механизмами Camunda BPM, работающими во многих микросервисах. Friedbert Samland, руководитель проекта IT-приложения Deutsche Telekom IT, объяснил, что новая система состоит из элементов:
- Микросерисы: Этот подход разделяет монолит и позволяет выполнять кросс-функциональную работу. Нет GUI, вместо него теперь чистая система BPMN. «Вдохновленные руководством по микросервисам соучредителя Camunda Bernd Ruecker,
мы запускаем движки Camunda во многих микросервисах, обращаясь напрямую к Брокеру сообщений», — пояснил Friedbert.
- Облако: Возможности облака резко сокращают время выполнения и позволяют применять поэтапный подход к доставке с оптимизацией. Не имея готового решения, Telekom IT разработала собственный подход на основе Kubernetes.
- Гибкая среда SAFe: Введение новой организации с более коротким временем сквозного цикла обеспечило гибкость и скорость.
- Философия DevOps: Автоматизация и самообслуживание являются ключевыми элементами философии DevOps Telekom IT и обеспечивают качество и скорость.
Camunda изменила правила игры
Одним из величайших преимуществ революции Camunda в Deutsche Telekom IT стала возможность «безопасность по умолчанию» («compliance-by-default»). Это высоко автоматизированное решение было необходимо глобально распределенному бизнесу, с командами, работающими по всему миру с различными поставщиками и конфиденциальными данными. Результатом является архитектура, которая обеспечивает «безопасность по умолчанию» («compliance-by-default») и защиту данных.
Deutsche Telekom IT также создала свою собственную платформу внутреннего мониторинга процессов, вдохновленную концепцией жетонов (token), использованной в Camunda’s Cockpit, чтобы пользователи могли с первого взгляда понимать прогресс любого процесса.
Кроме того, помимо поддержки очень гибкой философии DevOps, Camunda позволила Deutsche Telekom IT визуализировать сложную логику в одном месте, легко согласовать задачи сотрудников и автоматизированные задачи, и использовать один и тот же язык для бизнеса и разработки с BPMN.
Тем, кто думает пойти по стопам Deutsche Telekom IT, Willm Tüting дает совет: «Выбирайте стек с умом, не начинайте с полного набора, выбирайте вещи, которые приносят наибольшую пользу вашим потребностям. Думайте масштабно, начинайте с малого, не пытайтесь заполучить Святой Грааль с первой попытки — развивайтесь туда, где вы хотите быть».
*Примечание: С переводом статьи возились долго, из-за слайдов. Когда начинали перевод,
в оригинале статьи был абзац про «кошмар» (см. веб архив), но потом Camunda удалила его.
**Примечание: Переведенные слайды пресс-релиза в PDF можно скачать по ссылке.
===========
Источник:
habr.com
===========
===========
Автор оригинала: Camunda
===========Похожие новости:
- [PHP, Анализ и проектирование систем, Конференции, Микросервисы] 26 сентября приглашаем на оффлайн-митап HOT Backend&Web в Краснодаре
- [Серверное администрирование] Использование форм React с Tasklist Camunda (перевод)
- [Разработка веб-сайтов, Микросервисы] Как мы распилили монолит. Часть 1
- [Разработка веб-сайтов, Разработка мобильных приложений, Управление разработкой, Микросервисы] Micro-frontend. Асинхронный подход к мультикомандной разработке
- [Высокая производительность, Анализ и проектирование систем, Промышленное программирование, Распределённые системы] Выбор архитектурного стиля (часть 1)
- [IT-инфраструктура, История IT, IT-компании, Микросервисы] Как перестать беспокоиться и начать жить без монолита
- [Высокая производительность, Программирование, Анализ и проектирование систем, Промышленное программирование] Проблематика распределенных транзакций в контексте микросервисной архитектуры
- [Проектирование и рефакторинг, Управление разработкой, Микросервисы] Что делать если никто не хочет документировать? Организация документирования микросервисов по минимуму
- [Проектирование и рефакторинг, Управление разработкой, Микросервисы] Что делать если никто не хочет документировать? Организация документирования микросервисов по минимуму — часть 2
- [Open source, .NET, IT-инфраструктура] ViennaNET: набор библиотек для backend’а. Часть 2
Теги для поиска: #_mikroservisy (Микросервисы), #_camunda, #_bpmsistemy (bpm-системы), #_mikroservisy (микросервисы), #_mikroservisy (
Микросервисы
)
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 22-Ноя 19:26
Часовой пояс: UTC + 5
| Автор | Сообщение |
|---|---|
|
news_bot ®
Стаж: 6 лет 9 месяцев |
|
 Узнайте, как Deutsche Telecom перешла от каскадной разработки монолитного приложения к гибкой архитектуре на основе микросервисов. Запуск 10-летней монолитной системы Oracle BPEL оказался кошмаром (см.примечание*) для компании Deutsche Telekom IT GmbH. В связи с тем, что время на реализацию идей (time-to-market) превышало один год, а поставщик ограничил внедрение новых функций, компании Deutsche Telekom IT потребовалось быстро измениться. Узнайте, как этот ведущий поставщик IT-услуг всего за восемь месяцев полностью перешел от каскадной разработки (waterfall) монолитного приложения в архитектуру на основе микросервисов, работая с Camunda и гибкой методологией (agile). На сегодня компания Telekom IT полностью обновила свои системы и теперь:
Монолитные проблемы Deutsche Telekom IT GmbH является внутренним поставщиком IT-услуг компании Deutsche Telekom AG. Компания насчитывает около 9 700 сотрудников по всему миру и располагает общим бюджетом около 1,9 млрд. евро. Она отвечает за проектирование, разработку и эксплуатацию всех собственных и переданных ей IT-систем для поддержки бизнес-процессов Deutsche Telekom и ее дочерних компаний. В 2007 году компания Deutsche Telekom IT начала использовать движок Oracle BPEL для построения и запуска рабочих процессов BPM и автоматизации процессов. Но этот монолит создал ряд проблем, которые повлияли как на бизнес, так и на пользовательский опыт:
«Мы должны быть вовремя, мы не можем ждать семь дней, чтобы обработать заказ, мы не можем ждать семь дней, чтобы ответить на что-то, мы должны всегда быть впереди и всегда ответственными», — объяснил Willm Tüting, управляющий директор компании Conology GmbH, которая работает с Deutsche Telekom IT уже более 10 лет. Частичная гибкость — это бессмыслица В 2017 году, запустив 10-летнюю монолитную систему, компания Deutsche Telekom IT сделала первые шаги на пути к модернизации своих процессов, приняв «частично гибкий» подход к разработке, работая в трехмесячном спринте. «Мы создали несколько процессов для более быстрой доставки мелких исправлений, но это значительно усложнило жизнь», — сказал Willm Tüting. Все исправления должны были быть доставлены с более крупными запросами на изменения, на что уходило значительное количество рабочих часов. Кроме того, мы упирались в монолитную систему BPEL, которая не обеспечивала настоящей гибкости. Создание основ для перемен В 2017 году Deutsche Telekom начала инвестировать в оптоволоконные кабели, чтобы улучшить сервис для пользователей. Благодаря этому существенному обновлению оборудования появилась возможность произвести революцию в устаревших системах Deutsche Telekom IT. Это привело к полному изменению как операционной системы, так и подхода DevOps, руководствуясь тремя целями:
От одного поставщика до 43 платформ Помня о трех целях, Deutsche Telekom IT реализовала архитектуру на основе микросервисов в облаке с механизмами Camunda BPM, работающими во многих микросервисах. Friedbert Samland, руководитель проекта IT-приложения Deutsche Telekom IT, объяснил, что новая система состоит из элементов:
Camunda изменила правила игры Одним из величайших преимуществ революции Camunda в Deutsche Telekom IT стала возможность «безопасность по умолчанию» («compliance-by-default»). Это высоко автоматизированное решение было необходимо глобально распределенному бизнесу, с командами, работающими по всему миру с различными поставщиками и конфиденциальными данными. Результатом является архитектура, которая обеспечивает «безопасность по умолчанию» («compliance-by-default») и защиту данных. Deutsche Telekom IT также создала свою собственную платформу внутреннего мониторинга процессов, вдохновленную концепцией жетонов (token), использованной в Camunda’s Cockpit, чтобы пользователи могли с первого взгляда понимать прогресс любого процесса. Кроме того, помимо поддержки очень гибкой философии DevOps, Camunda позволила Deutsche Telekom IT визуализировать сложную логику в одном месте, легко согласовать задачи сотрудников и автоматизированные задачи, и использовать один и тот же язык для бизнеса и разработки с BPMN. Тем, кто думает пойти по стопам Deutsche Telekom IT, Willm Tüting дает совет: «Выбирайте стек с умом, не начинайте с полного набора, выбирайте вещи, которые приносят наибольшую пользу вашим потребностям. Думайте масштабно, начинайте с малого, не пытайтесь заполучить Святой Грааль с первой попытки — развивайтесь туда, где вы хотите быть». *Примечание: С переводом статьи возились долго, из-за слайдов. Когда начинали перевод, в оригинале статьи был абзац про «кошмар» (см. веб архив), но потом Camunda удалила его. **Примечание: Переведенные слайды пресс-релиза в PDF можно скачать по ссылке.              =========== Источник: habr.com =========== =========== Автор оригинала: Camunda ===========Похожие новости:
Микросервисы ) |
|
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 22-Ноя 19:26
Часовой пояс: UTC + 5