Как создать программу в облаке

В этой электронной книге описывается подход на основе шаблонов к созданию реальных облачных решений. Шаблоны применяются к процессу разработки, а также к методам архитектуры и программирования.

Содержимое основано на презентации, разработанной Скоттом Гатри и представленным им на норвежской конференции разработчиков (NDC) в июне 2013 года (часть 1, часть 2), а также в Microsoft Tech Ed Австралии в сентябре 2013 года. Многие другие обновили и дополнили содержимое при переходе с видео на записанную форму.

Целевая аудитория

Разработчики, которые интересуются разработкой для облака, учитывая переход в облако или не знакомы с облачной разработкой, вы найдете здесь краткий обзор наиболее важных концепций и методик, которые они должны знать. Основные понятия иллюстрируются конкретными примерами, а каждая глава ссылается на другие ресурсы для получения более подробной информации. Примеры и ссылки на дополнительные ресурсы предназначены для платформ и служб Майкрософт, но принципы, показанные в других платформах веб-разработки и облачных средах, также применяются.

Как разработать эффективное приложение в облаке

Разработчики, которые уже разрабатываются для облака, могут найти здесь идеи, которые помогут сделать их более успешными. Каждая глава серии может быть прочитана независимо, поэтому вы можете выбрать интересующие вас темы и выбрать их.

Любой, кто наблюдал за созданием реальных облачных приложений Скотта Гатри с помощью презентации Azure, и хочет получить дополнительные сведения и обновленную информацию будет найти здесь.

Шаблоны разработки облачных решений

В этой электронной книге описываются тринадцать рекомендуемых шаблонов для разработки облачных решений. Шаблон используется здесь в широком смысле, чтобы означать рекомендуемый способ выполнения действий: как лучше всего идти о разработке, проектировании и написании кода облачных приложений. Это ключевые шаблоны, которые помогут вам «попасть в яму успеха», если вы следите за ними.

• Автоматизируйте все.

• Используйте скрипты для повышения эффективности и минимизации ошибок в повторяющихся процессах.
• Демонстрация: скрипты управления Azure.

• Настройте структуру ветвления в системе управления версиями, чтобы упростить рабочий процесс DevOps.
• Демонстрация: добавление скриптов в управление версиями.
• Демонстрация: сохранение конфиденциальных данных из системы управления версиями.
• Демонстрация: использование Git в Visual Studio.

• Автоматизируйте сборку и развертывание с помощью каждой проверки системы управления версиями.

• Храните веб-уровень без отслеживания состояния.
• Демонстрация: масштабирование и автоматическое масштабирование в веб-приложения в Служба приложений Azure.
• Избегайте состояния сеанса.
• Используйте CDN с резервным вариантом, если CDN недоступен.
• Используйте модель асинхронного программирования.
• Демонстрация: асинхронная версия в ASP.NET MVC и Entity Framework.

• Общие сведения об Azure Active Directory.
• Демонстрация: создание приложения ASP.NET, использующего Azure Active Directory.

• Типы хранилищ данных.
• Выбор правильного хранилища данных.
• Демонстрация: база данных Azure SQL.

• Секционирование данных по вертикали, по горизонтали или для упрощения масштабирования реляционной базы данных.

• Хранение файлов в облаке с помощью службы BLOB-объектов.
• Демонстрация: использование хранилища BLOB-объектов в приложении Fix It.

• Типы сбоев.
• Область сбоя.
• Общие сведения об уровне обслуживания.

• Почему вы должны приобрести приложение телеметрии и написать собственный код для инструментирования приложения.
• Демонстрация: New Relic для Azure
• Демонстрация: ведение журнала кода в приложении Fix It.
• Демонстрация: внедрение зависимостей в приложении Fix It.
• Демонстрация: встроенная поддержка ведения журнала в Azure.

