Kubernetes сейчас называют стандартом для оркестрации контейнеров. Он лежит в основе многих облачных платформ контейнеризации: например, мы давно развиваем наш Kubernetes aaS на платформе Mail.ru Cloud Solutions.

Однако Kubernetes далеко не первый подобный инструмент на рынке: некоторые из систем-предшественников продолжают активно использовать и вроде бы даже успешно.

Почему так происходит, несмотря на то, что Kubernetes, можно сказать, одержал победу в своем классе и мы видим много примеров, когда он приходит на смену другим решениям? Например, не так давно разработчики Mesosphere DC/OS, в основе которой лежал Apache Mesos, прекратили ее развитие и сфокусировались на другой своей платформе — D2iQ Kubernetes (DKP). Думаю, что стоит разобраться, всегда ли хорош Kubernetes, когда оправдано использовать другие оркестраторы и о каких подводных камнях стоит знать.

Я Дмитрий Лазаренко, директор по продуктам облачной платформы Mail.ru Cloud Solutions (MCS). В этой статье расскажу об устройстве ряда оркестраторов-предшественников, сравню их с Kubernetes, посмотрю на его преимущества и недостатки по сравнению с ними.

В этой статье я расскажу про 8 методик оптимизации загрузки изображений, которые уменьшают необходимую пропускную способность сети и нагрузку на процессор при выводе на экран. Приведу примеры аннотированного HTML, чтобы вам было легче воспроизвести. Какие-то методики уже давно известны, а какие-то появились относительно недавно. В идеале, ваш любимый механизм публикации веб-документов (например, CMS, генератор статичных сайтов или фреймворк для веб-приложений) должен всё это реализовывать из коробки.

Я, Дмитрий Лазаренко, руковожу командой, создающей и внедряющей собственный Kubernetes aaS на платформе Mail.ru Cloud Solutions. Давно работая с внедрением Kubernetes, мы часто сталкиваемся с недопониманием нюансов этой технологии. Хочу рассказать о типичных стратегических просчетах при внедрении Kubernetes в крупных проектах.

Как сделать так, чтобы любой разработчик мог быстро накидать решение своей проблемы и гарантированно доставить его в прод? Деплоить приложение просто. Сделать из него полноценный продукт, чтобы десяток команд использовал его на сотне инстансов — сложнее. А если речь про мастер-систему на несколько терабайт, то уровень тревожности повышается, руки потеют, а база трещит по швам (может быть).

Я хочу поделиться способом деплоить без простоя и без отказа в обслуживании. Пайплайн на Jenkins, ноль посредников, 500 инстансов в production-среде за 60 минут. Всё это в опенсорсе. За подробностями приглашаю под кат.

Нет, это не очередная реклама одного известного автомобильного бренда. И даже не попытка литературного разбора стихотворения Рождественского. Речь пойдет о картах. Мы в Mail.ru Group продолжаем развивать собственные геосервисы как для нужд внутренних проектов, так и для запуска новых продуктов для широкого круга пользователей. Ядром географических данных для наших сервисов выступают данные картографического проекта OpenStreetMap. Но мы не хотим быть просто ленивыми потребителями, которые, получая обратную связь от пользователей, хранят исправления в локальной базе данных и не делятся ими с общественностью. Мы активно вносим свой вклад в проект OpenStreetMap. В цикле статей мы решили рассказать, как корректно вносить правки о наиболее насущных для нас объектах географической действительности.

Однажды на Zoom-созвоне нашей команды нить дискуссии ушла за пределы планируемого. На удаленке такое часто случается, потому что всем не хватает обычного «кухонного» общения в офисе. Разговор начался с итальянской книги, где на всех языках мира написано «Я тебя люблю». Потом были возражения, что языки программирования тоже языки, почему их там нет??? Затем мы вспомнили, что не за горами День всех влюбленных. Так мы придумали, как сделать ремейк этой книги на свой лад, а заодно вспомнить про свежий рейтинг языков программирования от IEEE.

Книгу мы выпустили небольшим тиражом, а в этом посте публикуем ее содержание: признания в любви на 53 самых популярных языках программирования. А в качестве бонуса предлагаем краткое описание каждого из них.

В наших образовательных проектах используется проектный подход. Студенты Технопарка, Техносферы, Техноатома, Технотрека и других совместных с вузами образовательных программ под конец обучения объединяются в команды, работают над проектами и представляют жюри финальные работы. 7 декабря 2020 года прошла защита таких работ в онлайн-формате, по итогам голосования лучшими признали 4 проекта.

Лучшие практики, несмотря на термин, не всегда хороши. В программировании многие из них не оправдывают своего названия. Они распространяются не благодаря своим заслугам или доказательствам эффективности, а из-за эффекта авторитета и использования обществом. По мере их распространения теряются нюансы. А с потерей нюансов становится легче заниматься их евангелизмом. В сочетании с нехваткой опыта это может привести к возникновению культа лучших практик. Представьте команду, которая одержима их использованием — скажем, разработкой через тестирование (test-driven development) или написанием пользовательских сценариев, — до такой степени, что это уже вредит. В эту ловушку попадали многие, в том числе и я.

Почему лучшие практики могут быть вредны? Почему мы любим им следовать? Когда и как они мешают? Чтобы ответить на эти вопросы, нужно понять, откуда берутся эти практики и как они распространяются в программировании.

В этот статье я хочу еще раз пройтись по особенностям работы транзакций в Tarantool, применительно к движку в памяти и дисковому движку. И главное — расскажу про новый менеджер транзакций, который появился в Tarantool версии 2.6, про его особенности, преимущества и устройство.

Когда меня спрашивают, что такое Tarantool, я отвечаю давно въевшееся в мозг: «Tarantool — persistent in-memory noSQL СУБД с хранимыми процедурами на Lua». Но всë не так просто. Вот in-memory — да, в основном в Tarantool используется memtx engine, движок в памяти, однако дисковый движок (vinyl) тоже давным-давно есть, и у него множество нюансов и особенностей. Или noSQL — да, в основном Tarantool используется как noSQL БД, но SQL он тоже умеет, точнее, какую-то его часть, а какую именно — это надо почитать.

Даже с хранимыми процедурами не совсем всё просто: то, что затевалось как способ сделать JOIN в noSQL БД, обросло кооперативно-многозадачной инфраструктурой для работы с сетью, файлами, HTTP, массой модулей и документации; сейчас Tarantool именуют сервером приложений с БД на борту. Да и хранимые процедуры бывают не только на Lua, но и на C.

Но это, в общем, скорее приятные оговорки, дескать, что поделать, Tarantool сложный и поэтому есть много деталей. А когда меня кто-нибудь спрашивал, есть ли в Tarantool’е транзакции и какой у них уровень изоляции, то я отвечал: «есть, serializable, но...» И далее следовали оговорки мелким шрифтом, которые портили радужную картину и время от времени вызывали негодование пользователей.

Больше никаких оговорок, пора рассмотреть новый менеджер транзакций под микроскопом.

Осталось всего годик потерпеть: по мнению итальянского журнала 1968 года так должен был выглядеть мир в 2022-м.

«Два по двадцать» — не лучший год в мировой истории. Он запомнится как угодно, но только не как год свершений, открытий или достижений (если только не какого-нибудь «дна»). Хотя, благодаря своей «круглости», многие футуристы и прогнозисты использовали его как некий рубеж, год возникновения каких-то прорывных технологий или изобретений. Давайте вспомним, какие предсказания не сбылись в Год Пандемии.

Предположим, мы создали кластер Kubernetes. И кто-то из команды разработчиков хочет развернуть и протестировать на нем новое приложение. Как нам предоставить ему доступ в кластер?

Команда Kubernetes aaS Mail.ru Cloud Solutions перевела простое руководство по предоставлению доступа к новому кластеру Kubernetes, включая настройку аутентификации и привязку ролей. Автор показывает процесс, используя клиентский сертификат x509.

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

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

Задача реализации синхронной репликации стояла перед командой разработчиков Tarantool долгие годы, к ней было совершено несколько подходов. И вот теперь в релизе 2.6 Tarantool обзавёлся синхронной репликацией и выборами лидера на базе алгоритма Raft.

Привет! Меня зовут Юра Дорофеев, я работаю над Android-версией мессенджера ТамТам. Представьте, что вы договариваетесь о встрече с другом, и он отправляет вам адрес. Но не отдельным сообщением, а посреди другого текста:


Как этот адрес быстро вставить в навигатор или карту? Приходится копировать всё сообщение, потом вырезать лишнее. А если вы за рулем, то проще переписать адрес с нуля или вообще озвучить его голосом. Ну и моё самое любимое — поздравления с днем рождения. В текущих реалиях это номер банковской карты среди текста сообщения:


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

Правда ли, что разработка в B2B и B2C — это совершенно два разных мира? Многие разработчики считают, что в B2B:

- медленная и неповоротливая разработка;

- используются технологии 10-летней давности;

- мало возможностей для профессионального развития;

- нужно постоянно писать кучу ненужных документов;

- приходится делать продукт только для клиента и сложно увидеть результат своей деятельности.

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

Я Дмитрий Лазаренко, директор по продуктам облачной платформы Mail.ru Cloud Solutions (MCS). Наша компания — B2B-проект, который вырос из стартапа внутри большой группы компаний. 

Расскажу о том, как у нас организованы процессы, вместе с нашими разработчиками: руководителем разработки MCS Михаилом Кебичем, руководителем разработки IAM и Hotbox Викторией Сусловой, старшим программистом команды разработки PaaS Азатом Хадиевым.

В декабре 2020 года, за неделю до нового года, компании Semrush и Mail.ru Group решили провести совместное обучающее мероприятие по информационной безопасности в формате CTF. 

Причём тут разработчики, тестировщики и devops, зачем и почему – расскажем в этой статье.

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

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

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

В этой серии статей я расскажу почти всё, что нужно знать о генераторах в JavaScript: что это такое, как их использовать и какие тонкости с ними связаны. И, как всегда, начнём мы с основ — общего представления о том, что такое генераторы.

Я не исхожу из того, что вы хоть что-то знаете о генераторах. Но вам требуется хорошо разбираться в итераторах и итерируемых объектах в JavaScript. Если вы с ними не знакомы или «плаваете в теме», то сначала углублённо изучите их. Если же вы владеете этими знаниями, то можно погружаться в мир генераторов. Это очень странный мир, в котором многое совершенно не похоже на то, что вы используете в обычном JS-коде. При этом сам механизм очень прост, и даже после прочтения этой статьи вы сможете уверенно использовать генераторы. Приступим!

В 2020 году, как никогда раньше, стала очевидна необходимость сделать цифровое пространство инклюзивным и доступным для всех. Из-за продолжающейся пандемии, которая осложнила личный доступ к услугам и перевела целые отрасли в онлайн, особенно сильно страдают люди с ограниченными возможностями. К тому же их количество с растет из-за долгосрочных последствий пандемии.

Есть много статей, объясняющих, для чего нужен Python GIL (The Global Interpreter Lock) (я подразумеваю CPython). Если вкратце, то GIL не даёт многопоточному чистому коду на Python использовать несколько ядер процессора.

Однако мы в Vaex исполняем большинство задач с интенсивными вычислениями на С++ с отключением GIL. Это нормальная практика для высокопроизводительных Python—библиотек, в которых Python всего лишь выступает в роли высокоуровневого связующего звена.

GIL нужно отключать явно, и это ответственность программиста, о которой он может забыть, что приведёт к неэффективному использованию мощностей. Недавно я сам побывал в роли забывшего, и нашёл подобную проблему в Apache Arrow (это зависимость Vaex, так что когда GIL не отключается в Arrow, мы (и все остальные) сталкиваемся с падением производительности).

Кроме того, при исполнении на 64 ядрах производительность Vaex иногда далека от идеала. Возможно, он использует 4000 % процессора вместо 6400 %, что меня не устраивает. Вместо того, чтобы наугад вставлять выключатели для изучения этого эффекта, я хочу разобраться в происходящем, и если проблема в GIL, то хочу понять, почему и как он тормозит Vaex.