Все крупные компании сейчас пытаются строить огромные централизованные хранилища данных. Или же ещё более огромные кластерные Data Lakes (как правило, на хадупе). Но мне не известно ни одного примера успешного построения такой платформы данных. Везде это боль и страдание как для тех, кто строит платформу данных, так и для пользователей. В статье ниже автор (Жамак Дегани) предлагает совершенно новый подход к построению платформы данных. Это архитектура платформы данных четвертого поколения, которая называется Data Mesh. Оригинальная статья на английском весьма объёмна и откровенно тяжело читается. Перевод так же получился немаленьким и текст не очень прост: длинные предложения, суховатая лексика. Я не стал переформулировать мысли автора, дабы сохранить точность формулировок. Но я крайне рекомендую таки продраться через этот непростой текст и ознакомиться со статьёй. Для тех, кто занимается данными, это будет очень полезно и весьма интересно.

Евгений Черный

Привет, Хабр! Меня зовут Иван, я разрабатываю сервис онлайн-голосований WE.Vote на основе блокчейн-платформы Waves Enterprise. Сама идея голосований в онлайне уже давным-давно реализована разными компаниями, но в любых кейсах «повышенной ответственности» все равно прибегают к старой доброй бумаге. Давайте посмотрим, как электронное голосование сможет посостязаться с ней в максимально строгих условиях.

«Как быстро мы упремся в сетевой канал, который использует Kafka — через года два или раньше?»

Общепринятые мировые практики против проведения нескольких трансформаций в компании одновременно. И все же они возможны, при соответствующей подготовке, привлечении необходимых ресурсов и правильном мониторинге результатов. Плюсами и минусами одновременных трансформаций на конференции DevOps Live 2020 поделился лидер трайба IT4IT в ОТП Банке Максим Ефимов. 

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

Продолжение. К предыдущим постам и карте цикла.

Будни разработчика. Цели определены, направления выбраны, задачи разжеваны. Нужно просто писать код и жевать кашку. Что может скрасить серость и однообразность существования? Конечно же daily standup - шоу, в котором есть место для каждого! Ну вот эти вот неожиданные «я посмотрел архитектуру и там ошибка» или вот «я добавил новый модуль, который нам может пригодиться в будущем» ну и, конечно, «я сделал всё проще и быстрей». Мы ведь именно ради этого делаем все церемонии груминга и планирования. Чтоб как бы подготовить почву и дать всем время посидеть молча и заготовить эти панчлайны на конец спринта. А самое обидное, что, потратив столько усилий, на сам стендап вы обычно не попадаете и панчи вам передаёт ваше начальство.

Эта статья является конспектом материала Effective Aggregate Design Part III: Gaining Insight Through Discovery.

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

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

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

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

Event storming — метод, который смещает акцент у событий с технического на организационный и бизнес уровни и помогает создать устойчивую модульную систему. Он нередко используется в контексте моделирования микросервисов. Но как применить его на практике?

При создании системы на микросервисах можно легко получить распределенный монолит. Event Storming не уберегает от этого на 100 %, но позволяет существенно снизить риск этого события. О том, как именно этого добиться, рассказал в своем докладе на конференции TechLead Conf 2020 практикующий консультант по архитектуре, процессам разработки и продуктовым практикам Сергей Баранов.

Всем привет! Давно читаю Хабр и руки чесались тоже написать чего-нибудь. Так получилось, что повод появился только когда я начал искать новую работу. Вдохновил меня на эту статью увлекательный рассказ о собеседованиях в Яндексе. "Хм, а мне ведь тоже есть чего рассказать" - подумал я и загорелся идеей описать свою историю о пройденных собеседованиях.

Небольшая вводная - я архитектор ПО и начиная с февраля месяца неспешно искал новую работу. За эти пару месяцев прошел около 20 собеседований и накопил небольшой опыт, которым хотел бы поделиться. Долго думал стоит ли указывать в данной статье названия компаний, которые особо "отличились" и пришел к выводу что лучше озвучить. Надеюсь, представители этих компаний не воспримут мои отзывы как попытку их очернить. Я бы хотел чтобы это воспринималось как конструктивная критика, которая поможет им понять что не так в существующих процессах найма сотрудников и исправить ошибки.

Итак, поехали! Что мы имеем - весна 2021 года и по моим (и не только моим) ощущениям рынок IT-специалистов сильно перегрет.  Рекрутеры в прямом смысле заваливают разными предложениями, причем высокие зарплатные ожидания мало кого пугают. На мой взгляд, одна из причин этого всего в том, что банки вдруг резко захотели в финтех. Очень много предложений от самых разных банков, но еще больше - от интеграторов, которым перепало от 15 млрд, которые ВТБ год назад решил вложить в развитие своего банковского ПО. Кроме банков и интеграторов удалось также пообщаться и с другими крупными и не очень IT-компаниями. О некоторых особо запомнившихся моментах в общении с рекрутерами хотел бы рассказать подробнее:

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

Как изменилась «удаленка» в 2021 году, после поправок в Трудовом кодексе – делимся нашим опытом. Как и многие в отрасли, мы остаемся на удаленке – для этого адаптировали к онлайну все процессы и взаимодействия в команде из 1000+ специалистов. Параллельно перестраиваем IT-офисы, вносим много изменений для будущей совместной работы. Рассмотрим правовой аспект и ответим на частые вопросы в статье, подготовленной нашей юридической службой.

Продолжение. К предыдущим постам и карте цикла.

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

Привет, Хабр! В комментариях к статьям из нашего хаба часто спорят: полезна ли Serverless. Хочу поднять флаг миротворца — и сказать, что бессерверная технология меняет весь рабочий процесс и взгляд на разработку. Для этого есть несколько причин.

Serverless смещает оплату в сторону подхода pay-as-you-go: вы платите столько, сколько израсходовано процессорного времени (плюс-минус 100 мс). Вы не ждёте запуска сервера, не распределяете нагрузку и не заморачиваетесь с техобслуживанием. Задача написана — задача исполнена. С другой стороны, возникают проблемы холодного старта, а многим проектам не подходит отсутствие чёткого контроля контейнера. В этой статье я расскажу, в каких именно случаях может пригодиться Serverless и когда к ней надо присмотреться.

Итак, в первой части было рассмотрено, какие бывают бизнес-процессы по степени их устойчивости к изменениям, технические концепции для реализации конкретного типа БП, а также пример логики добавления/удаления таска из адаптивной модели БП.
В этой части статьи собираюсь подробней описать, чем же adaptive BPM (aBPM) отличаются от normative BPM (nBPM) и от Adaptive Case Management (ACM), затем представить архитектуру получившейся aBPM системы.

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

Суть статьи очень простая - архитектор представитель бизнеса в разработке. Его амбассадор. Проводник мысли продакт-менеджера во все укромные уголки проекта. Продакту нужно дружить с архитектором. Быть с ним на одной волне. Только так он сможет получить ожидаемый результат.