В этой статье я расскажу об основных провайдерах облака, что нужно знать, чтобы работать на мощном клауд-проекте, и многое другое. Поскольку у меня больше всего опыта с Microsoft Azure, то и рассказывать о облаке буду с точки зрения именно этого провайдера.nnИ начнем с истории :)n
Почему я выбрал Azure
Azure создана и оптимизирована для работы как со старыми, так и с новыми приложениями, разработанными с помощью .NET фреймворка. Поэтому намного проще переносить сервисы Windows в облако Azure, чем на AWS или другие. Таким образом, для компаний, использующих корпоративный софт на основе .NET, Azure является очевидным выбором. Потому как .NET инженер я предпочитаю Azure.nnТакже это поддержка автоматизированного DevOps процесса. У среды разработки Visual Studio лучшие механизмы для работы именно с Azure, что существенно облегчает процесс разработки и развертывания аппликаций, если нет настроенного DevOps процесса, поскольку мы можем публиковать их в облако непосредственно с VS.nnПомимо Azure, наиболее популярными провайдерами облака являются AWS и GCP. Каждый из них предоставляет безопасную облачную среду и ряд инструментов для облегчения работы. Поэтому, по моему мнению, в выборе провайдера стоит полагаться больше на индивидуальные потребности заказчика.n
Преимущества работы в облаке
С каждым годом облачные технологии набирают все большую популярность, ведь с помощью облака можно получить следующие преимущества:n
Оптимизация затрат
Для некоторых компаний переход на облачную инфраструктуру – это отличный путь оптимизации затрат. Используя облако, клиент может не беспокоиться об обслуживании физических серверов, безопасности этой системы и многом другом. В результате требуется меньше людей, которые поддерживают инфраструктуру, что уменьшает затраты. Свободный ресурс можно использовать для экспериментов по оптимизации и расширению бизнеса.nnМы не раз помогали клиентам с оптимизацией инфраструктуры. Например, один из наших клиентов — международный стриминговый сервис — нуждался в решении, которое выдерживало бы высокую нагрузку в 36 миллионов уникальных посетителей и более 10 миллиардов запросов в неделю и которое было бы дешевле удерживать. Мы выбрали оптимизацию путем создания Kubernetes кластера в облаке AWS. Наши разработчики создали 30 микросервисов, содержание которых обходится клиенту примерно в 2000 USD ежемесячно.nnДля сравнения, неоптимизированная архитектура, состоявшая из EC2 OnDemand instances, обходилась нашему в клиенте более чем в 38000 USD в месяц.nnВот классический пример капитальных и операционных расходов:nn nnЕсли нам больше не нужен сервер, в варианте OpEx мы сможем его просто удалить, не использовать дальше и не тратить средства. В случае с CapEx у нас будет инфраструктура, потенциал которой мы не используем на полную мощность.nnТакже большие облачные провайдеры предоставляют готовые инструменты для управления средствами, оптимизацией и рекомендациями. В частности, Azure Cost Management предоставляет несколько инструментов, которые можно использовать для корректировки бюджета, отслеживания облачных расходов, оптимизации расходов и т.д. Этот ресурс имеется в свободном доступе для пользователей Azure и предлагает следующие инструменты:n
- Cost Analysis предоставляет детальное распределение расходов на все используемые услуги, показывая подробности облачных расходов.
- Cost Alerts посылает автоматические уведомления, когда расходы превышают предустановленный порог. К ним относятся уведомления о бюджетных и кредитных расходах.
- Budgets позволяет создавать бюджет в рамках подписки на Azure. Он также помогает отслеживать облачные расходы, устанавливая ограничения и уведомления.
- Pricing Calculator дает оценки стоимости Azure сервисов.
- Azure Advisor анализирует облачные конфигурации и статистику использования, чтобы предложить рекомендации по использованию облачных ресурсов и сокращению расходов Azure.
Время до выхода на рынок
TTM – это время от начала планирования идеи до конечного запуска решения и его выхода на рынок. Для стартапов и MVP этот показатель особенно критичен, ведь если запуск продукта затягивается, компания может проиграть конкурентам.nnИнфраструктура в облаке разворачивается гораздо быстрее. На закупку и подготовку физических серверов нередко уходят месяцы. Затем архитектуру нужно долго настраивать под нужды компании. Получить аналогичный – полностью готовый к работе облачный ресурс – можно за несколько минут.nnВ облаке разработчики могут легко протестировать новые идеи и проектировать архитектуру сервисов, поскольку они не зависят от ограничений оборудования. Кроме того, облачные провайдеры имеют готовые решения для Continuous Integration и Continuous Delivery, которые не требуют сложной настройки, поэтому с помощью облака можно легко имплементировать и новые версии продукта. Это позволяет ускорить выход новых версий, предоставляя пользователям все больше функций ежемесячно, еженедельно и в некоторых случаях даже ежедневно.nnОблачные среды также интегрируются с общими инструментами DevOps и системами логирования, что облегчает мониторинг и выявление проблем в продакшени.n
Масштабирование
Легкое масштабирование – это, пожалуй, наибольшее преимущество облака.nnЧто делать, если на следующей неделе вам придется расширить решение, чтобы, например, вывести его на новый рынок? А если это нужно сделать завтра? Именно здесь на помощь приходит облако. Если требования заказчика изменяются, можно легко увеличить или уменьшить пропускную способность системы, не инвестируя в физическую инфраструктуру.nnСуществует два способа зума в облаке: горизонтальное и вертикальное.nnВертикальное масштабирование происходит путём повышения мощности отдельного вычислительного устройства. Это обычно достигается увеличением количества вычислительных ядер, памяти или ресурсов ввода-вывода в сервер. Такой подход имеет свои ограничения, ведь количество процессоров не может расти неограниченно. Кроме того, стоимость многопроцессорных компьютеров непропорционально растет с количеством вычислительных ядер, поддерживаемых системой.nnГоризонтальное масштабирование состоит в предоставлении дополнительных серверов для удовлетворения определенных требований. В этом случае также часто распределяют нагрузки между серверами, чтобы ограничить количество запросов, получаемых любым отдельным сервером.nnОблачные службы имеют много разных вариантов зума. Например, в Azure есть такая функция как Azure AutoScale.nnAzure AutoScale – это встроенная функция, которая настраивает распределение ресурсов для сервисов в зависимости от их вычислительных требований. Можно масштабировать облачные службы, виртуальные машины, веб-сервисы и другие ресурсы в соответствии с определенными критериями (размер процессора, память, пропускная способность или использование диска). Azure AutoScale – это способ более эффективного использования облачных ресурсов и оптимизация затрат одновременно. Azure автоматически повысит вычислительную производительность во время пиковых часов работы и снизит скорость работы тогда, когда нагрузка не будет такой интенсивной. С помощью автоматического масштабирования Azure не нужно будет платить за какие-либо вычислительные мощности, которые не нужны, что существенно экономит средства.n
Аварийное восстановление
Что произойдет, если вы потеряете данные клиента?nnПотеря данных – серьезный риск для любой организации. Потеря дохода во время простоя и усилий, необходимых для восстановления информации, могут стоить компании сотни тысяч, если не миллионы.nnAzure имеет инструмент под названием Azure Site Recovery, позволяющий компаниям создавать планы восстановления, включающие процедуры репликации и возобновления сбоев. Azure Site Recovery также позволяет компаниям резервировать IP-адреса, устанавливать и настраивать балансировку нагрузки и интегрировать Azure Traffic Manager для бесперебойного переключения трафика.n
Безопасность
Облако провайдеры обычно обеспечивают хостинг и сертифицированный PCI-DSS, что чрезвычайно важно для соблюдения GDPR. Кроме того, облако предлагает расширенные меры безопасности для защиты вашего веб-сайта от DDoS-атак или других угроз.nnЭти преимущества и способствуют распространению облачных технологий на рынке. Все больше компаний ищут опытных экспертов для разработки облачных решений или миграции с on-premise на клауд.nnПожалуй, на каждом проекте, где работают с облаком, наработаны собственные подходы к работе. Потому я рассмотрю, что использовали мы.n
Самые эффективные практики для работы с облаком
Разработка стратегии облачной инфраструктуры зависит от глубокого понимания целей и требований бизнеса, поэтому очень сложно однозначно ответить, какие подходы наиболее эффективны. Однако необходимо соблюдать несколько лучших методов облачной инфраструктуры, которые покрывают ключевые потребности, которыми сталкиваются компании: безопасности, производительности, связности и надежности.nnMicrosoft предлагает ряд шаблонов для улучшения эффективности работы с облаком. Некоторые из них позволили нам решить некоторые проблемы при разработке облачных решений:● Deployment Stamps patternnnnnЭтот шаблон обеспечивает подготовку, управление, мониторинг и масштабирование ресурсов. Каждая отдельная копия называется штампом или единицей зума (scale unit). В среде с несколькими клиентами каждый штамп может служить отдельному клиенту. Можно развернуть несколько штампов, чтобы расширить аппликацию и обслуживать больше клиентов. Такой подход может улучшить масштабируемость, позволяя развертывать сервисы в ряде регионов и разделять данные клиента.nnНа проекте наша команда столкнулась с проблемой медленного доступа к нашим веб ресурсам из других регионов. Сервис находился в северной Европе, поэтому оптимизация слабых мест и улучшение производительности ее не решило бы. Именно поэтому мы пошли по пути гео-дистрибуции с помощью Deployment Stamps pattern.nnЧтобы избежать таких проблем в будущем, мы сгруппировали все необходимые ресурсы, используемые аппликацией, в независимую дистрибутивную единицу (scale unit). Дальше начали DevOps процесс.nnЧтобы ощутить все преимущества этого шаблона, нужно описать инфраструктуру в виде программного кода (infrastructure as code). Его построение сейчас имеет несколько альтернатив, например, JSON Azure Resource Manager Templates (ARM templates), Terraform, AWS Cloud Formation и другие. Поскольку наши сервисы размещены в облаке Azure и у нас в команде уже была определенная экспертиза по ARM templates — мы решили выбрать эту технологию. Создали шаблонный файл для всех ресурсов приложения и по одному файлу с параметрами для каждого региона. Для маршрутизации трафика между регионами использовали Azure traffic manager, его функции покрывали все наши потребности. Интегрировали шаблоны с Azure Pipelines для координации развертывания в каждом регионе.nnИ как результат, получили более стабильную веб аппликацию с быстрым доступом к ней из разных регионов.nn● Competing Consumers PatternnnnnПозволяет нескольким службам одновременно обрабатывать сообщения, полученные на одном канале обмена. Это необходимо для оптимизации пропускной способности, улучшения масштабируемости, доступности и сбалансирования рабочей нагрузки.nn● Circuit Breaker PatternnnnnПомогает обработать ошибки, на восстановление которых может потребоваться разное время при подключении к удаленной службе или ресурсу. Это может улучшить устойчивость и устойчивость программы.nn● Retry PatternnnnnПозволяет обрабатывать временные сбои при попытке подключения к ресурсам посредством повторных попыток выполнения завершившейся сбоем операции. Таким образом, приложение будет работать стабильнее.nn● Saga Distributed Transactions PatternnnnnSaga – это шаблон, который помогает согласовать данные между микросервисами в сценариях распределенных транзакций. Это последовательность транзакций, обновляющая каждый сервис и возвращающая сообщение, чтобы инициировать следующий шаг транзакции. Если шаг оказывается неудачным, Saga инициирует транзакции, которые нивелируют предыдущие транзакции, чтобы данные оставались актуальными.nnИспользование готовых шаблонов значительно облегчает и ускоряет работу с облаком.n
Наша компания предоставляет услуги по миграции наземных решений в облачные Azure, Amazon, Google Cloud, обращайтесь [email protected]