Часто приходится говорить с клиентами и партнёрами о целостной модернизации приложений. В контексте модернизации приложений наиболее востребованы такие аспекты как обеспечение надёжности приложений, упрощение проектирования и как можно более безотказная эксплуатация. Поэтому среди руководящих представителей инженерного звена всё популярнее становится практика обеспечения надёжности (SRE), де-факто превратившаяся в эксплуатационный стандарт для крупных корпораций. В этом посте я хотел бы изложить простую точку зрения на то, как сочетать SRE и модернизацию enterprise-приложений. Расскажу о том, как коррелируют две эти практики.
Модернизация приложений в основном сводится к следующему:
1. Модернизация технологий, применяемых в приложениях, т.e., эксплуатационной платформы (ОС, контейнеры, виртуальная машина, т.д.), технологий для промежуточного программного обеспечения (MW), сред исполнения приложений. Примеры – переход с .Net framework к .Net core, Jboss, Weblogic, WebSphere, WAS liberty, Open liberty, контейнеры и пр.). Также важна модернизация работы сданными на бэкэнде (трансформация технологий работы с базами данных, переход от распределённых баз данных к озеру данных, модернизация паттернов работы с РСУБД, в частности, переход от SQL к NoSQL, NewSQL, т.д.).
2. Модернизация процессов: упрощение работы с приложениями, трансформация сильно связанных процессов, систем и данных путём внедрения различных паттернов модульного проектирования и выстраивания интеллектуальных потоков задач, что, в свою очередь, позволяет автоматизировать различные процессы.
3. Модернизация платформ для целевого развёртывания приложений. Это (в частности, но не ограничиваясь) паттерны развёртывания с традиционного промежуточного ПО или операционной системы в контейнеры, облачные хранилища, накатывание Kubernetes, OpenShift, переход на различные энтерпрайз-дистрибутивы Linux, в частности, Red Hat Linux. Именно в RHEL можно задействовать для этого целый флот Java-ориентированных технологий, в частности, Quarkus, Vert.x, Thorntail, Node.js, Spring Boot.
4. Переписывание приложений частями или выборочное переписывание модулей, чтобы сделать их нативно-облачными, структурно упростить путём активного внедрения микросервисной архитектуры, модернизации модулей приложений, переход от традиционных паттернов к более легковесным, в частности, от паттернов Spring (модель MVC, аспектно-ориентированное проектирование, безопасность, JDBC, т.д.) к spring boot, т.д. Перепишите некоторые функции приложений в облачно-нативный вид, воспользуйтесь для этого опенсорсными облачно-нативными проектами, возьмите на вооружение облачно-нативную платформу для Java, например, Quarkus.
Теперь давайте коротко обсудим Site Reliability Engineering (SRE), чтобы понять, какая корреляция здесь прослеживается.
SRE – это практика ведения программной инженерии, нацеленная, прежде всего, на повышение надёжности софтверных сервисов. Эта практика становится тем важнее при переходе на удалёнку, а также в условиях, когда цифровой отпечаток отдельного приложения постоянно увеличивается. Речь о приложениях, построенных по моделям B2B, B2C, B2E. Практика SRE была впервые разработана и освоена в Google, а теперь превратилась в отраслевой стандарт и практикуется в компаниях любого размера. Эта практика не новая, а уже хорошо известная. Некоторые их важнейших её достоинств перечислены на следующей схеме:
Схема 1: Шесть достоинств SRE. Модернизация – самый важный из них
Источник: Gblog (google learning)
Базовые принципы SRE:
Недавно я прочитал статью Кита Малина Сугатхадасы, и он очень красиво объяснил эти взаимосвязи на следующей схеме:
Схема 2: Связи между людьми, процессами, политиками и продуктом в контексте SRE
Может быть условлено, что та система, которую поддерживают инженеры по обеспечению надёжности, должна соответствовать определённым отраслевым стандартам, например, ISO 27001 (регулирует безопасность) и ISO 9001 (регулирует качество). В рассмотренном выше случае должен быть способ организовать мониторинг: идёт ли система в ногу с этим стандартом или постепенно отклоняется от него. Подробнее об этом можно почитать в статье здесь.
На следующей схеме показано, как набор умений DevSecOps связывает модернизацию приложений и SRE. Именно так проще всего показать, что модернизация приложений – это потребность, DevSecOps – это принцип, а SRE – это реализация.
Схема 3: Корреляция между модернизацией приложений, обеспечением надёжности сайтов и DevSecOps
Подробнее вопрос DevOps можно изучить у Андреа Кроуфорд, являющейся Заслуженным инженером IBM, работающей в Cloud Garage Solution Engineering, DevOps. По словам Андреа, «Вся суть DevOps – в том, чтобы найти баланс между скоростью и качеством, это самое важное. Скорость без качества разрушительна для цифровой репутации. Качество без скорости убивает цифровую гибкость и отзывчивость». Её лекцию можете посмотреть здесь: https://youtu.be/UbtB4sMaaNM.
Ниже приведу ещё одну иллюстрацию с некоторыми определяющими принципами, которых нужно придерживаться в контексте модернизации приложений.
Схема 4: Корреляция между модернизацией приложений, обеспечением надёжности сайта и DevSecOps
Общими чертами между DevSecOps и SRE являются автоматизация, масштаб, оптимизация мощностей и систематическое представление. В ходе крупномасштабной программы по модернизации также задействуются схожие принципы, некоторые из них я привёл на расположенной выше схеме.
В деталях связи между SRE и DevOps (сегодня считается DevSecOps) объяснены ниже:
Подробнее об этом рассказано в IBM Cloud Learn Hub.
Резюмируя всё вышесказанное, покажу ещё одну схему (напоминающую поднос). Она демонстрирует, что приложения модернизировать необходимо, чтобы соответствовать целям обслуживания, заданным нашими клиентами. Разработка приложений рассматривается как средство модернизации приложений. Модернизация платформ с целью достижения высокой эксплуатационной надёжности – обязательное требование DevSecOps, и один из ключевых путей к достижению этих принципов – применение SRE.
Схема 5: Модернизация приложений и связанные с ней наилучшие практики и принципы
Модернизация приложений подпитывается различными возможностями облачных платформ и является важнейшей составляющей бизнес-роста, так как способствует повышению гибкости, обучению на опыте, ускорению инноваций и уменьшению совокупной стоимости владения, а также нежелательного технического долга. При разработке новых приложений важно вписывать их в стратегически подобранную платформу, а не увлекаться кросс-функционалом и постоянным дообучением руководящих специалистов. DevSecOps и SRE в комбинации – это неотъемлемая часть стратегии модернизации приложений. Подробнее о том, как базовые принципы SRE сочетаются с модернизацией приложений, можно почитать здесь.
В продолжение темы рекомендуем вам ознакомиться с книгой «Модернизация Java Enterprise: облачные технологии для разработчиков»:
» Оглавление
» Отрывок
Для Хаброжителей скидка 25% по купону — Java
По факту оплаты бумажной версии книги на e-mail высылается электронная книга.
Модернизация приложений в основном сводится к следующему:
1. Модернизация технологий, применяемых в приложениях, т.e., эксплуатационной платформы (ОС, контейнеры, виртуальная машина, т.д.), технологий для промежуточного программного обеспечения (MW), сред исполнения приложений. Примеры – переход с .Net framework к .Net core, Jboss, Weblogic, WebSphere, WAS liberty, Open liberty, контейнеры и пр.). Также важна модернизация работы сданными на бэкэнде (трансформация технологий работы с базами данных, переход от распределённых баз данных к озеру данных, модернизация паттернов работы с РСУБД, в частности, переход от SQL к NoSQL, NewSQL, т.д.).
2. Модернизация процессов: упрощение работы с приложениями, трансформация сильно связанных процессов, систем и данных путём внедрения различных паттернов модульного проектирования и выстраивания интеллектуальных потоков задач, что, в свою очередь, позволяет автоматизировать различные процессы.
3. Модернизация платформ для целевого развёртывания приложений. Это (в частности, но не ограничиваясь) паттерны развёртывания с традиционного промежуточного ПО или операционной системы в контейнеры, облачные хранилища, накатывание Kubernetes, OpenShift, переход на различные энтерпрайз-дистрибутивы Linux, в частности, Red Hat Linux. Именно в RHEL можно задействовать для этого целый флот Java-ориентированных технологий, в частности, Quarkus, Vert.x, Thorntail, Node.js, Spring Boot.
4. Переписывание приложений частями или выборочное переписывание модулей, чтобы сделать их нативно-облачными, структурно упростить путём активного внедрения микросервисной архитектуры, модернизации модулей приложений, переход от традиционных паттернов к более легковесным, в частности, от паттернов Spring (модель MVC, аспектно-ориентированное проектирование, безопасность, JDBC, т.д.) к spring boot, т.д. Перепишите некоторые функции приложений в облачно-нативный вид, воспользуйтесь для этого опенсорсными облачно-нативными проектами, возьмите на вооружение облачно-нативную платформу для Java, например, Quarkus.
Теперь давайте коротко обсудим Site Reliability Engineering (SRE), чтобы понять, какая корреляция здесь прослеживается.
SRE – это практика ведения программной инженерии, нацеленная, прежде всего, на повышение надёжности софтверных сервисов. Эта практика становится тем важнее при переходе на удалёнку, а также в условиях, когда цифровой отпечаток отдельного приложения постоянно увеличивается. Речь о приложениях, построенных по моделям B2B, B2C, B2E. Практика SRE была впервые разработана и освоена в Google, а теперь превратилась в отраслевой стандарт и практикуется в компаниях любого размера. Эта практика не новая, а уже хорошо известная. Некоторые их важнейших её достоинств перечислены на следующей схеме:
Схема 1: Шесть достоинств SRE. Модернизация – самый важный из них
Источник: Gblog (google learning)
Базовые принципы SRE:
- Увеличенная длительность работоспособности и доступности — опора на технологии, обеспечение расширенного сотрудничества между инженерами, клиентами и владельцами продукта. Инженеры по надёжности следят за тем, чтобы уровень надёжности и доступности сайта не отклонялся от целевых показателей.
- Система координат для измерения надёжности — инженеры определяют индикаторы уровней обслуживания (SLI) и целевые уровни обслуживания (SLO) для обеспечения согласованной эксплуатации систем. От того, насколько правильно определены SLI, напрямую зависит достижение целей сервиса, и это важная инженерная задача.
- Высокая степень автоматизации — здесь речь идёт о ключевых практиках, направленных на устранение тяжеловесных задач при эксплуатации в продакшене. В особенности это касается задач по поддержке ПО. В результате у инженера освобождается время, которое приходилось бы тратить на устранение неисправностей, и специалист может сосредоточиться на оттачивании архитектурных и эксплуатационных показателей платформы.
- Сквозное понимание — здесь инженеры по обеспечению надёжности тренируются развивать целостное представление обо всём процессе эксплуатации и его составляющих, о том, как устроена каждая из подсистем, и как они сшиваются вместе.
- Раннее обнаружение проблем — здесь имеется в виду концепция «быстрого отказа» в контексте эксплуатации. Исходим из того, что инженеры постоянно ищут, где существуют ограничения возможностей эксплуатации, а также способы улучшения конфигураций. Чем раньше выявляются, а затем решаются потенциальные проблемы, тем меньше они повлияют на вашу систему. Умение предвидеть проблему, опираясь на измерения, гораздо важнее умения ее решить.
Недавно я прочитал статью Кита Малина Сугатхадасы, и он очень красиво объяснил эти взаимосвязи на следующей схеме:
Схема 2: Связи между людьми, процессами, политиками и продуктом в контексте SRE
Может быть условлено, что та система, которую поддерживают инженеры по обеспечению надёжности, должна соответствовать определённым отраслевым стандартам, например, ISO 27001 (регулирует безопасность) и ISO 9001 (регулирует качество). В рассмотренном выше случае должен быть способ организовать мониторинг: идёт ли система в ногу с этим стандартом или постепенно отклоняется от него. Подробнее об этом можно почитать в статье здесь.
На следующей схеме показано, как набор умений DevSecOps связывает модернизацию приложений и SRE. Именно так проще всего показать, что модернизация приложений – это потребность, DevSecOps – это принцип, а SRE – это реализация.
Схема 3: Корреляция между модернизацией приложений, обеспечением надёжности сайтов и DevSecOps
Подробнее вопрос DevOps можно изучить у Андреа Кроуфорд, являющейся Заслуженным инженером IBM, работающей в Cloud Garage Solution Engineering, DevOps. По словам Андреа, «Вся суть DevOps – в том, чтобы найти баланс между скоростью и качеством, это самое важное. Скорость без качества разрушительна для цифровой репутации. Качество без скорости убивает цифровую гибкость и отзывчивость». Её лекцию можете посмотреть здесь: https://youtu.be/UbtB4sMaaNM.
Ниже приведу ещё одну иллюстрацию с некоторыми определяющими принципами, которых нужно придерживаться в контексте модернизации приложений.
Схема 4: Корреляция между модернизацией приложений, обеспечением надёжности сайта и DevSecOps
Общими чертами между DevSecOps и SRE являются автоматизация, масштаб, оптимизация мощностей и систематическое представление. В ходе крупномасштабной программы по модернизации также задействуются схожие принципы, некоторые из них я привёл на расположенной выше схеме.
В деталях связи между SRE и DevOps (сегодня считается DevSecOps) объяснены ниже:
- Принципы DevOps: снизить фрагментацию в организации, активно использовать имеющийся инструментарий и автоматизацию ->> Практика SRE: использовать тот же самый инструментарий для автоматизации и улучшения эксплуатации по мере того, как разработчики продолжают писать и улучшать код.
- Принципы DevOps: относиться к отказам как к нормальному явлению, внедрять постепенные изменения ->> Практика SRE: расходовать бюджет ошибок для непрерывного развёртывания новых функций и возможностей на приемлемом уровне.
- Принцип DevOps: всё измерять ->> Практика SRE: принимать решения о релизе новых программ, исходя из метрик SLA.
Подробнее об этом рассказано в IBM Cloud Learn Hub.
Резюмируя всё вышесказанное, покажу ещё одну схему (напоминающую поднос). Она демонстрирует, что приложения модернизировать необходимо, чтобы соответствовать целям обслуживания, заданным нашими клиентами. Разработка приложений рассматривается как средство модернизации приложений. Модернизация платформ с целью достижения высокой эксплуатационной надёжности – обязательное требование DevSecOps, и один из ключевых путей к достижению этих принципов – применение SRE.
Схема 5: Модернизация приложений и связанные с ней наилучшие практики и принципы
Заключение
Модернизация приложений подпитывается различными возможностями облачных платформ и является важнейшей составляющей бизнес-роста, так как способствует повышению гибкости, обучению на опыте, ускорению инноваций и уменьшению совокупной стоимости владения, а также нежелательного технического долга. При разработке новых приложений важно вписывать их в стратегически подобранную платформу, а не увлекаться кросс-функционалом и постоянным дообучением руководящих специалистов. DevSecOps и SRE в комбинации – это неотъемлемая часть стратегии модернизации приложений. Подробнее о том, как базовые принципы SRE сочетаются с модернизацией приложений, можно почитать здесь.
В продолжение темы рекомендуем вам ознакомиться с книгой «Модернизация Java Enterprise: облачные технологии для разработчиков»:» Оглавление
» Отрывок
Для Хаброжителей скидка 25% по купону — Java
По факту оплаты бумажной версии книги на e-mail высылается электронная книга.