• Используйте интеллектуальную логику повторных попыток и откатов, чтобы снизить влияние временных сбоев.
• Демонстрация: повторы и откаты в Entity Framework 6.

• Повышение масштабируемости и сокращение затрат на транзакции базы данных с помощью распределенного кэширования.

• Включите высокий уровень доступности и улучшите масштабируемость, слабо связав веб-уровни и рабочие уровни.
• Демонстрация: очереди службы хранилища Azure в приложении Fix It.

• Известные проблемы
• Рекомендации
• Скачивание, сборка, запуск и развертывание.

Эти шаблоны применяются ко всем облачным средам, но мы продемонстрируем их с помощью примеров на основе технологий и служб Майкрософт, таких как Visual Studio, Team Foundation Service, ASP.NET и Azure.

Как создать свое облачное хранилище Windows?

В оставшейся части этой главы представлен пример приложения Fix It и веб-приложения в облачной среде Служба приложений Azure, в которой выполняется приложение Fix It.

Пример приложения «Исправление»

Большинство снимков экрана и примеры кода, показанные в этой электронной книге, основаны на приложении Fix It, первоначально разработанном Скоттом Гатри , чтобы продемонстрировать рекомендуемые шаблоны и методики разработки облачных приложений.

Пример приложения — это простая система запросов рабочих элементов. Если вам нужно что-то исправленное, вы создадите билет и назначите его кому-то, а другие могут войти в систему и увидеть назначенные им билеты и пометить билеты как завершенные после завершения работы.

Это стандартный веб-проект Visual Studio. Он основан на ASP.NET MVC и использует базу данных SQL Server. Она может выполняться локально в IIS Express и может быть развернута на веб-сайте Azure для запуска в облаке. Вы можете войти с помощью проверки подлинности на основе форм и локальной базы данных или с помощью поставщика социальных сетей, например Google. (Далее мы также покажем, как войти с помощью учетной записи организации Active Directory.)

После входа в систему вы можете создать билет, назначить его кому-то и отправить фотографию того, что вы хотите исправить.

Вы можете отслеживать ход создания рабочих элементов, просматривать назначенные ему билеты, просматривать сведения о билетах и помечать элементы как завершенные.

Это очень простое приложение с точки зрения функции, но вы узнаете, как создать его таким образом, чтобы он смог масштабироваться до миллионов пользователей и будет устойчивым к таким вещам, как сбои базы данных и завершение подключения. Вы также узнаете, как создать автоматизированный и гибкий рабочий процесс разработки, который позволяет начать простой процесс и сделать приложение лучше и лучше, выполняя цикл разработки эффективно и быстро.

веб-приложения в Служба приложений Azure

Облачная среда, используемая для приложения Fix It, — это служба Azure, которую мы называем веб-сайтами. Эта служба позволяет размещать собственное веб-приложение в Azure без необходимости создавать виртуальные машины и обновлять их, устанавливать и настраивать службы IIS и т. д. Мы размещаем ваш сайт на наших виртуальных машинах и автоматически предоставляем резервное копирование и восстановление и другие службы.

Служба веб-сайтов работает с ASP.NET, Node.js, PHP и Python. Это позволяет быстро развертывать с помощью Visual Studio, веб-развертывания, FTP, Git или Team Foundation Server. Обычно это всего несколько секунд между началом развертывания и временем, когда обновление доступно через Интернет. Все это бесплатно, чтобы приступить к работе, и вы можете масштабироваться по мере роста трафика.

За кулисами веб-приложения в Служба приложений Azure предоставляет множество архитектурных компонентов и функций, которые необходимо создать самостоятельно, если вы собираетесь разместить веб-сайт с помощью IIS на собственных виртуальных машинах. Один из компонентов — это конечная точка развертывания, которая автоматически настраивает СЛУЖБЫ IIS и устанавливает приложение на столько виртуальных машин, на которые вы хотите запустить сайт.

