Всем привет. Меня зовут Илья Казначеев, я люблю облака, работаю с облаками и делаю облака в MTS Cloud. А еще я помогаю заехать и жить в облаках без боли.
В процессе работы я читаю и изучаю много интересного на тему устройства облаков и практик по работе с ними. Я решил делиться своими находками в этом канале.

Отличный блог Priyanka Vergadia - Developer Advocate в Google - где она рисует шпаргалки по технологиям и продуктам GCP.

Очень полезно, если хотите понять назначение и возможности какого-либо продукта GCP, но при этом нет желания читать очень непрозрачные доки.

Также отлично при подготовке к сертификации.

Недавно прочитал интересную статью про устройство S3 в MCS.

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

В целом статья интересная, почитать стоит и для понимания конкретно этой реализации (а реализация - это Tarantool на Tarantool и Tarantool’ом погоняет), и для общего представления об архитектуре распределенных файловых хранилищ, потому что у них есть много общего.

Интересная статья от Andreessen Horowitz касательно стоимости облачной инфраструктуры и экономии при отказе от нее.

Статья начинается с ряда громких заявлений, например:
- компании могут сэкономить до половины денег, тратимых на инфраструктуру, если выйдут из клауда на on-prem;
- компании на ранних стадиях развития могут получить до 10х от своих инвестиций в продукт за год, так почему бы не вложить туда сэкономленное.

При этом в статье много финансовой терминологии и отсылок к исследованиям, но не слова не сказано про total cost of ownership (TCO), в который в случае tech входит не только стоимость инфраструктуры (железо, сети, место в стойке), но и стоимость его обслуживания (штат админов, сетевиков, девопсов и т.п.). Сюда также не вошла возможная выгода при сокращении time to market (TTM), которая достигается при упрощении и автоматизации процессов (и dev, и ops) при переходе к облакам, за счет чего небольшие компании и могут так быстро расти (в том числе).

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

В целом неплохая аналитика, но подана в таком виде, что нужно делить на два. Но если вы все еще думаете, что облако - это решение всех проблем, то прочитать стоит.

Vantage выкатили шпаргалку по расчету стоимости в облаке. На данный момент там только AWS и только дюжина основных продуктов, но описания действительно простые и понятные. Будет полезно для тех, кто не работает очень плотно с AWS, и хочет прикинуть стоимость различных комбинаций/опций.

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

Одна из них - заметка про Karmada - инструмент на основе kubernetes federation для управления гибридным облаком. Проект ещё не увидел мажорный релиз, но за ним стоят гиганты как Tencent и Huawei, что внушает уверенность.

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

Команда A Cloud Guru записывает интересную серию видео про сравнение сервисов трех гиперскейлеров.
Что порадовало - видео очень информативные и интересные. Не просто “у AWS это называется так, а у GCP - так”, а подробно с датой выхода, эволюцией сервисов, отличием в функционале и возможностях, особенностями биллинга и другими нюансами в цифрах.
Для любителей почитать есть текстовые версии + несколько других сравнений, не вошедших в серию.

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

Бонус: у того же ACG есть замечательная серия The Cloud Dictionary of pain, которая представляет собой три методички (AWS, GCP и Azure соответственно), где разобраны базовые сервисы каждого провайдера, приведено сравнение с конкурентами и достаточно подробное описание плюсов и минусов каждого продукта + общая оценка его сложности.

Методички мне очень понравились, советую почитать. Доступны они бесплатно, но нужно указать емейл, чтобы прислали на почту.

Недавно Ably (SaaS pub/sub) оправдывались в своем блоге за то, что не используют Kubernetes. Статья интересная, много куда попала и вызвала кучу обсуждений. Вот основные тезисы:
- они используют флот машин с docker контейнерами под управлением AWS Auto Scaling groups;
- каждая группа запускает машины с заданным набором контейнеров;
- масштабирование достигается за счет групп;
- трафик распределяется за счет AWS ELB;
- у k8s большой оверхед и он очень сложный;
- вместо service mesh они используют просто виртуальную сеть AWS.

В целом набор групп + ELB это обычный сценарий разворачивание ландшафта поверх IaaS, и не совсем понятно, в чем тут особенность. Возможно, Ably крутится в среде стартапов, где неиспользование k8s является странным и старомодным, но на деле это вполне обычная архитектура. K8s действительно дает оверхед как по ресурсам, так по биллингу, однако вот что меня удивило:

1. на всех машинах сервисы запускаются в контейнерах, ОС и остальное - одинаковы. Не очень понятно, почему в угоду экономии отказались от K8s, но не отказались от контейнеров. Т.к. для каждой задачи запускается своя группа машин, было бы логичным собрать оптимизированные под эти задачи темплейты, и запускать там приложения без дополнительных уровней абстракции.
2. при старте докер скачивает контейнеры - опять же, почему бы сразу не положить контейнеры в темплейты?
3. автор много раз подчеркивает заоблачную сложность k8s - на деле это обстоит не так, особено если речь про managed k8s. Задача построения ландшафта внутри k8s обычно проще, чем построение того же на основе IaaS решений конкретного облака.
4. service mesh используется не для реализации сети внутри k8s (с чем оркестратор и сам справляется), а для принудительного внедрения сетевых политик в гетерогенную среду (причем это не обязательно k8s, некоторые service mesh, как cilium, работают также поверх ВМ), а также для упрощения внедрения сетевых и инфраструктурых практик (TLS, observability, circuit breaker, всевозможный аудит и т.п.).

Также много интересного было высказано в обсуждениях к статье, например в этом на HN. Если отбросить все комментарии про неработающий сайт (который не выдержал наплыв читателей), то было еще много по существу, например:
- k8s на деле не такой сложный, как описывает автор, комментаторы дали конкретные примеры;
- проблема биллинговой неэффективности не в больших нагрузках, а в неравномерной утилизации ресурсов. Здесь k8s помогает доутилизировать ресурсы ВМ, т.к. более равномерно распределяет нагрузку на ноды;
- запуск множества маленьких ВМ вместо подов k8s менее эффективен, т.к. приходится каждый раз тратить часть ресурсов ВМ на ОС, когда в случае нод k8s более крупного размера эта цена платится один раз на ноду, а контейнер переиспользует ядро для подов;
- вендор лок на AWS может ударить куда сильнее, чем вендор лок на k8s.

В качестве итога: k8s как и любой другой инструмент подходит не каждому, и если внедряемый инструмент не решает никакой проблемы, то он сам становится проблемой. K8s хорошо подходит для достаточно сложных и гетерогенных ландшафтов, и особенно хорош как платформа для реализации крупных инфраструктур с болшим количеством разных сервисов и проектов. Для запуска класической трехзвенки с горизонтальным масштаброванием есть инструменты куда проще - вроде Heroku или GCP App Engine - не стоит их недооценивать. Как и не стоит стесняться запускать свои нагрузки поверх флота ВМ безо всякой сложной оркестрации. Что стоит делать - так это хорошо понимать свой текущий инструментарий, чтобы выжать из него максимум производительности за минимум денег.

76% компаний готовы к мультиклауду - так гласят результаты опроса от HashiCorp. Разве что стоит сказать, что эти 76% опрошенных (~3200 компаний) - из тех, кто попал в рассылку HashiCorp - а это достаточно специфический сектор рынка.

Однако результаты интересные - например то, что опрошенные считают инструменты HashiCorp более “стратегической” технологией, чем Kubernetes. Также большинство склоняется к мультиклауду из-за оптимизации биллинга. Однако многие отмечают, что сейчас для этого не хватает как инструментов, так и навыков.

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

Любопытная идея использовать object storage вместо serverless базы данных. В статье помимо этого дан хороший обзор присутствующих на рынке объектных хранилок, начиная от AWS S3, и до экзотических.

Идея в целом интересная, хотя обеспечение безопасности в такой постановке вызывает ооочень большие вопросы.

Но с другой стороны, недавний релиз R2 - экстремально дешёвого хранилища от Cloudflare, совместимого с S3 - делает эту идею ещё более лакомой.

А где вы храните свои бессерверные JSONы?

Попалась отличная статья про устройство L4 балансировщика нагрузки в Яндекс.Облаке.

Выглядит как хорошо продуманное с точки зрения архитектуры и красиво реализованное решение, хотя много нюансов осталось за кадром. Идея разделить структуру ЛБ на три уровня - config plane, control plane и data plane - позволяет как лучше справляться с гетерогенными нагрузками, так и удобно в плане организации логики отдельных частей и доставки изменений.

Буду следить за развитием проекта и ждать публичного L7 балансировщика.

Работая с геораспределенными системами, я часто думаю о механизмах отказо- и катастрофоустойчивости. И если с ними в рамках одного региона (один или группа ЦОД) все не очень сложно, то когда в дело вступает мультирегиональная доступность, начинается интересное.
Обычно это интересное связано с глобалной балансировкой нагрузки (GSLB), построенной на двух столпах - DNS и BGP. И если первый относительно понятный, то со вторым у многих возникают проблемы. Как минимум потому, что толковых материалов на тему не так много.

