exam14

Билет 14

Понятие облачных вычислений. Категории служб и основные модели развертывания.
Обеспечивающие информационные технологии и программные средства, применяемые в моделях разработки TDD, BDD, MDD.

◀️ Реферат к вопросам экзамена по дисциплине Интернет-технологии 1 курса магистратуры ▶️

Выполнили: Чернат Николай ИДМ-22-05, Смирнов Александр ИДМ-22-06, Гаврилкин Т.С. ИДМ-22-02, Сорокина Татьяна ИДМ-22-04, Нуриев В.К. ИДМ-22-07

ТЕКСТ РЕФЕРАТА

Понятие облачных вычислений. Категории служб и основные модели развертывания.

Определение понятия "облачные вычисления"

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

Основные характеристики облачных вычислений, которые отличают их от других типов вычислений (интернет-ресурсов):

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

Преимущества облачных вычислений

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

Гибкость. За считанные минуты можно подключить больше ресурсов для выполнения «тяжёлых» вычислительных процессов, развернуть пару десятков виртуальных рабочих столов для новых сотрудников, создать тестовую среду для обкатки нового приложения — облачные вычисления дают компаниям мобильность и гибкость, которые невозможны при использовании локальной инфраструктуры.
Эластичность. Не нужно покупать оборудование «про запас» задолго до того, как оно действительно понадобится. Благодаря облакам можно получить ровно столько ресурсов, сколько требуется для решения текущих задач. Оборудование не простаивает, а организация не зависит от отдела закупок. Экономия бюджета. Облачные вычисления автоматизируют и удешевляют использование IT‑инфраструктуры. Например, облачный сервер можно включить на два часа и заплатить только за это время, так как провайдеры практикуют оплату по схеме pay‑as‑you‑go, то есть по факту потребления. При увеличении масштабов парка IT экономия средств становится значительной: нет лишних расходов.
Снижение издержек. Поддержка собственной вычислительной инфраструктуры требует денег на штатных IT‑специалистов, регулярные обновления ПО и другие процедуры. Облака позволяют переложить эту ответственность на провайдера. Организации получают производительное оборудование с актуальным ПО, которое обслуживают компетентные специалисты.
Стабильность. Условия бесперебойной работы виртуальной инфраструктуры прописываются в договоре с провайдером (в рамках SLA). Так организации получают гарантии стабильной работы своих сервисов и финансовую защиту в случае возникновения проблем. Управляемость. Организация может сама решить, какие ресурсы и в каком объёме она будет использовать. Для этого не нужно звонить менеджерам провайдера или оставлять заявки в техподдержке. С помощью личного кабинета или терминала в любой момент можно задать нужные параметры.
Безопасность. Уровень компетенций сотрудников облачного провайдера обычно выше, чем у сотрудников компаний‑клиентов. Кроме того, провайдер использует оборудование и ПО промышленного уровня, что повышает безопасность и надёжность IT‑систем.

Категории служб

Software as a Service (SaaS) - программное обеспечение как услуга. В этой модели предоставления облачных вычислений потребитель использует приложения поставщика, запущенные в облачной инфраструктуре, которые доступны клиенту через интерфейс (web-браузер) или интерфейс программы. Потребители не могут управлять и контролировать лежащую в основе облака инфраструктуру, включая сеть, серверы, операционные системы, хранилища данных или даже изменять параметры настройки конкретного приложения.

Преимущества SaaS

Экономия физической памяти. Программа не занимает место на смартфоне или компьютере.
Удобный доступ к приложению. Если есть интернет-соединение, программу можно открыть в любое время и в любом месте.
Гибкость. Можно выбрать тариф в соответствии с реально потребляемыми ресурсами, а также использовать только тот функционал, который нужен для выполнения задачи.
Унификация. Если штат компании состоит из офисных и удалённых сотрудников, приложения в системе SaaS помогают настроить работу по единому стандарту.

Недостатки SaaS
Проблемы с производительностью. Приложения, работа которых зависит от интернета, при работе в удаленных центрах обработки данных, иногда могут показывать низкую производительность.
Недостаточная безопасность данных. Это одна из основных причин, по которой некоторые компании не решаются перейти на модель «программное обеспечение как услуга».
Отсутствие поддержки интеграции. Часто необходимо интегрировать продукты SaaS с другими инструментами и приложениями.

Platform as a Service (PaaS) - платформа как услуга. Модель предоставления облачных вычислений, при которой потребитель получает доступ к использованию программной платформы: операционных систем, СУБД, прикладного ПО, средств разработки и тестирования ПО. Фактически потребитель получает в аренду компьютерную платформу с установленной операционной системой и специализированными средствами для разработки, размещения и управления веб-приложениями. Потребитель не управляет основной инфраструктурой облака, включая сеть, серверы, операционные системы или хранилища данных, но управляет развернутыми приложениями и возможно параметрами настройки конфигурации среды окружения.