Когда пользователь попадает на веб-сайт, он не попадает непосредственно на виртуальные машины IIS, они проходят через подсистемы балансировки нагрузки маршрутизации запросов приложений (ARR ). Вы можете использовать их с собственными серверами, но преимущество заключается в том, что они настроены автоматически. Они используют интеллектуальную эвристика, которая учитывает такие факторы, как сходство сеансов, глубина очереди в IIS и загрузка ЦП на каждом компьютере для направления трафика на виртуальные машины, на которых размещен ваш веб-сайт.

Если компьютер выходит из строя, Azure автоматически извлекает его из поворота, запускает новый экземпляр виртуальной машины и начинает направлять трафик к новому экземпляру — все без простоя приложения.

Все это происходит автоматически. Вам нужно создать веб-сайт и развернуть в нем приложение, используя Windows PowerShell, Visual Studio или портал управления Azure.

Краткое и простое пошаговое руководство по созданию веб-приложения в Visual Studio и его развертыванию на веб-сайте Azure см. в статье «Начало работы с Azure» и ASP.NET.

Сводка

В этом обзоре представлен список разделов, которые книга будет охватывать, снимки экрана примера приложения и краткий обзор веб-приложения в облачной среде Служба приложений Azure. Одним из больших преимуществ разработки приложений в облаке и облаком является то, что легко автоматизировать повторяющиеся задачи разработки, такие как создание тестовой среды и развертывание кода в нем. Как это сделать, это тема следующей главы.

Ресурсы

Дополнительные сведения о темах, описанных в этой главе, см. в следующих ресурсах.

• веб-приложения в Служба приложений Azure. Страница портала для документации по Azure по веб-приложения.
• веб-приложения, Облачные службы и виртуальных машинах: когда использовать какие? WAWS, как показано в этой главе, — это всего лишь один из трех способов запуска веб-приложений в Azure. В этой статье описываются различия между тремя способами и приводятся рекомендации по выбору подходящего варианта для вашего сценария. Как и веб-сайты, Облачные службы — это функция PaaS в Azure. Виртуальные машины — это функция IaaS. Описание PaaS и IaaS см. в разделе » Параметры данных «.

• Скотт Гатри начинается с шага 0. Что такое облачная ОС Azure?
• Архитектура веб-сайтов — с Стефаном Schackow.
• Внутренние веб-сайты Azure с Nir Mashkowski.

Источник: learn.microsoft.com

Создание приложения для мобильных устройств

Этот материал входит в серию технических статей, написанных командой архитекторов программных решений AWS для стартапов с целью помочь создателям стартапов заложить основу для быстрого развития их бизнеса. Эта серия является общим обзором технических решений, которые необходимо принять на этапе создания стартапа, а также сервисов AWS, наиболее подходящих для их реализации.

Помимо инструмента командной строки, AWS Amplify предоставляет также библиотеки для iOS, Android и JavaScript. Эти библиотеки помогут вам настроить и использовать необходимые сервисы в любом мобильном приложении. Интеграцию сервисов можно выполнить с помощью доступных сразу после установки библиотек компонентов интерфейса пользователя или же путем подробной настройки элементов базовых нативных платформ.

Для нашего приложения мы рекомендуем использовать React Native и встроенные компоненты, которые помогут создать кросс-платформенное мобильное приложение. Это означает, что приложение будет построено на общей базе кода и сможет работать как на системах под управлением iOS, так и на платформе Android. Кросс-платформенный характер ПО ускорит процесс вывода вашего приложения на рынок.

Теперь, когда мы узнали о подходящем способе управления сервисами и их интеграции в единое приложение, давайте вновь вернемся к тому сервису, который наиболее необходим в нашем приложении: к средству управления пользователями.

Управление пользователями

