Очень часто при обсуждении многопоточности на платформе .NET говорят о таких вещах, как детали реализации механизма async/await, Task Asynchronous Pattern, deadlock, а также разбирают System.Threading. Все эти вещи можно назвать высокоуровневыми (относительно темы хабрапоста). Но что же происходит на уровне железа и ядра системы (в нашем случае — Windows Kernel)?

На конференции DotNext 2016 Moscow Гаэл Фретёр, основатель и главный инженер компании PostSharp, рассказал о том, как в .NET реализована многопоточность на уровне железа и взаимодействия с ядром операционной системы. Несмотря на то, что прошло уже пять лет, мы считаем, что никогда не поздно поделиться хардкорным докладом. Гаэл представил нам хорошую базу по работе процессора и атомнарным примитивам.

Вот репозиторий с примерами из доклада. А под катом — перевод доклада и видео. Далее повествование будет от лица спикера.

Архитектор – это звучит… Звучит как-то не понятно. Наверное, поэтому всегда добавляют что-то. Ну типа «системный архитектор» или там «программный архитектор». Не то чтоб так стало понятно, что он делает, но точно кто-то важный. Я вообще пишу «архитектор информационных систем и программного обеспечения». Это ж как назовёшься -так и поплывешь! С архитекторами тут вообще такое дело – это как бы и не профессия. Ведь архитектором как стать? Либо тебя назовут таковым, либо сам назовёшься. Другого пути нет. Ни школы, ни спец. образования, никаких то там универсальных сертификатов нету. Только название и есть.

А раз оно есть – значит зачем-нибудь нужно! А нужно чтоб как-то указать на необходимость главного элемента мозаики – архитектуры. А раз нужен элемент, то за него, конечно, должен кто-то да отвечать. А раз должен, то вот и появляется такая должность.

Появляется, кстати, не всегда и не везде. Ведь не в каждой луже можно встретить кораблик. В самых больших - есть шанс. В такие лужи обычно и заплывают корабли из стартрека. Enterprise. Что же ищут эти корабли в корпоративных болотах? Чтоб вода не иссыхала, ветер только попутный и кругом гавани с блекджеком… Проще говоря им нужен сервис на много лет и так, чтоб исполнялись все их капризы за обещанные деньги.

Чтоб избежать проверенного классического сценария «много, дорого, бестолково» нужны ориентиры. Пунктир намеченного пути на карте требований и функционала. Это не красота и элегантность рисунков Леонардо, и не лабиринты цвета Поллока. Архитектура вообще не про искусство. Нет, все любят, когда красиво. Вот я бы строил дом, тоже бы хотел не бетонную коробку, а чтоб в вечность. Но у вечности, однако свои расценки. Так что даже Джи-мэн с кейсом полным золота хочет хайп и тренды, но строго в бюджет. Архитектура даёт парадигму.

По мере роста вашей инфраструктуры наличие роботов и надежная централизованная система логирования становится критически важными составляющими. Централизация логирования становится ключевым аспектом множества IT-задач и дает вам хороший обзор всей вашей системы.

Лучшее решение — агрегировать логи с метаданными из всех контейнеров. Это предоставит вам лучшие варианты отслеживания и возможность получить хорошую поддержку от сообщества. Здесь на сцену выходит ELK Stack. ELK, также известный как Elastic stack, представляет собой комбинацию современных инструментов с открытым исходным кодом, таких как ElasticSearch, Logstash и Kibana. Это полное решение для сквозного анализа журналов, которое вы можете использовать в своей системе.

Каждому компоненту отведена определенная роль: ElasticSearch лучше всего хранит необработанные логи, Logstash помогает собирать и преобразовывать логи в согласованный формат, а Kibana добавляет отличный уровень визуализации и помогает вам управлять вашей системой в удобной для пользователя манере.

В этом руководстве вы узнаете, как развернуть ELK и наладить агрегирование контейнерных логов. Мы собираемся объединить ELK с Filebeat, чтобы агрегировать контейнерные логи. Для этого мы собираемся создать собственный образ Docker.

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 лучших практик, используемых мной и моими коллегами старшими .NET разработчиками, которые и вдохновили меня написать эту статью. Эти методы научат вас определять, когда в приложении возникает утечка памяти, находить и исправлять ее. Наконец, я включил в статью стратегии для мониторинга и отчета об утечках памяти в уже развернутых программах.

• CancellationTokenSource — создаёт маркёры отмены (свойство Token) и обрабатывает запросы на отмену операции (перегруженные методы Cancel/CancelAfter).
• CancellationToken — маркёр отмены; позволяет несколькими способами отслеживать запросы на отмену операции: опросом свойства IsCancellationRequested, регистрацией callback-функции (через перегруженный метод Register), ожиданием на объекте синхронизации (свойство WaitHandle).
• OperationCanceledException — исключение, выброс которого по соглашению означает, что запрос на отмену операции был обработан и операция должна считаться отменённой. Предпочтительный способ генерации исключения — вызов метода CancellationToken. ThrowIfCancellationRequested.

Сталкиваясь с неопределенностью в процессе разработки, нам стоит пересмотреть взгляды на то, что для нас значит "двигаться быстро".

На прошлой неделе мы выпустили расшифровку первой части онлайн-встречи «Управление разработкой в «горизонтальных» компаниях», где приняли участие СТО Райффайзенбанка, Mindbox и руководитель разработки в Циан. 

Сегодня публикуем вторую и последнюю часть митапа: это вопросы «из зала», которые задали слушатели гостям. Пост получился объемным, поэтому, если не хотите читать, то посмотреть видео можно ниже (запустится сразу с нужного момента — там, где закончилась первая часть). 

• всегда ли ваши проекты выполняются в определенные сроки?
• Были ли у пользователей какие-либо жалобы?
• Поддержка проекта никогда не занимала много времени?
• Новый функционал всегда удачно вписывается в существующую архитектуру?

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