Rivalry2

HTML Diff

0 added 0 removed

Original 2026-01-01

Modified 2026-03-10

1 <p>Перед тем, как начать перенос приложения в облако и приступить к выстраиванию<strong>Cloud Native</strong>-архитектуры, следует убедиться, что ваше приложение к этому переносу по-настоящему готово. Специалисты выделяют 5 базовых принципов, которые характерны для современных Cloud Native-приложений.</p>

2 <h2>1. Динамичность</h2>

3 <p>Под динамичностью понимается возможность быстро развернуть и сконфигурировать систему на любой новой площадке, что особенно актуально в случае внезапной смены облачного провайдера. Средствами достижения динамичности являются такие известные подходы, как CI/CD и Infrastructure As Code (IaC).</p>

4 <p><strong>Инструменты</strong>: Terraform, Ansible, Salt, Foreman, Pulumi, Cloudify, AWS Cloud Formation.</p>

5 <h2>2. Возможность эксплуатации</h2>

6 <p>Здесь мы говорим о возможности управлять жизненным циклом систем в автоматизированном режиме. Говоря по правде, это свойство довольно тесно связано с динамичностью, так как включает в себя, в первую очередь, использование CI/CD-пайплайнов для автоматического развертывания программных приложений. То есть должна быть возможность быстро выкатывать новые сборки, отслеживая статус выполнения на разных средах и выполняя откат при сбоях.</p>

7 <p><strong>Инструменты</strong>: GitLab CI/CD, Jenkins, GoCD и пр.</p>

8 <h2>3. Возможность наблюдения</h2>

9 <p>В данном случае речь идет о мониторинге инфраструктуры и бизнес-метрик. Сложно переоценить значение мониторинга, причем не важно, о проекте какого масштаба мы говорим: Startup либо Enterprise. Однако на практике до сих пор есть проекты (и их немало), где мониторинга нет, а это чревато серьезными проблемами.</p>

10 <p>Когда мы говорим о переходе в облако, то здесь мониторинг поможет проверять хотя бы заявленный SLA провайдера, получая ретроспективу производительности при спорных ситуациях, не говоря уже о том, что мониторинг позволяет находить узкие места в архитектуре программных приложений, чтобы исправить их до того, как эти потенциальные проблемы станут оказывать влияние на пользователей.</p>

11 <p><strong>Инструменты</strong>: Zabbix, Prometheus, Grafana, Fluentd, OpenTracing, Jaeger. Также у облачных провайдеров возможно наличие собственного встроенного мониторинга.</p>

12 <h2>4. Эластичность</h2>

13 <p>Эластичность -- не что иное, как возможность масштабирования приложений с учетом меняющейся нагрузки. Тут уместно вспомнить автоматическое масштабирование и<strong>Kubernetes</strong>-- стандарт оркестрации контейнерных приложений, поддерживающий все нужные уровни масштабирования. Также ряд провайдеров поддерживает автомасштабирование на уровне кластера из коробки. Впрочем, построить эластичное приложение можно и без Kubernetes, а на основе чистого IaaS, применяя для обработки изменений нагрузки мониторинг и преднастроенные хуки.</p>

14 <h2>5. Отказоустойчивость</h2>

15 <p>В случае сбоя приложение должно иметь возможность быстрого восстановления, то есть влияние на пользователей должно быть минимальным. Да, определенные гарантии дают и облачные провайдеры, однако надо все равно обеспечить пресловутую отказоустойчивость на уровне инфраструктуры и самих программных приложений.</p>

16 <p><em>По материалам блога https://habr.com/ru/company/vk/blog/.</em></p>