Облачное программное обеспечение и архитектура больших данных — типы приложений, требования и компоненты

Введение

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

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

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

Типы приложений

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

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

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

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

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

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

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

Вот неполный список с некоторыми примерами:

• Статический сайт (Jekyll)
• Социальные медиа (Facebook, Twitter, Snapchat)
• Система управления контентом — CMS (WordPress)
• Система планирования ресурсов предприятия — ERP (Microsoft Dynamics, Oracle e-Business Suite)
• Торговля через Интернет (Amazon, Zappos)
• Управление взаимоотношениями с клиентами — CRM (Salesforce, Pipedrive)
• Производительность и оценка полезности (Google Docs, Slack, Trello, Evernote)
• Бухгалтерский учет, обработка платежей и выставления счетов (Quickbooks, PayPal)
• Email маркетинг (Mailchimp, ExactTarget)
• Закупка, заказы, инвентаризация
• Нацеленные на обработку данных
  • Бизнес-аналитика — BI
  • Обработка и аналитика больших данных, пакетный режим и режим реального времени
  • Интернет вещей (IoT)

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

«Облако»

Давайте сначала рассмотрим понятия сеть, центр обработки данных, кластер, грид и облако, прежде чем перейти в конкретные детали, прежде чем перейдём к конкретным деталям.

Компьютерная сеть представляет — множество компьютеров, которые сообщаются друг с другом, чтобы разделить ресурсы. Интернет является прекрасным примером массивной сети, в то время как домашняя локальная сеть или Wi-Fi сеть является хорошим примером меньшей и более частной сети. Общие ресурсы часто включают в себя веб-страницы, средства массовой информации, системы хранения данных, серверы приложений, принтеры и так далее. Узлы в сети идентифицируют друг друга и сообщаются по различным протоколам, HTTP и TCP / IP — наиболее распространенные из них.

Индивидуальные пользователи и некоторые компании могут разместить приложение и серверы хранения данных локально, часто эти серверы расположены в центре обработки данных. Центр обработки данных — объект, который размещает множество серверов и связанные с ними компоненты (напр., создание сетей, питание, охлаждение), всю необходимую инфраструктуру, безопасность и защиту от стихийных бедствий. Amazon и Google, например, используют множество огромных центров обработки данных, расположенных по всему миру, чтобы поддержать свои предложения.

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

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

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

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

Компоненты решения на основе облака

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

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

Типичные примеры компонентов решения включают в себя:

• Веб-браузеры
• Мобильные устройства и планшеты
• Серверы API
• Веб и статические серверы сайта
• Контейнерные серверы (напр., Docker)
• Серверы хостинг услуг, например, сервер очередей сообщений
• Бессерверные вычисления (напр., AWS Lambda)
• Сетевые серверы (напр., серверы доменных имен или DNS)
• Балансировщики нагрузки
• Сеть доставки контента (CDN)
• Поставщики идентификационной информации (IdP)
• Исходный код и билд-серверы
• Серверы электронной почты
• Планировщик заданий
• Накопители данных и системы управления базами данных
  • Хранилище данных транзакции (TDS/OLTP)
  • Хранилище основных данных
  • Хранилище оперативных данных
  • Витрина данных
  • Информационное хранилище
  • Озеро данных
  • RDBMS
  • NoSQL/NewSQL DBMS
• Большие данные
  • Сбор данных, извлечение, прием и интеграция
    • Программное обеспечение, базы данных, датчик, событие, и управляемые сообщениями компоненты.
  • Обработка данных и преобразование
  • Доступ к данным
  • Бизнес-аналитика, визуализация данных, информационные панели и отчеты
  • Продвинутая аналитика, интеллектуальный анализ данных, машинное обучение и искусственный интеллект

Функциональные и нефункциональные цели и требования

Первый шаг при разработке полного решения — определение функциональных и нефункциональных целей и требований.

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

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

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

Ниже приведен список некоторых общих нефункциональных требований. Отдельные из них будут обсуждаться более подробно позже.

• Производительность
• Масштабируемость
• Ремонтопригодность
• Повторное использование
• Компонуемость
• Модульность и слабая связанность
• Расширяемость
• Высокое качество
• Минимальный технический долг
• Простота
• Контролепригодность
• Простота развертывания и непрерывность доставки
• Дальнейшая устойчивость

Разделение интересов

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

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

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

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

Аналогичный принцип относится к объектно-ориентированному дизайну и программированию и известен, как общие шаблоны назначения ответственности или GRASP. GRASP — набор принципов для назначения ответственности классам и объектам.

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

Однако, разделение проблем не распространяется на основание кода программного приложения. Этот принцип применим к аппаратным средствам, облачным компонентам, созданию сетей (напр., модели OSI и IP), услугам и так далее. Многие архитектуры и темы, обсуждаемые в этой серии, мотивированы SoC.

Резюме

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

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

Original