2017 год стал важным годом для DevOps, поскольку число игроков в экосистеме существенно выросло, а количество проектов с CNCF утроилось. Глядя на год вперед, мы ожидаем, что инновации и рыночные изменения ускорятся еще больше. Ниже мы рассмотрели тенденции в области микросервисов в 2018 году: сервисные связки(так называемые “меши”), event-driven архитектуры, нативная безопасность контейнеров, GraphQL и Chaos инженерия.
1. Сервисные связки популярны!
Сервисные связки или “меши”, выделенный уровень инфраструктуры для улучшения связи между сервисами, в настоящее время наиболее обсуждаема в контексте облачности. По мере того, как контейнеры становятся более распространенными, топологии сервисов становится все более динамичными, требуя улучшеной функциональности сети. Сервисные связки могут помочь управлять трафиком через обнаружение сервисов, маршрутизацию, балансировку нагрузки, проверку работоспособности и наблюдаемость(observability). Сервисные связки пытаются укротить непоколебимую сложность контейнера.
Очевидно, что сервисные сетки становятся все более популярными, поскольку балансировщики нагрузки, такие как HAProxy, traefik и NGINX, начали перестраиваться и представлять себя как плоскости данных(data planes). Мы пока не видели широкомасштабного развертывания, но мы знаем о компаниях, которые уже используют связки на живых серверах, в “продакшене”, так сказать. Кроме того, сервисные связки не являются эксклюзивными для микросервисов или сред Kubernetes, и также могут применяться в среде VM и без сервера. Например, в Национальном Центре Биотехнологической Информации(NCBI) нет контейнеров, но используется Linkerd.
Сервисные связки также могут использоваться для Chaos инженерии, «дисциплины экспериментирования в распределенной системе, производимого с целью повышения уверенности в способности системы противостоять турбулентным условиям». Вместо установки демона, который выполняется на каждом узле, сервисная связка может вводить латентности и объекты сбоев в окружающей среде.
Istio и Buoyant's Linkerd — самые громкие предложения в Chaos инженерии. Обратите внимание, что Buoyant выпустил Conduit v0.1, сервисную связку с открытым исходным кодом для Kubernetes, в декабре прошлого года.
2. Восхождение event-driven архитектуры
Поскольку потребность в гибкости бизнеса увеличивается, мы начали видеть движение к «push» или архитектуре, основанной на событиях, в которой одна служба отправляет событие, а один или несколько контейнеров-наблюдателей, которые следили за этим событием, реагируют, запуская логику асинхронно без знания факта реагирования производителем событий. В отличие от архитектуры запроса-ответа, в управляемых событиями системах функциональный процесс и загрузка транзакции в инициирующем контейнере не зависят от доступности и завершения удаленных процессов в нижестоящих контейнерах. Дополнительным преимуществом этого является то, что разработчики могут быть более независимыми при разработке своих соответствующих сервисов.
В то время как разработчики могут создавать контейнерные среды для продуцирования событий, Function-as-a-Service (FaaS) по своей сути воплощает это качество. В архитектурах FaaS функция хранится как текст в базе данных и запускается событием. После вызова функции контроллер API получает сообщение и отправляет его через балансировщик нагрузки на шину сообщений, которая ставит его в очередь для планирования и предоставления контейнеру-вызову. После выполнения результат сохраняется в базе данных, пользователю отправляется результат, и функция выводится из эксплуатации до тех пор, пока не будет вызвана снова.
Преимущества FaaS включают в себя: 1) сокращенное время от написания кода до запуска службы, потому что нет артефакта для создания или выхода за пределы исходного кода и 2) сокращение перегрузки, поскольку функции управляются и масштабируются такими платформами FaaS, как AWS Lambda. Однако FaaS не совсем безпроблемны. Поскольку FaaS требует развязки каждой части сервиса, может существовать множество функций, которые трудно обнаружить, управлять, организовывать и контролировать. Наконец, без полной видимости, включая зависимости, трудно отлаживать системы FaaS, и могут появяться бесконечные циклы.
В настоящее время FaaS плохо подходит для процессов, требующих более длинных вызовов, большого объема данных загружаемых в память, и постоянной производительности. Хотя разработчики используют FaaS для фоновых заданий и временных событий, мы считаем, что варианты использования будут расширяться с течением времени, когда усовершенствуется слой хранения, а платформы станут более эффективными.
Осенью 2017 года Cloud Native Computing Foundation (CNCF) опросил более 550 человек, из которых 31% используют безсерверные технологии и 28% планируют использовать в течение следующих 18 месяцев. Опрос был углублен вопросом о том, какая конкретная серверная платформа используется. Из 169, использующих технологию без сервера, 77% сказали, что они использовали AWS Lambda. Хотя Lambda может возглавлять бессерверные платформы, мы считаем, что на окраинах могут быть интересные возможности. Вычисление этих границ будет особенно значимым для IoT и AR / VR.
3. Потребности в области безопасности меняются
Приложения, упакованные в контейнеры, по большей части более безопасны по умолчанию из-за доступа к ядру. В средах VM единственной точкой видимости является драйвер виртуального устройства. Теперь, перейдя в контейнерную среду, ОС имеет системные вызовы и семантическое значение. Это похоже, гораздо более насыщенная коммуникация. Раньше операторы могли бы получить некоторою долю таких возможностей, перебросив агент в виртуальную машину, но это было бы сложно. Контейнеры обеспечивают большую видимость, а интеграция в контейнерной среде тривиальна по сравнению со средой VM.
Помня вышесказанное, в обзоре “451 Research survey” мы можем найти сообщения о том, что безопасность является самым большим препятствием для принятия контейнеров. Первоначально уязвимости были основной проблемой безопасности в контейнерных средах. По мере того как количество готовых к использованию образов контейнеров в публичных реестрах размножалось, стало важно убедиться в том, что они свободны от уязвимостей. Со временем, сканирование образов и аутентификация стали товаром.
В отличие от виртуализованных сред, где гипервизор служит точкой доступа и контроля, любой контейнер с доступом к корню ядра(kernel root) в конечном счете имеет доступ ко всем контейнерам на ядре. В свою очередь, организации должны обеспечить взаимодействие контейнеров с хостом и какие контейнеры могут выполнять определенные действия или системные вызовы. Укрепление хоста для обеспечения надлежащего конфигурирования групп и пространств имен также важно для обеспечения безопасности.
Наконец, традиционные брандмауэры полагаются на правила IP-адресов, чтобы разрешить сетевые потоки. Этот метод не распространяется на контейнерные среды, поскольку динамические оркестраторы повторно используют IP-адреса. Обнаружение и реагирование в режиме реального времени имеет решающее значение для производственных сред и достигается путем отпечатков (фингерпринтов) в среде контейнера и построения детальной картины для базовой линии поведения, поэтому легко обнаружить аномальное поведение и оргадить злоумышленника. В отчете 451 отмечается, что 52% опрошенных компаний используют контейнеры на продакшене, что говорит об ускорении принятия компаниями решений, основанных на контейнерах для обнаружения угроз во время работы.
4. Переход от REST к GraphQL
Создана Facebook в 2012 году отдана публике как опенсорс в 2015, GraphQL — это спецификация API, которая является языком и выполнением запросов. Системы типа GraphQL позволяют разработчикам определять схемы данных. Новые поля могут быть добавлены, и поля могут быть сняты(объявлены устаревшими) без ущерба для существующих запросов или реструктуризации клиентского приложения. GraphQL силен тем, что не привязан к определенной базе данных или механизму хранения.
Сервер GraphQL работает как единый HTTP эндпоинт, который выражает полный набор возможностей службы. Определяя отношения между ресурсами в терминах типов и полей (а не ендпоинтов, как в REST), GraphQL может следовать ссылкам между свойствами, чтобы сервисы могли получать данные из нескольких ресурсов с использованием одного запроса. Кроме того, API REST требует загрузки нескольких URL-адресов для одного запроса, увеличивая нагрузку на сеть и замедляя запросы. С уменьшением количества обращений, GraphQL уменьшает объем ресурсов, необходимых для каждого запроса данных. Возвращенные данные обычно форматируются в JSON.
Существуют дополнительные преимущества использования GraphQL над REST. Во-первых, клиенты и серверы “развязаны”, поэтому их можно поддерживать отдельно. В отличие от REST, GraphQL использует схожий язык для связи между клиентами и серверами, поэтому отладка проще. Форма запроса полностью соответствует форме данных, извлекаемых с сервера, что делает GraphQL очень эффективным и эффективным по сравнению с другими языками, такими как SQL или Gremlin. Запросы отражают форму их ответа, поэтому могут быть обнаружены отклонения, и можно определить поля, которые не разрешаются правильно. Поскольку запросы проще, во всем процессе больше стабильности. Эта спецификация наиболее популярна в поддержке внешних API-интерфейсов, но мы видим также, что она используется для внутренних API.
Пользователи GraphQL подключают также Amplitude, Credit Karma, KLM, NY Times, Twitch, Yelp и т. д. В ноябре Amazon подтвердила мнение о росте популярности GraphQL, запустив AWS AppSync, который включал поддержку GraphQL. Будет интересно посмотреть, как GraphQL развивается в контексте gRPC и альтернативной Twitch's Twirp RPC framework.
5. Chaos становится более известен.
Первоначально популяризирован Netflix, а позже — Amazon, Google, Microsoft и Facebook, проводили эксперименты с Chaos по созданию системы для повышения уверенности в ее способности противостоять проблемам на “продакшене”. За последние десять лет Chaos инженерия развилась в легитимную технологию. Она началась с Chaos Monkeys, которая отключала сервисы в производственных средах расширяя масштабы тестирования Failure Injection Testing (FIT) и, Chaos Kong, подходящий для более крупных сред.
Поверхностно кажется, что хаос-инжиниринг — это всего лишь инъекционная суматоха. В то время как взломы системы могут быть забавными, это может не всегда быть продуктивным или предоставлять полезную информацию. Техника Chaos воплощает в себе более широкий спектр не просто неудачных инъекций, но и других симптомов, как например скачков трафика, необычных комбинаций запросов и т. д., Чтобы выявить существующие проблемы. Помимо проверки неких допущений, он должен также выявлять новые свойства системы. Благодаря выявлению слабых мест в системе команды могут помочь повысить отказоустойчивость и предотвратить негативный опыт пользователя.
Новые технологии, такие как нейронные сети и глубокое обучение, настолько сложны, что определение того, как что-то работает, может стать менее важным, чем доказательство того, что оно работает. Техника Хаоса помогает в решении этой задачи, проверяя целостностно систему для выявления нестабильности. Это, вероятно, станет еще более приемлемой практикой, поскольку инженеры работают над тем, чтобы сделать их все более запутанные системы более надежными.
По мере того как хаос-инжиниринг становится более распространенным, он может принимать форму существующих проектов с открытым исходным кодом, коммерческих предложений или, как упоминалось выше, реализован через сервисную связку.
