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

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

И последнее, думаю, надо представится. Меня зовут Владимир Воловиков. Опыт работы в сфере разработки программного обеспечения более 20 лет. В должности Системного архитектора и Программного архитектора, в общей сложности, более пяти лет. Имею четыре международных сертификата. Текущее место моей работы Системный архитектор, Банк ВТБ. 

Автор выражает благодарность людям, которые помогли в написании статьи:

И в особенности Махешу Балакришнану, к числу почитателей которого я присоединился:

Ничто как фундаментальный архитектурный подход

Привет, Хабр! Меня зовут Роман, я работаю разработчиком в компании Arenadata, где мы решаем много задач, связанных с Greenplum. Как-то мне представился случай разобраться с одним непростым, но вполне типичным для этой СУБД кейсом. Необходимо было выяснить, на обработку каких запросов уходит неадекватно много системных ресурсов. В этой статье мне бы хотелось поделиться своими наработками и рассказать о трёх проверенных мной способах мониторинга утилизации системных ресурсов, потребляемых запросами в Greenplum.

Исследование направленно на изучение вопроса построения архитектуры системы управления поведением объекта, как замены концептуального представления – «цифровой» двойник, часть полученных результатов разработок, изложенных в статье, показывают основные методы и подход системы

При зарождении, появлении концепции «цифрового» двойника, сформировалось несколько позиций, старающихся выразить концептуальное представление виртуального прототипа – «цифрового» двойника, существующего объекта. Промышленность начало рассматривать «цифровой» двойник как разновидность систем и сред: a) PLM – управление жизненным циклом изделия, под жизненным циклом в настоящей, принятой и распространённой на предприятиях, системе понимается процесс производства изделия, максимум передаются/получается данные применяемые в I) маркетинге, за частую не адресном или не объективном; II) сервисном (прим.: не в полной мере), хаотичном обслуживании выпущенных изделий, применяемых человеком или машиной (прим.: системой); b) PLM+ERP+датчики, представляемая система, при практическом построении, когда концепция начинает приобретать проектную архитектуру с набором методов, показывает такие же I и II проблемы, но в дополнении к этому появляется «слепая зона» в восприятии реальности, активней, сильнее влияющая чем первые (прим.: III).

Приведённые разновидности, рассматриваемые как организация и реализация «цифрового» двойника в существующей реалии, содержат набор проблем. Представленные выше в качестве нескольких примеров (прим.: I, II, III), должны учитываться в исследованиях, разработках, а также практических опытах при создании решений, перехода от концепции к проектной архитектуре – системе управления поведением объекта.

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

 Далее вы узнаете больше об этом путешествии и о том, как мы смогли:

• Уменьшить сложность для владельцев сервисов, которым больше не нужно знать и отвечать за терминацию протоколов безопасности и работу со множеством токенов безопасности,

• Повысить безопасность путем делегирования процесса управления токенами сервисам и командам, обладающим опытом в этой области,

• Улучшить возможности аудита и криминалистического анализа.

Перевод @middlejava

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

Что меня сподвигло написать эту статью? Определенный опыт взаимодействия с разного уровня руководителями. Рассмотрим такую ситуацию. У нас есть вакансия, звучит она как Архитектор. И, вроде бы, понимание есть, что должен делать этот человек, но по факту оказывается, ждут “эникейщика”. 

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

И последнее, думаю надо представится. Меня зовут Владимир Воловиков. Работаю в ИТ сфере я уже почти 20-ть лет. В должности Системного архитектора и Программного архитектора, в общей сложности, более пяти лет. Имею четыре международных сертификата. Текущее место моей работы Системный архитектор, Банк ВТБ. 

Привет! Меня зовут Иван, я занимаюсь бэкенд-разработкой в Ozon: пишу микросервисы на Go для личного кабинета продавца. В прошлом году мы запустили новый процесс регистрации продавцов, в котором задействовано сразу несколько микросервисов. В нём стало больше шагов, при этом каждый из них выполняется в разных микросервисах. Поэтому мы задались вопросом: «А что будет, если один из шагов упадёт?».

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

"Всякое решение плодит новые проблемы" (закон Мерфи)

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

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

Latency - очевидная метрика, приходящая на ум почти всегда, когда дело доходит до мониторинга наших сервисов. Будь это простой контроллер, воркер, вычитывающий ивент из очереди, или сервис, делающий бэкап вашей монги — любой логический кусок кода, перформанс которого для нас важен. Рассмотрим простой пример: у вас есть сервис, принимающий запросы от пользователей и возвращающий на UI необходимые данные. Если этот сервис в продакшне и вы уже достаточно зрелый проект, вполне вероятно, что вы уже настроили метрики и мониторите их. А может даже настроили алерты, pagerduty, назначили on-call инженеров, отчитываетесь за выполнение своих SLA раз в месяц. Почти наверное один из алертов у вас будет на latency этого сервиса. И я попробую угадать - вы используете персентили в качестве статистики.

Угадал? А что если я скажу, что это не лучший вариант? Что если я пойду дальше и буду утверждать, что персентили могут скрывать серьезные изменения в latency после очередного деплоя?

Более пяти лет назад мы запустили платформу Slack, предоставив разработчикам легкий способ создавать приложения в Slack и публиковать их в нашей App Directory. Сегодня миллионы пользователей переносят свою работу в Slack, и их приложения, создаваемые более чем 885 000 активными разработчиками, действующими на этой платформе – залог дальнейшего улучшения совместной работы в Slack. 

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

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