Преимущества PaaS

Быстрая развертываемость: не нужно долгого подключения и настроек, чтобы приступить к задаче. Программы быстро вызываются из системы.
Не нужно администрировать: поддержка и обновление локальных центров обработки данных будет происходить на стороне платформы.
Вариативность: несмотря на то, что PaaS — это практически готовый продукт, его возможности почти не ограничены.
Автоматизация: PaaS позволяет автоматизировать рутинные процессы, а также задачи, которые обычно выполняются вручную.
Ускоряет выпуск продукта на рынок: не нужно разбираться и настраивать систему. Можно сразу приступить к реализации идеи.

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

Infrastructure as a Service (IaaS) - инфраструктура как услуга. Модель предоставление облачных вычислений, при которой потребитель получает возможность управлять средствами обработки и хранения, а также и другими фундаментальными вычислительными ресурсами (виртуальными серверами и сетевой инфраструктурой), на которых он может самостоятельно устанавливать операционные системы и прикладные программы под собственные цели. Потребитель не управляет основной инфраструктурой облака, но управляет операционными системами, хранилищем и развернутыми им приложениями.

Преимущества IaaS

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

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

Основные модели развертывания

Private cloud (частное облако) - инфраструктура, предназначенная для использования облачных вычислений в масштабе одной организации, возможно также клиентами и подрядчиками данной организации. Частное облако может находиться в собственности, управлении и эксплуатации как самой организации, так и третьей стороны (или какой-либо их комбинации), и оно может физически существовать как внутри, так и вне юрисдикции владельца.
Community cloud (облако сообщества) - облачная инфраструктура, которая предназначена для исключительного использования облачных вычислений определенным сообществом потребителей от организаций, которые решают общие проблемы.
Public cloud (публичное облако) - инфраструктура, предназначенная для свободного использования облачных вычислений широкой публикой. Общественное облако может находиться в кооперативной (совместной) собственности, управлении и эксплуатации одной или более из организаций сообщества или третьей стороны (или какой-либо их комбинации), и оно может физически существовать как внутри, так и вне юрисдикции владельца.
Hybrid cloud (гибридное облако) - это комбинация различных облачных инфраструктур (частных, публичных или сообществ), остающихся уникальными объектами, но связанных между собой стандартизованными или частными технологиями, которые обеспечивают возможность обмена данными и приложениям (например, кратковременное использование ресурсов публичных облаков для балансировки нагрузки между облаками).

Облачные вычисления: мифы и заблуждения

«Облако» основано только на программном обеспечении Теоретически вполне можно построить облако на стандартных серверах (x86) и интеллектуальном программном обеспечении. Объединяем несколько виртуальных устройств и получаем «облако». Но на самом деле это далеко не так. По разным причинам, таким как поддержание адекватной производительности (специализированные ASICs или выделенные аппаратные ресурсы), обеспечение совместимости (установка драйверов для каждой новой платформы x86), или функций контроля (HIPPA, PCI-DSS, ведомственная изоляция, и т. д.), еще далеко не все системные разработчики отказались от использования выделенных аппаратных ресурсов для определенных элементов своих дата-центров. В принципе неизбежность виртуализации некоторых компонентов компьютерной среды очевидна. Поэтому лидеры рынка выпускают соответствующее оборудование. Например, Nexus 1000v, который обеспечивает прозрачность трафика виртуальных машин на уровне сетевой безопасности, с встроенной технологией VN-Link, обеспечивающей мобильность сети. А также виртуальный шлюз безопасности и vWAAS. В одних случаях, клиенты выбирают виртуальные устройства. В других случаях, они предпочитают комбинацию программных и аппаратных ресурсов, например, контрольных точек, представленных Nexus 1010v. Все эти унифицированные сетевые услуги обеспечивают системных разработчиков стандартным набором приемов, позволяющих в случае необходимости совместно использовать программные и аппаратные ресурсы.

Обеспечивающие информационные технологии и программные средства, применяемые в моделях разработки TDD, BDD, MDD

TDD — Test Driven Development

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

Звучит просто и понятно. Многим знаком такой подход к разработке и даже сам "Uncle Bob" активно его пропагандирует.

TDD считается одной из форм правильного метода построения приложения. Философия разработки на основе тестов заключается в том, что ваши тесты являются спецификацией того, как ваша программа должна вести себя. Если вы рассматриваете свой набор тестов как обязательную часть процесса сборки, если ваши тесты не проходят, программа не собирается, потому что она неверна. Конечно, ограничение заключается в том, что правильность вашей программы определена только как полнота ваших тестов. Тем не менее, исследования показали, что разработка, основанная на тестировании, может привести к снижению ошибок на 40-80% в производстве. Начав использовать TDD, вы можете почувствовать, что работаете медленнее, чем обычно. Так происходит потому что вы будете работать вне «зоны комфорта», и это вполне нормально.

