Микросервисы / распределенные системы
4.21K subscribers
107 photos
1 video
21 files
318 links
Мысли, новости и ссылки по распределенным система и распределенной разработке.

Рекламу не размещаю.
Download Telegram
​​Получается такая аккуратная картинка, которая достаточно неплохо встраивается в текущие процесссы любой организации от стартапа до very big enterprise.

Это один из множества способов сформировать достаточно стройную и понятную система работы с архитектурой со встроенным процессом анализа и непрерывных улучшений и с поддержкой эволюционного развития как самого продукта, так и его архитектуры.
Продолжим тему истории компаний, на этот раз — SoundCloud. Объемная и достаточно детальная статья:
https://philcalcado.com/2015/09/08/how_we_ended_up_with_microservices.html
Groupon тоже перешел на микросервисы и достаточно давно, их история:
https://engineering.groupon.com/2013/misc/i-tier-dismantling-the-monoliths/
И про микросервисы в Gilt, так же достаточно интересная статья. Интересна, как и другие статьи, тем, что в них не теория, а что компании в действительности делали (может иногда и преукрашено и слишком асбрактно, но общее направление увидеть не сложно)
https://www.infoq.com/news/2015/04/scaling-microservices-gilt/
Всех с наступающим Новым Годом! 🎄🥂⛄️
​​Краткое сравнение SOA и микросервисов от infopulse
Сделал редирект на канал ArchDays в youtube c http://archdays.ru/youtube/
Теперь делится ссылкой на канал станет проще.

А странно в этой истории то, что все условия для того, чтобы сделать человеческий урл, вроде /archdays на самом youtube все условия уже год как выполнены, но google по неизвестной причине не дает возможность этого сделать, поддержка молчит. Если кто-то знает, как решить проблему (обложка есть, лого есть, подписчиков > 600) – напишите в комментариях, буду признателен за помощь.
Для микросервисной архитектуры жизненно-важным является наличие DevOps-культуры. При этом эту культуру пытаются как-то измерить, но чаще пытаются измерить производительность команд, нередко, чтобы сравнивать между собой (facepalm).
По мне так это странный способ и сами три пути DevOps и принципы CALMS дают ответ на то, что следует измерять, а в книге Accelerate так вообще все раскладывается по полочкам.
Посмотрим на измерение важных вещей в трех измерениях:
1. Outcomes на уровне компании
2. Здоровье команд
3. Компетенции

Почему именно эти срезы? В чем-то это моя любимая фрактальная структура. Outcome (так я не нашел достойного перевода этому термину для отделения от output и result, можете предложить вариант в коментариях), так вот, outcome на уровне компании — это результат работы команд, состоящих из людей, обладающий нужными компетенциями на необходимом уровне.

Далее по-порядку:
Метрики уровне компании, мой перевод из отчета State of DevOps 2019