Есть среди программистов такая фракция, в которой Kubernetes пользуется дурной репутацией как чрезмерно сложный пожиратель времени и технология, которой следует сторониться стартапам. Использовать Kubernetes в рамках небольшой команды — явный признак инженерного переусложнения.

Я и сам замешан в перемывании косточек на эту тему.

TPM (Trusted Platform Module) — это международный стандарт, обеспечивающий доверенную работу с вычислительными платформами в целом и предоставляющий ряд возможностей обеспечения безопасности в компьютерных системах, в частности: хеширование, шифрование, подписывание, генерацию случайных чисел и т.д.


Он был разработан консорциумом TCG (группа по доверенным вычислениям) и стандартизирован в 2009 году Международной организацией по стандартизации (ISO) и Международной электротехнической комиссией (IEC), получив номер ISO/IEC 11889:2009.

SQL в API??? 

Верно, вы уже успели подумать: «это же безумие, предоставлять API, который принимает SQL». Да, это ужасная идея. Особенно, если API обращён к Интернету. Делать так небезопасно, вы напрашиваетесь на атаки в виде SQL-инъекций. Поддержка такого интерфейса превратится в кошмар, а сама реализация бэкенда будет замкнута на конкретную технологию (это будет какая-нибудь база данных ANSI SQL).

Но справедливо ли такое суждение? Время его пересмотреть!

Некоторое время назад я написал статью, в которой критически высказался о Linux-разработчиках, не желающих поддерживать дистрибутив, если он предназначен для работы на компьютерах, которым более 15 лет. За это я получил немало критики от читателей с Hacker News. Кто-то указывал, что я не понимаю, насколько же это сложно – создать и поддерживать дистрибутив Linux. Были и такие, кто советовали мне просто накатить на старый компьютер старую версию Windows. Я же начал пользоваться Linux в первую очередь для избегания Windows, так как считал её монструозным порождением Билла Гейтса. Фактически, разработчики операционной системы, ранее обещавшие освободить меня от Windows, теперь склоняют меня вернуться к Windows, как только мой компьютер настолько состарится, что им станет неудобно его поддерживать. Ответы, которые я получаю от Linux-разработчиков, явно свидетельствуют, что Linux больше не является операционной системы для технарей-компьютерщиков, желающих сохранить на ходу свои любимые винтажные машины. Напротив, Linux превратился в операционную систему, которую разработчик рассматривает как средство для прокачки карьеры. Те, кому интересно подробнее разобраться в нарастающей дисфункциональности Linux и узнать, почему сложилась такая ситуация, могут посмотреть это видео на YouTube.

❯ Кэши для отдельных ядер процессора

В TCMalloc кэши для отдельных ядер процессора реализуются при помощи перезапускаемых последовательностей (man rseq(2)) под Linux. Эту возможность ядра разработали Пол Тёрнер и Эндрю Хантер из Google, а также Мэтью Дезнойерс из EfficiOS. При помощи перезапускаемых последовательностей можно вплоть до завершения выполнять область памяти (атомарно, относительно других потоков, выполняющихся на том же ядре процессора), либо выходить из этого процесса, если ядро прервёт этот процесс, например, вытеснив его или прервавшись на обработку сигнала.

Если вы хотите организовать перезапуск системы при миграции с ядра на ядро или при вытеснении процесса, то наиболее общий случай такой операции можно оптимизировать (не переносить с ядра на ядро тот процесс, который уже выполняется), избегая атомарных операций. Можно оптимизировать и более редкий случай – вытеснение как таковое. В результате такого компромисса нужно обеспечить, чтобы на всех путях выполнения нашего кода поддерживались такие операции перезапуска. Вся последовательность, кроме окончательного сохранения в памяти, когда изменение фиксируется, должна быть приспособлена к перезапуску.

Расскажу, как мы в PayPal начинали осваивать Kubernetes. На тот момент большинство наших рабочих нагрузок выполнялось на Apache Mesos, и в рамках этой миграции нам требовалось разобраться с некоторыми аспектами производительности у кластеров, в которых будет работать Kubernetes – с учётом той плоскости управления, что действует в PayPal. Из всех этих аспектов важнее всего было понять, как именно масштабируется платформа, а также выявить, как можно было бы улучшить масштабируемость, настраивая параметры кластера.

Тогда как Apache Mesos может прямо из коробки масштабироваться вплоть до 10 000 узлов, масштабировать Kubernetes непросто. При масштабировании Kubernetes требуется учитывать не только количество узлов и подов, но и ещё некоторые вещи, в частности: сколько ресурсов создано, сколько у нас контейнеров на под, сколько всего сервисов задействовано, а также пропускная способность при развёртывании подов. В этом посте описаны некоторые проблемы, с которыми нам довелось столкнуться при масштабировании, и рассказано, как нам удалось с ними справиться.

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

Командам, которые занимаются обработкой данных (поступающих пакетными партиями в рабочих потоках) сложно соответствовать современным требованиям по обработке данных в режиме реального времени. Почему? Потому что пакетный поток данных – от доставки данных до их дальнейшей обработки и анализа – это такая вещь, при работе с которой нужно уметь ждать.

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

Но в опенсорсном пространстве есть решение, разработанное в опенсорсе. В сочетании друг с другом Apache Kafka, Flink и Druid, позволяют создать архитектуру для обработки данных, которая работает в режиме реального времени и позволяет исключить все эти этапы ожидания. В этом посте мы исследуем, как комбинация этих инструментов позволяет создавать широкий спектр приложений для обработки данных в режиме реального времени.

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

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

Многие из тех, кто устанавливает дистрибутив Linux для одной-единственной цели, например, для работы с контейнерами, предпочитают развёртывание по принципу «поставил и забыл». На конференции FOSDEM 2023, состоявшейся в Брюсселе, было представлено несколько проектов из разряда таких «минимальных дистрибутивов Linux». Все они — Fedora CoreOS, Ubuntu Core, openSUSE MicroOS и Bottlerocket OS – решают такие задачи по-своему. Из выступлений на FOSDEM можно составить интересную перспективу, демонстрирующую, в чём эти проекты отличаются на уровне применяемых подходов.

Один из самых естественных треков развития для программиста – стремиться стать программным архитектором. Проектирование систем – непростое дело, а для того, чтобы построить сложную систему, нужно как быть экспертом-технарём, так и обладать опытом в предметной области. На наработку этих навыков требуется немало времени и усилий. Читая книгу Марка Ричардса и Нила Форда «Фундаментальный подход к программной архитектуре», я нашёл у них метафору «архитектурных ката». В их трактовке ката – это отработка решения для элементарной задачи. Я решил опробовать подход с ката, чтобы прокачать мои навыки проектирования систем.

Не так давно я побывала на конференции Kubecon 2023 в Чикаго. Готовясь к конференции, я почитала статьи в блогах, а на самой конференции посетила несколько семинаров для начинающих (в жанре «101»). Но всё равно не могла сказать, что уверенно понимаю эту технологию. Хуже всего прошёл последний день конференции. Я решила добираться в отель на такси и вызвала Uber. И водитель спрашивает: «А о чём была конференция»? Я ему отвечаю: «О Kubernetes». Попыталась объяснить, но почти сразу поняла, что двух слов на эту тему связать не смогу.

Только представьте себе: уезжать с трёхдневной конференции, но быть не в силах рассказать таксисту о той технологии, которая на ней обсуждалась. Фейспалм. Поэтому теперь попытаюсь реабилитироваться и пофантазировать, как следовало бы рассказать о Kubernetes таксисту Uber.

Вам не казалось, что игры у вас на компьютере постоянно тормозят и лагают? Если освоить разгон графического процессора, то ваши любимые игры и мультимедийные приложения, вероятно, станут работать как по маслу. Не нужно довольствоваться низкой кадровой частотой или неоптимальными настройками. Учитесь безопасно разгонять GPU, чтобы с полным правом сказать: «да у меня зверь-машина». Кроме того, научитесь пользоваться специальным оптимизационным софтом, при помощи которого удобно высвобождать пространство под данные, повышать скорость и необычайно наращивать производительность.

Из каких соображений можно хранить данные в виде ячеистой сети

Во всех организациях, где мне доводилось работать, всегда понимали важность данных. Поэтому я видел, что руководство либо заинтересовано, либо прямо планирует создать платформу нового поколения для обращения с этими данными. Как правило, ставится цель перейти от сильно связанных интерфейсов и вариабельных потоков данных к целостной архитектуре, которая позволяла бы аккуратно связать всю экосистему. Речь идёт о распределённой облачной ячеистой топологии (data mesh), где данные можно группировать в зависимости от их предметной области, трактовать “данные как продукт,” организуя в каждой предметной области конвейерную обработку собственных данных. Такой подход отличается от перекачки данных (data plumbing), практикуемой на традиционных (монолитных) платформах, которые, как правило, отличаются сильной связанностью данных. Из-за этого зачастую замедляется поглощение, хранение, преобразование и потребление данных из централизованного озера или хаба.

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

Гексагональная архитектура — это архитектурный паттерн, представленный Алистером Кокберном и описанный у него в блоге в 2005 году. Основная идея заключается в том, чтобы структурировать приложение таким образом, чтобы это приложение можно было разрабатывать и тестировать в изоляции, не завися от внешних инструментов и технологий.

Вот как сам Кокберн описывает эту архитектуру одним тезисом:

Добиться, чтобы приложение в равной степени могло управляться пользователями, программами, автоматизированными тестовыми или пакетными сценариями, а также разрабатываться и тестироваться в изоляции от устройств и баз данных, на которых оно впоследствии будет выполняться. — Алистер Кокберн, 2005 г.

В этой статье мы рассмотрим некоторые задачи, как правило, решаемые в типичных программных проектах. Затем мы поговорим о гексагональной архитектуре и о том, как она призвана решить эти задачи. Мы также рассмотрим некоторые детали реализации такой архитектуры и варианты тестирования.

JavaScript — это мощный язык, который является частью фундамента интернета. У этого мощного языка также есть некоторые свои особенности. Например, знаете ли вы, что значение 0 === -0 равно true, или что Number("") дает 0?

Дело в том, что иногда эти причуды могут заставить вас почесать в затылке или даже задаться вопросом, был ли Брендан Эйч под кайфом в тот день, когда он изобретал JavaScript. Что ж, дело здесь не в том, что JavaScript — плохой язык программирования или он — зло, как говорят его критики. Со всеми языками программирования связаны какие-то странности, и JavaScript не является исключением.

В этом материале мы покажем подробное объяснение некоторых важных вопросов на интервью по JavaScript. Моя цель будет состоять в том, чтобы тщательно объяснить эти вопросы, чтобы мы могли понять лежащие в их основе концепции.

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

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

Объединим две эти цели – и обнаружим, сколько же существует странных и магических методов для неблокирующего совместного использования данных в разных потоках. Давайте поговорим об одном из этих методов – «чтение-копирование-запись» (RCU).

Terraform позволяет создать облачную инфраструктуру с помощью всего одной команды. Допустим, вы хотите запустить Elasticsearch и Kibana в кластере Kubernetes.

Для этого можно написать несколько файлов .tf и выполнить команду terraform apply для инициализации кластера Kubernetes и развёртывания на нем нескольких подсистем.



Теперь предположим, что вам нужны и другие экземпляры стека Elastic, которые можно использовать для демонстрации. В этом случае придется создать новые рабочие пространства Terraform и выполнить terraform apply несколько раз.

Проблема такого подхода заключается в том, что в этом случае придется каждый раз реплицировать всю инфраструктуру. Следовательно, у вас будет несколько кластеров Kubernetes. На запуск каждого кластера уходит не менее 15 минут, а его стоимость на AWS составляет 72 долл. в месяц.



Гораздо лучшей альтернативой было бы повторное использование одного кластера Kubernetes и создание на его основе нескольких сред. Таким образом, вы платите за один кластер, и вам не нужно ждать создания нового кластера каждый раз, когда вы создаете новую среду.

Сигнал SIGSEGV, применяемый в Linux, означает нарушение сегментирования в рамках работающего процесса. Ошибки сегментирования возникают из-за того, что программа пытается обратиться к участку памяти, который пока не выделен. Это может произойти из-за бага, случайно вкравшегося в код, либо из-за того, что внутри системы происходит некая вредоносная активность.

Сигналы SIGSEGV возникают на уровне операционной системы, но столкнуться с ними также вполне можно и в контексте контейнерных технологий, например, Docker и Kubernetes. Когда контейнер завершает работу, выдав код возврата 139, дело именно в том, что он получил сигнал SIGSEGV. Операционная система завершает процесс контейнера, чтобы предохраниться от нарушения целостности памяти.

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

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

В нынешнюю эпоху пластика, силиконовых женщин и одноразовых вещей хочется чего-то надёжного и долговечного. Хочется привыкнуть к компьютеру, сделать его частью своей жизни, а может и семейной реликвией, которая достанется правнукам. Естественно, при возможности простого апгрейда компонентов.

Реально ли создать такой компьютер? Представьте, что после Апокалипсиса работающий ПК станет настоящим подарком для многих поколений одичавших потомков… А если жизнь пойдёт обычным порядком, всё равно приятно прикоснуться к такой реликвии через какие-нибудь 100 или 500 лет.