Хорошая статья от хороших ребят на хорошем канале!

интересная статья о том как работают с кешами в Etsy. https://codeascraft.com/2017/11/30/how-etsy-caches/


Если коротко, то ребята используют Ketama в качестве реализации consisten hashing. Это библиотека на C или Java с обвязками для разных популярных языков программирования, которая делает hash ring (вот неплохая статья о hash ring), которую, впрочем, критикуют за то что при добавлении новой ноды требуется заново вычислять все кольцо, а значения не перераспределюятся равномерно, так что лучше использовать какой-то md5 в качестве хеш функции и большее количество бакетов.

Вторая часть статьи о так называемом “cache smearing” - технике когда к самым популярным ключам добавляют немного случайных данных, чтобы положить их сразу в несколько бакетов и читать не с одной ноды, а с нескольких. Сам механизм вычисления какой ключ популярный и как именно они добавляют случайные значения не опубликован.

Lyft зарелизили cni-ipvlan-vpc-k8s: IPvlan для Kubernetes в AWS

https://eng.lyft.com/announcing-cni-ipvlan-vpc-k8s-ipvlan-overlay-free-kubernetes-networking-in-aws-95191201476e

В сопутствующей статье они описали, с какими проблемами пришлось столкнуться при деплое Kubernetes в AWS VPC: ограничение в 50 маршрутов роут-таблицы для VPC, что ведёт к развертыванию своих overlay сетей с BGP и профурсетками.

И, соответственно, как они это решали с помощью ENI, но так, чтобы не только упростить конфигурацию, но и сохранить производительность сети на должном уровне

В общем, если вы разворачиваете Kubernetes в AWS, вам это будет полезно at scale

P.S: Lyft -- это как Uber, только чуточку дешевле и покрывает только США

#kubernetes #aws #networking

Вы любите сервисные сетки (service mesh)? Но Linkerd со Scala как-то не оч? Те же ребята написали mesh на Rust & Go! Назывется Conduit

Зачем переписывать себя? Потому что у Conduit очень узкая специализация. Это service mesh специально для Kubernetes!

Почитать можно тут:

https://buoyant.io/2017/12/05/introducing-conduit/

Пока в альфа-версии, но попробовать уже можно

#kubernetes

Реакция Твиттера:

Посмотрите этот замечательный доклад на Velocity Conf от шикарной Julia Grace:

Julia — Head of Infrastructure Engineering в Slack — рассказывает о то, как построить процессы в Infrastructure Team. Потому что все модные тулзы, конечно, помогают нам доставлять продукт быстрее (и как следствие возвращать инвестиции раньше). Однако, даже используя все самые новые и модные вещи, вам будет очень сложно развернуься без нормально отлаженых процессов.

Кстати, рекомендую подписаться на неё в Twitter

#culture #agile

Ian Lewis объясняет, что такое container runtime, какие они бывают и почему это словосочетание вызывает путанницу

Если тезисно:
- у самого понятия "runtime" тоже несколько определений.
- в статье опираются на то, что рантайм — это некая сущность, которая поддерживает исполнение. Пример: HotSpot Runtime в Java
- таким образом есть low level и high level рантаймы
- первые позволяют вам лишь запускать контейнеры (lxc, runc)
- вторые уже содержат какие-то API, фичи вокруг менеджмента имаджей и проч

to be continued

Часть I:
https://www.ianlewis.org/en/container-runtimes-part-1-introduction-container-r

#containers

​​Окей, вы настроили мониторинг. У вас есть куча метрик, которые даже собраны в красивые дашборды

Куда смотреть? Надо ли будить половину команды, если вырос cpu_wio на 7% бэкэндов? А на 20%? Или мы просто будем сомтреть на valid_response_p95_rate и алерить по данной метрике?

Конечно, это всё очень индивидуально, и у разных людей разные мнения по поводу "золотых сигналов". Т.е индикаторов, что у нас сейчас всё overall good или overall bad. Почитать о разных мнениях можно тут:

https://medium.com/devopslinks/how-to-monitor-the-sre-golden-signals-1391cadc7524

В кратце о методах:

Google: Latency, Traffic, Errors, and Saturation
Brendan Gregg: Utilization, Saturation, and Errors
Tom Wilkie: Rate, Errors, and Duration

Ну а дальше уже в статье всё разжёвано детальней

#monitoring #observability

Amazon теперь предупреждает, если у вас есть шанс выйти за пределы бесплатного лимита (free tier)

Удобно для ведения pet-проектов и просто знакомства с платформой

#aws

Hackernoon опубликовал интересное сраванение Azure Container Instances и AWS Fargate

https://hackernoon.com/azure-container-instances-vs-aws-fargate-3216607f63f4

