Тред https://twitter.com/iximiuz/status/1337810082587963392

Я тут как-то уже писал про Cloud Native Landscape. Это такая крутая интерактивная визуализация всех CNCF проектов. В какой-то момент я даже поверил, что эта визуализация придает некоторый смысл зонтику CNCF. Но потом передумал и продолжил ломать голову над тем, почему вдруг мы получили такой взрывной рост каких-то cloud-native проектов (да, мутный термин). И тут недавно мне напомнили одну вещь про... микросервисы! Ни для кого не секрет, что на самом деле микросервисы пытаются решать организационные проблемы, а не технические. Типа как код и зоны ответственности поделить между командами и сделать так, чтобы никто не толкался. Конечно, разрезать все на микросервисы! Фишка в том, что это похоже создает целый пласт новых технических проблем. Большие монолиты были дофига сложными, писать код в shared environment было тоже сложно. А теперь вдруг сервисы стали маленькими и никто, кроме твоих товарещей по команде твой код не ломает! То есть жизнь стала вроде как проще. Но похоже есть в природе закон сохранения сложности. И вся эта сложность написания кода для монолита переползла на уровень инфраструктуры. И теперь мы должны думать, как эффетивный RPC уровень замутить, как HTTP запросы трейсить, как логи собирать с сотен контейнеров, service mesh всякие мутить и т.п. Так что похоже, что именно эти технические проблемы, появившиеся из-за перехода на микросервисы, и решают CNCF проекты.

https://iximiuz.com/en/posts/making-sense-out-of-cloud-native-buzz/

TIL: Оказывается, у понятия Cloud Native есть официальное определение! Да еще и переведенное на много-много языков! Вот вариант на русском:

Нативные облачные (Cloud native) технологии позволяют организациям создавать и запускать масштабируемые приложения в современных динамических средах, таких как публичные, частные и гибридные облака. Контейнеры, сервисные сита (service meshes), микросервисы, неизменяемая инфраструктура и декларативные API являются примером такого подхода.

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

Cloud Native Computing Foundation ставит целью адаптировать эту парадигму, развивая и поддерживая экосистему проектов, с открытым исходным кодом, независимую от их поставщиков. Мы демократизируем современные модели, чтобы сделать эти инновации доступными для всех.

https://github.com/cncf/toc/blob/master/DEFINITION.md

Не знаю, кто как провёл выходной, а я - рисовал 🙈

https://twitter.com/iximiuz/status/1353045442087571456?s=21

В опасное время живем, товарищи!

https://blog.google/threat-analysis-group/new-campaign-targeting-security-researchers/

Восхищаюсь людьми, которые имеют смелость разворачивать не-managed Kubernetes кластеры для своего production. Со стороны мне всегда казалось, что в этом cloud native зоопарке слишком много moving parts чтобы спасть спокойно. Не столько с технической точки зрения (это наоборот весело, как LEGO собираешь), сколько с точки зрения безопасности. Без выделенной (большой и опытной) команды для поддержки инфраструктуры, обычным dev командам путь только в облака - EKS или GKE, а лучше Fargate или Cloud Run.

Иначе получится что-то вроде этого:

https://twitter.com/iximiuz/status/1358392288708349952

И в продолжение темы веселых взломов...

https://twitter.com/iximiuz/status/1359599798278647808

Что-то я давно сюда ничего не писал... Отчасти потому, что последний месяц был по уши в работе над серией статей про Computer Networking для самых маленьких (с картинками).

https://iximiuz.com/en/posts/computer-networking-101/

TIL: nibble - 4 бита, aka полубайт!

bite - укус
nibble - что-то вроде покусывания


struct bpf_insn {
__u8 code; // <-- байт
__u8 dst_reg:4; // <-- полубайт
__u8 src_reg:4; // <-- еще один полубайт
...
};

Коротенько о зарплатах в Европе

Есть один товарищ, ex-разработчик, ex-Microsoft, ex-Uber. Но не из долины, а местный, европейский. У него классный блог про всякие engineering management темы. И, в частности, про зарплаты.

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

Суть простая: есть три лиги tech компаний. Классификация происходит по локализации рынка труда! Локальные компании конкурируют за специалистов (читай разработчиков) в своем городе. И такие локальные специалисты мигрируют из одной такой локальной компании в другую. Региональные компании конкурируют со всеми локальными, а также другими крупными игроками в их регионе/стране. Ну а глобальные готовы перевозить специалистов из других стран/континентов.

Зарплаты в каждой лиге отличаются в разы! Если принять за x1 зарплату разраба в локальной компании, то в региональной она будет x2. А в глобальной - от x3 до x10 и выше.

NB: x1 в Западной Европе это где-то 50-60K EUR в год.

Конечно, требования к специалистам отличаются в разных лигах. И уровень стресса, видимо, тоже. Но не думаю, что прямо в 10 раз... Как человек, прошедший путь от локальной, до около-глобальной компании говорю =) Так что каждый должен решить для себя, в какой лиге ему играть.

https://blog.pragmaticengineer.com/software-engineering-salaries-in-the-netherlands-and-europe/

P.S. Полагаю, что в некотором приближении такая модель верна для всего IT рынка труда, включая СНГ.

Rust увлечен идеей четкого владения данными. Вы начинаете со значения в стеке и перемещаете его. Когда вам нужно получить доступ к значению из нескольких мест, вы его копируете. Если копирование слишком дорого или неуместно, вы начинаете использовать ссылки. Ссылки могут быть ограничены сроком службы. Когда ансамбль времени жизни становится слишком сложным или невозможным для статического выражения, вы начинаете помещать свои значения в кучу и передавать указатели. Наиболее часто используемые типы указателей - это Box <T> и Rc <T>. Сами указатели являются переменными стека и, следовательно, подчиняются одному и тому же принципу владения. Box единолично владеет значением, на которое он указывает, поэтому мутации упрощаются. Rc обеспечивает долевое владение. С точки зрения компилятора, совместное владение означает отсутствие изменений. Если вам нужно изменить общее значение, компилятор вам больше не поможет. Вы отказываетесь от статического доказательства правильности и обманываете компилятор с помощью Rc<RefCell<T>>. RefCell обеспечивает фиктивную неизменяемость во время компиляции и позволяет получать изменяемую ссылку во время выполнения. Но за магию всегда есть цена! (c) Цена RefCell - паника во время выполнения, когда вы случайно получаете две изменяемые ссылки на одно и того же значение.

Мне определенно нравится качество этого перевода. Google Translate rules!

P.S. скоро допишу очередную дилетансткую статью по Rust'у

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

https://habr.com/ru/company/timeweb/blog/558612/