Нашел просто замечательную статью, в которой на примерах описано, что такое BGP Anycast, как он работает и как его самостоятельно настроить (спойлер: вам понадобится от 256 белых IP адресов). Anycast позволяет вашему запросу магическим образом прийти на ближайший к вам GSLB облачного провайдера - а не на случайный как в случае DNS Round-Robin, где ни о какой оптимальности пути речи не идет. А еще в статье есть примеры, как сломать весь интернет через BGP, но это уже совсем другая история…

Наткнулся на прекрасное - интерактивная шпаргалка по продуктам GCP.
Выглядит немного неоднозначно, но штука реально удобная.
Если знаете шпаргалки по другим облакам - накидайте в комментарии.

Пока собираю материал на интересную заметку, вот вам новость.
Google Cloud запустил очередной learning path.
Неплохая возможность изучить интересующее направление (их там много) и поделать бесплатные лабы.
Не реклама, но как GDE рекомендую. В свое время проходил такой, когда готовился к сертификации PCA, в этот раз записался на Digital Leader (что бы это не значило). В общем, если есть свободное время, можно потратить его с пользой.

Посмотрел очень неплохое видео MCS (ныне VK Cloud) об их инфраструктуре и работе K8s на ее основе.
Здесь нет rocket science, однако очень подробно и структурированно рассказано про то, из чего состоит инфраструктура облачного провайдера, и как компоненты используют друг друга, ну и конечно же, как поверх IaaS облака работает K8s сервис.
Особенно интересно это смотреть, зная изнутри, как работает совершенно другой облачный провайдер, а работает он очень похожим образом (спойлер: как и все остальные).
Очень советую, если хотите примерно понимать, из чего состоит облако внутри, с примерами конкретных технологий и продуктов.

Читал postmortem про недавний сбой Cloudflare (спойлер: it's always BGP), и наткнулся на интересную статью про L4 балансировщик нагрузки Cloudflare - Unimog.

Вообще, распределенные балансировщики нагрузки - это облачная технология, которая восхищает меня больше всего. И статья меня очень порадовала. Здесь очень простым языком рассказывается, как реализованы их балансировщики, обслуживающие anycast TCP и UDP запросы на флот серверов. Причем, для балансировщиков не выделены свои машины, они живут на тех же серверах, что и остальное. Также дано понятное объяснение, как и для чего используется eBPF, как и набор интересных решений по маршрутизации пакетов между серверами, обновлению конфигураций при добавлении и отключении серверов, динамической балансировке, поддержке долгих (несколько суток) TCP сессий, оптимизации трафика и сравнение с альтернативами.

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

Прочитал серию статей про то, как OpenAI строят инфраструктуру для своих вычеслений. Тема довольно интересная, а сегодня особенно актуальная, и мне всегда было любопытно, как это делают “большие” игроки.

К моему удивлению, при своих объемах OpenAI запускает вычисления на кластере Kubernetes, правда с большим количеством доработок как в самом кластере, так и на уровне инфраструктуры под ним и упрощения доступа к железу. Про эти оптимизации особенно подробно в последних статьях.
Более того, я не слышал, чтобы кто-то имел кластера такого размера (более 7,5К нод на 2021 год, вероятно сильно больше сейчас).
В блоге дают неплохую аргументацию тому, почему выбран именно Kubernetes, а например не запуск задач на отдельных ВМ или на каком-то самодельном оркестраторе - это тулинг и удобства, который из коробки дает кубер, упрощение менеджмента флота машин, и подобное.

Увлекательное чтение, особенно почитать про ограничения, с которыми столкнулись на таких объемах нод (а значит и объеме данных, проходящих через control plane и хранящихся в etcd), и сложности нетворкинга.

(2021) Scaling Kubernetes to 7,500 nodes
(2018) Scaling Kubernetes to 2,500 nodes
(2016) Infrastructure for deep learning

В целом в блоге много интересного про управление ресурсами, оптимизацию и масштабирование.

Yandex Cloud выпустил первую серию (видео)подкаста про то, как устроено их облако, а конкретно этот выпуск - про платформу данных. Немного бизнесово, но интересно и познавательно, советую послушать на досуге.

Вообще Яндекс часто радует хорошими техническими докладами про внутрянку облака, как на конференциях, так и просто на своем канале. Чтобы не быть голословным:
- конференция Яндекса про инфраструктуру облака.
- доклад с Highload про масштабирование (а на самом деле подробный разбор базовых компонентов облака, очень круто для новичков в теме).

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