TDD задает следующий порядок этапов программирования:

Красный - напишите небольшой тест, который не работает, а возможно, даже не компилируется.
Зеленый - заставьте тест работать как можно быстрее, при этом не думайте о правильности дизайна и чистоте кода. Напишите ровно столько кода, чтобы тест сработал.
Рефакторинг - удалите из написанного вами кода любое дублирование.
Освоив TDD, разработчики обнаруживают, что они пишут значительно больше тестов, чем раньше, и двигаются вперед маленькими шагами, которые раньше могли показаться бессмысленными.

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

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

Эта методология позволяет добиться создания пригодного для автоматического тестирования приложения и очень хорошего покрытия кода тестами, так как ТЗ переводится на язык автоматических тестов, то есть всё, что программа должна делать, проверяется. Также TDD часто упрощает программную реализацию: исключается избыточность реализации — если компонент проходит тест, то он считается готовым.

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

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

TDD — Type Driven Development

Type Driven Development сокращенно пишется также, как и разработка через тестирование, поэтому обычно пишут полное название.

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

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

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

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

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

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

BDD — Behaviour Driven Development

Из-за некоторого методологического сходства TDD (Test Driven Development) и BDD (Behaviour Driven Development) часто путают даже профессионалы. В чем же отличие? Концепции обоих подходов похожи, сначала идут тесты и только потом начинается разработка, но предназначение у них совершенно разное. TDD — это больше о программировании и тестировании на уровне технической реализации продукта, когда тесты создают сами разработчики. BDD предполагает описание тестировщиком или аналитиком пользовательских сценариев на естественном языке — если можно так выразиться, на языке бизнеса.

BDD — behaviour-driven development — это разработка, основанная на описании поведения. Определенный человек(или люди) пишет описания вида "я как пользователь хочу когда нажали кнопку пуск тогда показывалось меню как на картинке" (там есть специально выделенные ключевые слова). Программисты давно написали специальные тулы, которые подобные описания переводят в тесты (иногда совсем прозрачно для программиста). А дальше классическая разработка с тестами.

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

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

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

Если записывать названия тестов в виде предложений и при записи имен методов использовать лексику бизнес-домена, созданная документация становится понятна заказчикам, аналитикам и тестировщикам.

Тексты сценариев записываются в определенной форме.

Имея (прим. given — данное) какой-то контекст,
Когда (прим. when) происходит событие,
Тогда (прим. then) проверить результат.

Или другой пример на русском:

+Сценарий 1: На счету есть деньги+

Имея счет с деньгами

И валидную карточку

И банкомат с наличными

Когда клиент запрашивает наличные

Тогда убедиться, что со счета было списание

И убедиться, что наличные выданы

И убедиться, что карточка возвращена

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

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

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

В чем преимущество BDD?

Тесты читаемые для не программистов
Их легко изменять. Они часто пишутся почти на чистом английском
Их может писать product owner или другие заинтересованные лица
Результаты выполнения тестов более "человечные"
Тесты не зависят от целевого языка программирования. Миграция на другой язык сильно упрощается

Минусы:

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

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

Подробнее о BDD можно прочитать тут.

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

MDD — Model Driven Development

В последнее время много внимания в публикациях отводится теме архитектуры и разработке на основе моделей MDA (Model Driven Architecture) и MDD (Model Driven Development). Не вдаваясь в подробности, выделим только ключевые моменты.

Разработка, управляемая моделями, (англ. model-driven development) — это стиль разработки программного обеспечения, когда модели становятся основными артефактами разработки, из которых генерируется код и другие артефакты. Если говорить проще, то вся суть разработки сводится к построению необходимых диаграмм, из которых впоследствии мы генерируем рабочий код проекта.

Основная цель MDD — минимизация затрат, связанных с привязкой к конкретным системным платформам и программным инфраструктурам. Ведь основная бизнес-логика содержится в диаграммах и не сковывает нас рамками выбора языка программирования и инструментов разработки.

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

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

Идея MDD не нова ‑ она использовались с переменным успехом и раньше. Причиной возросшего внимания к ним в настоящее время является то, что автоматизации поддается значительно больше процессов, чем раньше. Это развитие отражается в появлении MDD-стандартов, что ведет к унификации соответствующих средств. Одним из таких стандартов является пересмотренная версия Unified Modeling Language – UML 2.0.

По стандартам Object Management Group (OMG) создание приложения состоит из следующих шагов:

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

Классический пример применения MDD, который используется уже давно, — моделирование баз данных. На основе одной концептуальной модели данных вы можете поддерживать несколько связанных с ней физических моделей для различных СУБД.

Какие преимущества мы получаем:

ускоряется вывод минимального жизнеспособного продукта (Minimum Viable Product) на рынок;
сокращается время на: генерацию каркаса приложения, модели классов, базы данных;
постоянно обновляемая документация;
для участников проекта диаграммы намного нагляднее кода.