Ща сек)

пасиб

@Kankas_dtsehw а какие compute modules порекомендуешь для TuringPi?

Тебе тоже предложение на предзаказ прислали? :)

Я подписался на рассылку давно, так что они шлют time to time

ребята, а можете накидать хороших англоязычных технических подкастов, которые вы слушаете?

ага, этот хорош. Что-то еще слушаешь?

Лол, я их записываю 🙂

чукча не читатель (с)

у тебя же точно есть какая-нибудь годнота?)

Есть, я больше про бизнес слушаю. Invest Like The Best, Acquired, Angelneers, CTO Connection, Decoder, Modern CTO

Software Engineering Daily

спасиб

Java PubHub?

ага, спасибо

Разбор падения Slack от 4 января:

https://slack.engineering/slacks-outage-on-january-4th-2021/

Весьма полезное чтиво – хронология, детали, выводы. Кроме ставшего классическим /proc/sys/fs/file-max, есть и специфичные амазоновские причины.

Масштабирование AWS Transit GateWay (TGW)

TGW менеджится Амазоном, потому повлиять на него мы не можем. В то время, как часть проблем у Slack возникла из-за того, что резко возросший трафик через их корневой TGW, через который завязаны их окружения, давал ошибки, не успевая масштабироваться, добавляя проблем во время падения Slack. Амазоновцы вручную боролись с этой ситуацией:

However, our TGWs did not scale fast enough. During the incident, AWS engineers were alerted to our packet drops by their own internal monitoring, and increased our TGW capacity manually.

Чтобы такого избежать, нужно "прогревать" TGW, аналогично тому, как такое предусмотрено для ELB:

https://aws.amazon.com/articles/best-practices-in-evaluating-elastic-load-balancing/#pre-warming

Shared VPC vs different VPCs

Другой момент – отрицательные стороны от использования отдельных VPC. Если бы у Slack использовалась Shared VPC – и для окружения, и для мониторинга, то трафик бы не упёрся бы в узкое горлышко TGW (его скорости масштабирования), через который и соединяются отдельные VPC.

#TGW #Shared_VPC #design