Я не утверждаю, что Slack всегда проектировал API хорошо. У нас были ошибки, и платформа определенно могла бы быть удобнее для разработчиков. Но мы признаем эти ошибки и определяем, как их исправить – иногда даже дополнительно упирая на то, чтобы придерживаться какого-то выбора, сделанного в прошлом, тогда как сейчас мы бы с этим выбором не согласились — и в целом можем улучшить для разработчика опыт работы с платформой.

Чтобы разработать свой распределенный SQL-движок, можно написать свой SQL-оптимизатор для построения движков. Вам придется сделать парсер, семантический анализатор и придумать правила трансформации и оптимизации. Всё протестировать, а потом как-то интегрировать в свою систему. Но можно пойти более быстрым путем — внедрить для этого готовый инструмент.

Владимир Озеров, бывший инженер Hazelcast, а сейчас руководитель Querify Labs, на конференции HighLoad++ 2021 поделился опытом разработки и проектирования с нуля распределенного SQL-движка для продукта Hazelcast IMDG. Видео его выступления можно посмотреть здесь.

Сегодня статья о том, для чего в Hazelcast IMDG понадобилась эта разработка, и в чем преимущества и недостатки фреймворка Apache Calсite. Как на нем были реализованы встроенные оптимизации, выбор вторичных индексов и планирование перемещения данных в кластере. И как справились с описанием запросов произвольной сложности, кооперативной многозадачностью и оптимизированием сетевого протокола.

Здравствуйте, меня зовут Дмитрий Карловский. А вы на канале Core Dump, где мы берём различные темы из компьютерной науки и раскладываем их по полочкам.

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

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

Как бы хороша ни была ваша CDN, часть пользователей будет мучаться с её настройкой. Нам, как одному из топ-3 европейских CDN-провайдеров, очень хотелось сократить число таких пользователей до минимума. Для этого пришлось повозиться с интерфейсом личного кабинета, разработать плагины для CMS и, что самое главное, интегрировать CDN с DNS-хостингом. Теперь пользователи в no-code режиме подключают сеть доставки контента к своим сайтам за несколько минут. Рассказываем, как мы это сделали.

Как архитектор-консультант в Red Hat, я имел возможность поработать над множеством проектов для наших клиентов. У каждого из них есть свои особенности, которые, однако, имеют некоторые общие черты. Большинство клиентов хотят знать, как скоординировать запись в несколько систем одновременно. Ответ на этот вопрос обычно включает подробное объяснение двойной записи, распределенных транзакций, современных альтернатив, а также возможных сценариев сбоев и недостатков каждого подхода. Как правило, именно в этот момент заказчик понимает, что разделение монолитного приложения на микросервисы - долгий и сложный путь, обычно требующий компромиссов.

Non-fungible token (NFT) или невзаимозаменяемый токен – это криптографический токен, являющейся производной от смарт контрактов в Ethereum. Его основная уникальность от других крипто токенов вроде биткойна в том, что один NFT нельзя заменить другим. Каждый NFT это полностью уникальный токен, который присоединяется к конкретному цифровому файлу, что в таком случае делает файл уникальным. Даже если попытаться копировать этот файл NFT не скопируется и останется у первоначального файла, таким образом делая его оригиналом. NFT нельзя разделить или заменить, его можно сравнить с полностью уникальным предметом в реальном физическом мире.

Впервые NFT появился в 2017 году в сеть Ethereum в качестве игры «Криптокотики» (Crypto Kitties), в ней можно растить и разводить криптовалюту в виде котов. Отдельный криптокотик — олицетворение механики NFT. Его нельзя разделить, он обладает уникальным номером, геномом из 256-битной ДНК и 12 атрибутами, которые можно передать потомкам — цвет глаз, форму рта и прочее. В NFT вшита информация о создателе криптокотика, а также о его виртуальных отпрысках. В 2018 году самый дорогой криптокотик был продан за $140 тыс.

Но настоящий бум NFT произошел в начале 2021 года. С декабря 2020 по февраль 2021 общий объем продаж с NFT поднялся с 12 до 340 миллионов долларов США.  Это связанно с тем, что деятели искусства и пользователи сети стали увидели новые возможности продажи своих работ благодаря NFT. NFT решил основную проблему людей занимающимся цифровым искусством. Это проблема подтверждения подлинности объекта искусства.

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

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

Есть исследование от Google, которое говорит, что если ваш сайт открывается больше трех секунд, то вы потеряете около 40% десктопных пользователей и более 50% — мобильных. Еще есть репорт от Amazon, который говорит, что для Amazon каждые 100 мс дополнительного latency стоит им 1% продаж. В объемах Amazon это миллионы долларов.

В зависимости от вашего бизнеса вам стоит тоже ответить на вопрос: Does the latency matter?

Я работаю как системный инженер уже более 8 лет. Хочу поделиться опытом, который получил в процессе решения задач в компании Big Data Technologies. У нас есть какой-никакой highload. В пике это 30 тысяч rps, и вопрос с latency довольно остро стоит перед бизнесом.

Привет, меня зовут Денис, в Arenadata я занимаюсь Greenplum — распределённой СУБД с открытым исходным кодом, разработанной на основе PostgreSQL и заточенной под аналитический профиль нагрузки. Моя работа (помимо разработки) заключается в разборе инцидентов, когда в кластерах клиентов происходит что-то непонятное для нашей технической поддержки. Такие истории обычно заканчиваются детальным внутренним разбором произошедшего, рекомендациями для клиентов и внесением правок в код Greenplum (как в наш fork, так и в upstream). Я расскажу вам про один из инцидентов, которым я занимался в последнее время. Хотя этот случай не привел к технически сложным доработкам, он является показательным примером того, как мы исследуем проблемы с Greenplum. Заодно я расскажу о подробностях внутреннего устройства Greenplum и PostgreSQL, которые не описаны в документации.