Сегодня перед нами стоит большая задача, мы как архитекторы должны предоставлять нашим клиентам решения, оптимальные с точки зрения затрат и результатов, мы должны всегда принимать во внимание различные аспекты, такие как атрибуты качества или нефункциональные требования, чтобы таким образом улучшить дизайн и реализацию архитектур приложений, которые вы хотите перенести или создать непосредственно в облаке.
Существуют некоторые принципы, которые Microsoft предлагает для того, чтобы приложения, развернутые в облаке, соответствовали нефункциональным требованиям клиентов, эти принципы приведены ниже:
Автоматическое восстановление:
Мы должны думать обо всем, когда мы разрабатываем распределенные системы, будь то архитектура SOA или архитектура микросервисов, мы должны учитывать аспекты аварийного восстановления, особенно в сервисах, которые должны быть в режиме 24/7 онлайн, и наш уровень обслуживания высок.
Резервирование:
Что произойдет, если один из сервисов, обеспечивающий выставление счетов или регистрацию заказов, выйдет из строя, как мы можем гарантировать, что наш уровень обслуживания будет соблюден, именно, путем разработки резервного приложения, например, с помощью методов масштабирования или георепликации или не централизуя жизненно важные функции в отдельных местах или экземплярах, мы всегда должны думать о том, что если… и никогда не принимать ничего на веру, эти 0,00001% могут произойти, и мы должны быть готовы к этому.
Минимизируйте координацию:
Это можно выразить одним словом «параллелизм», часто в программировании этот момент воспринимается очень серьезно, сейчас с асинхронным программированием это более распространено, но что происходит, когда этот параллелизм находится на уровне архитектуры, когда мы проектируем архитектуру, мы должны заботиться о транзакциях между системами и различными сервисами, пытаясь, когда это возможно, обеспечить полную согласованность, но в случае, если мы не можем, тогда принимаем и работаем с возможной согласованностью.
Горизонтальное масштабирование:
Облачное программное обеспечение должно работать по принципу «Потребляйте то, что вам нужно», т.е. разработанное приложение должно быть подготовлено таким образом, чтобы экземпляры можно было добавлять или удалять по мере необходимости, это необходимо для того, чтобы продолжать гарантировать наш уровень обслуживания, что способствует стабильности нашего решения.
Разделение по границам:
В этот момент мы упоминаем о важности лимитов и вертикального масштабирования, поскольку в облаке все услуги имеют лимиты и квоты, тогда мы возвращаемся к вопросу, что произойдет, если… например, в ходе продажи я достигну своего лимита экземпляров моего плана обслуживания приложений, а сложность заключается в том, что продажи продолжают поступать!
Здесь важность предыдущего пункта: наши приложения всегда должны использовать преимущества ресурсов горизонтально или, в противном случае, разделить решение, выбрав контексты или какой-либо дифференциатор, который поможет обеспечить необходимую производительность для всех сред.
Проектирование для эксплуатации:
Здесь многое зависит от того, кто и как будет выполнять решение или какого типа это решение, то есть для каждого решения всегда должна быть поддержка конфигурации для операционного отдела компании, поскольку решения должны быть способны конфигурироваться и обновляться по мере необходимости операционным отделом и, конечно, клиентами.
Управляемые услуги:
Используйте PaaS, когда это возможно, вместо IaaS, это делается для того, чтобы облегчить управление ресурсами, при использовании PaaS-решения вся инфраструктура поддерживается Azure, однако это во многом зависит от решения, поскольку некоторые решения требуют специальных конфигураций на определенных серверах или ОС, всегда помните об оценке масштаба и о том, с каким решением мы имеем дело.
Выбор хорошего хранилища данных:
И мы приходим с вопросом, какие данные будут храниться? Как лучше SQL или NoSQL? Архивные или документарные? и как всегда в таких случаях, ответ — зависит от ситуации. но здесь я рекомендую вам принять это во внимание, выполнить полное отображение решения, как обстоят дела с текущей базой данных, при необходимости перенастроить базу данных и оптимизировать ее в соответствии с целью, либо для транзакций, либо для поиска, всегда принимайте во внимание, для чего используются данные.
Дизайн должен развиваться:
Хотите верьте, хотите нет, но внедрение программных архитектур на начальном этапе является сложной задачей, но после прозрачного внедрения они символизируют экономию времени и денег, но почему я об этом говорю.
Часто, когда предлагаются рефакторы в приложениях, команды разработчиков не очень хорошо к этому относятся, и это совершенно понятно. Наша задача как архитекторов — показать им путь, дать им визуализацию и обзор средне- и долгосрочного плана, чтобы в будущем, когда BA попросит об изменении, это не было «боже, где код, который это делал?» или знаменитое «так я получил код?», а было: «мы проанализировали, что изменение находится в области X на компоненте Y и повлияет на Z зависимостей». Поверьте, вначале это сложно, но в среднесрочной перспективе с обновлениями вы увидите улучшения в ваших изменениях.
Создавайте с учетом потребностей бизнеса:
Это можно резюмировать словами «будьте внимательны к клиенту», и под этим я подразумеваю особое внимание при принятии требований, нет глупых вопросов! Наоборот, вы должны спрашивать больше минимальных деталей и всегда переосмысливать нас и нашего клиента различные ситуации или случаи использования и последствия, которые влекут за собой, если они не работают или работают правильно, всегда помните, все разработки должны быть обоснованы бизнес-требованиями.
Надеюсь, вы найдете его полезным и оставите свои комментарии, чтобы продолжить совершенствование, я делюсь своими сетями для любых вопросов, и они сказали бы там …. Я прихожу и ухожу!
Twitter
YouTube
Facebook
Linkedin