Там про cloud native architecture и все такое облачное, может кому пригодится. Я сам уже два раза участвовал и учился, мне нравится

+

Вот, а второе - это то что Google Developer Group организует совместную подготовку к сертификациям по Google Cloud, будут рассказывать, показывать и объяснять, что там и как

Я сейчас перешлю сюда ссылки для регистрации и участия, там много написано, я своими словами долго буду объяснять

📚 Google Developer Groups организуют совместную подготовку к Google Cloud Certification.

2 направления:
- Associate Cloud Engineer
- Professional Cloud Architect

Чек-лист подготовки:

1 шаг – до 15 апреля зарегистрируйтесь на сайте;

2 шаг – для участия в программе необходим профиль на qwiklabs.com и минимум один бейдж. Вы можете получить его после прохождения лабы по ссылке (бесплатно до 15 апреля);

3 шаг – 10 апреля в 12:00 (по Москве) пройдет встреча, на которой мы расскажем детали курса и ответим на вопросы — регистрация на встречу;

4 шаг – 19 апреля первое занятие в группе с менторами. Всего занятий будет 6, раз в неделю. Также будет открыт бесплатный курс самоподготовки на платформе pluralsight.com;

5 шаг – присоединяйтесь к нашему чату в Slack (участники со всей Европы, общение на английском) и Telegram (участники русскоязычного сообщества);

6 шаг – 24 мая пройдет последнее занятие в группе с менторами. После можно будет начать думать об экзамене и продолжать обсуждать вопросы в наших чатах.

Вот, может тоже пригодится

раз пошла такая пьянка - то в этом году Tarantool участвует в Google Summer of Code, что тоже весело :)

(правда время подачи пропозалов закрывается уже 13го апреля, и "времени на раскачку у нас нет")

3

Почитал про USL не все 50 страну еще. С первого раза такое трудно мне осознать , но вот очень понравилось.осрьенно про знаменатель. Выходит ,что если у нас есть contention ( некое ожидание в очереди ) ,то у системы есть предел масштабирования ,а если есть ненулевые coherence, то сроупут уйдет в 0 при n к бесконечности. Интересно , а есть примеры и объяснение этих параметров для реальных систем. Например для Кафки или для каких то баз данных

Там получается много дополнительных сложностей, если начать учитывать асинхронку и многоядерность, на самом деле. Но в общем виде формула очень помогает понять, как оно работает, и почему "наша система линейно масштабируется" - маркетинговый буллшит

Интересно осознать эти параметры . Контеншион я сейчас так понимаю. Смотрим на диаграмму системы , если там есть один компонент,через который идут все запросы ,то сразу можно говорить ,что это контеншион и система имеет предел масштабирования. Например в hdfs есть name node. Это контеншион.

А вот пример параметра, который отвечает за кохеренс ... Не могу придумать. На ум приходит только oracle rac и его cr events, но их смысл уже не  помню, но там что то было такое , что даже при чтении надо общаться со всеми нодами.а может тут в качестве примера можно взять MESI, который для cpu?

Вот hdfs вырос из paper про GFS. И если посмотреть на архитектуру , то они похоже - есть name node и data nodes ( master и chunk servers) . Name node фактически держит таблицу , которая определяет на каких data node расположен файл. Т.е есть некий сервер , который держит связку файла и хостов ,где он лежит. В Azure storage , судя по их пейпер то же самое. Вопрос , а ессть ли в каких то распределенных файловых системах другой подход ? Этот сервер ,который хранит связку выглядит как узкое место. Хочется понять . Бывает ли иначе.

17

О, какие люди ✋

ну это не обязательно ОДИН сервер
это может быть группа серверов с raft \ paxos
вот кстати кто нибудь знает есть ли варианты которые нормально бы работали при latency между узлами 250-500ms?

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