Современные мобильные приложения позволяют пользователям входить в систему и выходить из нее. Как уже упоминалось ранее, наше приложение должно обеспечивать возможность управления пользователями, так как в нем будут храниться их персональные данные: огромное количество списков дел, которые важно запомнить пользователю. Создание аккаунта пользователя поможет в управлении доступом к принадлежащим ему данным, а также предоставит возможность персонализации характера взаимодействия с программой, что существенно увеличит популярность мобильного приложения. Что также важно, по причине использования персональных данных подход на базе применения аккаунтов поможет нам монетизировать приложение на дальнейших этапах его развития.

Как создавать приложения в облаке

SaaS – это наиболее распространенная модель оказания услуг для большинства поставщиков софта. Эта модель также помогает поставщикам облачных решений предоставлять инфраструктурные услуги (IaaS). Приложения зачастую создаются в публичном облаке, например, в Amazon Cloud (AWS), Microsoft Azure, Google Cloud и др.

Однако иногда организации используют ресурсы своего дата-центра для размещения приложений, чтобы инвестировать только в свою инфраструктуру. Для разработки приложений SaaS нужно больше, чем просто деплой в облаке. Правильное проектное планирование поможет качественно проработать структуру, оптимально сократить расходы и более эффективно управлять развертыванием. В этой статье будет представлено несколько ключевых моментов и советов по распространению приложений, работающих по модели SaaS , которая еще долго будет широко применяться.

Отличия SaaS-разработки от On-Prem модели

Микросервисная архитектура .

Если у вас монолитное приложение, возможно, имеет смысл разбить его на логические части, которые можно развернуть по отдельности. Это не только улучшит модульность, но и оптимизирует приложение для того, чтобы оно занимало меньше места. Предположим, у вас есть приложение, которое использует фоновые процессы.

Можно развернуть основное приложение и фоновые процессы отдельно, разбив это все на 2 или более отдельных приложения. Это сократит потребность в ресурсах. Кроме того, теперь есть возможность еще и независимо масштабировать приложения по отдельности в зависимости от потребностей каждой части. Если есть спрос на фоновые процессы, вы можете увеличить размер ресурса под них, то же самое можно сделать и с ресурсами для основного приложения. Так как ресурс для каждого модуля небольшой, масштабирование конкретного дискретного уровня или элемента обойдется дешевле, чем масштабирование больших ресурсов.

Непрерывная поставка обновлений

Это новинка для многих локальных приложений. Клиенты всегда ожидают последней версии от облачных приложений. Если смотреть на это со стороны разработчика, — теперь вы можете не только апдейтить по частям, но и вносить изменения в структуру данных пользователей так, чтобы они этого не заметили. Процесс обновления приложения становится полностью прозрачным для клиентов.

Это лишь некоторые моменты. Но основная суть очевидна.

Вопросы архитектуры приложений в облаке

Выбирайне подходчщие сервисы. Допустим, вы хотите развернуть приложение в облаке, но для начала задумайтесь, какие именно облачные сервисы вы хотите использовать для этой цели? Просто IaaS (Инфраструктура как услуга)? Или PaaS (Платформа как услуга)? Ответ не всегда на поверхности.

А если планируете развернуть приложение на нескольких облачных платформах или локально? Имеет смысл пользоваться услугами поставщика по минимуму и больше внимания уделить модели IaaS. Итак, вот несколько рекомендаций:

Приценитесь и выберите оптимальное решение

Важным фактором при выборе решения должна быть стоимость. Например, некоторые PaaS-сервисы, управляемые поставщиками облачных решений, могут быть переведены под управление силами вашей команды, чтобы снизить затраты. Хотя такая схема подходит не для каждого сервиса, стоит все предусмотреть.

Учитывайте опыт своей команды

Задайте себе вопросы:

— Что нужно конкретно вам, чтобы использовать облачный сервис?

— Если бы ваша команда самостоятельно занималась поддержкой основной инфраструктуры, какие навыки были бы ей необходимы?

Проектируйте с учетом вероятности отказа системы

