Согласитесь: конкуренция среди ІТ-компаний настолько высока, а услуги специалистов настолько в цене, что в битве за клиентов побеждает тот, кто может предоставлять максимально точную информацию и быстрые результаты. Именно поэтому акселераторы сегодня создают многие. Мы с коллегами в ЕРАМ давно убедились: предложить клиентам бесплатно свою интеллектуальную собственность – подчас хорошее конкурентное преимущество. Это – одна из причин, по которой ежегодно наши эксперты создают различные решения для ускорения и оптимизации процессов поставки программного продукта.
В этом материале Андрей Трубицын, Senior Solution Architect в EPAM Украина, расскажет о своем опыте создания акселератора для миграции приложений из On-Premise в Cloud. Далее — текст от первого лица.
А что если такой запрос – не единичный? ЕРАМ в силу своих масштабов реализует ежегодно сотни проектов. Несколько десятков из них могут касаться миграции сотен приложений в облака. В таких условиях понимание, что работу необходимо оптимизировать, а некоторые процессы задокументировать и автоматизировать, возникает достаточно быстро и здесь также необходимо говорить о некотором акселераторе.
Вообще, акселератор, на мой взгляд, – понятие достаточно широкое. Оно включает в себя все, что позволяет ускорить delivery-процесс. Вплоть до качественной документации: для команды из 2-3 человек она уже облегчит передачу знаний новым членам рабочей группы и значит оптимизирует процесс в целом. Ну, а если речь идет о большом количестве кросс-функциональных команд, что очень распространено в текущей ситуации на рынке, то автоматизация повторяющихся процессов – важная задача. Как правило, именно архитектор решений может увидеть такие тенденции на масштабе всего проекта и донести необходимость оптимизировать их менеджменту.
Конечно, если речь идет о переносе 1-5 приложений, то нет смысла усложнять: необходимо понять архитектуру в On-Premise, построить таргет-архитектуру в облаке, прописать процесс транзита и после выполнять его, присматривая за тем, чтобы команда по миграции следовала всем требованиям проекта. Однако, если речь идет о 800 максимально разноплановых приложениях, как было у заказчика, с которым я недавно сотрудничал, понимание, что надо оптимизировать и ускорять процессы, исходя из прошлого опыта, возникает быстро.
Представим, что мы получили новую порцию приложений для миграции, скажем,40 приложений. Нам надо сообщить заказчику, когда мы завершим миграцию, ведь клиент должен планировать работу своих команд, бюджеты, зависимости, чтобы правильно понять, в какие моменты выполнять задачи, связанные с нашим процессом. Потому дорожная карта работы и толковая оценка очень важны. Однако взять и оценить сразу несколько десятков или даже сотен приложений сложно: нет времени пойти в каждое, посмотреть его архитектуру, пересчитать базы данных, выявить зависимости и процедуры, количество пользователей и востребованность приложения и так далее. Поэтому прежде всего надо понять, с чем мы имеем дело и на основе опросника сделать первую (пусть и не самую точную) оценку.
Итак, первая часть нашего акселератора – это своего рода опрос. Он позволяет с помощью анкетирования Product Owner-ов и архитекторов клиента, а также знания нашего предыдущего опыта миграции, составить базовое понимание времени, которое потребуется на заданную работу. То есть, если мы знаем, что одну хранимую процедуру в базе можно мигрировать в течение дня в соответствии с опредленным паттерном, а таких процедур у нас 5000, то можно сделать заключение, что потребуется 5000 человекодней только на этот шаг. Подобные вычисления позволяют нам делать определенные оценочные суждения и строить дорожную карту.
Второй шаг для ускорения миграции – формирование беклога для инженеров, анализ кода и выявление деталей имплементации. Специалист, запуская нужный инструмент, получает в Jira или другом планере список задач для выполнения. Он будет, конечно, не полным, но больше 90% всех деталей, которые надо изменить, покроет. Для каждой задачи в беклоге обозначена оценка времени на выполнение. Снова же, мы основываем наши оценки на наблюдениях, за какое время разработчики разных квалификаций выполняют одну и ту же работу. А помимо задачи и оценки времени доступна ссылка на пример выполнения, готовый темплейт или словесное описание подхода для решения. Благодаря этому проект получает еще более точную оценку запланированного времени и автоматизирование всех деталей имплементации благодаря удачному переиспользованию знаний от других команд. Все это позволяет привлекать к массовой миграции новые команды и тратить на их обучение и онбординг минимум времени.
Далее – детали имплементации транзита приложения в облако. Снова пример: скажем, у вас есть сервис в On-Premise, который работает с SFTP. При миграции в облако у клиента есть требования, которые запрещают использовать SFTP-сервис, и правило, которое говорит, что обмен данными происходит через S3 bucket в облачном сервисе Amazon. Анализатор кода смотрит на исходный код сервиса, находит работу с SFTP-сервисом и подсвечивает это как задачи на изменение имплементации, создание S3 bucket (если он не создан), подключение AWS SDK в исходный код, использование API Amazon вместо API SFTP и проделывает другие необходимые действия.
И третья часть – непосредственное изменение кода. Вероятно, из всего перечня деталей имплементации, которые нужно изменить при миграции в клауд, какие-то будут достаточно простыми. Например, надо изменить строку, которая определяет способ подключения к базе данных. В принципе, это посильная задача для того, чтобы делать ее автоматически. Если так поступить, то время, которое инженер тратит на банальную, рутинную работу, сократится.
Давайте разберемся, в чем польза такого акселератора для менеджера, архитектора и инженера.
Опрос позволит дать достаточно качественные оценки для планирования и детального обсуждения с клиентами. В то время как конкуренты попросят дополнительного времени на эстимацию, вы, опираясь на предыдущий опыт, сможете оперировать вполне конкретными цифрами. Четкая оценочная модель дает большую уверенность и обоснование прогнозов. На стадии пресейлов это очень важно.
Конечно, чтобы такой опрос дал хорошие результаты, Product Owner-ы, архитекторы и инженеры клиента должны знать продукт. Хуже дело, если в системе есть сервисы, которые работают, но никто не знает как. В таком случае оценочная часть акселератора не поможет. Придется обращаться ко второй – и запускать сканирование кода.
Справиться с этой задачей отчасти помогут инструменты по сканированию кода. Однако именно работа архитектора меньше всего автоматизируется: если выявить зависимости и влияние нашего приложения на другие мы еще можем, то понять, какие сервисы влияют на наш продукт, крайне непросто. Лично я в данный момент не вижу пути для оптимизации этого процесса. Инструменты по сканированию сети или зависимостей, которые доступны в интернете, на моей памяти ни разу не давали хорошего результата. Причина проста: безопасность. Вам скорее всего не разрешат сканировать весь нетворк клиента в On-Premise. Да и запустить инструмент непонятного производителя в недрах системы заказчика, где находятся данные, охраняемые как коммерческая тайна, очень рискованно. Даже если вам позволят использовать некий тул после оценки его безопасности, она может занять несколько месяцев. А вы за это время могли бы уже мигрировать часть приложения в облако.
Поэтому основная польза для архитектора от такого акселератора состоит в том, что он достаточно быстро получает набор некой технической информации, которая может помочь в его оценочных суждениях и работе по созданию таргет-архитектуры и процесса миграции из On-Premise в Cloud.
По моему опыту, чтобы оценить миграцию в облако, стоит смотреть на следующие моменты:
Вскоре стало ясно, что подобную задачу решают и другие лидеры и команды ЕРАМ (такие вот издержки глобальной компании: некоторые умы мыслят схоже и сталкиваются с одинаковыми вызовами). Мы пообщались с коллегами и пришли к выводу, что акселератор можно использовать как для непосредственной разработки, так и для пресейлов и и первой оценки сложности миграции экосистемы клиента в облако. Опросники, которые мы составляли параллельно, покрывали несколько разные аспекты и это натолкнуло на мысль, что мы можем создать общую базу вопросов. В таком случае на первом этапе использования акселератора каждый специалист сможет собрать свою анкету согласно конкретному запросу, клиенту, его специфике и требованиям к миграции.
Мы с коллегами начали работать как одна команда и сформировали достаточно базовую архитектуру будущего акселератора. Это front-end приложение с одним из «движков» на JavaScript для создания опросников, back-end на основе Java и PostgreSQL для сбора, агрегации и работы со статистикой, правилами для Sonarqube, которые помогают искать проблемы в коде, и репортингом. Сразу замечу, что мы используем свой front-end вместо front-end-а Sonarqube потому, потому что смотрим в будущее и хотим агрегировать результаты работы многих инструментов, а архитектуру нашего продукта сделать максимально простой для изменений, чтобы он мог эволюционировать и добавление новых функций занимало минимум времени. Также мы планируем добавлять различные сканеры в наш акселератор и каждый из них будет выдавать какой-либо набор метрик. Далее мы будем агрегировать эти метрики, включая результаты опросника, что позволит максимально точно и полно судить об On-Premise приложениях клиента и проводить миграцию в самые сжатые сроки.
У нас большие планы, потому что запрос на акселератор уже достаточно острый. На горизонте у ЕРАМ есть несколько крупных клиентов, которые делают миграцию и заинтересованы в нашем продукте. В данный момент мы взаимодействуем с командами на проектах для разных заказчиков, чтобы скоординировать усилия и получить результат, которые принесет максимум пользы как для нынешних, так и для будущих клиентов.
habr.com
В этом материале Андрей Трубицын, Senior Solution Architect в EPAM Украина, расскажет о своем опыте создания акселератора для миграции приложений из On-Premise в Cloud. Далее — текст от первого лица.
Таблетка от рутины
Давайте начнем с простого примера. Представьте распространенную ситуацию: для миграции в облако заказчик выбирает микросервисную архитектуру. Она предполагает создание микросервиса-пустышки, который будет встраиваться в платформу и соответствовать всем требованиям клиента по тегированию, безопасности и прочим аспектам. В энтерпрайз этот процесс – достаточно трудоемкий и потребует 5-7 человекодней. Если система большая и микросервисов много, то имеют смысл акселераторы для создания «пустышки» и CI/CD пайплайнов для нее, а также Cloud Formation скриптов для выгрузки в рабочее окружение. Другой вариант - акселератор для создания простейших паттернов для аутентификации, например, API gateways и лямбды для аутентификации. Акселераторы существенно ускорят имплементацию функционала, сократят время скучной, повторяющейся работы для инженеров, а значит отчасти повысят их мотивацию и удовлетворенность от работы. В итоге новая функциональность появится на продакшене быстрее и с лучшим качеством.А что если такой запрос – не единичный? ЕРАМ в силу своих масштабов реализует ежегодно сотни проектов. Несколько десятков из них могут касаться миграции сотен приложений в облака. В таких условиях понимание, что работу необходимо оптимизировать, а некоторые процессы задокументировать и автоматизировать, возникает достаточно быстро и здесь также необходимо говорить о некотором акселераторе.
Вообще, акселератор, на мой взгляд, – понятие достаточно широкое. Оно включает в себя все, что позволяет ускорить delivery-процесс. Вплоть до качественной документации: для команды из 2-3 человек она уже облегчит передачу знаний новым членам рабочей группы и значит оптимизирует процесс в целом. Ну, а если речь идет о большом количестве кросс-функциональных команд, что очень распространено в текущей ситуации на рынке, то автоматизация повторяющихся процессов – важная задача. Как правило, именно архитектор решений может увидеть такие тенденции на масштабе всего проекта и донести необходимость оптимизировать их менеджменту.
Конечно, если речь идет о переносе 1-5 приложений, то нет смысла усложнять: необходимо понять архитектуру в On-Premise, построить таргет-архитектуру в облаке, прописать процесс транзита и после выполнять его, присматривая за тем, чтобы команда по миграции следовала всем требованиям проекта. Однако, если речь идет о 800 максимально разноплановых приложениях, как было у заказчика, с которым я недавно сотрудничал, понимание, что надо оптимизировать и ускорять процессы, исходя из прошлого опыта, возникает быстро.
Концепция акселератора
Свой акселератор для миграции приложений из On-Premise в Cloud мы с коллегами условно разделили на три части:- для менеджеров и архитекторов: акселерация discovery и оценки по миграции, которые помогут в планировании и минимизации рисков для delivery;
- для архитекторов и инженеров: рекомендации, чтобы оценить и создать беклог работы, которую предстоит провести с кодом для успешной миграции;
- для инженеров: советы для работы с кодом и простые изменения в коде, которые помогут автоматизировать миграцию.
Представим, что мы получили новую порцию приложений для миграции, скажем,40 приложений. Нам надо сообщить заказчику, когда мы завершим миграцию, ведь клиент должен планировать работу своих команд, бюджеты, зависимости, чтобы правильно понять, в какие моменты выполнять задачи, связанные с нашим процессом. Потому дорожная карта работы и толковая оценка очень важны. Однако взять и оценить сразу несколько десятков или даже сотен приложений сложно: нет времени пойти в каждое, посмотреть его архитектуру, пересчитать базы данных, выявить зависимости и процедуры, количество пользователей и востребованность приложения и так далее. Поэтому прежде всего надо понять, с чем мы имеем дело и на основе опросника сделать первую (пусть и не самую точную) оценку.
Итак, первая часть нашего акселератора – это своего рода опрос. Он позволяет с помощью анкетирования Product Owner-ов и архитекторов клиента, а также знания нашего предыдущего опыта миграции, составить базовое понимание времени, которое потребуется на заданную работу. То есть, если мы знаем, что одну хранимую процедуру в базе можно мигрировать в течение дня в соответствии с опредленным паттерном, а таких процедур у нас 5000, то можно сделать заключение, что потребуется 5000 человекодней только на этот шаг. Подобные вычисления позволяют нам делать определенные оценочные суждения и строить дорожную карту.
Второй шаг для ускорения миграции – формирование беклога для инженеров, анализ кода и выявление деталей имплементации. Специалист, запуская нужный инструмент, получает в Jira или другом планере список задач для выполнения. Он будет, конечно, не полным, но больше 90% всех деталей, которые надо изменить, покроет. Для каждой задачи в беклоге обозначена оценка времени на выполнение. Снова же, мы основываем наши оценки на наблюдениях, за какое время разработчики разных квалификаций выполняют одну и ту же работу. А помимо задачи и оценки времени доступна ссылка на пример выполнения, готовый темплейт или словесное описание подхода для решения. Благодаря этому проект получает еще более точную оценку запланированного времени и автоматизирование всех деталей имплементации благодаря удачному переиспользованию знаний от других команд. Все это позволяет привлекать к массовой миграции новые команды и тратить на их обучение и онбординг минимум времени.
Далее – детали имплементации транзита приложения в облако. Снова пример: скажем, у вас есть сервис в On-Premise, который работает с SFTP. При миграции в облако у клиента есть требования, которые запрещают использовать SFTP-сервис, и правило, которое говорит, что обмен данными происходит через S3 bucket в облачном сервисе Amazon. Анализатор кода смотрит на исходный код сервиса, находит работу с SFTP-сервисом и подсвечивает это как задачи на изменение имплементации, создание S3 bucket (если он не создан), подключение AWS SDK в исходный код, использование API Amazon вместо API SFTP и проделывает другие необходимые действия.
И третья часть – непосредственное изменение кода. Вероятно, из всего перечня деталей имплементации, которые нужно изменить при миграции в клауд, какие-то будут достаточно простыми. Например, надо изменить строку, которая определяет способ подключения к базе данных. В принципе, это посильная задача для того, чтобы делать ее автоматически. Если так поступить, то время, которое инженер тратит на банальную, рутинную работу, сократится.
Давайте разберемся, в чем польза такого акселератора для менеджера, архитектора и инженера.
Польза для Delivery-менеджера
Сразу отмечу, что на миграционных проектах эту роль может выполнять и архитектор. Как бы там ни было, задача этого специалиста – пообщаться с клиентом, определить объем работы, оценить время на выполнение, построить дорожную карту и согласовать все это с заказчиком. Очевидно, что для всех этих задач акселератор для миграции приложений из On-Premise в Cloud – незаменимый помощник.Опрос позволит дать достаточно качественные оценки для планирования и детального обсуждения с клиентами. В то время как конкуренты попросят дополнительного времени на эстимацию, вы, опираясь на предыдущий опыт, сможете оперировать вполне конкретными цифрами. Четкая оценочная модель дает большую уверенность и обоснование прогнозов. На стадии пресейлов это очень важно.
Конечно, чтобы такой опрос дал хорошие результаты, Product Owner-ы, архитекторы и инженеры клиента должны знать продукт. Хуже дело, если в системе есть сервисы, которые работают, но никто не знает как. В таком случае оценочная часть акселератора не поможет. Придется обращаться ко второй – и запускать сканирование кода.
Польза для архитектора
При миграции архитектору важно понимать зависимости системы. Если инженеры смогут переделать код, чтобы он заработал в облаке, то архитектору надо знать как сервисы взаимодействуют в On-Premise и как сохранится это взаимодействие после того, как транзит завершится. Например, в случае с On-Premise классикой является взаимодействие сервисов через базу данных или просто файловую систему: один сервис пишет файл утром, а другой читает его вечером. Или у клиента может быть очень древняя система для оркестрации рабочего процесса и мигрировать ее в облако не получится банально потому, что она устарела и не поддерживается. Таких особенностей может быть много и архитектору важно понять все связи и зависимости в системе приложения и над ним.Справиться с этой задачей отчасти помогут инструменты по сканированию кода. Однако именно работа архитектора меньше всего автоматизируется: если выявить зависимости и влияние нашего приложения на другие мы еще можем, то понять, какие сервисы влияют на наш продукт, крайне непросто. Лично я в данный момент не вижу пути для оптимизации этого процесса. Инструменты по сканированию сети или зависимостей, которые доступны в интернете, на моей памяти ни разу не давали хорошего результата. Причина проста: безопасность. Вам скорее всего не разрешат сканировать весь нетворк клиента в On-Premise. Да и запустить инструмент непонятного производителя в недрах системы заказчика, где находятся данные, охраняемые как коммерческая тайна, очень рискованно. Даже если вам позволят использовать некий тул после оценки его безопасности, она может занять несколько месяцев. А вы за это время могли бы уже мигрировать часть приложения в облако.
Поэтому основная польза для архитектора от такого акселератора состоит в том, что он достаточно быстро получает набор некой технической информации, которая может помочь в его оценочных суждениях и работе по созданию таргет-архитектуры и процесса миграции из On-Premise в Cloud.
Польза для инженера
Как правило, инженер мигрирует одно приложение за один раз. Он не знает, сколько времени потребуется на миграцию 100-200 и больше сервисов. Однако это важно. Если предстоит большая миграция, то ему стоит начинать собирать правила, чтобы потом включить их в Sonarqube или другой инструмент и делать анализ кода точнее и быстрее. В таком случае, когда начнется миграция нового приложения и менеджер задаст вопрос, как быстро удастся ее завершить, у инженера будет возможность сделать приблизительный рассчет благодаря качественному анализу кода и правилам, сохраненным после предыдущего процесса.По моему опыту, чтобы оценить миграцию в облако, стоит смотреть на следующие моменты:
- Язык приложения;
- Фреймворк;
- Application сервер;
- Базы данных и их количество;
- Использование файловой системы;
- Интеграцию с внешними сервисами и переиспользование внешнего API в вашей системе, а также зависимость от количества внешних серверов.
Немного внутренней кухни
Схожие вызовы на разных аккаунтах изначально заметил СТО ЕРАМ Эли Фельдман. С его легкой руки задача попала в наш Центр компетенции по Java, где за нее взялся я и пару коллег. На старте работы над новым акселератором мы поняли, что для начала нужен опросник и оценочная модель. Первым шагом для их формирования стало создание общей таблицы в Excel. Мы планировали проверить модель и потом уже имплементировать ее в продукт. На втором этапе (создание беклога) мы стали смотреть в сторону Sonarqube и его правил. Не было смысла разрабатывать с нуля свой анализатор кода, куда логичнее использовать один из самых продвинутых open-source «движков». Сделав выбор, мы начали писать правила, которые могли бы быть имплементированы на Java в Sonarqube и переиспользованы в любой точке ЕРАМ. Третий этап нашей работы – проработка плагинов для популярных IDE.Вскоре стало ясно, что подобную задачу решают и другие лидеры и команды ЕРАМ (такие вот издержки глобальной компании: некоторые умы мыслят схоже и сталкиваются с одинаковыми вызовами). Мы пообщались с коллегами и пришли к выводу, что акселератор можно использовать как для непосредственной разработки, так и для пресейлов и и первой оценки сложности миграции экосистемы клиента в облако. Опросники, которые мы составляли параллельно, покрывали несколько разные аспекты и это натолкнуло на мысль, что мы можем создать общую базу вопросов. В таком случае на первом этапе использования акселератора каждый специалист сможет собрать свою анкету согласно конкретному запросу, клиенту, его специфике и требованиям к миграции.
Мы с коллегами начали работать как одна команда и сформировали достаточно базовую архитектуру будущего акселератора. Это front-end приложение с одним из «движков» на JavaScript для создания опросников, back-end на основе Java и PostgreSQL для сбора, агрегации и работы со статистикой, правилами для Sonarqube, которые помогают искать проблемы в коде, и репортингом. Сразу замечу, что мы используем свой front-end вместо front-end-а Sonarqube потому, потому что смотрим в будущее и хотим агрегировать результаты работы многих инструментов, а архитектуру нашего продукта сделать максимально простой для изменений, чтобы он мог эволюционировать и добавление новых функций занимало минимум времени. Также мы планируем добавлять различные сканеры в наш акселератор и каждый из них будет выдавать какой-либо набор метрик. Далее мы будем агрегировать эти метрики, включая результаты опросника, что позволит максимально точно и полно судить об On-Premise приложениях клиента и проводить миграцию в самые сжатые сроки.
У нас большие планы, потому что запрос на акселератор уже достаточно острый. На горизонте у ЕРАМ есть несколько крупных клиентов, которые делают миграцию и заинтересованы в нашем продукте. В данный момент мы взаимодействуем с командами на проектах для разных заказчиков, чтобы скоординировать усилия и получить результат, которые принесет максимум пользы как для нынешних, так и для будущих клиентов.
Упрощай и властвуй. Как акселератор может ускорить миграцию приложений из On-Premise в Cloud?
Согласитесь: конкуренция среди ІТ-компаний настолько высока, а услуги специалистов настолько в цене, что в битве за клиентов побеждает тот, кто может предоставлять максимально точную информацию и...
habr.com