на чем пишут облачные сервисы
Чем занимается облачный разработчик и как им стать
Авторизуйтесь
Чем занимается облачный разработчик и как им стать
директор практики облачных решений AT Consulting
Рынок облачных решений ежегодно растёт, а вместе с ним растёт и спрос на облачных специалистов, которые специализируются на построении и обслуживании виртуальной инфраструктуры. Я работаю с облачными технологиями уже 11 лет и все эти годы даже в среде разработчиков (особенно среди джунов) сталкиваюсь со стереотипом – «ой, да что там делать, развернул и пошёл». В реальности всё намного сложнее и увлекательнее. В этой статье я расскажу, чем на самом деле занимаются облачные айтишники и какие навыки им требуются.
Как все думают, что это устроено
Облака и всё, что с ними связано, окружены множеством стереотипов. Считается, что работать с ними легко, стоят они дешево, а после развёртывания всё само каким-то волшебным образом масштабируется. В сознании начинающих разработчиков такие проекты не выдерживают конкуренции с модными трендами типа нейросетей или голосовых помощников – облака кажутся чем-то очевидным и скучным.
Вот наиболее часто встречающиеся ложные утверждения про облака: они волшебно надёжные, работают всегда и сами по себе; не требуют больших затрат; можно поменять облачного провайдера в любой момент; о безопасности можно не думать – надо только применять шифрование при доступе к облачному сервису.
Как на самом деле это устроено
Мир облаков чрезвычайно богат разнообразными технологическими инструментами: контейнеры, средства автоматизации инфраструктуры, распределённые хранилища и базы данных, виртуальные сети и файерволы и многое другое. Участнику облачного проекта недостаточно знаний только одного или двух языков программирования или одного средства тестирования: от инженеров здесь ждут более широкого кругозора. При этом все современные продукты очень быстро обновляются, новые фичи появляются каждый месяц, каждые полгода выходят большие релизы. За этой гонкой нужно внимательно следить, чтобы эффективно использовать инструменты в работе и строить оптимальные архитектуры.
Ниже краткое описание того, что на самом деле происходит в облачном мире.
Надёжность
Мир облаков – это мир микросервисов и распараллеливания нагрузки, то есть все приложения пишутся как совокупность маленьких сервисов, которые можно запускать в любом количестве для обслуживания нужного числа пользователей. На словах выглядит легко, а на практике надо понимать, как работают распределённые системы, как организовать параллельную и отложенную обработку запросов, как организовать передачу сообщений между частями приложения, как осуществлять балансировку нагрузки между всеми запущенными элементами, как автоматически запускать и останавливать сервисы при росте нагрузки или сбоях инфраструктуры.
Масштабируемость
Облака предоставляют много возможностей для работы с большой нагрузкой, но все эти инструменты надо уметь применять. И более того, приложения нужно создавать так, чтобы эти инструменты работали.
Затраты
Облачные проекты – это всегда про расчёт и оптимизацию затрат. Вообще, вопрос расчёта затрат на инфраструктуру и другие сервисы на облачном рынке гораздо менее прозрачный, чем в обычных проектах. За каждый использованный сервис придётся платить. Виртуальные машины, дисковые операции, трафик, операции записи в базах данных, контейнеры – все это ресурсы, которые будут стоить денег, а под нагрузкой – больших денег. Поэтому всем участникам надо на ранних стадиях проекта думать о том, как сократить расходы. Если раньше это делалось при покупке сервера и в меньшей степени зависело от разработчиков и других участников проекта, то теперь об этом приходится задумываться каждому.
Ещё одно отличие – нужно задействовать максимум возможностей оплаты только использованных ресурсов. Если можно отключить услугу ночью и работать только днём, то надо это сделать, потому что это экономит деньги. Но такой подход требует большего уровня автоматизации, чем раньше.
Провайдеры
Сейчас облачные провайдеры предоставляют широкий спектр чрезвычайно удобных инструментов. В качестве примера часто приводят AWS: даже просто прочитать список сервисов этого провайдера – уже долгое дело. Российские провайдеры тоже быстро наращивают перечни услуг. Конечно, при создании приложения удобно использовать такие гибкие инструменты, но со временем возникает риск того, что приложение нужно будет перенести на мощности другого провайдера или развернуть на собственной инфраструктуре. Это может стать большой или даже не решаемой в разумные сроки проблемой. Даже похожие сервисы у разных провайдеров реализованы по-разному, не говоря уже об отличиях в перечне услуг. При проектировании приходится соблюдать баланс и в этом разрезе – как использовать сервисы так, чтобы не оказаться зависимым от провайдера, но при этом максимизировать выгоду от облачной архитектуры.
Безопасность
Краеугольный камень любой бизнес-системы. По некоторым исследованиям, ошибки в конфигурации облачных сервисов лидируют среди угроз безопасности приложений. Как устроена аутентификация, как настроены файерволы и виртуальные сети, каковы настройки доступа к базе данных, как реализуется авторизация, какие версии программных продуктов и библиотек используются, как их обновлять – все это нужно знать.
Надо отметить, что в любом (даже простом) облачном проекте используются десятки разных инструментов, программных продуктов и облачных сервисов. На плечи инженеров контроля качества и специалистов по безопасности ложится большая работа по отслеживанию возможных ошибок, ведущих к угрозе проникновения или утечки данных. Им нужно понимать основы подходов к разработке, которые помогают уменьшить риски в области безопасности, например, DevSecOps.
Состав команды на проекте
Основное изменение в структуре команды – это появление Cloud DevOps Engineer. Он отвечает за настройку инфраструктуры для нормального функционирования программного обеспечения, оценивает среды развёртывания приложений заказчика.
В таких проектах мы работаем с Kubernetes, Ansible, Terraform, поэтому часто требуется помощь высококвалифицированных администраторов, которые будут глубоко погружены в процесс разработки. Иногда такие спецы, познавшие тайны администрирования, берут на себя часть функций DevOps. В остальном структура вполне классическая: руководитель проекта, архитектор, аналитики, разработчики, тестировщики.
Если в проекте используется стороннее облачное решение, то состав команды дополняется специалистом по конкретному облачному продукту, например VMware, или даже командой со стороны провайдера. В таком случае работа технически становится проще (не нужно ничего изобретать, используем готовый продукт), но усложняется реализация – решение накладывает ограничения на то, как его можно использовать.
Что нужно знать, чтобы стать облачным разработчиком?
Так или иначе, большая часть разработки связана с предоставлением сервисов через облако – это можно назвать мейнстримом разработки. До облачной «лихорадки» IT-проект выглядел так: написали программу, купили сервер или несколько, установили программу на сервер, подключили интернет и работаем, всё что дальше – эксплуатация. Такие классические проекты постепенно становятся редкостью либо относятся к специализированным областям из разряда программирования микроконтроллеров или САПР.
Если вы облачный разработчик, то вот с чем, скорее всего, вам придётся столкнуться в работе:
Основываясь на этом описании типичных задач и проблем разработчика, я могу выделить следующие области знаний, которые вам очень пригодятся, если вы решите попробовать силы в таком проекте:
Сейчас есть бесконечное множество способов получить знания: даже беглый поиск по запросу «книги/курсы + облачные системы/масштабирование систем/DevOps, DevSecOps» даст тысячи результатов. Из книг могу выделить Ивана Портянкина «Программирование Cloud Native. Микросервисы, Docker и Kubernetes» – отлично подойдёт начинающим. Затем можно продолжить книгой Ли Атчисона «Масштабирование приложений. Выращивание сложных систем» – это уже более основательное произведение.
Не забывайте про Coursera, я рекомендую три курса: Continuous Delivery & DevOps (The University of Virginia), Cloud Computing Concepts, Part 1 (The University of Illinois at Urbana-Champaign), Cloud Computing Security (The University of Colorado).
Для тренировки вы можете просто взять облако любого из провайдеров (лучше российского, так как это более актуально для нашего рынка) – «Яндекс.Облако», Mail.Ru Cloud Solutions, Selectel, «Ростелеком» – и с помощью его инструментов попробовать развернуть небольшой сайт, взяв за основу какую-либо CMS. Задачка со звёздочкой: написать набор скриптов, которые будут заказывать виртуальные машины и разворачивать сайт автоматически в выбранном облаке. Такое упражнение даст много очков на любом собеседовании.
Чему можно научиться на облачных проектах?
Выделю два набора компетенций, которые круто прокачиваются в облаках: автоматизация и системное администрирование, а также умение использовать ограниченную, простую функциональность облачных сервисов для решения сложных IT-задач.
Работа с облачными технологиями неизбежно приведёт вас к росту экспертизы в автоматизации, CI/CD (непрерывная интеграция и доставка), к росту знаний конкретных облачных продуктов, в части решения интеграционных задач.
Обычно новички приходят на какую-то из этих должностей – разработчик, системный администратор, тестировщик – и начинают изучать одну из областей ремесла. Чем быстрее человек расширяет кругозор в смежных областях, тем быстрее идёт профессиональный рост. Например, разработчик Java может начать с доработки некоторых функций в конкретно выбранных местах исходного кода проекта. Постепенно разработчик учится работать с базами данных, реализовывать API, запускать Java-приложения в контейнерах и на серверах, создавать автотесты, автоматизировать развёртывание в Jenkins или Gitlab CI и т. д. Постепенно можно стать старшим разработчиком и впоследствии архитектором.
Те специалисты, у которых хорошо получается общаться с заказчиками систем, могут вырасти в руководителей команд или проектов. Но без сильной технической базы руководить облачными проектами невозможно.
Где работать – у вендора или интегратора?
Облачные разработчики, как и любые другие, по разные стороны отвечают за разные аспекты одного и того же.
Разработчик на стороне вендора решает задачи по развитию продукта: ищет способы оптимизировать алгоритмы и сделать его лучше от версии к версии. Часто для этого нужны узкоспециализированные знания, понимание архитектуры ПО конкретной компании. Другими словами, рост на стороне вендора обычно идёт в сторону узкой специализации и часто медленнее, чем на стороне интегратора. Но и темп работы обычно более спокойный.
Разработчик интегратора решает комплексные задачи заказчика при помощи своего кода и облачных сервисов – для этого ему нужен широкий кругозор и знание продуктов разных вендоров. На таких проектах часто приходится мыслить нестандартно и уметь быть гибким, подстраиваться под изменения условий задачи и смену архитектуры.
Введение в Облачные Вычисления для Всех от Инженера Microsoft, Ex-Amazon
Многие из вас слышали про мировой успех облачных компаний и таких компаний как Amazon Web Services, Microsoft Azure и Google Cloud Platform. Сейчас мы видим, как отечественное облако активно развивается – Яндекс Облака, Mail.ru облако и Сбербанк тоже работает в этом направлении.
Лично у меня нет опыта работы с отечественным облаками и пока они еще достаточно молодые, но, я очень надеюсь, что они справятся с задачей и у нас появятся конкурентно способные облачные провайдеры.
Сам я занимаюсь задачами аналитики и инжиниринга данных, то есть работаю с buzz words – Big Data, Data Platform, Lakehouse, Data Lake, Data Science, Machine Learning (ML), AI и т. п., в крупных международных компаниях – Amazon, Microsoft, Xbox. Про все эти дела я уже 3 года успешно пишу в своем телеграмм канале Инжиниринг Данных, где уже больше 10 тысяч подписчиков.
Я работаю с облаками с 2014 года, с 2016 по 2020 в Амазоне (почти 5 лет), где принимал участие в знаменитом проекте Rolling Stone по миграции on-premise инфраструктуры для аналитики в облако AWS.
Мое выступление в Mail.ru про Эффективность Амазон.
И далее в других командах создавал облачную дата платформу, теперь это называется data products для Business Intelligence и Machine Learning.
В Амазоне я проходил много тренингов по AWS и сдавал их экзамены, то есть все время был в «облачной» среде. Потом я перешел в Microsoft Gaming, и стал делать похожие вещи на Microsoft Azure. И продолжаю делать, теперь я могу рассказать, как строить платформу аналитику для ААА игры, это значит уровень блокбастера, игры, которые создается годами и имеет многомилионный бюджет.
Но работать с Azure, я начал намного раньше, когда создавал консалтинг компанию Rock Your Data в Канаде с целью делать «rolling stone» проекты для компаний в Северной Америке. В 2017–2018 году идея миграции в облака не была такой популярной как сейчас. Идея была правильная, но имплементация плохая, я подробно рассказал об этом в статье – «Опыт создания аналитической консалтинг-компании в Северной Америке (не очень успешный)»
Уже в то время я параллельно изучал Microsoft Azure, чтобы сдать экзамены и получить статус партнера. Все было достаточно просто после опыта в AWS.
Другая моя активность связана с Университетом Виктории в Британской Колумбии.
У них я читал лекции по облачным вычислениям для бизнес студентов (MBA) программы. Вообще история забавная. Сколько я жил в Канаде, я все время хотел преподавать в университете, чтобы сделать буст карьере. Я писал профессорам, факультетам, но реакции ноль. Это реально история не про опыт, а про связи. Важно знать кого-то, кто тебя порекомендует нужному человеку.
Один раз ходил на собеседование на курс по визуализации данных и аналитике, то, что нужно. Но мне отказали, зато предложили учить облачным вычислениям, ну облачные, так облачные. Я обычно не теряюсь в непонятных ситуациях, заодно походу разберусь, подумал я.
Сразу поделюсь вам хорошими книгами по этой тематике, которые я использовал. Само собой, я использовал все доступные обучающие ресурсы в Амазоне – внешние и внутренние. Я знал, как рассказать про облака понятно за пару уроков, но чтобы разбить программу на 12 уроков по 4 часа, это пришлось подумать и покопаться.
Week 1: Cloud Computing overview and essential cloud technologies.
Week 2: Cloud concepts and business benefits
Week 3: Cloud security fundamentals
Week 4: Cloud Architectures and Cloud Migration
Week 6: Cloud Career paths and professional certifications
Другой моей задачей было рассказать так, чтобы сильно не привязываться к конкретному вендору. В целом получилось неплохо. Я донес до людей значение Cloud Computing и различные аспекты использования облачных сервисы и многое другое.
Вот кстати лучшие книги, которые я нашел по теме, и которые использовал активно:
Cloud Computing: Concepts, Technology & Architecture – это прямо реально учебник, где много рассказывается про устройство дата центра и оборудования.
Ну конечно стоит поблагодарить Амазон за оплату книг, этих, и еще штук 20-30 других по моей тематике😉
Таким образом у меня есть курс и контент на английском. И при этом я активно развиваю сообщество аналитики и совершенно бесплатно учу людей профессиям аналитики с целью дальнейшего трудоустройства и весьма эффективно – проект называет datalearn.ru. На сайт за год зарегистрировалось больше 4000 студентов. Многие пришли от других платных школ, не буду называть их название, но таких много, кто зарабатывает деньги продавая buzz words. Моя цель закрепить мой опыт и своего образа paying back my home country. Это мой персональный challenge и я его закончу.
Согласной моей программе в течение первых 4х модулей я рассказываю базовые вещи из мира аналитики, которые не сильно изменились за 10 лет. Модуль 5 был посвящен облачным вычислениям, потому что:
1) Во-первых, в мире практически все компании используют облачные решения и уже знание основ AWS, Azure, GCP это почти как базовое знание Excel в описании вакансии. Про это уже могут даже не писать.
2) Во-вторых, в РФ ситуация обратная, так как по закону у нас нет дата центров AWS, Azure, GCP и использовать облачные вычисления не безопасно. Все помнят, как глушили IP AWS, когда попытались заблокировать телеграмм. Я сам пострадал, так как у меня был интернет-магазин на AWS для тещи. И следовать наши специалисты не имеет тех возможностей, которые умеют западные специалисты. Поэтому я хотел закрыть этот пробел.
Таким образом, я собрался силами и записал курс, и, как мне кажется, он получился очень интересным. Я его добавил, как модуль 5 – «Введение в облачные вычисления» в свой курс на Data Learn. Но постарался его сделать максимально независимым, чтобы люди, кому не нужна аналитика, могли понять, что такое облачные вычисления, как они используются в мире.
Я хотел добавить курс бесплатно на STEPIK, но там куча ограничений по размеру видео и оформлению, поэтому добавлю сюда.
Давайте я вкратце расскажу про что программа и что в нее включено. Чтобы вы сразу могли получить весь контент. При условии, если вы хотите делать лабораторные работы, лучше зарегистрироваться и получить доступ ко всем контенту. Все бесплатно и лежит в открытом доступе.
1. Введение в Облачные Вычисления
В этом модуле мы узнаем про облачные вычисления, или просто cloud computing. Мы начнем с основ, и поговорим и главных вендорах и их решениях. Я расскажу про свой опыт с облачными решениями и постараюсь вас научить их использовать и дать достаточно знаний для того, чтобы вы могли понимать, что это такое, и как это используется, а так же применять в работе.
В этом видео вы узнаете про:
Основные вендоры облачных решений AWS, Microsoft Azure и Google Cloud
Типы облачных сервисов и их примеры (Cloud Service Models)
Модели облачных решений (Cloud Model Types)
Безопасность облачных решений и Shared Responsibility Model
Научитесь создавать виртуальную машину и подключаться к ней через SSH
Настраивать сеть для безопасного доступ (Networking)
Попробуете различные облачные сервисы
Примеры профессий, сертификации от вендоров и тренинги
2. Введение в Облачные вычисления (Cloud Computing)?
В 2020 году и в 1-м квартале 2021 года западные вендоры (AWS, Azure, GCP) показали рекордные доходы. «Облако» используется повсеместно в западных странах и становится все популярней и востребовании. Прежде чем мы начнем использовать «облако» для аналитических задач, мы должны познакомиться с основами облачных вычислений.
В этом видео вы узнаете про:
Несколько кейсов из прошлого
История зарождения облачных вычислений и идеи utility computing
Ключевые бизнес драйверы и риски
Определения, терминология и характеристики облачных вычислений
Основные компоненты облачных вычислений и датаценров
Ключ к облакам: как сделать свои приложения Cloud-Native
В предыдущем посте мы рассказали, как облачные сервисы превратились в негласный стандарт предоставления ИТ-услуг. Нетрудно догадаться, что компании, которые желают по-прежнему зарабатывать на пользовательских приложениях, должны адаптировать и создавать новые продукты с учетом Cloud-Native подхода. Впрочем, для разработчиков это однозначно позитивная новость, поскольку использование облачных технологий открывает для них огромные новые возможности. Главное уметь ими правильно распорядиться.
Когда приложение заказывает окружение
Если вы уже читали гид по облачным технологиям, то наверняка помните, что одним из «источников магии» облаков является технология виртуализации. Благодаря этому разработчику практически не нужно задумываться о параметрах серверов, на которых будет работать его приложение. Зачем тратить на это время, если правильно настроенный гипервизор или контейнер могут сконфигурировать машину с практически любыми характеристиками, которые нужны приложению для работы?
Развитием этой идеи является подход Infrastructure as code (IAC). Его суть в том, чтобы дать возможность разработчикам или службам эксплуатации применять для обслуживания инфраструктуры такие же подходы, которые используются на этапе разработки. Он позволяет готовить общие программные блоки управления заранее и легко осуществлять интеграцию таких компонентов в новых проектах.
Возможности современных ЦОДов уже позволяют переходить к декларативному языку управления инфраструктурой. В идеале, приложение должно само администрировать занимаемый им пул ресурсов в дата-центре. Это позволит разработчику не быть запертым в ограничениях, связанных с процессом работы с инфраструктурой, когда надо заказывать и проектировать наперед или если одни и те же компоненты инфраструктуры повторяются в разных проектах.
Фактически разработчик или инженер делает Pull Request, в котором находится конфигурация виртуальной машины (ядра, память, сеть, шаблон и т.д.), далее менеджер виртуального окружения самостоятельно создает машину или создает новый инстанс базы данных или стартует предустановленный сервис, согласно настройкам в файле. Такой подход — настоящее спасение при работе с большими данными и нейронными сетями. Приложения, связанные с этими технологиями, в некоторых случаях нуждаются в динамически изменяемых объемах памяти и процессорных мощностей.
Например, для обучения сети необходимо «прогнать» через нее сотни гигабайт информации, и облака позволяют получить необходимые для этого мощности по запросу. После того, как обучение будет завершено, ресурсы возвращаются в пул провайдера, а разработчику не нужно думать, чем их занять или как по-другому сконфигурировать приложение, чтобы оно продолжало работу на меньшем объеме мощности.
Монолит vs. упорядоченный хаос
Благодаря тому, что облака умеют эластично подстраиваться под потребности разработчика, это, теоретически, упрощает еще одну задачу – проблему масштабирования приложений. Почему теоретически?
К сожалению, задача по масштабированию приложений не является линейной. Чтобы приложение справлялось с огромными нагрузками в периоды пиковой посещаемости (или вычислений), недостаточно просто давать ему дополнительную память и процессорные мощности. Абсолютно у каждого традиционного приложения есть порог, после которого оно уже не в состоянии «переварить» новые ресурсы и продемонстрировать рост производительности. Проблема в данном случае состоит не в ресурсах, а в самой архитектуре большинства программ.
Особенно остро эта проблема стоит для приложений с монолитной архитектурой, которые, фактически, представляют собой единые бинарные файлы. Достоинства такого подхода очевидны: монолитные приложения достаточно просты и линейны. Все сценарии поведения пользователя можно предсказать, отследить и при необходимости произвести отладку бага.
Однако у такой простоты есть цена. Во-первых, это уже упомянутые выше проблемы с масштабированием. В какой-то момент даже самое продуманное монолитное приложение перестает работать эффективнее от апгрейда конфигурации сервера на котором оно исполняется.
Во-вторых, монолитное приложение не так-то просто перенести на новые сервера и для этого может потребоваться полная перекомпиляция программы.
В-третьих, такое приложение сложно поддерживать и развивать. Любое обновление превращается требует полной сборки всей программы, и ошибка в одном из блоков кода может обернуться падением всей системы.
В поисках идей, как решить эти проблемы была разработана другая концепция – service-oriented architecture (SOA). Она подразумевает, что приложение разделено на несколько модулей, каждый из которых предоставляет другим какую-то функциональность. Между собой модули взаимодействуют через набор веб-служб, и независимо друг от друга могут обращаться к единой или к собственным базам данных.
Такой подход действительно упрощает поддержку программы и не превращает ее обновление «в работу сапера», в которой нет права на ошибку; но и у него есть свои недостатки. Ключевой из них – проблемы с масштабированием разработки таких приложений. По мере роста программы, новые функции становится все сложнее «запихивать» в изначально утвержденные архитектором 5-10 пакетов. Их число становится все больше, что оборачивается проблемами с поддержкой.
Микросервис как элемент эволюции приложения
Результатом эволюции SOA стала идея микросервисной архитектуры, которая и используется при конструировании облачных приложений. Концептуально идеи обоих подходов крайне схожи, и некоторые архитекторы даже не выделяют микросервисную архитектуру в отдельную парадигму, считая ее частным случаем SOA.
Микросервисная архитектура подразумевает, что приложение состоит не из какого-то небольшого количества крупных модулей, а из множества независимых друг от друга частей. В отличие от монолита, в микросервисном приложении можно использовать различные способы взаимодействия компонентов между собой. У системы нет единого, заранее определенного состояния. Вместо этого каждый компонент работает «по ситуации»: как только ему поступает событие он начинает работу. Это позволяет делать очень гибкую и независимую архитектуру.
При этом число сервисов в микросервисном приложении постоянно меняется – какие-то добавляются, какие-то удаляются. В новом подходе можно любой микросервис заменить и вместо него встроить цепочку микросервисов. Другие сервисы продолжают стабильно работать, потому что не связаны напрямую между собой. Такова естественная эволюция программы. Благодаря этому у разработчиков и архитекторов появляется возможность быстро что-то менять, чтобы реагировать на изменения бизнес-требований и опережать конкурентов.
Помимо повышения скорости выпуска обновлений использование микросервисной архитектуры позволяет добиться децентрализации управления. Команда, которая отвечает за разработку того или иного сервиса, сама вправе определять его внутреннюю архитектуру и его особенности. Такой подход, кстати, сейчас в Блоке Технологии внедряет Архитектурный совет Сбербанка.
При этом садясь за разработку своего облачного приложения не следует спешить со скорейшим дроблением его на составные элементы. Главный противник подобного бездумного подхода — Мартин Фаулер; он же – один из авторов идеи микросервисной архитектуры. Проще изначально использовать монолитный подход, и потом стимулировать эволюцию приложения «естественным образом», ориентируясь на расшивку узких мест и добавление дополнительных функций.
В результате можно сформулировать следующее правило: задача программиста при работе с микросервисной архитектурой – не просто разбить приложение на максимальное количество составных частей, а разумным образом разграничить их ответственность за получение и обработку данных.
Четыре детали
Помимо множества очевидных достоинств, у микросервисной архитекутуры есть свои особенности, которые необходимости учитывать при разработке своего облачного приложения. В частности, для поддержки работы такого приложения необходимо постоянно поддерживать повышенные требования к качеству управления внутренними API.
Когда один из компонентов меняет свой интерфейс, он должен поддерживать обратную совместимость, чтобы поддерживать прошлую версию собственного API. Если это правило соблюдается, можно динамично переключаться со старой версии на новую без сбоев работе. Если же поддержка прежней версии API не проработана, то это грозит в лучшем случае, потерей части функциональности приложения, а в худшем – постоянными сбоями в его работе.
Вторая важная особенность микросервисных приложений заключается в сложностях поиска в них багов. Если «падает» приложение, написанное в монолитной логике или SOA, найти источник проблемы не составит труда. В приложении, состоящем из множества сервисов, поиск причины бага может сильно затянуться из-за того, что данные от пользователя нередко проходят обработку через несколько микросервисов, и сложно определить, в каком именно из них происходит сбой. При этом процесс поиска бага нужно вести очень аккуратно: любой неудачный рефакторинг может привести к поломке работающего модуля, и в дополнение к первоначальной проблеме разработчик получит вторую.
Третья важная деталь, которую необходимо учитывать, разрабатывая облачное приложение – способ взаимодействия его составных частей между собой. Как и в SOA, для обмена данными сервисы используют веб-службы, но в микросервисной архитектуре появились паттерны взаимодействия, например, как streaming, CQRS, Event sourcing. Обычно разработчики рассчитывают, что время отклика между запросом и ответом в приложении достаточно небольшое. В распределенной системе нельзя полагаться даже на то, что ответ вообще придет.
Так же в архитектуре облачных приложений микросервисы используют различные базы данных, наиболее оптимально подходящие для решения их конкретных задач. Например, гриды могут быстро читать, но с трудом справляются с большим количеством операций по изменениям данных. Такая база хорошо подойдет для ведения счетов вкладов – они редко изменяются. Другой тип операций – процессинг; в нем ежедневно по каждой карте могут быть десятки изменений, а чтений данных наоборот мало.
Наконец, четвертый факт, о котором нужно помнить при разработке облачного приложения – микросервисная архитектура ориентирована в первую очередь на использование сервисов без поддержки состояний. При этом не стоит впадать в крайности. Некоторые сервисы, при необходимости, все же могут осуществлять поддержку состояния, если того требует бизнес-логика, и они должны быть спроектированы особенно тщательно.
Например: если пользователь делает запрос на получение кредита, то получившая заявку система должна это состояние сохранить, чтобы передать его другим сервисам. А вот сервис, отвечающий за поиск информации во внутренней картотеке кредитных историй, может не сохранять состояние и забыть о том, данные на какого именного пользователя он искал пару минут назад – все равно уже через мгновенье ему придет новый запрос (хотя и в этом процессе может быть различное поведение сервиса).
Все описанные выше примеры и практики уже активно используются лидерами мировой ИТ-отрасли. Например, пионером в развитии микросервисной архитектуры является Netflix. Компания выпустила множество open-source приложений, библиотек и фреймворк для мониторинга, балансировки и логирования запущенных микросервисных приложений.