Чёт я как-то заэтсамое и получился перерыв. Нехорошо.

Я на днях в Титтвере наткнулся на интересную дискуссию о том, стоит ли теперь всем париться OPS задачами. Но перед тем как сюда её загонять, надо как-то собрать всё воедино. А надо же ещё и работу работать.

Так что почитайте пока про SRE с точки зрения NewRelic, а я сегодня-завтра твиттерскую дискуссию в постик оформлю

https://blog.newrelic.com/2017/10/30/site-reliability-engineer-sre/

Я знаю, что многие тут используют Slack. Так что ловите тёмную тему для него :)

https://github.com/widget-/slack-black-theme

По идее должно рабоать под Mac, Linux и Windows

Итак, как и обещал, сорал воедино мнения о том, кто должен заниматься OPS. Тут как бы нет одного мнения, скорее всё оч сильно зависит от контекста (в котором вы работаете)

Аргументы за то, что OPS — это теперь общая задача:
- все пишут код
- системы стали сложными и распределенными, поэтому знать всё целиком почти невозможно, но вот знать ту часть, над которой работаешь лучше до конца
- всем должно быть не наплевать

Звучит, конечно, красиво, но есть и аргументы против. Они куда более приземлённые:
- системы стали более сложными и распределенными, соответственно есть куча штук, которые надо знать. Если вы свалите это всё на девелоперов, они охренеют
- правильное распределение задач и knowledge sharing ведёт к успеху, но всё равно останутся какие-то чисто Dev и чисто Ops штуки. И это нормально, что кадый не зватается за всё

По итогам, спор, вроде есть, но в то же время основные тезисы одинаковы. Тогда зачем об этом писать? Да потому что в реальной жизни очень часто встают вопросы, кому куда можно ходить, кто может SSH, кто нет и так далее. От ответа на вопрос: кто исполняет OPS задачи будет зависить очень много решений в вашей конторе, как по доступу, так и иногда по инфраструктуре.

И если раньше стоял вопрос: почему вы не даёте своим разрабам доступ по SSH на прод, разве вы им не доверяете? Сейчас же Kelsey Hightower на Кубконе напряму заявляет, что разработчикам kubectl ни к чему

C'est la vie

И вдогонку твитт, который мне нравится)

https://twitter.com/lizrice/status/938788726926397440

Я так подумал, что надо соответствовать никнейму, потому решил немного копнуть в сторону chaos engineering. А тут как раз Gremlin Inc зарелизили свою Resilience as a Service платформу. В двух словах, это SaaS Chaos Monkey с возможностью роллбека. Вы платите деньги за то, что вашу инфраструктуру кто-то ломает. Шикарно, я считаю!

https://blog.gremlin.com/introducing-gremlin-orchestrating-chaos-b137b74f2371

Алсо, я только начал копать, так что, если вы знаете что-то интересное по теме, пишите сразу мне (@grem1in)
Ну и вообще, любой фидбэк приветствуется!

#chaos

Немного новостей от AWS (дайджеста ради):

- Amazon ECS теперь поддерживает Windows контейнеры. Поддержка до этого была в бета-версии

- io1 волумы можно розганять до 32,000 IOPS и 500 MB/s per volume

- Aurora теперь HIPAA Compliant

- Резилнулся Route 53 Naming API, который упрощает управление DNS для микросервисов, когда те скейлятся (вверх или вниз)

- Релизнулся AWS SSO - Single Sign In. Ну об этом уже многие писали

- Managed ElasticSearch обновили до версии 6.0

- Теперь можно кастомизировать верфикацию email в SES. Ну чтобы вы кастомерам вскую недописанную фигню не слали

- AWS нотифает, когда вы подходите к лимиту Free Tier. Ну об этом я уже тоже писал

- Можно делать кластерные проверки в CloudWatch

Пока писал, задумался, что Безос долетит до Марса раньше Маска...

#aws

В Docker Enterprise Edition и Docker для Mac и Windows добавили нативно Kubernetes. В том смысле, что вам уже не потребуется minikube

Пока что в закрытой бете, попросить доступ можно тут:

https://beta.docker.com

Но судя по реакции людей, они пока не особо доступ раздают.

#docker #kubernetes

Как-то месяц назад (кстати ровно месяц назад) Turbine Labs написали статью о том, как переехали с Nginx на Envoy. Тогда об этом все очень много писали.

Ну и народ такой: ну Ок, какая-то контора переехала на новый модный прокси. Однако, если вам интересно копнуть, что ж такое этот зверь — Envoy, вот тут неплохой дилннопост на Medium:

https://medium.com/@copyconstruct/envoy-953c340c2dca

Оригинальная статья TurbineLabs:
https://blog.turbinelabs.io/our-move-to-envoy-bfeb08aa822d

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