Backend Engineer
В своем стремлении перейти на микросервисы я столкнулся с аналогичными проблемами. Чаще всего я работал с клиентами и корпорациями, чей «микросервисный» дизайн приводил к единому моносервису. По сути, монолитное приложение было заменено действительно большим RESTful API.
Я решил рассмотреть пример создания целенаправленного микросервисного дизайна… правильным способом.
На тему миграции с монолита на микросервисную архитектуру были написаны замечательные статьи, например, эта, возможно, относится к лучшим примерам. Преимущества и недостатки этих архитектур должны быть достаточно очевидны. Однако я хочу поговорить о другом: о стратегии. Мы создаем монолиты, потому что с ними легче начинать работу. Микросервисы обычно возникают в силу необходимости, когда наша система уже находится в продакшне.
Однако при принятии решения о необходимости миграции возникает множество вопросов: как вы определяете границы услуги? Как вы проверяете свойства самовосстановления архитектуры микросервиса?
Это особенно сложно с учетом распределенности сервисной сетки. Нам нужно иметь представление обо всем приложении, поскольку его фрагменты разделены. Наша цель — сохранить преимущества, которые мы имели в унаследованном монолите, избежав при этом сильной связанности, которая является его неотъемлемой частью. В данной статье я расскажу о некоторых практических подходах, которые вы можете использовать при выполнении этой миграции.
В этой статье расскажем о решении для поддержки бизнес-процессов оператора и управления доходами. Также поделимся опытом разработки одного из его компонентов с использованием микросервисов. Эта информация будет полезна как для инженеров, которые собираются применять микросервисную архитектуру в разработке приложений, так и для владельцев и менеджеров продуктов, которые должны иметь представление о ее основах для оценки связанных с проектом рисков.
В серии из трех статей рассказываем о переходе с монолитной на микросервисную архитектуру. Разбираемся, когда и кому это действительно нужно, рассматриваем 7 миграционных шаблонов и самый больной вопрос: «Как быть с данными?».
От автора: в этой статье я поделюсь своим опытом тестирования микросервисов. В последние годы команды разработчиков программного обеспечения внедряют архитектуру микросервисов, чтобы иметь возможность разрабатывать, тестировать и деплоить сервисы независимо и быстро. Для эффективного тестирования таких систем необходимо хорошо знать их архитектуру.
В серии из трех статей рассказываем о переходе с монолитной на микросервисную архитектуру. Разбираемся, когда и кому это действительно нужно, рассматриваем 7 миграционных шаблонов и самый больной вопрос: «Как быть с данными?».
Привет, Хабр! Меня зовут Руслан Сафин и я расскажу про микросервисы и как определить необходимую гранулярность. Я работаю техническим директором в Byndyusoft. Развиваю техническую культуру и участвую в проектах в роли IT-архитектора, а ещё преподаю авторский курс по IT-архитектуре в университете. В коммерческой разработке 15 лет. Из необычного — проектировал защиту от накруток в интернет-голосовании конкурса Мисс Россия и автоматическое определение предвзятости судей в танцевальном спорте.
Byndyusoft занимается заказной разработкой с продуктовым подходом. Так как наша компания работает с крупными заказчиками, мы постоянно учимся новому, перенимаем и сами делимся практиками, наблюдаем и используем разные подходы и приёмы проектирования. Этим практическим опытом я и поделюсь в статье.
Микросервисная архитектура помогает строить гибкие и масштабируемые приложения. Однако в случае бессистемного использования этого подхода вы довольно быстро столкнётесь с разочарованием и неконтролируемыми сложностями. Избежать проблем помогает Domain-Driven Design (DDD) — предметно-ориентированное проектирование. В статье расскажем о принципах его работы, а также разберём основы стратегических паттернов в Golang.
Думаю, не я один упирался в стеклянный потолок, когда действия есть, а результата нет. Кажется, еще чуть-чуть и все изменится: бизнес попрет, навыки прокачаются, доходы увеличатся, но несмотря на все усилия — ничего не меняется. Хочу поделиться несколькими ловушками мышления, из-за которых возникает бег на месте, и которые доставили мне особенно много хлопот.
Я пообщался с коллегами из геймдева и попросил их дать рекомендацию или какие-то напутственные слова, которые бы помогли начинающим разработчикам игр или были бы полезны тем, кто уже давно работает в индустрии. В результате получилась подборка советов от специалистов из разных областей, которая на мой взгляд будет полезна всем, кто занимается созданием игр. Приятного чтения!
Управлять программистами в ИТ-компании – дело особое. Не сказать, что сильно сложное. Совру, если назову простым. Особое.
Книжек, статей, курсов создано великое множество. Что-то помогает, у кого-то получилось. Собственно, промахнуться с оценкой сложно – отрасль ведь не просто существует, но и весьма активно развивается. Даже в нашей деревне. Значит, как-то, кое-как, с горем пополам, но управление программистами не только возможно, но и получается.
Однако, кризисы случаются. Бывает, что затяжные – например, какая-нибудь серьёзная деревенская компания не может ни найти, ни воспитать приличного руководителя программистов. Благо, сейчас это не великая проблема – бизнес вполне себе растёт лишь потому, что растёт рынок, и заполнить его некому. Поэтому за начальника сойдёт и табуретка. Но – лишь до поры, до времени.
Регулярно ИТ-бизнес думает-думает, решает-решает, плюнет, да и снова попробует старый добрый метод: нанять успешного руководителя из другой сферы. Производство, строительство, торговля – ну суть. Оттуда много кандидатов, у них подтверждённый опыт, зачастую – MBA, и они такие прям чёткие всегда! Знают, чего хотят, на что способны, чего им нужно.
Мне этих руководителей всегда искренне жаль – я знаю, что их ждёт, каков будет их путь, почему они в итоге уволятся. Я не семи пядей во лбу, просто в течение многих лет наблюдал их в обеих сферах – ИТ и той, из которой они пришли, где добились успеха. Могу плюс/минус сопоставить контексты, работающий инструментарий, важные и второстепенные личностные качества.
Много раз пытался объяснить, помочь – и начинающим руководителям-варягам, и тем, кто их тащит в ИТ. Никто, разумеется, не слушал. Ну да я уже привык, поэтому сижу себе помалкиваю.
Однако, тут такая история вышла: в ИТ-компанию собралась устроиться некто Ира, хорошая знакомая моего хорошего знакомого. Он, как мог, пытался её отговорить, но не преуспел, т.к. сам работает программистом, и руководителем никогда не был.
Попросил меня. Я предложил формат статьи – и моё мнение услышит, и ваше. В конце концов, вполне возможно, я не прав, как это обычно случается (если верить вашим комментариям).
Итак, погнали. Буду писать, как бы лично обращаясь к Ирине.
За последние два года роль тимлида в ИТ-компаниях существенно выросла. Но при этом повысились требования и функциональные обязанности лидеров команд, участники которых могут находиться в разных странах и часовых поясах. Умение обеспечить эффективную работу распределенных команд сегодня выходит на первое место и является важным компонентом выживаемости ИТ-бизнеса. О том, как изменилась роль тимлида в последнее время и об эволюции руководящих специалистов команда Artezio поговорила с экспертами отрасли во время публичной дискуссии.
Мало написать "программное обеспечение", - права на него надо ещё уметь защищать!
В российском праве "программное обеспечение" именуется "Программами для ЭВМ".
А термины "Программное обеспечение", "Софт", "Программный продукт" и т.д. - это сленг.
Программы для ЭВМ охраняются наравне с литературными произведениями, и поэтому программы для ЭВМ являются объектами права интеллектуальной собственности (точнее: авторского права).
Статья 1261 Гражданского кодекса РФ гласит, что "Программой для ЭВМ является представленная в объективной форме совокупность данных и команд, предназначенных для функционирования ЭВМ и других компьютерных устройств в целях получения определенного результата, включая подготовительные материалы, полученные в ходе разработки программы для ЭВМ, и порождаемые ею аудиовизуальные отображения".
При этом, по общему правилу, словосочетание "совокупность данных и команд" пока понимается именно как последовательность букв и иных символов в программном коде.
И поэтому пока что главным критерием для сравнения программ для ЭВМ является установление фактов идентичности исходных текстов (исходных кодов) этих программ.
Однако, как говорится "Гладко было на бумаге, да забыли про овраги".
Эта статья подготовлена на основе доклада «Микросервис головного мозга» Михаила Трифонова, Lead frontend Cloud и основателя frontend-сообщества TeamSnack. Мы разберём когда необходимы микрофронты, каким должен быть технологический стек, как нарезать мироксервисы и какие существуют стандарты при построении микросервисной архитектуры.
Эта статья, по сути, продолжение первой части «Микросервис головного мозга. Пилим всё, что движется». В ней Михаил рассказывал, как ему с командой удалось ускорить разработку с помощью микросервисного подхода. Они поэтапно строили микросервисную архитектуру, распилили монолит, UIKIT и создали архитектуру.
Ну, вы, наверное, слышали. Илон Маск недавно стал первым человеком в истории, потерявшим больше $200 млрд. Раньше рекорд был за Масаёси Соном, главой SoftBank, потерявшим $59 млрд в двухтысячном. На третьем месте легендарный Эйке Батиста, который в 2012-2013 гг. умудрился потерять $30 млрд и стать банкротом. А потом попытался выкрутиться из этого положения и попал в тюрьму на 30 лет. От седьмого богача планеты — до заключенного без гроша в кармане.
До банкротства и тюрьмы Маску еще далеко, он по-прежнему в топ-10 миллиардеров, но ещё один такой год (а дела с Твиттером складываются не очень хорошо) — и всё вполне может к тому прийти.