SaaS – это наиболее распространенная модель оказания услуг для большинства поставщиков софта. Эта модель также помогает поставщикам облачных решений предоставлять инфраструктурные услуги (IaaS). Приложения зачастую создаются в публичном облаке, например, в Amazon Cloud (AWS), Microsoft Azure, Google Cloud и др. Однако иногда организации используют ресурсы своего дата-центра для размещения приложений, чтобы инвестировать только в свою инфраструктуру. Для разработки приложений SaaS нужно больше, чем просто деплой в облаке. Правильное проектное планирование поможет качественно проработать структуру, оптимально сократить расходы и более эффективно управлять развертыванием. В этой статье будет представлено несколько ключевых моментов и советов по распространению приложений, работающих по модели SaaS, которая еще долго будет широко применяться.
Микросервисная архитектура.
Если у вас монолитное приложение, возможно, имеет смысл разбить его на логические части, которые можно развернуть по отдельности. Это не только улучшит модульность, но и оптимизирует приложение для того, чтобы оно занимало меньше места. Предположим, у вас есть приложение, которое использует фоновые процессы. Можно развернуть основное приложение и фоновые процессы отдельно, разбив это все на 2 или более отдельных приложения. Это сократит потребность в ресурсах. Кроме того, теперь есть возможность еще и независимо масштабировать приложения по отдельности в зависимости от потребностей каждой части. Если есть спрос на фоновые процессы, вы можете увеличить размер ресурса под них, то же самое можно сделать и с ресурсами для основного приложения. Так как ресурс для каждого модуля небольшой, масштабирование конкретного дискретного уровня или элемента обойдется дешевле, чем масштабирование больших ресурсов.
Логично?
Непрерывная поставка обновлений
Это новинка для многих локальных приложений. Клиенты всегда ожидают последней версии от облачных приложений. Если смотреть на это со стороны разработчика, - теперь вы можете не только апдейтить по частям, но и вносить изменения в структуру данных пользователей так, чтобы они этого не заметили. Процесс обновления приложения становится полностью прозрачным для клиентов.
Это лишь некоторые моменты. Но основная суть очевидна.
Выбирайне подходчщие сервисы. Допустим, вы хотите развернуть приложение в облаке, но для начала задумайтесь, какие именно облачные сервисы вы хотите использовать для этой цели? Просто IaaS (Инфраструктура как услуга)? Или PaaS (Платформа как услуга)? Ответ не всегда на поверхности. А если планируете развернуть приложение на нескольких облачных платформах или локально? Имеет смысл пользоваться услугами поставщика по минимуму и больше внимания уделить модели IaaS. Итак, вот несколько рекомендаций:
Приценитесь и выберите оптимальное решение
Важным фактором при выборе решения должна быть стоимость. Например, некоторые PaaS-сервисы, управляемые поставщиками облачных решений, могут быть переведены под управление силами вашей команды, чтобы снизить затраты. Хотя такая схема подходит не для каждого сервиса, стоит все предусмотреть.
Учитывайте опыт своей команды
Задайте себе вопросы:
- Что нужно конкретно вам, чтобы использовать облачный сервис?
- Если бы ваша команда самостоятельно занималась поддержкой основной инфраструктуры, какие навыки были бы ей необходимы?
Проектируйте с учетом вероятности отказа системы
Проектирование отказоустойчивых и высокодоступных приложений имеет основополагающее значение для облачных услуг. Предположим, ваше приложение работает со сбоями, сможете ли вы гарантировать, что пользователи продолжат с ним работать? Учтите, сбои могут быть как в приложении, так и в базовой инфраструктуре.
Использование балансировщика нагрузки
Узлы приложения для этого размещают за балансировщиком нагрузки, чтобы в случае выхода из строя нескольких узлов, приложение обслуживалось через другие узлы.
Использование модели с географическим распределением
Некоторые поставщики предлагают возможность для распределения приложения по нескольким географическим областям, чтобы даже в случае физического воздействия на одну локацию (например, из-за стихийного бедствия) приложение можно было бы обслуживать из других локаций. Например, облако AWS предлагает развертывание приложения в нескольких зонах доступности.
Безопасность
Безопасность включает в себя множество аспектов – от защиты инфраструктуры до защиты приложений. Некоторые аспекты безопасности нацелены на доступность только требуемых портов, использование как можно меньших привилегий для ресурсов, управление доступом на основе ролей, шифрование и т.д. Безопасность не должна рассматриваться как одномоментное действие. Это продолжительный процесс, который должен постоянно совершенствоваться.
Многопользовательская аренда
Ключевое преимущество работы в облаке – это возможность обслуживания нескольких пользователей, использующих один и тот же экземпляр приложения. Это помогает выявить некоторые очевидные пробелы в проекте приложения, чтобы гарантировать, что данные пользователей разделены как с целью обеспечения безопасности, так и в целях его администрирования. Некоторые используют разные экземпляры базы данных для каждого клиента. А другие – одну базу данных, присваивая данным идентификаторы конкретных клиентов. Независимо от того, какой подход вы используете, важно убедиться, что архитектура отвечает требованиям масштабируемости и безопасности. Например, если вы решите использовать базу данных для каждого клиента, вы можете разместить несколько баз данных в одном экземпляре СУБД.
Минимизация времени простоя системы и бесшовное обновление
Многие клиенты ожидают от приложений SaaS минимального или нулевого времени простоя. И так как обычно поддержкой занимается компания-разработчик приложения, обновления происходят бесшовно. Проблема заключается в том, что ваше приложение, возможно, не предназначено для обновлений без прерывания работы, особенно если оно изначально не разрабатывалось как SaaS-приложение. Есть 2 ключевых аспекта, которые следует учитывать:
а) обновление кода приложения
б) изменение структуры данных в хранилище
Для выкатывания приложений могут быть использованы специальные стратегии, в которых новый выпуск деплоится в новой программной среде (стеке), затем тестируется и запускается, если деплой прошел успешно. Старые ресурсы стека могут быть выведены из эксплуатации и задействованы позже. Один из подходов к бесшовному обновлению состоит в том, чтобы сделать модель данных «n-1 совместимой». Это значит, что, если развернутый выпуск имеет версию модели данных n, она совместима с предыдущей версией модели (n-1), таким образом гарантируется, что обновление не сломает ее. Откуда гарантии? На протяжении всего цикла разработки требуется серьезная дисциплина и следование определенным рекомендациям, например, нельзя удалять столбцы, предоставляя необходимые скрипты обновления для обработки любых потребностей миграции данных и т.д. В случае, если обновление не произойдет, есть возможность откатить его. Теперь ясно, что это не только технически сложно в исполнении из-за миграции и отката данных, но еще и может замедлиться процесс развертывания. Вам следует тщательно продумать, что наиболее подходит под ваши потребности, и реализовать соответствующее решение.
Еще немного о финансовой составляющей
По мере создания вашего приложения и проектирования деплоя, вы можете предложить несколько подходов для развертывания. Тем не менее, для успешной реализации модели SaaS необходимо выбрать наиболее экономически эффективную модель, которая не только отвечает вашим актуальным потребностям, но может удовлетворить еще и потенциальные, например, в случае роста или падения спроса на ресурс. Сейчас поясним. Допустим, вы не хотите растрачиваться впустую на резервирование ресурсов, но и хотите избежать ситуации, когда приложение не справляется с очень большим наплывом пользователей и высокой нагрузкой. Важно найти правильный баланс. Эмпирическое правило при выборе размера ресурса: всегда прислушивайтесь к своему опыту, а если в процессе тестирования выяснится, что требуется более высокая конфигурация, - увеличивайте.
DevOps – очень актуальная тема в разрезе модели SaaS, стоит рассмотреть ее отдельно. Выделим ключевые моменты DevOps для облачной модели:
Непрерывный деплой
Процессы DevOps должны иметь возможность принимать зарегистрированный код, создавать из него сборку, которая затем проходит через различные этапы (контроль качества, производительность, финальный деплой) в автоматическом режиме. Может быть несколько процессов (например, для каждой стадии) и главный процесс, который производит сборку от начала и до конца. Теперь для разработки скриптов процессов тоже может потребоваться время, но в конечном счете это приведет к полной или практически полной автоматизации развертывания.
Использование системы контроля версий для всего, включая изменения DevOps
Понятно, что для кода приложения используется ветка master репозитория. Важно сделать то же самое и для любых изменений кода скриптов DevOps. Например, когда вы внедряете изменения в инфраструктуру, они тоже должны быть включены в систему контроля версий, протестированы и только затем отправлены в продакшн.
Гибкая инфраструктура
Чтобы преуспеть в SaaS, вам надо убедиться, что ваша инфраструктура достаточно гибкая и справится с изменениями спроса на ресурсы. По мере роста спроса она должна масштабироваться до соответствующего уровня, а при снижении – высвобождать незадействованные мощности. Экспериментируйте, чтобы отыскать баланс. К примеру, вы можете использовать автоматическое масштабирование, облачная инфраструктура в этом случае будет «подстраиваться» сама.
Мониторинг и оповещения
Технологические стеки обычно состоят из десятков постоянно обновляющихся компонентов, устранение неполадок может стать проблемой. Важно использовать правильные механизмы мониторинга и оповещения, чтобы в случае алерта получилось быстро устранить проблему. Хороший совет – использовать некоторые базовые возможности мониторинга через облако: централизованное ведение журнала, аварийные сигналы, уведомления об ошибках.
О планировании и расстановке приоритетов
Как и в любом успешном проекте, в SaaS тоже без планирования не обойтись. Хотя многие стремятся просто выкатывать версии одну за другой в продакшн. Но всегда важно учитывать первичные потребности бизнеса и правильно расставлять приоритеты. Да, вы не ослышались, растягивать цели – неплохо. Важно сначала правильно все спланировать. Если у вас нет хорошего модульного тестирования или автотеста, и вы пытаетесь выкатить каждый новый фрагмент кода в продакшн, вряд ли это сулит хорошие перспективы в итоге. Могут возникнуть неприятные последствия. Программные продукты начнут слишком часто ломаться после деплоя, и проектная группа будет вынуждена тратить время и усилия на сглаживание негативных последствий.
SaaS влияет также на модель автоматизации
В своей инфраструктуре вы можете продавать лицензии лишь на определенную сумму, а при SaaS вам предстоит переосмыслить модель для вашего бизнеса. Хотите ли вы использовать модель на основе подписки, на основе потребления, гибридную модель или какую-то еще…
Надеемся, вы получили исчерпывающее представление о том, что необходимо для разработки облачного или SaaS-приложения. Это, безусловно, полезный опыт, помогающий взглянуть на разработку приложения, учитывая разные аспекты, и грамотно запустить его в продакшн. Как говорится: «Облако – это путешествие, а не конечный пункт прибытия!»