Проектирование отказоустойчивых и высокодоступных приложений имеет основополагающее значение для облачных услуг. Предположим, ваше приложение работает со сбоями, сможете ли вы гарантировать, что пользователи продолжат с ним работать? Учтите, сбои могут быть как в приложении, так и в базовой инфраструктуре.

Полезные возможности облачных провайдеров

Использование балансировщика нагрузки

Узлы приложения для этого размещают за балансировщиком нагрузки, чтобы в случае выхода из строя нескольких узлов, приложение обслуживалось через другие узлы.

Использование модели с географическим распределением

Некоторые поставщики предлагают возможность для распределения приложения по нескольким географическим областям, чтобы даже в случае физического воздействия на одну локацию (например, из-за стихийного бедствия) приложение можно было бы обслуживать из других локаций. Например, облако AWS предлагает развертывание приложения в нескольких зонах доступности.

Безопасность

Безопасность включает в себя множество аспектов – от защиты инфраструктуры до защиты приложений. Некоторые аспекты безопасности нацелены на доступность только требуемых портов, использование как можно меньших привилегий для ресурсов, управление доступом на основе ролей, шифрование и т.д. Безопасность не должна рассматриваться как одномоментное действие. Это продолжительный процесс, который должен постоянно совершенствоваться.

Многопользовательская аренда

Ключевое преимущество работы в облаке – это возможность обслуживания нескольких пользователей, использующих один и тот же экземпляр приложения. Это помогает выявить некоторые очевидные пробелы в проекте приложения, чтобы гарантировать, что данные пользователей разделены как с целью обеспечения безопасности, так и в целях его администрирования.

Некоторые используют разные экземпляры базы данных для каждого клиента. А другие – одну базу данных, присваивая данным идентификаторы конкретных клиентов. Независимо от того, какой подход вы используете, важно убедиться, что архитектура отвечает требованиям масштабируемости и безопасности. Например, если вы решите использовать базу данных для каждого клиента, вы можете разместить несколько баз данных в одном экземпляре СУБД.

Минимизация времени простоя системы и бесшовное обновление

Многие клиенты ожидают от приложений SaaS минимального или нулевого времени простоя. И так как обычно поддержкой занимается компания-разработчик приложения, обновления происходят бесшовно. Проблема заключается в том, что ваше приложение, возможно, не предназначено для обновлений без прерывания работы, особенно если оно изначально не разрабатывалось как SaaS -приложение. Есть 2 ключевых аспекта , которые следует учитывать:

а) обновление кода приложения

б) изменение структуры данных в хранилище

Для выкатывания приложений могут быть использованы специальные стратегии, в которых новый выпуск деплоится в новой программной среде (стеке), затем тестируется и запускается, если деплой прошел успешно. Старые ресурсы стека могут быть выведены из эксплуатации и задействованы позже.

Один из подходов к бесшовному обновлению состоит в том, чтобы сделать модель данных «n-1 совместимой». Это значит, что, если развернутый выпуск имеет версию модели данных n, она совместима с предыдущей версией модели (n-1), таким образом гарантируется, что обновление не сломает ее. Откуда гарантии?

На протяжении всего цикла разработки требуется серьезная дисциплина и следование определенным рекомендациям, например, нельзя удалять столбцы, предоставляя необходимые скрипты обновления для обработки любых потребностей миграции данных и т.д. В случае, если обновление не произойдет, есть возможность откатить его. Теперь ясно, что это не только технически сложно в исполнении из-за миграции и отката данных, н о еще и может замедлиться процесс развертывания. Вам следует тщательно продумать , что наиболее подходит под ваши потребности, и реализовать соответствующее решение.

Еще немного о финансовой составляющей

По мере создания вашего приложения и проектирования деплоя, вы можете предложить несколько подходов для развертывания. Тем не менее, для успешной реализации модели SaaS необходимо выбрать наиболее экономически эффективную модель, которая не только отвечает вашим актуальным потребностям, но может удовлетворить еще и потенциальные, например, в случае роста или падения спроса на ресурс . Сейчас поясним. Допустим, вы не хотите растрачиваться впустую на резервирование ресурсов, но и хотите избежать ситуации, когда приложение не справляется с очень большим наплывом пользователей и высокой нагрузкой. Важно найти правильный баланс. Эмпирическое правило при выборе размера ресурса: всегда прислушивайтесь к своему опыту, а если в процессе тестирования выяснится, что требуется более высокая конфигурация, — увеличивайте.

О DevOps для SaaS

DevOps – очень актуальная тема в разрезе модели SaaS, стоит рассмотреть ее отдельно. Выделим ключевые моменты DevOps для облачной модели:

Непрерывный деплой

Процессы DevOps должны иметь возможность принимать зарегистрированный код, создавать из него сборку, которая затем проходит через различные этапы (контроль качества, производительность, финальный деплой ) в автоматическом режиме. Может быть несколько процессов (например, для каждой стадии) и главный процесс, который производит сборку от начала и до конца. Теперь для разработки скриптов процессов тоже может потребоваться время, но в конечном счете это приведет к полной или практически полной автоматизации развертывания .

Использование системы контроля версий для всего, включая изменения DevOps

Понятно, что для кода приложения используется ветка master репозитория. Важно сделать то же самое и для любых изменений кода скриптов DevOps . Например, когда вы внедряете изменения в инфраструктуру, они тоже должны быть включены в систему контроля версий, протестированы и только затем отправлены в продакшн.

Гибкая инфраструктура

Чтобы преуспеть в SaaS, вам надо убедиться, что ваша инфраструктура достаточно гибкая и справится с изменениями спроса на ресурсы. По мере роста спроса она должна масштабироваться до соответствующего уровня, а при снижении – высвобождать незадействованные мощности. Экспериментируйте, чтобы отыскать баланс. К примеру, вы можете использовать автоматическое масштабирование, облачная инфраструктура в этом случае будет «подстраиваться» сама.

Мониторинг и оповещения

Технологические стеки обычно состоят из десятков постоянно обновляющихся компонентов, устранение неполадок может стать проблемой. Важно использовать правильные механизмы мониторинга и оповещения, чтобы в случае алерта получилось быстро устранить проблему. Хороший совет – использовать некоторые базовые возможности мониторинга через облако: централизованное ведение журнала, аварийные сигналы, уведомления об ошибках.

Кое-что еще о SaaS.

О планировании и расстановке приоритетов

Как и в любом успешном проекте, в SaaS тоже без планирования не обойтись. Хотя многие стремятся просто выкатывать версии одну за другой в продакшн. Но всегда важно учитывать первичные потребности бизнеса и правильно расставлять приоритеты. Да, вы не ослышались, растягивать цели – неплохо. Важно сначала правильно все спланировать.

Если у вас нет хорошего модульного тестирования или автотеста, и вы пытаетесь выкатить каждый новый фрагмент кода в продакшн, вряд ли это сулит хорошие перспективы в итоге. Могут возникнуть неприятные последствия. Программные продукты начнут слишком часто ломаться после деплоя, и проектная группа будет вынуждена тратить время и усилия на сглаживание негативных последствий.

SaaS влияет также на модель автоматизации

В своей инфраструктуре вы можете продавать лицензии лишь на определенную сумму, а при SaaS вам предстоит переосмыслить модель для вашего бизнеса. Хотите ли вы использовать модель на основе подписки, на основе потребления, гибридную модель или какую-то еще…

Надеемся, вы получили исчерпывающее представление о том, что необходимо для разработки облачного или SaaS-приложения. Это, безусловно, полезный опыт, помогающий взглянуть на разработку приложения, учитывая разные аспекты, и грамотно запустить его в продакшн. Как говорится: «Облако – это путешествие, а не конечный пункт прибытия!»

Источник: oncloud.ru