Перед вами перевод статьи Manjunath M, которая была опубликована на Bits and Pieces. Мы предлагаем прочитать ее тем, кто уже преодолел этап подготовки к миграции и приступает к следующему шагу.
Обычно компании рассматривают разные способы переноса приложений в облачное хранилище во время оценки и планирования портфеля — на второй стадии миграции. Задумываются также над тем, какие приложения будет легче перенести и что повлечет за собой их миграция. Именно на этом этапе разработчик понимает, насколько сложны и взаимозависимы компоненты его среды разработки. С его точки зрения, многое может пойти не так.
Чтобы предотвратить возможные трудности, компания должна разработать план миграции, найти наиболее эффективный способ переноса приложений и приоритизировать их.
Сложность переноса зависит от самого приложения, в частности от лицензионных соглашений и используемой архитектуры.
Лучше начать с наименее сложного приложения. Причины очевидны: пользователь облака, который переносит данные, тут же получит результат, а также постепенно ознакомится с системой.
Ниже вы найдете несколько советов, которые помогут вам разработать надежную стратегию переноса приложений в облачное хранилище.
Создавайте приложения быстрее, работая с их компонентами
Bit превращает компоненты в строительные блоки, с которыми вы можете работать, как архитектор. С легкостью отправляйте компоненты в облако, перемещайте их из одного проекта в другой или внутри приложения — самостоятельно или вместе со своей командой. Это бесплатно, попробуйте.
SSL в веб-приложении имеет огромное значение, так как речь идет о безопасности. Если пренебречь шифрованием, любой, кто попытается перехватить передаваемую информацию, достигнет своей цели.
Alibaba Cloud — пример сервиса, который предоставляет SSL-сертификаты. Его услуги довольно дорогие, а сертификаты больше подходят для предприятий.
Есть и другой вариант — популярный бесплатный SSL-сервис центра сертификации Let's Encrypt.
Чтобы с помощью клиента Certbot были сгенерированы клиентские сертификаты для приложений, сервер пользователя должен отвечать требованиям домена.
Большинство компаний, предоставляющих облачные сервисы, предлагают доменные имена, в стоимость которых включена защита данных в Whois.
Ваш облачный аккаунт — результат делового соглашения между вами или вашей организацией и поставщиком облачных услуг. Защита учетных данных — одна из самых больших проблем, связанных с миграцией в облако. Возьмем, к примеру, AWS (Amazon Web Services). Так как с вашей корневой учетной записи осуществляется управление связанными ресурсами и сервисами AWS, требуется предоставить ей полный доступ ко всем данным, включая те, на которые распространяются права администратора. Стоит учитывать, что риски при этом увеличиваются.
Совет: при использовании AWS не генерируйте ключ доступа к своему корневому аккаунту, и вообще не делайте этого без необходимости. Лучше воспользоваться системой AWS IAM (Identity and Access Management), завести учетные записи и предоставить им необходимые права для ежедневного использования системы AWS.
Все это относится не только к AWS. Вы столкнетесь со схожими проблемами и рисками, пользуясь любым облачным сервисом. Так, передача данных ничем не регулируется. Пользователи могут делиться своими учетными данными — например, с сотрудниками, если те их потеряли.
Чтобы решить проблему в этой сфере, требуется установить правила, касающиеся потери учетных данных и обмена ими, а также описывающие порядок действий в случае их кражи.
Если ваши учетные данные и приложения надежно защищены, вы как пользователь можете не волноваться о возможности несанкционированного доступа к ним. Однако было бы хорошо на всякий случай иметь план восстановления данных.
Ниже даны несколько рекомендаций.
Независимо от того, переносите ли вы существующее приложение или создаете с нуля облачное, вам нужно будет выбрать правильную облачную инфраструктуру. Характеристики, которыми она должна обладать:
Есть множество поставщиков ПО, которые предлагают свои услуги на различных публичных облаках. Google, Azure и AWS — только некоторые из них. Часто пользователям приходится требовать, чтобы независимые поставщики ПО работали с несколькими облачными платформами, ведь это обеспечивает масштабируемость, избыточность данных и улучшенную доступность.
Снижая совокупную стоимость владения, использование облачных технологий приносит выгоду не только потребителям услуг поставщиков ПО, но и самим поставщикам, которым основанная на подписке SaaS-модель дает постоянный доход.
Как только вы произвели оценку приложения, технологической платформы и соотнесли результат с целями вашего бизнеса, выберите стратегию миграции. Это можно сделать быстро, если определены важные компоненты и приложения для переноса, а также сроки исполнения.
Если вы независимый поставщик ПО, который имеет дело с приложениями уровня предприятия, вам подойдет стратегия поэтапной облачной миграции, при которой неудобство пользователей будет сведено к минимуму.
Учитывая требования к данным вашего приложения, а также такие важные факторы, как безопасность, использование ресурсов, совокупная стоимость владения и контроль, вы можете выбрать подходящую облачную платформу. Помимо этого, у вас есть выбор между частным, публичным и гибридным облаками.
Публичное облако, пожалуй, самое экономное решение, особенно если вы работаете с SaaS-приложением с растущими требованиями к инфраструктуре. Частное облако, напротив, будет лучшим вариантом, если контроль и безопасность для вас важнее всего. Как следует из названия, гибридное облако — это смесь публичной и частной облачных инфраструктур. Данный тип облаков быстро набирает популярность, так как сочетает в себе гибкость обоих видов, предоставляя при этом необходимые услуги.
Если у вашего приложения обширный багаж наработок, который трудно перенести, начните с модели развертывания на хостинге.
Она предоставляется в виде выделенной архитектуры (single tenancy) и позволяет использовать приложение с помощью виртуального рабочего стола, локальных хостинговых сервисов или через сервис-провайдеров. Этот метод удовлетворяет потребности вашего клиента в отношении инфраструктуры, обслуживания, поддержки и обновлений.
Прибегая к постепенной миграции, большинство независимых поставщиков ПО могут легко добиться первых результатов еще до того, как начнут переносить более сложные приложения.
Следующий логический шаг — провести реорганизацию или рефакторинг архитектуры приложения, чтобы затем предложить его как сервис. Качества, которыми должен обладать этот сервис:
Если вы еще не решили, как приступить непосредственно к облачной миграции, наши проверенные и исчерпывающие советы должны помочь вам в этом, став руководством к первому шагу.
Миграция в облако не происходит одномоментно. Тем не менее, понимание вероятных осложнений и должная подготовка сделают процесс миграции настолько гладким и безболезненным, насколько это возможно.
Обычно компании рассматривают разные способы переноса приложений в облачное хранилище во время оценки и планирования портфеля — на второй стадии миграции. Задумываются также над тем, какие приложения будет легче перенести и что повлечет за собой их миграция. Именно на этом этапе разработчик понимает, насколько сложны и взаимозависимы компоненты его среды разработки. С его точки зрения, многое может пойти не так.
Чтобы предотвратить возможные трудности, компания должна разработать план миграции, найти наиболее эффективный способ переноса приложений и приоритизировать их.
Сложность переноса зависит от самого приложения, в частности от лицензионных соглашений и используемой архитектуры.
Лучше начать с наименее сложного приложения. Причины очевидны: пользователь облака, который переносит данные, тут же получит результат, а также постепенно ознакомится с системой.
Ниже вы найдете несколько советов, которые помогут вам разработать надежную стратегию переноса приложений в облачное хранилище.
Создавайте приложения быстрее, работая с их компонентами
Bit превращает компоненты в строительные блоки, с которыми вы можете работать, как архитектор. С легкостью отправляйте компоненты в облако, перемещайте их из одного проекта в другой или внутри приложения — самостоятельно или вместе со своей командой. Это бесплатно, попробуйте.
Облачная безопасность: используйте HTTPS
SSL в веб-приложении имеет огромное значение, так как речь идет о безопасности. Если пренебречь шифрованием, любой, кто попытается перехватить передаваемую информацию, достигнет своей цели.
Alibaba Cloud — пример сервиса, который предоставляет SSL-сертификаты. Его услуги довольно дорогие, а сертификаты больше подходят для предприятий.
Есть и другой вариант — популярный бесплатный SSL-сервис центра сертификации Let's Encrypt.
Чтобы с помощью клиента Certbot были сгенерированы клиентские сертификаты для приложений, сервер пользователя должен отвечать требованиям домена.
Большинство компаний, предоставляющих облачные сервисы, предлагают доменные имена, в стоимость которых включена защита данных в Whois.
Облачная безопасность: защитите свои учетные данные
Ваш облачный аккаунт — результат делового соглашения между вами или вашей организацией и поставщиком облачных услуг. Защита учетных данных — одна из самых больших проблем, связанных с миграцией в облако. Возьмем, к примеру, AWS (Amazon Web Services). Так как с вашей корневой учетной записи осуществляется управление связанными ресурсами и сервисами AWS, требуется предоставить ей полный доступ ко всем данным, включая те, на которые распространяются права администратора. Стоит учитывать, что риски при этом увеличиваются.
Совет: при использовании AWS не генерируйте ключ доступа к своему корневому аккаунту, и вообще не делайте этого без необходимости. Лучше воспользоваться системой AWS IAM (Identity and Access Management), завести учетные записи и предоставить им необходимые права для ежедневного использования системы AWS.
Все это относится не только к AWS. Вы столкнетесь со схожими проблемами и рисками, пользуясь любым облачным сервисом. Так, передача данных ничем не регулируется. Пользователи могут делиться своими учетными данными — например, с сотрудниками, если те их потеряли.
Чтобы решить проблему в этой сфере, требуется установить правила, касающиеся потери учетных данных и обмена ими, а также описывающие порядок действий в случае их кражи.
Облачная безопасность: делайте резервные копии и проверяйте ресурсы для восстановления
Если ваши учетные данные и приложения надежно защищены, вы как пользователь можете не волноваться о возможности несанкционированного доступа к ним. Однако было бы хорошо на всякий случай иметь план восстановления данных.
Ниже даны несколько рекомендаций.
- Регулярно делайте резервную копию экземпляра базы данных с помощью снимков файловой системы или другого инструмента восстановления.
- Размещайте самые важные компоненты приложения в разных зонах доступности и при необходимости дублируйте информацию.
- Разрабатывайте приложения так, чтобы они поддерживали динамические IP-адреса при перезагрузке экземпляра базы данных.
- Отслеживайте события и вовремя реагируйте на них.
- Убедитесь, что можете справиться с любыми сбоями. Как минимум вы должны уметь вручную подключать сетевой интерфейс или эластичный IP-адрес к резервному экземпляру базы данных.
- Регулярно тестируйте восстановление экземпляров базы данных и томов Amazon EBS, чтобы выявить возможные неполадки.
Выберите подходящую среду хостинга
Независимо от того, переносите ли вы существующее приложение или создаете с нуля облачное, вам нужно будет выбрать правильную облачную инфраструктуру. Характеристики, которыми она должна обладать:
- вертикальные и горизонтальные гибкость и масштабирование;
- поддержка доступа в разных странах;
- доставка данных в один клик;
- возможность отследить информацию об использовании и финансовых оборотах;
- избыточность и резервное копирование данных.
Есть множество поставщиков ПО, которые предлагают свои услуги на различных публичных облаках. Google, Azure и AWS — только некоторые из них. Часто пользователям приходится требовать, чтобы независимые поставщики ПО работали с несколькими облачными платформами, ведь это обеспечивает масштабируемость, избыточность данных и улучшенную доступность.
Снижая совокупную стоимость владения, использование облачных технологий приносит выгоду не только потребителям услуг поставщиков ПО, но и самим поставщикам, которым основанная на подписке SaaS-модель дает постоянный доход.
Сформулируйте стратегию миграции и разработайте дорожную карту
Как только вы произвели оценку приложения, технологической платформы и соотнесли результат с целями вашего бизнеса, выберите стратегию миграции. Это можно сделать быстро, если определены важные компоненты и приложения для переноса, а также сроки исполнения.
Если вы независимый поставщик ПО, который имеет дело с приложениями уровня предприятия, вам подойдет стратегия поэтапной облачной миграции, при которой неудобство пользователей будет сведено к минимуму.
Учитывая требования к данным вашего приложения, а также такие важные факторы, как безопасность, использование ресурсов, совокупная стоимость владения и контроль, вы можете выбрать подходящую облачную платформу. Помимо этого, у вас есть выбор между частным, публичным и гибридным облаками.
Публичное облако, пожалуй, самое экономное решение, особенно если вы работаете с SaaS-приложением с растущими требованиями к инфраструктуре. Частное облако, напротив, будет лучшим вариантом, если контроль и безопасность для вас важнее всего. Как следует из названия, гибридное облако — это смесь публичной и частной облачных инфраструктур. Данный тип облаков быстро набирает популярность, так как сочетает в себе гибкость обоих видов, предоставляя при этом необходимые услуги.
Выбирайте постепенную миграцию
Если у вашего приложения обширный багаж наработок, который трудно перенести, начните с модели развертывания на хостинге.
Она предоставляется в виде выделенной архитектуры (single tenancy) и позволяет использовать приложение с помощью виртуального рабочего стола, локальных хостинговых сервисов или через сервис-провайдеров. Этот метод удовлетворяет потребности вашего клиента в отношении инфраструктуры, обслуживания, поддержки и обновлений.
Прибегая к постепенной миграции, большинство независимых поставщиков ПО могут легко добиться первых результатов еще до того, как начнут переносить более сложные приложения.
Используйте облачную архитектуру
Следующий логический шаг — провести реорганизацию или рефакторинг архитектуры приложения, чтобы затем предложить его как сервис. Качества, которыми должен обладать этот сервис:
- API и сервис-ориентированная архитектура;
- расширяемая модель данных со встроенной защитой;
- готовая поддержка мультиарендности;
- возможность гибкой конфигурации;
- совместимость с общими для индустрии облачными платформами и использование сервисов от третьих лиц, которые могут расширить функционал ключевого продукта.
Выводы
Если вы еще не решили, как приступить непосредственно к облачной миграции, наши проверенные и исчерпывающие советы должны помочь вам в этом, став руководством к первому шагу.
Миграция в облако не происходит одномоментно. Тем не менее, понимание вероятных осложнений и должная подготовка сделают процесс миграции настолько гладким и безболезненным, насколько это возможно.
saipr
Пора хранить в облаке криптографические токены:
