Как создать приложение в облаке
Облачные сервисы все глубже проникают в российскую технологическую отрасль. Их внедряют небольшие компании и стартапы, которые никогда не использовали локальную инфраструктуру. Но также облака популярны и у крупных компаний из зарегулированных сфер, например, финансовых организаций и государственных предприятий.
Причина популярности облаков проста: cloud-сервисы настолько активно развиваются, что с их помощью можно решить множество ИТ-задач бизнеса — например, организовать корпоративную инфраструктуру в облаке, разместить клиентские приложения или обеспечить высокую доступность веб-ресурсов даже при пиковых нагрузках. И разработка — не исключение.
Сервисы CloudMTS позволяют сократить расходы на ИТ-инфраструктуру и time-to-market продукта, обеспечить безопасность данных и даже начать работать с ранее недоступными технологиями искусственного интеллекта.
В сегодняшней статье разберемся, какие сервисы действительно помогут за 30 дней запустить digital-продукт, как бесплатно проверить их эффективность на реальных задачах и подключить с максимальной выгодой.
Полезные решения для разработчиков
Публичное облако (IaaS)
Это готовая виртуальная инфраструктура, подходящая для решения различных задач, связанных с разработкой digital-продуктов и приложений:
- разработка и тестирование в облаке;
- размещение приложений (включая высоконагруженные и business-critical сервисы);
- повышение отказоустойчивости и многое другое.
Публичное облако имеет множество преимуществ:
Во-первых, аренда IaaS обойдется намного дешевле, чем закупка собственного оборудования и лицензий. К тому же, использование облачных ресурсов полностью освобождает вас от необходимости администрирования и модернизации аппаратной части — об этом позаботятся сотрудники провайдера, у которого вы арендуете виртуальную инфраструктуру.
Оплачивать IaaS можно по модели Pay-as-You-Go — то есть по фактическому потреблению ресурсов. А если нагрузка на приложение увеличится и вам понадобится больше ресурсов — их можно масштабировать буквально за несколько минут.
Облачная платформа с GPU-ускорителями
Если вы работаете с технологиями искусственного интеллекта, глубокого и машинного обучения, компьютерного зрения или разрабатываете проекты умных городов — без мощных ресурсов не обойтись. У облачного провайдера можно арендовать ресурсы высокопроизводительной платформы с GPU-ускорителями.
Сервисы такого типа предоставляют далеко не все поставщики, однако теперь они доступны не только крупному бизнесу, но и стартапам. Например, небольшой пул ресурсов GPU SuperCloud от CloudMTS можно арендовать за вполне доступную даже для небольшой компании сумму.
Content Delivery Network (CDN)
Если вы хотите, чтобы ваше приложение без задержек работало у пользователей из любой точки России и мира, — вам поможет услуга CDN. Географически распределенная сеть доставки контента увеличивает скорость передачи данных, а кэш-серверы обеспечивают доступность сайта или приложения даже при проблемах на стороне сервера-источника.
Дополнительно CDN помогает повысить позиции сайта в выдаче поисковых систем и снижают нагрузку на ИТ-инфраструктуру за счет сотен серверов по всему миру.
Объектное хранилище
Наиболее универсальный тип облачного хранилища с высокой степенью надежности. Подойдет для размещения статического контента сайтов и мультимедиа-файлов, резервных копий, графических данных и даже Big Data.
Резервное копирование (BaaS)
Без бэкапов — никуда. Однако о резервном копировании нередко вспоминают уже тогда, когда приходится восстанавливать данные. Защитить ИТ-проекты и собственные цифровые продукты от потери данных можно с помощью готовых инструментов резервного копирования.
Большинство бэкап-решений позволяют создавать резервные копии ИТ-инфраструктуры вне зависимости от того, какие ресурсы вы используете для разработки — облако провайдера или собственную площадку. Чтобы настроить эффективное резервное копирование, необязательно нанимать отдельного специалиста — современные BaaS-инструменты обладают дружелюбным интерфейсом, который будет понятен даже новым пользователям.
Web Application Firewall (WAF)
Чаще всего команды разработчиков сосредоточены на развитии функционала и скорости вывода продукта на рынок, а вопросы безопасности откладывают на потом. Увы, веб-приложения — наиболее популярная среда для атак, поэтому о защите нужно думать сразу, а не после того, как злоумышленники захотят получить доступ к вашему сервису.
Самый простой способ — подключить Web Application Firewall. WAF обеспечивает точечную защиту веб-приложения от SQL-инъекций, XSS, XXE, RCE и других угроз OWASP Top-10, предотвращает брутфорс, кражу учетных данных и атаки на логику приложений.
Сервисы для agile-разработки
Гиперскейлеры предлагают сотни инструментов для автоматизации и ускорения процесса разработки. Например, из сервисов Microsoft Azure разработчикам однозначно будут полезны:
- Azure Functions — облачная служба с регулярно обновляемой инфраструктурой и готовыми ресурсами, необходимыми для запуска приложений.
- Azure App Service — служба для создания веб-приложений, API и приложений Azure Functions для любых платформ и устройств
- Azure Event Hub — полностью управляемая платформа потоковой передачи больших данных и служба приема событий.
- Azure IoT Hub — создание приложений интернета вещей с помощью двунаправленного обмена данными.
- Azure Marketplace — маркетплейс готовых ИТ-программ, служб и приложений для разработчиков.
- Azure SQL Database — базы данных SQL для веб-приложений и приложений, ориентированных на работу в облаке.
- Terraform в Azure — автоматизация управления инфраструктурой Azure с помощью Terraform.
Как подключить облачные сервисы для разработки
С CloudMTS вы получаете бесплатный доступ ко всем сервисам для разработчиков сразу на 30 дней. Этого хватит не только на тестирование функционала — вы сможете разработать, протестировать и запустить собственный цифровой продукт без затрат на подключение услуг.
Масштабируемое облако Elastic Cloud, GPU SuperCloud, CDN, S3 хранилище, резервное копирование на базе Acronis Infoprotect, WAF и сервисы Azure не ограничены по функционалу. Чтобы подключить их — просто оставьте заявку на нашем сайте.
В предыдущем посте мы рассказали, как облачные сервисы превратились в негласный стандарт предоставления ИТ-услуг. Нетрудно догадаться, что компании, которые желают по-прежнему зарабатывать на пользовательских приложениях, должны адаптировать и создавать новые продукты с учетом Cloud-Native подхода. Впрочем, для разработчиков это однозначно позитивная новость, поскольку использование облачных технологий открывает для них огромные новые возможности. Главное уметь ими правильно распорядиться.
Когда приложение заказывает окружение
Если вы уже читали гид по облачным технологиям, то наверняка помните, что одним из «источников магии» облаков является технология виртуализации. Благодаря этому разработчику практически не нужно задумываться о параметрах серверов, на которых будет работать его приложение. Зачем тратить на это время, если правильно настроенный гипервизор или контейнер могут сконфигурировать машину с практически любыми характеристиками, которые нужны приложению для работы?
Развитием этой идеи является подход Infrastructure as code (IAC). Его суть в том, чтобы дать возможность разработчикам или службам эксплуатации применять для обслуживания инфраструктуры такие же подходы, которые используются на этапе разработки. Он позволяет готовить общие программные блоки управления заранее и легко осуществлять интеграцию таких компонентов в новых проектах.
Возможности современных ЦОДов уже позволяют переходить к декларативному языку управления инфраструктурой. В идеале, приложение должно само администрировать занимаемый им пул ресурсов в дата-центре. Это позволит разработчику не быть запертым в ограничениях, связанных с процессом работы с инфраструктурой, когда надо заказывать и проектировать наперед или если одни и те же компоненты инфраструктуры повторяются в разных проектах.
Фактически разработчик или инженер делает Pull Request, в котором находится конфигурация виртуальной машины (ядра, память, сеть, шаблон и т.д.), далее менеджер виртуального окружения самостоятельно создает машину или создает новый инстанс базы данных или стартует предустановленный сервис, согласно настройкам в файле. Такой подход — настоящее спасение при работе с большими данными и нейронными сетями. Приложения, связанные с этими технологиями, в некоторых случаях нуждаются в динамически изменяемых объемах памяти и процессорных мощностей.
Например, для обучения сети необходимо «прогнать» через нее сотни гигабайт информации, и облака позволяют получить необходимые для этого мощности по запросу. После того, как обучение будет завершено, ресурсы возвращаются в пул провайдера, а разработчику не нужно думать, чем их занять или как по-другому сконфигурировать приложение, чтобы оно продолжало работу на меньшем объеме мощности.
Монолит vs. упорядоченный хаос
Благодаря тому, что облака умеют эластично подстраиваться под потребности разработчика, это, теоретически, упрощает еще одну задачу – проблему масштабирования приложений. Почему теоретически?
К сожалению, задача по масштабированию приложений не является линейной. Чтобы приложение справлялось с огромными нагрузками в периоды пиковой посещаемости (или вычислений), недостаточно просто давать ему дополнительную память и процессорные мощности. Абсолютно у каждого традиционного приложения есть порог, после которого оно уже не в состоянии «переварить» новые ресурсы и продемонстрировать рост производительности. Проблема в данном случае состоит не в ресурсах, а в самой архитектуре большинства программ.
Особенно остро эта проблема стоит для приложений с монолитной архитектурой, которые, фактически, представляют собой единые бинарные файлы. Достоинства такого подхода очевидны: монолитные приложения достаточно просты и линейны. Все сценарии поведения пользователя можно предсказать, отследить и при необходимости произвести отладку бага.
Однако у такой простоты есть цена. Во-первых, это уже упомянутые выше проблемы с масштабированием. В какой-то момент даже самое продуманное монолитное приложение перестает работать эффективнее от апгрейда конфигурации сервера на котором оно исполняется.
Во-вторых, монолитное приложение не так-то просто перенести на новые сервера и для этого может потребоваться полная перекомпиляция программы.
В-третьих, такое приложение сложно поддерживать и развивать. Любое обновление превращается требует полной сборки всей программы, и ошибка в одном из блоков кода может обернуться падением всей системы.
В поисках идей, как решить эти проблемы была разработана другая концепция – service-oriented architecture (SOA). Она подразумевает, что приложение разделено на несколько модулей, каждый из которых предоставляет другим какую-то функциональность. Между собой модули взаимодействуют через набор веб-служб, и независимо друг от друга могут обращаться к единой или к собственным базам данных.
Такой подход действительно упрощает поддержку программы и не превращает ее обновление «в работу сапера», в которой нет права на ошибку; но и у него есть свои недостатки. Ключевой из них – проблемы с масштабированием разработки таких приложений. По мере роста программы, новые функции становится все сложнее «запихивать» в изначально утвержденные архитектором 5-10 пакетов. Их число становится все больше, что оборачивается проблемами с поддержкой.
Микросервис как элемент эволюции приложения
Результатом эволюции SOA стала идея микросервисной архитектуры, которая и используется при конструировании облачных приложений. Концептуально идеи обоих подходов крайне схожи, и некоторые архитекторы даже не выделяют микросервисную архитектуру в отдельную парадигму, считая ее частным случаем SOA.
Микросервисная архитектура подразумевает, что приложение состоит не из какого-то небольшого количества крупных модулей, а из множества независимых друг от друга частей. В отличие от монолита, в микросервисном приложении можно использовать различные способы взаимодействия компонентов между собой. У системы нет единого, заранее определенного состояния. Вместо этого каждый компонент работает «по ситуации»: как только ему поступает событие он начинает работу. Это позволяет делать очень гибкую и независимую архитектуру.
При этом число сервисов в микросервисном приложении постоянно меняется – какие-то добавляются, какие-то удаляются. В новом подходе можно любой микросервис заменить и вместо него встроить цепочку микросервисов. Другие сервисы продолжают стабильно работать, потому что не связаны напрямую между собой. Такова естественная эволюция программы. Благодаря этому у разработчиков и архитекторов появляется возможность быстро что-то менять, чтобы реагировать на изменения бизнес-требований и опережать конкурентов.
Помимо повышения скорости выпуска обновлений использование микросервисной архитектуры позволяет добиться децентрализации управления. Команда, которая отвечает за разработку того или иного сервиса, сама вправе определять его внутреннюю архитектуру и его особенности. Такой подход, кстати, сейчас в Блоке Технологии внедряет Архитектурный совет Сбербанка.
При этом садясь за разработку своего облачного приложения не следует спешить со скорейшим дроблением его на составные элементы. Главный противник подобного бездумного подхода — Мартин Фаулер; он же – один из авторов идеи микросервисной архитектуры. Проще изначально использовать монолитный подход, и потом стимулировать эволюцию приложения «естественным образом», ориентируясь на расшивку узких мест и добавление дополнительных функций.
В результате можно сформулировать следующее правило: задача программиста при работе с микросервисной архитектурой – не просто разбить приложение на максимальное количество составных частей, а разумным образом разграничить их ответственность за получение и обработку данных.
Четыре детали
Помимо множества очевидных достоинств, у микросервисной архитекутуры есть свои особенности, которые необходимости учитывать при разработке своего облачного приложения. В частности, для поддержки работы такого приложения необходимо постоянно поддерживать повышенные требования к качеству управления внутренними API.
Когда один из компонентов меняет свой интерфейс, он должен поддерживать обратную совместимость, чтобы поддерживать прошлую версию собственного API. Если это правило соблюдается, можно динамично переключаться со старой версии на новую без сбоев работе. Если же поддержка прежней версии API не проработана, то это грозит в лучшем случае, потерей части функциональности приложения, а в худшем – постоянными сбоями в его работе.
Вторая важная особенность микросервисных приложений заключается в сложностях поиска в них багов. Если «падает» приложение, написанное в монолитной логике или SOA, найти источник проблемы не составит труда. В приложении, состоящем из множества сервисов, поиск причины бага может сильно затянуться из-за того, что данные от пользователя нередко проходят обработку через несколько микросервисов, и сложно определить, в каком именно из них происходит сбой. При этом процесс поиска бага нужно вести очень аккуратно: любой неудачный рефакторинг может привести к поломке работающего модуля, и в дополнение к первоначальной проблеме разработчик получит вторую.
Третья важная деталь, которую необходимо учитывать, разрабатывая облачное приложение – способ взаимодействия его составных частей между собой. Как и в SOA, для обмена данными сервисы используют веб-службы, но в микросервисной архитектуре появились паттерны взаимодействия, например, как streaming, CQRS, Event sourcing. Обычно разработчики рассчитывают, что время отклика между запросом и ответом в приложении достаточно небольшое. В распределенной системе нельзя полагаться даже на то, что ответ вообще придет.
Так же в архитектуре облачных приложений микросервисы используют различные базы данных, наиболее оптимально подходящие для решения их конкретных задач. Например, гриды могут быстро читать, но с трудом справляются с большим количеством операций по изменениям данных. Такая база хорошо подойдет для ведения счетов вкладов – они редко изменяются. Другой тип операций – процессинг; в нем ежедневно по каждой карте могут быть десятки изменений, а чтений данных наоборот мало.
Наконец, четвертый факт, о котором нужно помнить при разработке облачного приложения – микросервисная архитектура ориентирована в первую очередь на использование сервисов без поддержки состояний. При этом не стоит впадать в крайности. Некоторые сервисы, при необходимости, все же могут осуществлять поддержку состояния, если того требует бизнес-логика, и они должны быть спроектированы особенно тщательно.
Например: если пользователь делает запрос на получение кредита, то получившая заявку система должна это состояние сохранить, чтобы передать его другим сервисам. А вот сервис, отвечающий за поиск информации во внутренней картотеке кредитных историй, может не сохранять состояние и забыть о том, данные на какого именного пользователя он искал пару минут назад – все равно уже через мгновенье ему придет новый запрос (хотя и в этом процессе может быть различное поведение сервиса).
Все описанные выше примеры и практики уже активно используются лидерами мировой ИТ-отрасли. Например, пионером в развитии микросервисной архитектуры является Netflix. Компания выпустила множество open-source приложений, библиотек и фреймворк для мониторинга, балансировки и логирования запущенных микросервисных приложений.
В этой электронной книге описывается подход, основанный на шаблонах, для создания реальных облачных решений. Шаблоны применяются к процессу разработки, а также к методикам архитектуры и программирования.
Содержимое основано на презентации, разработанной Скотт Гатри (, и доставляется ИТ-специалистом на конференции для норвежских разработчиков (NDC) в июне 2013 (часть 1, часть 2) и в Microsoft Tech Ed австралии в сентябре, 2013 (часть 1, часть 2). Многие другие были обновлены и дополнены содержимым при переходе из видео в письменную форму.
Целевая аудитория
Разработчикам, которые интересуются разработкой для облака, в том числе переходим в облако или не знакомы с разработкой в облаке, будет представлен краткий обзор наиболее важных концепций и рекомендаций, которые необходимо знать. Основные понятия показаны в конкретных примерах, а в каждой главе содержатся ссылки на другие ресурсы для получения более подробных сведений. Примеры и ссылки на дополнительные ресурсы предназначены для Microsoft Frameworks and Services, но эти принципы также применяются и к другим платформам веб-разработки и облачным средам.
Разработчики, которые уже разрабатывают для облака, могут найти здесь идеи, которые помогут сделать их более успешными. Каждую главу серии можно читать независимо друг от друга, чтобы можно было выбирать интересующие вас темы.
Все, кто наблюдался с Скотт Гатри (для создания реальных облачных приложений с помощью презентации Azure и хочет получить дополнительные сведения и обновленную информацию, найдет это здесь.
Шаблоны разработки в облаке
В этой электронной книге объясняется, как тринадцать рекомендованные шаблоны для разработки в облаке. "Шаблон" используется здесь в широком смысле, что означает рекомендуемый способ сделать следующее: как лучше всего разрабатывать, проектировать и программировать облачные приложения. Это ключевые шаблоны, которые помогут Вам «попадать в «смолу успеха», если вы их проберете.
- Используйте скрипты для повышения эффективности и снижения числа ошибок в повторяющихся процессах.
- Демонстрация. сценарии управления Azure.
- Настройка структуры ветвления в системе управления версиями для упрощения рабочего процесса DevOps.
- Демонстрация: Добавление скриптов в систему управления версиями.
- Демонстрация: Обеспечьте защиту конфиденциальных данных от системы управления версиями.
- Демонстрация. использование Git в Visual Studio.
- Автоматизируйте сборку и развертывание с каждым возвратом системы управления версиями.
- Типы хранилищ данных.
- Выбор правильного хранилища данных.
- Демонстрация: база данных SQL Azure.
- Секционирование данных по вертикали, горизонтали или обоим, чтобы упростить масштабирование реляционной базы данных.
- Храните файлы в облаке с помощью службы BLOB-объектов.
- Демонстрация. Использование хранилища BLOB-объектов в приложении Fix ИТ.
- Типы сбоев.
- Область сбоя.
- Основные сведения об SLA.
- Используйте интеллектуальную логику повтора и возврата, чтобы уменьшить влияние временных сбоев.
- Демонстрация. повторное или обратное отключение в Entity Framework 6.
- Повышение масштабируемости и снижение затрат на транзакции базы данных за счет использования распределенного кэширования.
- Обеспечение высокой доступности и повышение масштабируемости благодаря слабо связанным веб-и рабочим уровням.
- Демонстрация. очереди службы хранилища Azure в приложении Fix ИТ.
- Известные проблемы
- Рекомендации
- Загрузка, сборка, запуск и развертывание.
В этой оставшейся части главы представлен пример приложения Fix it и веб-приложения в облачной среде службы приложений Azure, в которой выполняется приложение для устранения проблем.
Пример приложения Fix ИТ
Большинство снимков экрана и примеров кода, приведенных в этой электронной книге, основаны на приложении Fix ИТ, первоначально разработанном Скотт Гатри ( , чтобы продемонстрировать Рекомендуемые шаблоны и методики разработки облачных приложений.
Вы можете отслеживать ход выполнения созданных рабочих элементов, просматривать сведения о билетах и помечать их как завершенные.
Это очень простое приложение с точки зрения возможностей, но вы узнаете, как создать его, чтобы он мог масштабироваться до миллионов пользователей и будет устойчивым к таким возможностям, как сбои баз данных и разрывы подключений. Вы также узнаете, как создать автоматизированный и гибкий рабочий процесс разработки, который позволит вам быстро и лучше повысить эффективность и улучшить работу приложения.
Веб-приложения в службе приложений Azure
В фоновом режиме веб-приложения в службе приложений Azure предоставляют множество архитектурных компонентов и функций, которые вам пришлось бы создавать, если вы собираетесь разместить веб-сайт с помощью IIS на собственных виртуальных машинах. Один из компонентов — это конечная точка развертывания, которая автоматически настраивает IIS и устанавливает приложение на столько виртуальных машин, сколько требуется для запуска сайта.
Если компьютер выходит из строя, Azure автоматически извлекает его из ротации, запускает новый экземпляр виртуальной машины и начинает направление трафика на новый экземпляр — все без времени простоя для приложения.
Все это происходит автоматически. Вам нужно всего лишь создать веб-сайт и развернуть в нем приложение, используя Windows PowerShell, Visual Studio или портал управления Azure.
Сводка
В этом вводе представлен список разделов, которые будут рассмотрены в книге, снимки экрана примера приложения и краткий обзор веб-приложений в облачной среде службы приложений Azure. Одно из замечательных преимуществ разработки приложений в и в облаке заключается в том, что можно легко автоматизировать повторяющиеся задачи разработки, такие как создание тестовой среды и развертывание в нем кода. Как это сделать, тема в следующей главе.
Ресурсы
Дополнительные сведения о темах, описанных в этой главе, см. в следующих ресурсах.
Одна из главных «фишек» глобальных облаков – огромный выбор встроенных в их платформы готовых ИТ-сервисов для разработки бизнес-приложений. Их настолько много, и они настолько быстро развиваются, что далеко не каждый опытный ИТ-специалист успевает следить за новинками. Рассказываем, какие полезные приложения мы бы выбрали из облака Amazon и почему.
Базовые тренды-2020
Для того, чтобы понять, почему то или иное приложение полезно или популярно, нужно понимать, какие приоритетные задачи оно решает.
Общий тренд 2020 года в построении корпоративной ИТ-инфраструктуры – переход на разработку облачных приложений. Это подразумевает не просто миграцию бизнес-инструментов в облачную среду, а целенаправленное создание приложений специально под развертывание в облаке с фокусом на масштабируемость и гибкость конкретной облачной среды.
Поэтому важные тренды работы в облаке сегодня касаются преимущественно инструментов и технологий, которые помогают разрабатывать приложения в облаке:
● Containers (Контейнеры) – это масштабируемая среда в облаке, которая включает в себя всю логику, необходимую для запуска приложений.
Контейнеры изолируют среды выполнения приложений друг от друга, но совместно используют ядро ОС. Гибкие и стандартизированные, они поддерживают перенос приложений между всеми типами инфраструктуры, включая общедоступные и частные облака, виртуализированные серверы и серверы с открытым исходным кодом.
Благодаря этим особенностям контейнеры удобно использовать для создания облачных приложений, которые можно развернуть и запустить в любой облачной среде. Компания может выбрать любого облачного провайдера в любое время и также легко перейти к другому провайдеру.
Низкие расходы на эксплуатацию контейнеров наряду с высокой плотностью в одной виртуальной машине делают контейнеры идеальными для развертывания приложений в виде микросервисов, т. е. в виде набора независимо развертываемых сервисов.
● Serverless computing (Бессерверная парадигма предоставления инфраструктуры) – это модель облачных вычислений, в которой поставщик облачных сервисов запускает сервер и динамически распределяет необходимые ресурсы между потребителями.
Ценообразование основано на ресурсах, потребляемых приложением, а не на заранее приобретенной емкости. Разработчикам не нужно выделять серверы или управлять масштабированием инфраструктуры. Облачный провайдер позволяет разработчикам абстрагироваться от этих задач и, благодаря этому, быстрее внедрять код в продуктивную среду.
Допустим, произошло событие, которое запускает код приложения. Облачный провайдер динамически распределяет ресурсы для выполнения этого кода. Пользователь прекращает платить, как только код завершает свою работу.
В результате снижаются расходы бизнеса на инфраструктуру, упрощается структура операций, растет эффективность DevOps.
● Automation (Автоматизация). В 2020 году автоматизация разработки – это не столько тенденция, сколько растущая необходимость. Автоматизация развертывания, тестирования и оповещений позволяет быстрее и надежнее развертывать и обновлять приложения.
● Statelessness, или Stateless protocol (Протокол без сохранения состояния) – локальные приложения часто хранят данные о своем состоянии (state) в инфраструктуре, в которой выполняется код. Поэтому приложение может быть повреждено при добавлении/удалении ресурсов сервера.
Облачные нативные приложения не привязаны к инфраструктуре, что означает возможность их выполнения в распределенном режиме, когда они сохраняют свое состояние независимо от базовой инфраструктуры. Их общение с сервером состоит из независимых пар «запрос-ответ».
● Right-sized capacity (Автоматическое распределение ресурсов облака)– облачные платформы, на которых развернуты приложения, динамически распределяют и перераспределяют свои ресурсы в зависимости от текущих потребностей приложения.
Традиционные ИТ-службы разрабатывают специализированное настраиваемое инфраструктурное решение, которое зачастую имеет слишком большой размер и основывается на оценках емкости при крайних сценариях, при этом практически отсутствует возможность его масштабирования в короткие сроки. Right-sizing устраняет эту проблему на уровне проектирования решения.
Желтая майка лидера
Что хорошего предлагает разработчикам в свете всего вышесказанного Amazon Web Services?
Список ресурсов AWS, относящихся к разработке облачных приложений, довольно обширный, все доступные инструменты в один материал не поместятся даже при беглом рассмотрении.
Мы выбрали топ приложений, которые, на наш взгляд, будут максимально востребованы бизнесом для целей разработки в ближайшем будущем.
● Amazon DynamoDB – полностью управляемая, мультирегиональная, многопользовательская, надежная база данных со встроенной системой безопасности, резервного копирования и восстановления, а также кэширования в памяти для интернет-приложений.
● Amazon Simple Storage Service (S3) – масштабируемая и недорогая веб-служба хранения объектов, предназначенная для оперативного резервного копирования и архивирования данных и программ приложений.
● AWS Lambda – вычислительный сервис, который позволяет разработчикам запускать код без необходимости управлять серверами. Он выполняет код только при необходимости и автоматически масштабируется.
● AWS Fargate – программное ядро для бессерверных вычислений на базе контейнеров, которое работает как с Amazon Elastic Container Service (ECS), так и с Amazon Elastic Kubernetes Service (EKS).
● Amazon Cognito облегчает контроль аутентификации пользователей, а также доступ к любым мобильным приложениям на устройствах, подключенных через Интернет.
● Amazon CloudFront – глобальный сервис CDN (content delivery network), который помогает в безопасной доставке данных, видео, приложений и API.
Также рассмотрим несколько узкоспециализированных областей.
Интеграция приложений
● AWS Step Functions позволяет координировать несколько сервисов AWS в бессерверных рабочих процессах, быстро создавать и обновлять приложения. Также можно объединять сервисы, такие как AWS Lambda и AWS Fargate, в многофункциональные приложения.
● Amazon EventBridge – серверная шина событий, предназначенная для простого соединения облачных нативных приложений с использованием данных из собственных приложений пользователя, интегрированных приложений SaaS и сервисов AWS.
Мобильная разработка
● AWS AppSync – управляемый сервис, который использует GraphQL, чтобы обеспечить простой доступ приложений к нужным данным. Это упрощает разработку, позволяя создавать гибкий API для безопасного доступа, манипулирования и объединения данных из нескольких источников.
Для мобильных и веб-приложений он также обеспечивает локальный доступ к данным, когда устройства отключаются, и синхронизацию данных с настраиваемым разрешением конфликтов, когда они снова подключаются к сети.
● AWS Amplify – платформа для разработки безопасных, масштабируемых мобильных и веб-приложений. Помогает аутентифицировать пользователей, надежно хранить данные и метаданные пользователей, разрешать выборочный доступ к данным, интегрировать машинное обучение (machine learning), анализировать метрики приложений и выполнять код на стороне сервера.
Охватывает весь рабочий процесс разработки приложений от контроля соответствия используемых версий ПО до развертывания в продуктивной среде и легко масштабируется от тысяч пользователей до десятков миллионов.
● Amazon Pinpoint – маркетинговая и аналитическая служба, размещенная в общедоступном облаке AWS, которая позволяет организациям взаимодействовать и отслеживать показатели, связанные с использованием приложений конечными пользователями.
Машинное обучение и искусственный интеллект
● Amazon CodeGuru – сервис для автоматического анализа кода и рекомендаций по производительности приложения. Он основан на машинном обучении, лучших практиках и уроках, извлеченных из миллионов обзоров кода и тысяч приложений, представленных в проектах с открытым исходным кодом и внутри AWS.
● Amazon Personalize –сервис машинного обучения, который позволяет разработчикам создавать индивидуальные рекомендации для клиентов, использующих их приложения.
● Amazon Forecast – полностью управляемый сервис, который использует машинное обучение для объединения данных временных рядов с дополнительными переменными для составления прогнозов.
● Amazon Transcribe использует процессы глубокого обучения для автоматического распознавание речи (ASR) в целях быстрого и точного преобразования речи в текст в различных приложениях.
Инструменты разработчика
● AWS Cloud9 – облачная интегрированная среда разработки (IDE) для написания, запуска и отладки кода только с помощью браузера.
● AWS Cloud Development Kit (AWS CDK) – среда разработки программного обеспечения с открытым исходным кодом для моделирования и предоставления ресурсов облачных приложений с использованием знакомых языков программирования.
● AWS X-Ray помогает разработчикам анализировать и отлаживать распределенные приложения.
● AWS CodePipeline – полностью управляемая служба непрерывной доставки, которая помогает автоматизировать конвейеры выпуска для быстрого и надежного обновления приложений и инфраструктуры.
Приведенный выше список полезных инструментов от Amazon можно пополнять постоянно – AWS учитывает текущие тренды разработки и добавляет все новый и новый функционал, который существенно помогает не только создавать и развертывать приложения, но и совместно работать над этими задачами.
Кейс: ИТ-задача и ее решение с помощью сервисов AWS
Одно из преимуществ работы в AWS – возможность сочетать и комбинировать как описанные выше, так и другие инструменты, а также базовые ресурсы облака, в нужные именно вам конфигурации для достижения поставленных целей.
Как эти инструменты применяются на практике, можно описать на примере контент-провайдера, пользующегося решениями облака AWS через наш сервис Direct Cloud Connect.
В роли заказчика выступил один из крупнейших российских мультимедийных сервисов, круглосуточно обеспечивающий пользователей развлекательным контентом. Ежемесячная аудитория насчитывает 17 млн человек. Сервис постоянно развивается и внедряет новые технологии для обеспечения высокого качества изображения и звука.
Подключение к облачным сервисам должно было решить такие задачи заказчика, как:
● развитие сервисов для обработки и анализа данных;
● организация «песочницы» для тестирования новых решений;
● размещение данных сервисов в надежной и высокопроизводительной ИТ-инфраструктуре;
● внедрение единого интерфейса и связи сервисов с локальной инфраструктурой заказчика для повышения удобства управления.
Облачные сервисы AWS стали оптимальной платформой для выполнения всех перечисленных задач.
Для технической реализации компания Linxdatacenter предоставила L2-канал QinQ от площадки Linxdatacenter в Москве до ЦОДа FR5 во Франкфурте. На базе прямого выделенного канала подключили заказчика к платформе AWS с использованием подключений Private и Public Virtual.
Канал Linxdatacenter обеспечивает минимальные сетевые задержки и стабильную работу с сервисами AWS. Надежность соединения гарантируется резервным подключением к платформе через другого провайдера.
В результате, все поставленные ИТ-задачи заказчик решает с помощью сервисов AWS:
● EC2 – вычисления в облаке,
● VPC – частное облако,
● S3 – хранение (бэкапы),
● Lambda, Athena - аналитика,
● Elemental MediaPackage – подготовка и защита контента для live-трансляций,
● CloudFront (CDN от AWS) – тестирование раздачи 4К-контента.
Николай Ляшук, менеджер по продуктам компании Linxdatacenter
Читайте также: