Возможно, многим знакома библиотека ELMAH (Error Logging Modules and Handlers), которая позволяет организовать простое журналирование ошибок для любого сайта, созданного с помощью .NET Framework.

Этот простой и проверенный временем инструмент выручал меня во многим проектах.
Несколько лет назад, создавая свой новый проект под .NET Core я с досадой обнаружил, что ELMAH не работает под .NET Core.

Но это же opensource проект! Несколько выходных в работе над форком, и вот готова первая версия ELMAH работающая под .NET Core.

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

Хочу поделиться своим опытом реализации микросервисной архитектуры поверх actor-model фреймоворков, таких как AKKA и Microsoft Orleans.

Моя гипотеза: если использовать один стек для реализации микросервисов, то можно:

• Существенно снизить сложность разработки и объем кода
• Упростить отладку и поиск ошибок
• Упростить деплой
• Упростить задачу определения границ сервисов
• Избавится от ограничения применения stateful-сервисов
• Упростит работу с распределенными транзакциями.

О… Похоже на «серебряную пулю»! Давайте разберемся, так ли это.

В рамках современной микросервисной архитектуры мы можем разделить микросервисы на две основные группы в зависимости от их взаимосвязи и взаимодействия. Первая группа представляет из себя внешние микросервисы, которые напрямую доступны пользователям. В основном это API на основе HTTP, которые используют обычные текстовые сообщения (JSON, XML и т. д.), оптимизированные для использования сторонними разработчиками, использующие передачу репрезентативного состояния (REST) ​​в качестве коммуникационной технологии. 

Распространенность и хорошая поддержка REST играют решающую роль в успехе внешних микросервисов. OpenAPI предоставляет четко определенные спецификации для описания, создания, использования и визуализации REST API. Для таких API существуют системы управления API, которые обеспечивают безопасность, ограничение скорости, кеширование и монетизацию наряду с реализацией бизнес-требований. В качестве альтернативы REST API на основе HTTP можно использовать GraphQL, но это уже тема для отдельной статьи.

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

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

INTRO

Вы когда-нибудь задумывались как устроен ID видео на YouTube?
Возможно, вы уже знаете/нашли ответ, но, как показали обсуждения на Stack Overflow, многие понимают эту технологию неправильно. Если вам интересно изучить что-то новое, добро пожаловать под кат.

В этом году, когда из-за пандемии все мероприятия перешли в онлайн, мы уже проводили «фестивальчик на удалёночке» TechTrain. Теперь число заражений снова бьёт рекорды, вопрос «как интересно провести выходной дома» снова актуален, и мы устраиваем TechTrain 2020 Autumn: он состоится 24 октября.

Что можно будет увидеть? И доклады, и различные разговорные формы: круглые столы, интервью, набросы в прямом эфире. И, как водится на TechTrain, топовых спикеров, которые в своей сфере пользуются большим уважением. Например, на вопросы о производительности будут отвечать трое экспертов сразу: двое из Java-мира (Алексей Шипилёв и Андрей Паньгин), третий из .NET (Андрей Акиньшин).

Какие-то темы рассчитаны на определённых разработчиков («Ускоряем Flutter-разработку»), какие-то — на всех («Будущее IDE»). Расписали все темы под катом.

Сегодня хочу рассказать о нашем пути реализации межпроцессного взаимодействия между приложениями на NET Core и NET Framework при помощи протокола GRPC. Ирония заключается в том, что GRPC, продвигаемый Microsoft как замена WCF на своих платформах NET Core и NET5, в нашем случае случился именно из-за неполноценной реализации WCF в NET Core.

Я надеюсь эта статья найдется поиском когда кто-то будет рассматривать варианты организации IPC и позволит посмотреть на такое высокоуровневаое решение как GRPC с этой, низкоуровневой, стороны.

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

Disclaimer: это мой личный топ из тех книг, которые я лично прочитал, и у которых первое издание было в прошлом веке, даже если она переиздавалась недавно (при условии актуальности именно того издания, которое было в прошлом веке).

В данном топе книги не упорядочены по важности, они все очень хорошие, но есть одна книга, которая равнее других.

Начало

Привет, Хабр!

Микросервисы уже давно стали классикой в бэкенд архитектуре, но в отличие от бэкенда, во фронтенде одновременно можно использовать только один фреймворк. Это порождает неудобства при масштабировании и переиспользовании модулей. Микросервисный подход избавляет от необходимости придерживаться конкретного фреймворка и дает возможность программисту сосредоточиться на конкретном модуле с использованием наиболее удобных для него инструментов. Мы не пропагандируем расширение зоопарка технологий и использование каждого фреймворка необходимо тщательно обдумать, прежде чем внедрять. Подробнее — в статье от разработчика команды BSL gyk007.