10,99 €
Mehr erfahren.
- Herausgeber: Питер
- Kategorie: Wissenschaft und neue Technologien
- Sprache: Russisch
Облачные вычисления — это, пожалуй, наиболее революционная разработка в IT со времен виртуализации. Облачно-ориентированные архитектуры обеспечивают большую гибкость по сравнению с системами предыдущего поколения. В этой книге продемонстрированы три важнейших аспекта развертывания современных cloud native архитектур: организационное преобразование, модернизация развертывания, паттерны облачного проектирования. Книга начинается с краткого знакомства с облачно-ориентированными архитектурами — на примерах объясняется, какие черты им присущи, а какие нет. Вы узнаете, как организуется внедрение и разработка облачных архитектур с применением микросервисов и бессерверных вычислений как основ проектирования. Далее вы изучите такие столпы облачно-ориентированного проектирования, как масштабируемость, оптимизация издержек, безопасность и способы достижения безупречной эксплуатационной надежности. В заключительных главах будет рассказано о различных общедоступных архитектурах cloud native, — от AWS и Azure до Google Cloud Platform. Прочитав эту книгу, вы освоите приемы, необходимые для перехода на облачно-ориентированные архитектуры с учетом требований вашего бизнеса. Вы также узнаете о перспективных тенденциях в сфере облачных сервисов и векторах развития облачных провайдеров.
Das E-Book können Sie in Legimi-Apps oder einer beliebigen App lesen, die das folgende Format unterstützen:
Seitenzahl: 397
Veröffentlichungsjahr: 2023
Ähnliche
Переводчики К. Синица, С. Черников
Литературный редактор А. Саидов
Корректоры Е. Павлович, Н. Рощина
Том Лащевски, Камаль Арора, Эрик Фарр, Пийум Зонуз
Облачные архитектуры: разработка устойчивых и экономичных облачных приложений. — СПб.: Питер, 2021.
ISBN 978-5-4461-1588-4
© ООО Издательство "Питер", 2021
Все права защищены. Никакая часть данной книги не может быть воспроизведена в какой бы то ни было форме без письменного разрешения владельцев авторских прав.
Оглавление
Предисловие
Цель книги — определить область практического применения облачных вычислений. Это исследование их возможностей, отвечающее на множество вопросов «почему» и «как».
Основная цель облачных технологий состоит в повышении мощности облачных вычислений и возможности заставить приложения работать в облаке так, как они могут это делать на локальных машинах. Книга будет полезна всем, кто имеет отношение к облачным вычислениям, включая разработчиков, конечных пользователей и, таким образом, весь бизнес в целом. Целью ИТ-разработчиков всегда должно быть удовлетворение потребностей бизнеса. Издание поможет ИТ-специалистам составить эффективные планы для достижения этой цели.
Рассмотрим преимущества перехода к облачным технологиям.
• Производительность. Предоставляемый по умолчанию доступ к встроенным функциям облачных сервисов обеспечивает более высокую производительность по сравнению с той, что возможна при использовании внешних функций. Например, вы можете пользоваться системой ввода-вывода, которая работает с функциями автоматического масштабирования и балансировки нагрузки.
• Эффективность. Благодаря своим особенностям облачно-ориентированные приложения позволяют более эффективно использовать базовые ресурсы. Это приводит к повышению производительности и/или снижению эксплуатационных расходов.
• Стоимость. Более эффективные приложения обычно дешевле в эксплуатации. Облачные провайдеры ежемесячно присылают счета в зависимости от количества потребляемых ресурсов, поэтому, если выполнить больше операций с меньшими затратами, можно существенно сэкономить.
• Масштабируемость. Поскольку вы используете приложения, оптимизированные для облачных интерфейсов, то получаете прямой доступ к функциям автоматического масштабирования и балансировки нагрузки облачной платформы.
Чтобы воспользоваться преимуществами облачной платформы, в том числе платформ IaaS (таких как AWS), вы должны проектировать приложения так, чтобы они не были привязаны к конкретному физическому ресурсу. Например, если вы обращаетесь к вводу-выводу напрямую с такой платформы, как Linux, вам необходимо получить доступ к уровню абстракции облака или к его собственным API.
Облака могут обеспечить уровень абстракции или виртуализации между приложением и базовыми физическими (или виртуальными) ресурсами независимо от того, разработаны они для облака или нет. Но этого недостаточно. Если вы собираетесь пользоваться облачными технологиями, вам придется напрямую управлять нужными ресурсами.
Когда архитектура учитывается при проектировании, разработке и развертывании приложения, использование базовых облачных ресурсов может быть на 70 % эффективнее. В результате увеличение эффективности облачных вычислений позволяет сэкономить деньги. Вы платите за используемые ресурсы, поэтому приложения, которые расходуют их наиболее эффективно, работают быстрее и обходятся дешевле в финансовом плане.
Cloud native — это не только приведение кода в соответствие с особенностями конкретного облака, но и изменение подхода к архитектурному проектированию. Такие ориентированные на облако архитектуры могут быть автомасштабированными, распределенными, без сохранения состояния и слабо связанными — и это лишь некоторые из характеристик. Если вы хотите сделать приложения облачно-ориентированными, то прежде, чем начинать рефакторинг кода, постарайтесь переосмыслить его архитектуру.
Затратен ли новый подход к архитектуре приложений по ресурсам и деньгам, рискованнее ли он? Да. Тем не менее соотношение «риск/вознаграждение», как правило, склоняется в сторону вознаграждения, если срок службы приложения составляет от 10 до 15 лет (что справедливо для большинства предприятий). Усилия по реорганизации и рефакторингу приложения с долгосрочным использованием окупятся многократно.
При переносе приложений в облако аргументы более убедительны в отношении подхода cloud native. Для большинства приложений, выбранных для перемещения в облако, преимущества перевешивают затраты, но учитывая, что затраты на рефакторинг в 30 раз больше, чем на простое повторное размещение, предприятия неохотно решаются полностью перейти к такому подходу.
Таким образом, возникает еще один процесс обучения — он будет подобен тому, в ходе которого мы разрабатывали приложения на основе API, ориентированных на такие платформы, как Unix/Linux. Нам пришлось исправлять ошибки, прежде чем мы добились успеха. Подозреваю, что и теперь мы будем следовать той же схеме. Через несколько лет облачная среда станет лучшим из того, что сможет предложить ИТ-индустрия. Однако этого не произойдет, пока мы не ошибемся еще несколько раз. Некоторые вещи остаются неизменными.
Итак, облачно-ориентированные приложения, которые используют облачные архитектуры, — это наш путь? Судя по тому, что вы читаете предисловие к данной книге, вы уже уверены, что это так. Прочитав всю книгу, вы только убедитесь в этом. Когда вы развернете свою первую или вторую архитектуру cloud native, вы на практике увидите, что это так.
Дэвид Линтикум (David Linthicum), главный специалист по облачной стратегии, Deloitte Consulting LLP
В тот момент, когда я пишу эти строки (летом 2018 года), к использованию облачных вычислений уже перешли многие организации. Размещая приложения в облаке, компании могут сократить расходы и перестать зависеть от ресурсов, не связанных с добавленной стоимостью, таких как серверы и сети. Неудивительно, что, по данным RightScale, почти 90 % компаний каким-то образом используют облачные ресурсы.
Однако применение облака просто как дешевого внешнего или виртуализированного центра обработки данных все еще оставляет нерешенной значительную часть облачных вычислений. Применив подход cloud native к системам и архитектурам приложений, компании могут воспользоваться преимуществами гибких и практически неограниченных вычислительных мощностей, систем хранения и сетевых возможностей современного общедоступного облака и тем самым стать намного более полезными для своих клиентов.
Что представляют собой приложения, оптимизированные для выполнения в облаке (cloud native)? В первую очередь они определяются возможностью автоматически масштабироваться при увеличении и снижении нагрузки. Сегодня большинство компаний сосредотачивают максимальное количество серверов в своих центрах обработки данных в ожидании большой нагрузки, а затем следят за тем, чтобы в среднем загрузка их ЦП оставалась на одном уровне. Благодаря использованию функций автоматического масштабирования в облаке приложения могут разрастаться и сокращаться по мере необходимости без вмешательства человека. Если вам нужна повышенная пропускная способность — пожалуйста; если в ней пропала необходимость, то вы ею не пользуетесь и не платите за нее.
Облачное приложение устойчиво к ошибкам и сбоям. Если по какой-то причине аппаратное обеспечение — сервер или маршрутизатор — выходит из строя или в базе данных происходит катастрофическая ошибка, облачное приложение должно обнаружить ошибку и исправить ее, возможно, путем создания нового инстанса1 на другой стойке или даже в другом облачном дата-центре в другом регионе.
Вычисления cloud native ускоряют процессы в ИТ-сфере, что дает о себе знать и в бизнесе, который обслуживается ИТ, а это позволяет специалистам быстрее и с меньшими усилиями внедрять подходы и решения на основе Agile и DevOps. Это дает ИТ-специалистам возможность чаще внедрять новые проекты — до нескольких раз в день — и использовать для большей надежности конвейеры автоматического тестирования. Появляется возможность экспериментировать в облаке, пользуясь машинным обучением и расширенной аналитикой, без необходимости принимать решения о дорогостоящих закупках. Благодаря ускорению в ИТ-сфере компании могут предоставлять своим клиентам более качественные и быстрые решения, привлекать новых клиентов за счет глобальной доступности облака и, возможно, даже менять свои основные бизнес-модели.
Существует множество новых технологий — контейнеров, API-шлюзов, менеджеров событий, инструментов бессерверной обработки данных, — которые при правильной реализации могут дать вам преимущества облачных вычислений. Однако переход к cloud native подразумевает не только технологические, но и организационные и культурные изменения. В частности, переход от каскадной модели развития к гибким (Agile) и бережливым (Lean) подходам, внедрение непрерывной интеграции/непрерывной поставки позволят понять, что такое вообще облачная архитектура.
Внедрение облачных методологий и архитектур имеет множество преимуществ, включая повышение потенциала информационных технологий и, что более важно, эспоненциальное расширение инновационных возможностей для вашего бизнеса. Это делает облачно-ориентированные вычисления неотъемлемым и ведущим фактором внедрения современных облаков.
Настоятельно рекомендую вам прочитать эту книгу. В ней вы найдете примеры создания приложений, которые используют облако по назначению, и откроете новый мир продуманных инновационных решений.
Миха Краль (Miha Kralj), генеральный директор, Cloud Native Architecture, Accenture LLP
1Сервера в терминологии AWS. — Примеч. пер.
Об авторах
Том Лащевски (Tom Laszewski) — ведущий специалист по облачным технологиям, помогавший независимым разработчикам ПО, системным администраторам, создателям стартапов и корпоративным клиентам модернизировать ИТ-системы и разрабатывать инновационные программные решения. Сегодня он возглавляет группу специалистов, отвечающих за стратегию трансформации бизнеса и ИТ ключевых клиентов AWS. Многие из этих клиентов стремятся к модернизации облачных вычислений и цифровой трансформации с использованием архитектур cloud native.
Камаль Арора (Kamal Arora) — автор книг и ведущий специалист с более чем 15-летним опытом работы в сфере ИТ. В настоящее время трудится в Amazon Web Services и возглавляет многопрофильную команду высококвалифицированных архитекторов решений, которые помогают партнерам и корпоративным клиентам переходить в облако. Камаль активно интересуется последними инновациями в облаке и пространстве AI/ML, а также их влиянием на наше общество и повседневную жизнь.
Спасибо моей жене Пунам Ароре за безусловную поддержку и моим близким — Киран, Радживу, Нише, Аарини и Риан — за их постоянную заботу и поддержку. И последнее, но не менее важное: мы скучаем по тебе, папа!
Эрик Фарр (Erik Farr) — ведущий специалист с более чем 18-летним опытом работы в ИТ-индустрии. Он участвовал в разработке передовых облачных технологий и различных корпоративных архитектур, работал с крупнейшими компаниями и системными интеграторами. Сегодня в Amazon Web Services он возглавляет команду опытных архитекторов, которые помогают глобальным партнерам и системным интеграторам создавать собственные облачные архитектуры масштаба предприятия. До работы в AWS Эрик сотрудничал с Capgemini и The Walt Disney Company, которые всегда стремились к созданию чего-то нового для клиентов.
Хотел бы сказать спасибо моей замечательной семье — Стейси, Фэйт и Сидни — за поддержку.
Пийюм Зонуз (Piyum Zonooz) — архитектор решений для глобальных партнеров в Amazon Web Services, где он работает с компаниями из различных отраслей, помогая внедрять облачные технологии и реорганизовывать продукты, делая их полностью облачными. Он возглавлял проекты по анализу TCO, проектированию инфраструктуры, внедрению DevOps и полной трансформации бизнеса. До работы в AWS Пийюм был ведущим архитектором в рамках Accenture Cloud Practice, где руководил крупномасштабными проектами по внедрению облачных технологий. Пийюм окончил Иллинойсский университет в Урбане-Шампейне.
О научном редакторе
Санджив Джайсвал (Sanjeev Jaiswal) — выпускник CUSAT, специалист в области компьютерных технологий, имеет десятилетний опыт практической работы. В основном использует Perl, Python, AWS и GNU/Linux. В сфере его интересов — пен-тестирование, проверка исходного кода, проектирование и реализация механизмов защиты в AWS и проектах облачной безопасности. Он также изучает DevSecOps и автоматизацию безопасности. В свободное время Санджив читает лекции студентам инженерных специальностей и ИТ-специалистам.
Он написал книгу Instant PageSpeed Optimization и выступил соавтором книги Learning Django Web Development.
Хочу поблагодарить свою жену Шалини Джайсвал за то, что всегда была рядом, и своих друзей Ранджана, Ритеша, Микки, Шанкара и Сантоша за их постоянную поддержку.
Введение
Эта книга поможет вам понять основные этапы проектирования, необходимые для построения масштабируемых систем. Вы узнаете, как эффективно планировать ресурсы и технологические стеки для достижения большей безопасности и отказоустойчивости. При этом вы изучите основные архитектурные принципы на реальных примерах. В этой книге применен практический подход с примерами из реальной жизни, которые помогут вам при разработке облачных приложений и эффективном переносе вашего бизнеса в облако.
Для кого эта книга
Эта книга предназначена для архитекторов программного обеспечения, которые заинтересованы в разработке отказоустойчивых, масштабируемых и высокодоступных облачных приложений.
Структура издания
Глава 1 «Введение в архитектуруcloud native». В этой главе рассматриваются достоинства и недостатки архитектур cloud native, связанные с ними мифы, а также возможные сложности работы в облаке.
В главе 2 «Процесс перехода в облако» говорится о том, что значит работать в облаке. Данное явление будет рассмотрено с разных сторон, в том числе будет рассказано о том, как выполнить миграцию из локальной или существующей среды в облако.
Глава 3 «Разработка приложений cloud native» подробно рассматривает разработку архитектур cloud native с использованием микросервисов и бессерверных вычислений.
В главе 4 «Как выбрать технологический стек» рассматривается общая технология, которая используется для создания архитектур cloud native, от приложений с открытым исходным кодом до лицензионного программного обеспечения. Здесь мы будем исследовать торговые площадки, которые могут быть использованы для потребления ресурсов в облаке. Наконец, обсудим процесс закупок и модели лицензирования, распространенные в облаке.
В главе 5 «Масштабируемость и доступность» рассказывается о доступных инструментах/функциях и стратегиях, которые можно использовать при разработке систем cloud native для их масштабирования и обеспечения высокой доступности. В этой главе будет рассмотрено, как работают эти инструменты и/или функции, как они используют приложения cloud native и как их развертывать.
В главе 6 «Безопасность и надежность» обсуждаются модели безопасности, функции, доступные в облаке, подводные камни и лучшие практики, связанные с безопасностью ИТ-систем. В ней также будет рассмотрено, как работают функции безопасности и как они могут помочь пользователям облака развернуть более защищенную среду.
Глава 7 «Оптимизация затрат» описывает модель ценообразования для облачных сред. Мы обсудим подходы к оценке затрат, а также различия между старой и облачной моделями.
В главе 8 «Эксплуатация облачных сервисов» рассказывается об инструментах, процедурах и моделях, обеспечивающих непрерывную работу сред, развернутых в облаке. В этой главе будут изложены организационные модели, стратегии управления и шаблоны развертывания для поддержки работоспособности систем.
Глава 9 «Amazon Web Services» фокусируется на том, чтобы дать представление о возможностях разработки облачных приложений Amazon Web Services.
Глава 10 «Microsoft Azure» посвящена рассмотрению возможностей разработки облачных приложений Microsoft Azure.
Глава 11 «Google Cloud Platform» посвящена ознакомлению с возможностями разработки облачных приложений на Google Cloud Platform.
В главе 12 «А что же дальше? Тенденции развития архитектуры облачных приложений» приведен анализ будущих тенденций и ожиданий от различных облачных провайдеров, работающих на рынке.
Как получить максимальную пользу от книги
1. При чтении книги будет полезен опыт работы с архитектурой программного обеспечения.
2. Следует внимательно изучить все примеры и инструкции, которые приведены в соответствующих местах.
Загрузка файлов примеров кода
Вы можете загрузить файлы примеров кода для этой книги на сайте GitHub по адресу github.com/PacktPublishing/Cloud-Native-Architectures.
Условные обозначения
В этой книге используется ряд условных обозначений.
КодВТексте обозначает фрагменты программного кода в тексте, имена таблиц базы данных, имена папок, имена файлов, расширения файлов, пути, фиктивные URL-адреса, ввод пользователя и обработчики Twitter. Например: «Для обработчика укажите значение lambda_function.lambda_handler».
Блок кода обозначается следующим образом:
print('Loading function') def respond(err, res=None): return {
'statusCode': '400' if err else '200', 'body': err if err else res,
'headers': { 'Content-Type': 'application/json', }, }
Когда мы хотим обратить ваше внимание на определенную часть блока кода, соответствующие строки или элементы выделяются полужирным шрифтом:
print('Loading function')
def respond(err, res=None):
return {
'statusCode': '400' if err else '200',
'body': err if err else res,
'headers': {
'Content-Type': 'application/json',
},
}
Курсивом выделены новые термины и важные понятия.
Таким шрифтом выделены элементы интерфейса, которые вы видите на экране, например, названия пунктов меню или диалоговых окон. Вот пример: «Щелкните на названии API Бессерверная служба погоды, чтобы войти в его конфигурацию».
Так выделены предупреждения или важные заметки.
Советы и хитрости обозначены таким образом.
От издательства
Ваши замечания, предложения, вопросы отправляйте по адресу [email protected] (издательство «Питер», компьютерная редакция).
Мы будем рады узнать ваше мнение!
На веб-сайте издательства www.piter.com вы найдете подробную информацию о наших книгах.
1. Введение в архитектуру cloud native
Распространение облачных вычислений привело к появлению новой парадигмы в разработке, внедрении и обслуживании компьютерных систем. Хотя у этой парадигмы существует много разных названий, наиболее часто используемое — «архитектуры cloud native». В книге мы рассмотрим, что такое архитектуры cloud native, почему они являются новым подходом и бывают разными и как внедряются во многих глобальных компаниях. Как следует из названия, речь идет об облаке и использовании сервисов облачных провайдеров для проектирования этих архитектур с целью решения бизнес-задач новыми, надежными и безопасными способами. Цель этой главы состоит в том, чтобы объяснить и определить, что представляют собой архитектуры cloud native, а также дать представление об их плюсах, минусах и связанных с ними мифах. Мы рассмотрим, что значит cloud native, разберемся с характеристиками и компонентами, которые требуются для этого типа архитектуры, и оценим шаги, которые должна предпринять компания для получения развитой (зрелой) модели.
Что такое архитектуры cloud native
Если вы спросите 100 человек, каково определение термина cloud native, то получите 100 разных ответов. Почему так много? Во-первых, сами облачные вычисления не стоят на месте, поэтому определения, предложенные несколько лет назад, возможно, не совсем соответствуют текущему состоянию облака. Во-вторых, архитектуры cloud native — это совершенно новая парадигма, использующая новые методы решения бизнес-задач, которые обычно могут быть достигнуты только в масштабе облачных вычислений. Наконец, определения могут сильно различаться в зависимости от того, какого специалиста вы просите их дать: архитектора, разработчика, администратора или руководителя, принимающего решения. Итак, что же такое cloud native?
Начнем с общепринятого определения облачных вычислений в соответствии с AWS: «Облачные вычисления — это предоставление вычислительной мощности, хранилища базы данных, приложений и других ИТ-ресурсов по требованию через платформу облачных сервисов по Интернету с оплатой по факту».
Таким образом, в своей основной форме cloud native означает использование сервисов облачных вычислений для разработки решения, однако это только часть того, что требуется для перехода на облачные технологии. Cloud native — это гораздо больше, чем просто использование базовой облачной инфраструктуры, даже если это наиболее востребованная из доступных услуг.
Автоматизация и разработка приложений также играют важную роль в этом процессе. Облако, разработанное на основе API, позволяет реализовывать чрезвычайно широкую автоматизацию и масштабирование, чтобы не только создавать инстансы или конкретные системы, но и развертывать весь корпоративный ландшафт без участия человека. Наконец, критически важным компонентом при создании облачной архитектуры является подход, используемый для разработки конкретного приложения. Системы, созданные с помощью лучших облачных сервисов и развернутые с широкой автоматизацией, могут не приносить желаемых результатов, если логика приложения не учитывает новый масштаб, в котором ему, возможно, придется работать.
Определение модели зрелости cloud native
Нет единственно правильного ответа на вопрос о том, что представляет собой архитектура cloud native, так как к ней могут быть отнесены многие типы архитектур. Используя три принципа, или оси, проектирования — сервисы cloud native, проектирование, ориентированное на приложения, и автоматизацию, — можно оценить большинство систем по уровню зрелости cloud native. Кроме того, эти принципы постоянно расширяются по мере разработки новых технологий, методов или шаблонов проектирования, и поэтому архитектуры cloud native будут продолжать развиваться. Мы, авторы этой книги, считаем, что облачные архитектуры формируются эволюционным путем и соответствуют модели зрелости возможностей (https://ru.wikipedia.org/wiki/Capability_Maturity_Model). В книге архитектуры cloud native будут описываться с помощью модели Cloud Native Maturity Model (CNMM) в соответствии с изложенными принципами проектирования (рис. 1.1).
Ось 1. Облачные сервисы
Чтобы разобраться, как система связана с CNMM, важно выявить компоненты архитектуры cloud native. По определению, cloud native требует использования облачных сервисов. У каждого провайдера облачных вычислений будет свой набор сервисов, причем самые продвинутые обеспечивают самый богатый набор функций. Объединение этих сервисов, от базовых строительных блоков до самых передовых технологий, определит, насколько сложна архитектура cloud native на оси облачных сервисов (рис. 1.2).
Рис. 1.1
Рис. 1.2
Сервисы поставщика развитого облака
Amazon Web Services (AWS) часто называют самой продвинутой облачной платформой (на момент написания книги). На рис. 1.3 показаны все сервисы, которые AWS может предложить, от базовых строительных блоков до предложений по удаленному управлению и использованию продвинутых сервисов платформы.
Рис. 1.3
Компоненты облачных сервисов
Независимо от уровня зрелости, поставщик облачных вычислений всегда предлагает такие возможности, как вычисления, хранение, сетевое взаимодействие и мониторинг. В зависимости от уровня зрелости облака организации и команды, разрабатывающей систему, стоит начать переход в cloud native, используя эти строительные блоки базовой инфраструктуры. Инстансы виртуального сервера, блочное дисковое хранилище, хранилище объектов, волоконно-оптические линии и VPN, балансировщики нагрузки, мониторинг облачного API и мониторинг инстансов — это все типы строительных блоков, которые клиент будет использовать в начале работы с облаком. Аналогично компонентам, доступным в существующем локальном центре обработки данных, эти сервисы позволят командам разработчиков начать знакомство с приложениями в облаке. Применение данных сервисов — это минимум, необходимый для разработки архитектуры cloud native и отражающий относительно низкий уровень на оси сервисов cloud native.
Зачастую компания выбирает миграцию существующего приложения в облако и выполняет ее по модели «поднять и переместить». В этом случае она просто перенесет стек приложений и окружающие компоненты в облако, никак не изменяя дизайн, технологии или архитектуру компонентов. В таких миграциях используются только основные строительные блоки, предлагаемые облаком, поскольку они существуют и в локально затребованных точках клиента. Хотя это низкий уровень зрелости, он важен, так как позволяет получить опыт работы с облаком. Даже при использовании строительных блоков облачных сервисов команда разработчиков быстро добавит свои собственные ограничительные правила, политики и соглашения об именах, чтобы изучить более эффективные методы решения проблем безопасности, развертывания, работы в сети и реализации прочих основных требований к облачно-ориентированным системам.
Одними из основных результатов, которые компания получит на этом этапе зрелости, являются понимание основных свойств облака и того, как эти свойства влияют на методы проектирования, — например, как соотносятся горизонтальное и вертикальное масштабирование, как эти архитектурные решения сказываются на финансовых расходах и как их эффективно реализовать. Кроме того, это позволяет понять, как работает выбранный поставщик облачных сервисов, как он группирует свои сервисы в определенных местах, а также как эти группы взаимодействуют для обеспечения высокой доступности и аварийного восстановления с помощью существующей архитектуры. Наконец, изучение облачного подхода к хранилищу и возможность передачи обработки в облачные сервисы, которые эффективно и естественно масштабируются на платформе, — критически важный подход к проектированию архитектур. Несмотря на то что использование строительных блоков облачных сервисов говорит об относительно низком уровне зрелости, оно очень важно для компаний, которые только начинают свою деятельность в облачной инфраструктуре.
Предложения поставщиков, предоставляющих облачные сервисы
Недифференцированная рутинная работа — так часто можно описать ситуацию, когда время, усилия, ресурсы или деньги затрачиваются на выполнение задач, которые не приносят прибыли компании. Термин «недифференцированный» означает, что не существует методов различить разные способы выполнения данной работы. Рутинной работой можно назвать решение сложных технологических и эксплуатационных задач, которые, если все сделано правильно, никто никогда не распознает, а их неправильное выполнение может привести к катастрофическим последствиям для бизнес-операций. Эта фраза в совокупности означает, что компания решает сложные задачи, неправильное выполнение которых может повлиять на бизнес, но в то же время ее специалисты не понимают, как все сделать правильно, что не только не приносит пользы бизнесу, но и может легко ему навредить.
К сожалению, такое положение вещей характерно для подавляющего большинства задач ИТ-отделов в корпоративных компаниях и в то же время является важным аргументом за использование облака. Поставщики облачных услуг разбираются в технологических инновациях и эксплуатации крупномасштабных систем так хорошо, как в большинстве компаний и не мечтали. Таким образом, имеет смысл только то, что поставщики облачных услуг усовершенствовали свои сервисы, включив в них удаленно управляемые решения, которые находятся под их полным контролем, а потребителю нужно лишь разработать бизнес-логику или данные, развертываемые в сервисе. Это дает возможность переложить выполнение недифференцированной рутинной работы на поставщика облачных услуг и позволяет компании выделять значительно больше ресурсов для увеличения ценности бизнеса (его отличия от конкурирующих продуктов).
Как мы уже видели, существует множество комбинаций облачных сервисов, которые можно использовать для проектирования собственных архитектур облаков с помощью только базовых строительных блоков и шаблонов. Но, когда команда разработчиков станет лучше понимать, какие сервисы имеются у выбранного поставщика облачных вычислений, и более обдуманно подходить к их выбору, она, несомненно, захочет использовать более усовершенствованные облачные сервисы. Продвинутые поставщики облачных решений будут предлагать сервисы, которые способны заменить компоненты, требующие недифференцированной рутинной работы. В число удаленно управляемых решений, которые предлагают поставщики облачных услуг, входят следующие:
• базы данных;
• Hadoop2;
• службы каталогов;
• балансировщики нагрузки;
• системы кеширования;
• хранилища данных;
• репозитории кода;
• инструменты автоматизации;
• поисковая система Elastic.
Еще одна важная характеристика этих сервисов — гибкость, которую они привносят в решение. Если система спроектирована для использования данных инструментов, но управляется командой эксплуатации, то зачастую процесс предоставления виртуального инстанса, конфигурации, настройки и обеспечения безопасности проекта значительно замедляет прогресс, достигнутый группой разработчиков. Использование сервисов, удаленно управляемых поставщиком облачных услуг, вместо этих компонентов с самостоятельным управлением позволит командам быстро внедрить архитектуру и начать тестирование приложений, которые будут работать в этой среде.
Использование сервисов, предлагаемых поставщиком облачных вычислений, не обязательно усложняет шаблоны архитектуры, однако позволяет мыслить шире и не ограничиваться рутинной работой. Концепция отсутствия локальных ограничений, например ограниченных физических ресурсов, является критическим атрибутом проектирования при создании облачных архитектур, которые позволят системам достичь масштаба, недостижимого другими способами. Вот, например, отдельные области, в которых применение сервисов, управляемых поставщиком облачных услуг, может обеспечить лучше масштабируемую собственную облачную архитектуру:
• использование управляемых балансировщиков нагрузки для разделения компонентов в архитектуре;
• применение управляемых систем хранилищ данных для предоставления только необходимых объемов хранилищ и автоматического масштабирования при импорте большего количества данных;
• использование управляемых РСУБД, которые обеспечивают быструю и эффективную обработку транзакций и при этом изначально обладают устойчивостью и высокой доступностью.
Современные облачные сервисы
Поставщики облачных сервисов развивают свой бизнес и продолжают совершенствовать предложения, позволяя решать с их помощью еще более сложные задачи. Нынешняя волна инноваций, внедряемых ведущими поставщиками облачных вычислений, предполагает дальнейшее увеличение количества сервисов, при этом поставщик управляет их масштабами и безопасностью и снижает стоимость, сложность и риски для клиента. Один из способов достижения этого — реорганизация существующих технологических платформ таким образом, чтобы они не просто решали конкретные технические проблемы, но и делали это с учетом преимуществ облачных вычислений. Например, в AWS есть сервис управляемых СУБД Amazon Aurora, построенный на полностью распределенном и самовосстанавливающемся хранилище, предназначенном для обеспечения безопасности данных и их распределения по нескольким зонам доступности. Этот сервис повышает полезность предложений управляемых сервисов, специфичных для СУБД, как описано в предыдущем подразделе, позволяя также создавать массив хранилищ, который увеличивается по требованию и настраивается для облака, чтобы обеспечить производительность, в пять раз бо'льшую, чем дают аналогичные движки СУБД.
Не все современные удаленно управляемые сервисы представляют собой переработку существующих технологий. С внедрением бессерверных вычислений поставщики облачных технологий убирают недифференцированную рутинную работу не только из процесса эксплуатации, но и из разработки. Поскольку облако может предложить практически безграничные ресурсы, разделение крупных приложений на отдельные функции является следующей большой волной проектирования распределенных систем и ведет непосредственно к формированию архитектур cloud native.
По данным AWS, «бессерверные вычисления позволяют создавать и запускать приложения и сервисы, не задумываясь о серверах. Бессерверные приложения не требуют от вас подготовки и масштабирования каких-либо серверов и управления ими. Вы можете создавать их практически для любого типа приложения или серверной службы, и все, что требуется для запуска и масштабирования вашего приложения, а также обеспечения высокой доступности, выполняется за вас».
Существует много видов бессерверных решений, включая сервисы для вычислений, обработки сообщений и оркестрации, прокси-серверы для API, хранилища, базы данных, средства анализа и инструменты разработчика. Один из ключевых атрибутов, определяющих, является ли облачный сервис бессерверным или только управляемым предложением, — это способ оценки его лицензирования и использования. Бессерверный подход позволяет отказаться от прежней централизованной модели ценообразования, привязанной непосредственно к отдельным серверам, и сделать основной упор на потребление. Время, в течение которого выполняется функция, требуемое количество транзакций в секунду или их комбинация являются общими показателями, которые используются для ценообразования на основе потребления с предложениями без серверов.
Использование усовершенствованных облачных сервисов с собственным управлением и дальнейшее внедрение новых по мере их выпуска показывает высокий уровень зрелости CNMM и позволяет компаниям разрабатывать самые современные облачные архитектуры. Благодаря данным сервисам и опытной команде разработчиков компания сможет выйти за рамки возможного, когда будут устранены существовавшие ранее ограничения и реализованы действительно безграничные и гибкие возможности. Например, вместо традиционного трехуровневого распределенного вычислительного стека, состоящего из внешнего интерфейса, приложений или промежуточного программного обеспечения и системы оперативной обработки транзакций БД, новый подход к этому шаблону проектирования позволит ввести шлюз API, который использует вычислительный контейнер, управляемый событиями, в качестве конечной точки и управляемую и масштабируемую СУБД NoSQL для хранения. Все эти компоненты могут попасть в бессерверную модель, что дает возможность команде разработчиков сосредоточиться на бизнес-логике, а не на том, как достичь требуемого масштаба.
За бессерверными и другими продвинутыми удаленно управляемыми сервисами будущее. В настоящее время передовые технологии облачных вычислений — это предложения, выпускаемые в областях искусственного интеллекта, машинного и глубокого обучения. У поставщиков развитых облачных сервисов есть сервисы, которые подпадают под эти категории, а постоянные инновации происходят в гипермасштабе. Мы все еще находимся на раннем этапе развития искусственного интеллекта, но команды разработчиков должны думать наперед.
Обзор оси облачных сервисов
В разделе «Ось 1. Облачные сервисы» описаны компоненты, которые могут составить облачную архитектуру, и продемонстрированы современные подходы к созданию приложений и их использованию. Как и в случае с любыми принципами проектирования в CNMM, разработка начинается с понимания основной идеи и продвигается по мере того, как команда разработчиков все лучше овладевает методами проектирования крупномасштабных систем. Однако применение компонентов облачных вычислений — это лишь один из принципов проектирования, необходимых для создания развитой архитектуры cloud native. Они применяются в сочетании с двумя другими принципами — автоматизацией и ориентированностью на приложения для создания систем, которые могут безопасно и надежно использовать преимущества облака.
Ось 2. Проектирование, ориентированное на приложения
Второй принцип облачных технологий заключается в том, как будет спроектировано и разработано само приложение. В этом разделе основное внимание будет уделено фактическому процессу разработки приложений, а также будут определены приемы, которые позволяют создавать собственные облачные архитектуры. Подобно другим способам проектирования CNMM, разработка приложений cloud native — это постепенный процесс с применением разных подходов, которые обычно сменяют друг друга. В конечном итоге при использовании и других принципов CNMM результатом будет сложная и надежная облачная архитектура с богатыми возможностями, которая способна развиваться по мере совершенствования мира облачных вычислений (рис. 1.4).
Рис. 1.4
Принципы проектирования 12-факторных приложений
«Двенадцатифакторное приложение» — это методология создания приложений программного обеспечения в виде сервисов, называемых веб-приложениями (web apps) или software-as-a-service (SaaS) (https://12factor.net/). Эта методология была предложена в конце 2011 года, и ее факторы часто называют базовыми строительными блоками для разработки масштабируемых и надежных приложений cloud native. Ее принципы применяются к приложениям, написанным на любом языке программирования и использующим любую комбинацию вспомогательных сервисов (база данных, очередь, кэш-память и т.д.), они становятся все более полезными на любой платформе облачного поставщика. Идея, лежащая в основе 12-факторного приложения, заключается в том, что при разработке приложений необходимо учитывать 12 важных факторов, которые сводят к минимуму время и затраты на добавление новых разработчиков, обеспечивают возможность чистого взаимодействия со средой, позволяют развернуть приложение у поставщиков облачных сервисов, способны минимизировать расхождения между средами и разрешить масштабирование приложения. В следующей таблице перечислены эти двенадцать факторов (https://12factor.net/).
№ п/п
Фактор
Описание
1
Кодовая база
Одна кодовая база, отслеживаемая в системе контроля версий, — множество развертываний
2
Зависимости
Явно объявляйте и изолируйте зависимости
3
Конфигурация
Сохраняйте конфигурацию в среде выполнения
4
Вспомогательные сервисы
Считайте вспомогательные сервисы подключаемыми ресурсами
5
Сборка, релиз, выполнение
Строго разделяйте стадии сборки и выполнения
6
Процессы
Запускайте приложение как один или несколько процессов, не сохраняющих внутреннее состояние (stateless)
7
Привязка портов
Экспортируйте сервисы через привязку портов
8
Параллелизм
Масштабируйте приложение с помощью процессов
9
Утилизируемость
Максимизируйте надежность с помощью быстрого запуска и корректного завершения работы
10
Паритет разработки/работы приложения
Делайте среды разработки, промежуточного и рабочего развертывания максимально похожими
11
Ведение журнала
Считайте журнальные записи потоком событий
12
Задачи администрирования
Выполняйте задачи администрирования/управления с помощью разовых процессов
В предыдущих разделах этой главы уже обсуждалось, как CNMM учитывает несколько факторов из этой методологии. Например, фактор 1 — хранение базы кода в репозитории — лучшая стандартная практика. Факторы 3, 10 и 12 основаны на разделении сред, но при этом они не должны отделяться друг от друга с точки зрения кода и конфигурации. Фактор 5 гарантирует, что у вас есть чистый и повторяемый конвейер CICD с разделением функций. А фактор 11 касается обработки журналов как потоков событий таким образом, чтобы их можно было анализировать и обрабатывать практически в реальном времени. Остальные факторы хорошо согласуются с разработкой облака по той простой причине, что они сосредоточены на том, чтобы быть автономными (фактор 2), рассматривать все как услугу (факторы 4 и 7), обеспечивать эффективное масштабирование (факторы 6 и 8) и корректно обрабатывать неисправности (фактор 9). Разработка приложения с использованием 12-факторной методологии — не единственный способ создания нативных облачных архитектур. Тем не менее он предлагает стандартизированный набор принципов, которые, если их придерживаться, позволят приложению стать более развитым согласно CNMM.
Монолитная, сервис-ориентированная и микросервисная архитектуры
Шаблоны проектирования архитектур постоянно развиваются с применением последних технологических инноваций. Монолитные архитектуры были популярными на протяжении длительного времени, во многом благодаря высокой стоимости физических ресурсов и низким темпам. Эти шаблоны хорошо подходят для рабочих компьютеров и мейнфреймов, и даже сегодня существует множество приложений, работающих как монолитные архитектуры. Поскольку технологические процессы и бизнес-требования стали более сложными, а скорость выхода на рынок приобретает все большее значение, для поддержки этих требований были развернуты дополнительные монолитные приложения. В конце концов, эти монолитные приложения должны были взаимодействовать друг с другом, чтобы обмениваться данными или выполнять функции, которые имелись в других системах. Это взаимодействие стало предшественником ориентированных на сервисы архитектур (SOA), которые позволили командам разработчиков создавать меньшие по сравнению с монолитными компоненты приложений, внедрять компоненты промежуточного программного обеспечения для поддержания связи и исключать возможность доступа к компонентам иначе, кроме как через специальные конечные точки. Проекты SOA приобрели все большую популярность во время бума виртуализации, поскольку развертывание сервисов на виртуализированном оборудовании стало проще и дешевле.
Сервис-ориентированные архитектуры состоят из двух или более компонентов, которые предоставляют свои сервисы другим сервисам через специальные протоколы связи. Последние часто называют веб-сервисами, они состоят из нескольких общих протоколов (WSDL, SOAP и RESTful HTTP) в дополнение к протоколам обмена сообщениями, таким как JMS. По мере роста сложности различных протоколов и сервисов все шире распространялось использование сервисной шины предприятия (enterprise service bus, ESB) в качестве промежуточного уровня. Это позволило сервисам изолировать свои конечные точки, и сервисная шина предприятия могла позаботиться о переводах сообщений из различных источников, чтобы получить правильно отформатированный вызов желаемой системы. Хотя этот подход упростил взаимодействие между сервисами, он в то же время добавил сложности логике промежуточного программного обеспечения, необходимой для преобразования вызовов сервисов и обработки рабочих процессов. Это часто приводило к созданию весьма сложных SOA-приложений, в которых код приложения для каждого из компонентов необходимо было развертывать одновременно, что приводило к «большому взрыву» и рискованному масштабному развертыванию в составном приложении.
Подход SOA положительно повлиял на проблемные последствия непредвиденных изменений, которые изначально имели монолитные архитектуры, путем разделения основных компонентов на отдельные приложения. Однако появилась проблема сложности развертывания. Она проявлялась в том, что вызывала так много взаимозависимостей, что часто требовалось одно большое развертывание для всех приложений SOA. В результате эти рискованные развертывания — «большой взрыв» — часто предпринимались лишь несколько раз в год, а резкое снижение скорости замедляло выполнение бизнес-требований. По мере того как облачные вычисления стали более распространенными, а ограничения локальных сред начали постепенно исчезать, появился новый архитектурный шаблон — микросервисы. Действуя через облако, команды разработчиков приложений больше не должны были ждать месяцами, чтобы получить вычислительные возможности для тестирования своего кода, также они не были ограничены физическими ресурсами.
Стиль архитектуры микросервисов имеет ту же распределенную природу, что и SOA, только сервисы делятся на еще более обособленные и слабо связанные прикладные функции. Микросервисы не только уменьшают последствия непредвиденных изменений, даже дополнительно изолируя функции, но и значительно увеличивают скорость развертывания приложений, рассматривая каждую микросервисную функцию как собственный компонент. Деятельность небольшой группы специалистов DevOps, ответственной за конкретный микросервис, позволит осуществлять непрерывную интеграцию и непрерывную доставку кода небольшими порциями, что увеличивает скорость и обеспечивает быстрый откат в случае непредвиденных проблем, возникающих в сервисе.
Микросервисы и облачные вычисления хорошо сочетаются друг с другом, и зачастую микросервисы считаются наиболее развитым типом архитектуры cloud native на данный момент. Причина такой хорошей сочетаемости заключается в том, что поставщики облачных услуг часто разрабатывают их в виде отдельных строительных блоков, которые можно использовать различными способами для достижения бизнес-результата. Подход, основанный на стандартных блоках, дает командам разработчиков приложений возможность комбинировать и сопоставлять сервисы для решения своих проблем, вместо того чтобы применять конкретный тип хранилища данных или язык программирования. Это привело к увеличению числа инноваций и шаблонов проектирования, использующих преимущества облака, таких как бессерверные вычислительные сервисы, скрывающих управление ресурсами от команд разработчиков, что позволяет им сосредоточиться на бизнес-логике.
Особенности облачно-ориентированного проектирования
Независимо от используемой методологии или облачно-ориентированного шаблона проектирования, который в итоге реализуется, существуют определенные характеристики, которые должны быть общими для всех облачно-ориентированных архитектур. Не все из этих характеристик необходимо рассматривать в контексте облачных архитектур, однако их реализация делает систему более развитой, поэтому они находятся на более высоком уровне CNMM. К таким характеристикам относятся инструментарий, безопасность, распараллеливание, отказоустойчивость, управляемость событиями и забота о будущем.
• Инструментарий. Включение инструментария приложения — это больше чем просто анализ потоков журналов. Для этого требуется способность контролировать и измерять производительность приложения в режиме реального времени. Добавление инструментария напрямую приведет к тому, что приложение сможет распознавать условия задержки, сбои компонентов из-за сбоев системы и другие характеристики, важные для конкретного бизнес-приложения. Инструментарий имеет решающее значение для многих других соглашений разработки, поэтому включение его в качестве объекта первого класса в приложение принесет выгоду в долгосрочной перспективе.
• Безопасность. Все приложения нуждаются во встроенной защите. Тем не менее проектирование архитектуры безопасности в cloud native имеет решающее значение для обеспечения использования приложением в своих интересах сервисов безопасности облачных поставщиков, а также сторонних сервисов безопасности на всех уровнях. Это позволит повысить защиту приложения и уменьшить степень поражения в случае атаки или взлома.
• Распараллеливание. Производительность приложения в ходе масштабирования зависит непосредственно от его способности выполнять отдельные процессы параллельно. Это предусматривает возможность параллельного выполнения одного и того же набора функций или одновременное выполнение множества различных функций в приложении.
• Отказоустойчивость. Важно учитывать, как приложение будет обрабатывать неисправности и в каком объеме при этом продолжать работать. Использование инноваций поставщиков облачных услуг, таких как развертывание в нескольких физических центрах обработки данных, применение нескольких разделенных уровней приложения, а также автоматизация запуска, завершения работы и миграции компонентов приложения между местоположениями поставщиков — все это способы обеспечения отказоустойчивости приложения.
• Управляемость событиями. Приложения, управляемые событиями, могут использовать методы, которые анализируют события для выполнения действий, будь то бизнес-логика, изменение отказоустойчивости, оценка безопасности или автоматическое масштабирование компонентов приложения. Все события регистрируются и анализируются с помощью передовых методов машинного обучения, что позволяет применять дополнительную автоматизацию при выявлении новых событий.
• Забота о будущем. Размышления о будущем — это важнейший способ гарантировать, что приложение будет развиваться в соответствии с CNMM с течением времени и появлением инноваций. Реализация этих соображений поможет ему стать перспективным. Однако все приложения должны быть оптимизированы с помощью автоматизации и постоянных улучшений кода, чтобы всегда иметь возможность обеспечить требуемые бизнес-результаты.
Обзор оси проектирования, ориентированного на приложения
Существует много различных методологий, которые можно использовать для создания облачного приложения, включая микросервисы, шаблоны проектирования 12-факторных приложений и соглашения облачного проектирования. Не существует единого правильного пути разработки облачных приложений, и, как и любые фрагменты CNMM, они будут развиваться по мере появления новых соглашений. Приложение достигнет максимального уровня развития для данной оси, как только будут реализованы большинство этих принципов проектирования.
Ось 3. Автоматизация
Третий и последний принцип cloud native — это автоматизация. В этой главе подробно обсуждались и объяснялись другие принципы CNMM, в частности, почему использование облачных сервисов и проектирование, ориентированное на приложения, позволяют архитектурам cloud native становиться более масштабными. Однако сами по себе они не дают возможности системе действительно использовать все преимущества облака. Если бы система была разработана с использованием самых современных сервисов, но эксплуатация приложения выполнялась вручную, было бы трудно понять, для чего она предназначена. Этот тип автоматизации часто называют «инфраструктура как код» (Infrastructure as Code, IaC), и он эволюционирует, позволяя создавать сложные архитектуры cloud native. Поставщики облачных услуг обычно разрабатывают все свои сервисы так, чтобы они были конечными точками API, что позволяет программным вызовам создавать, изменять или уничтожать сервисы. Этот подход — движущая сила IaC. Для сравнения, раньше команда эксплуатации отвечала не только за проектирование и конфигурирование инфраструктуры, но и за физическую настройку и развертывание компонентов.
Благодаря автоматизации IaC команды эксплуатации теперь могут сосредоточиться на разработке приложений и полагаться на поставщика облачных услуг в том, чтобы справиться с недифференцированной рутинной работой при распределении ресурсов. Инфраструктура как код затем обрабатывается, как любой другой артефакт развертывания для приложения, хранится в репозиториях исходного кода и поддерживается для обеспечения долгосрочной согласованности наращивания среды. Степень автоматизации по-прежнему высока, причем на ранних этапах основное внимание уделялось созданию среды, настройке ресурсов и развертыванию приложений. По мере развития решения автоматизация будет совершенствоваться, включая в себя более развернутый мониторинг, масштабирование и повышение производительности, и в конечном итоге будет предусматривать аудит, соблюдение нормативных требований, управление и оптимизацию всего решения. На следующем этапе при автоматизации самых передовых архитектур используются искусственный интеллект, а также методы машинного и глубокого обучения для самовосстановления и самостоятельного управления системой с целью изменения ее структуры в зависимости от текущих условий.
Автоматизация — это ключ к обеспечению масштабирования и безопасности, необходимых для облачной архитектуры (рис. 1.5).
Рис. 1.5
Управление средой, конфигурация и развертывание
Проектирование и развертывание приложения в облаке, а также управление им сложны, так как все системы должны быть настроены и сконфигурированы. Эти процессы можно упростить и согласовать путем реализации процессов создания и настройки среды в виде кода. Существует множество облачных сервисов и ресурсов, которые выходят далеко за рамки традиционных серверов, подсетей и физического оборудования, управляемых локально. На этом этапе оси автоматизации основное внимание уделяется предоставлению среды на основе API, конфигурации системы и развертыванию приложений, что позволяет клиентам использовать код для выполнения этих повторяющихся задач.
Независимо от того, является ли решение крупной и сложной реализацией для корпоративной компании или относительно простым развертыванием системы, применение автоматизации для управления согласованностью имеет решающее значение при создании архитектурыcloud native. Для больших и сложных решений или в тех случаях, когда нормативные требования включают необходимость разделения обязанностей, компании могут использовать подход, называемый «инфраструктура как код» (IaC), чтобы разделить разные команды эксплуатации и сосредоточить их внимание только на определенной области, например на базовой инфраструктуре, создании сетей, безопасности и мониторинге. В других случаях все компоненты может обрабатывать одна команда, возможно, даже команда разработчиков, если используется модель DevOps. Независимо от того, как развивается IaC, важно в ходе этого процесса обеспечить гибкость и согласованность, частое развертывание систем и точное соблюдение требований проектирования.
Существует множество способов управления системой с помощью IaC. В некоторых случаях каждый раз, когда происходит изменение среды, полная автоматизация IaC реализуется для замены существующей среды. Это называется неизменяемой инфраструктурой, поскольку системные компоненты никогда не обновляются, а каждый раз заменяются новой версией или конфигурацией. Это позволяет компании уменьшить влияние среды или конфигурации и обеспечивает строгий способ подтверждения корректности процессов администрирования и уменьшения проблем безопасности, которые могут появиться при реализации вручную.
Несмотря на то что подход с неизменяемой инфраструктурой имеет свои преимущества, может оказаться нереально каждый раз заменять среду полностью, поэтому необходимо вносить изменения на уровне конкретных компонентов. При таком подходе автоматизация все еще имеет решающее значение для обеспечения согласованной реализации, однако это сделает облачные ресурсы изменяемыми или даст им возможность меняться со временем. Существует множество поставщиков, у которых есть продукты для обеспечения автоматизации на уровне инстанса, и большинство поставщиков облачных услуг имеют управляемые предложения для обеспечения этого типа автоматизации. Эти инструменты позволят запускать код или сценарии в среде для внесения изменений. Такие сценарии будут частью инфраструктуры как артефакты развертывания кода и станут разрабатываться и поддерживаться так же, как набор неизменяемых сценариев.
Управление средой и ее конфигурация — не единственный способ автоматизации на базовом уровне. Развертывание кода и гибкость также очень важны для обеспечения полностью автоматизированной архитектуры cloud native. На рынке существует множество инструментов, позволяющих автоматизировать весь конвейер развертывания, часто называемый непрерывной интеграцией, непрерывным развертыванием (CICD). Конвейер развертывания кода часто включает в себя все аспекты процесса, от регистрации кода, автоматической компиляции с анализом кода, упаковки и развертывания до применения конкретных сред для обеспечения чистого развертывания. Используемые по принципу «инфраструктура как код», конвейеры CICD обеспечивают архитектуре cloud native исключительную гибкость и согласованность.
Мониторинг, соблюдение нормативных требований и оптимизация с помощью автоматизации
Архитектуры cloud native, которые используют сложные сервисы и охватывают несколько географических регионов, требуют возможности часто меняться в зависимости от шаблонов использования и других факторов. Применение автоматизации для мониторинга всего диапазона решения, обеспечения соответствия стандартам компании или нормативным требованиям, а также постоянной оптимизации использования ресурсов демонстрирует растущий уровень зрелости. Как и при любой эволюции, построение на предыдущих этапах зрелости дает возможность задействовать передовые методы, которые позволяют повысить масштабность решения.
Одними из наиболее важных сведений, которые можно собрать, являются данные мониторинга, которые поставщики облачных технологий будут включать в свои предложения. У серьезных поставщиков облачных услуг сервисы мониторинга встроены в их сервисы, они способны собирать показатели, события и журналы этих сервисов, которые в противном случае были бы недоступны. Использование таких сервисов мониторинга для запуска основных событий — это тип автоматизации, который обеспечивает общее состояние системы. Например, система, задействующая парк вычислительных виртуальных машин в качестве логического уровня компонента сервиса, обычно ожидает определенного количества запросов, но периодически всплеск числа запросов приводит к быстрому увеличению нагрузки на ЦП и росту сетевого трафика в этих инстансах. При правильной настройке сервис облачного мониторинга обнаружит это увеличение и запустит дополнительные инстансы, чтобы выровнять нагрузку до более приемлемых уровней и обеспечить надлежащую производительность системы. Запуск дополнительных ресурсов обусловлен проектной конфигурацией системы, для которой требуется автоматизация IaC, чтобы гарантировать, что новые инстансы будут развернуты с использованием таких же точно конфигурации и кода, что и все остальные в кластере. Этот тип деятельности часто называют автоматическиммасштабированием, он действует и в обратном порядке, удаляя инстансы после того, как число запросов уменьшилось.
Автоматизация соответствия конфигураций среды и системы становится все более важной для крупных корпоративных клиентов. Включение автоматизации в постоянные аудиторские проверки соответствия между компонентами системы показывает высокий уровень зрелости по оси автоматизации. Сервисы для получения моментальных снимков конфигурации позволяют создать подробную картину структуры среды и хранятся в виде текста, что дает возможность долгосрочного анализа. Используя автоматизацию, такие снимки можно сравнить с предыдущими представлениями о среде, чтобы убедиться, что конфигурация не изменилась. Вдобавок текущий снимок можно сравнить с требующимися и совместимыми конфигурациями, которые будут соответствовать требованиям аудита в отраслях, регулируемых законодательством.
Оптимизация облачных ресурсов — это область, которую легко проигнорировать. Система была спроектирована до появления облака, и оценивалась емкость, необходимая для работы этой системы в пиковых условиях. Поэтому еще до того, как система была создана, было куплено дорогое и сложное аппаратное и программное обеспечение. Из-за этого часто случалось, что значительная часть избыточной емкости простаивала в ожидании увеличения количества запросов. При использовании облака эта проблема почти исчезает, однако разработчики системы все еще сталкиваются с ситуациями, когда неизвестно, какая емкость потребуется. Для решения этой проблемы можно использовать автоматическую оптимизацию, чтобы постоянно проверять все компоненты системы и, оценивая исторические тренды, понимать, чрезмерна или недостаточна нагрузка на эти ресурсы. Можно добиться этого с помощью автоматического масштабирования, однако есть намного более сложные способы, которые, будучи правильно реализованными, обеспечат дополнительную оптимизацию. Например, автоматизированная проверка запущенных инстансов во всех средах на предмет неиспользуемой емкости и их отключение или аналогичная проверка для выключения всех сред разработки по ночам и выходным могут сэкономить компании много денег.
Одним из ключевых способов получения развитой облачной архитектуры с точки зрения мониторинга, соблюдения нормативных требований и оптимизации является использование обширной инфраструктуры ведения журналов. Загрузка данных в эту среду и анализ этих данных для принятия решений — сложная задача, и проектная группа должна хорошо понимать, как работают различные компоненты, и обеспечить постоянный сбор всех необходимых данных. Такого рода инфраструктура помогает избавиться от мысли, что журналы — это файлы, которые нужно собирать и хранить, и начать думать о них как о потоках событий, которые следует анализировать в реальном времени на предмет каких-либо аномалий. Например, довольно быстрым способом реализации каркаса журналирования было бы использование ElastiCache, Logstash и Kibana, часто называемого стеком ELK, для захвата всех типов событий системного журнала, событий журнала сервисов облачных поставщиков, а также других журналов событий.
Прогнозная аналитика, искусственный интеллект, машинное обучение и не только
По мере того как система развивается и становится все более глубоко автоматизированной, она все больше полагается на данные, которые сама генерирует для анализа и обработки. Подобно проекту мониторинга, соответствия и оптимизации, рассмотренному ранее, развитая облачная архитектура будет постоянно анализировать потоки событий журнала для выявления аномалий и неэффективности, однако признаком наибольшей зрелости становится использование искусственного интеллекта (AI) и машинного обучения (ML) для прогнозирования того, как события могут повлиять на систему, и внесения корректировок, предотвращающих снижение производительности, безопасности или других показателей эффективности бизнеса. Чем обширнее круг разнородных источников, из которых поступают данные о событиях, и чем дольше они сохраняются, тем больше исходных данных для принятия мер будут получать эти инструменты.
Используя строительные блоки автоматизации, обсуждавшиеся ранее, в сочетании с AI и ML, система получает множество возможностей решить проблему, которая может повлиять на бизнес.
Данные важны, когда дело доходит до прогнозной аналитики и машинного обучения. Бесконечный процесс обучения системы классификации событий требует времени, данных и автоматизации. Основой методов AI и ML является возможность сформировать прогноз с ориентиром на корреляцию, казалось бы, не связанных между собой событий и данных. На основании этого прогноза подготавливается ряд действий, которые ранее приводили к коррекции аналогичных аномалий. Автоматическое реагирование на событие, которое соответствует гипотезе о причине аномалии, и реализация корректирующих действий — это пример использования прогнозирующей аналитики на основе ML для решения проблемы до того, как она станет влиять на бизнес. Кроме того, всегда будут возникать ситуации, когда регистрируется новое событие и невозможно точно соотнести его с ранее известной аномалией, основываясь на ранее полученных данных. Даже несмотря на это, отсутствие корреляции само по себе показательно и позволяет перекрестно связывать события, аномалии и ответы и тем самым накапливать опыт.
Существует много примеров того, как использование ML на наборах данных показывает корреляцию, которую не может увидеть человек, просматривающий те же самые наборы данных, например, как часто неудачная попытка пользователя войти в систему приводила к блокировке по сравнению с миллионами других попыток и были ли эти блокировки результатом безобидного ввода неверного пароля из-за забывчивости или грубой атаки с целью получить доступ в систему. Поскольку алгоритм может искать все необходимые наборы данных и коррелировать результаты, он сможет идентифицировать закономерности, говорящие о том, безопасное событие или злонамеренное. Используя выходные данные этих шаблонов, можно предпринять превентивные действия для предотвращения возможных проблем с безопасностью, быстро изолируя ресурсы веб-интерфейса или блокируя запросы от пользователей, которые считаются вредоносными из-за того, откуда они поступают (IP-адрес или конкретная страна), типа передаваемого трафика (DDoS-атака) или другого сценария.
Этот тип автоматизации, если он будет правильно реализован в системе, позволит создать самые современные из возможных на сегодня архитектур. Учитывая текущее состояние доступных облачных сервисов, использование прогнозной аналитики, искусственного интеллекта и машинного обучения — это самый передовой способ создания продвинутой архитектуры cloud native. Однако по мере того, как сервисы станут более совершенными, появятся дополнительные методы, и разработчики будут продолжать использовать их, чтобы гарантировать надежность своих систем и предотвратить ущерб для бизнеса.
