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

Преимущества подхода:
- возможна технологическая разнородность;
- легко достигается изящная деградация;
- отдельные части системы независимо масштабируются;
- независимое развертывание сервисов;
- простое разделение отвественности между командами.

Казалось бы, можно заменить микросервисную архитектуру простым вынесением кода в библиотеки. Но это решает только часть проблем — невозможна техническая разнородность, простое масштабирование, независимое развёртывание. Плюс, остается проблема неконтролируемой связности.

Микросервисы — не серебряная пуля. Они подвержены всем проблемам распределённых систем. Важно научиться качественно развёртывать, тестировать и мониторить такую систему. Микросервисная архитектура подходит не всем компаниям.

#микросервисы

Кстати, напоминаю, что микросервисы — это не только бекенд. Посмотрите хороший доклад про микро-фронтенды.

Микро-фронтенд

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

Сейчас вокруг многие обсуждают микросервисы на фронтенде. Значит немного странно, но, вероятно, нам это нужно.

Тематический доклад — Разрываем монолит.

#фронтенд #архитектура

​​С Новым годом, друзья 🎉

Спасибо, что читаете этот канал.

​​Немножко статей для чтения на праздниках. Две софт-скиловые, одна совсем простая и одна очень серьезная.

+ Работа программистом, свой бар и квест-рум: последние полгода я совмещаю это всё — автор боится не выдержать конкуренции с молодыми специалистами через 10-20 лет и готовит запасные варианты, звучит как отличная идея

+ Good times create weak men — программисты теряют экспертизу, размышления о причинах и последствиях

+ Качество кода — довольно попсовая статья о способах сделать код лучше, очень базовая, но качественная

+ Функциональное программирование: дурацкая игрушка, которая убивает производительность труда (часть 1, часть 2) — ну тут все понятно, просто прочтите

#дайджест

​​Осознанная меркантильность

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

Тематическая статья — Осознанная меркантильность.

#softskills

Архитектор развития

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

Работа архитектора в меньшей степени касается конкретных сервисов и в больше степени — их связей, пространства между микросервисами, способов их взаимодействия.

Основные отвественности архитектора:
• определение концептуального технического устройства системы;
• умение сотрудничать в лидерами отдельных команд для выработки архитектурных решений;
• коррекция уровня автономности команд.

#микросервисы

На Хекслете вышла статья «Преждевременная оптимизация: абсолютное зло или иногда полезная практика?», в которой кажется все специалисты выразили завидное единодушие. Почитайте.

#общие_знания

Всех нас занимают вопросы: «Как стать лучшим инженером?», «Как расти профессионально?». На них в целом, похоже нет ответов. Зато можно попробовать изменить отдельные аспекты своей работы.

Хороший тематический доклад — Мерцание технологий, или Инжиниринг.

#softskills #рост

​​Зачитываюсь книгой про микросервисы, поэтому статей на этой неделе совсем мало 😢

+ Архитектура программного обеспечения переоценена, простой и понятный дизайн — недооценен — архитектура ПО не то, чем кажется, отличный обзор от Гергелия Ороса (чувак из Uber)

+ Понимание брокеров сообщений — вообще-то это книга, но на Хабре сейчас выходит ее перевод по главам, первая глава — хорошее введение в тему

+ Метапрограммирование в JavaScript и TypeScript — немногие разработчики пользуются приемами метапрограммирования, а это мощная концепция, которая может сильно упросить код

#дайджест

Я читаю много статей на английском, но почему-то не хотел их добавлять в дайджесты. Добавить?
anonymous poll

Да – 254
👍👍👍👍👍👍👍 92%

Нет – 21
👍 8%

👥 275 people voted so far. Poll closed.

Типизация

Я большой адепт ограничений. Люблю, когда инструмент заставляет меня писать лучший код. Строгая статическая типизация — это как раз такие ограничения. Да, нужно больше думать, тратить больше времени. Зато результат получается лучше.

Но, к сожалению, в JavaScript-мире я не могу получить желаемого. Самый популярный инструмент типизации TypeScript дает мне статическую слабую типизацию. Плюс в нем довольно плохо работает вывод типов, очень мягкие правила проверки типов по умолчанию. Этого мало. Поэтому, я с интересом смотрю на альтернативные решения. Elm, Scala.js, PureScript — это все очень весело, но абсолютно бессмысленно. Слишком непопулярные решения, которые требуют менять кодовую базу.

Недавно наткнулся на Hegel.js — это статический типизатор, которые переваривает аннотации типов от TypeScript, но лишен его проблем. Если этот проект дойдет до продакшн-реди состояния, я обязательно возьму его в пару проектов. Доклад автора на HolyJS — Как и зачем я пишу свой статический типизатор.

Что такое сильная/слабая и статическая/динамическая типизация рассказывал тут.

#языки

Шрифты

Во фронтенд разработке есть две проблемы: подключение шрифтов и настройка CORS.

Вадим Макеева рассказал в докладе все о шрифтах в вебе: как их правильно подготовить (сжать, обрезать) и подключить. Смотрите его доклад со странным названием _ __ _____?.

С CORS все сложнее, пару месяцев назад осерчал и запилил мини-тред в твиттере.

#фронтенд

Как моделировать сервисы

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

Слабая связность — это когда можно легко внести изменения в один сервис, не трогая остальные. Чтобы этого достичь, нужно гарантировать, что каждый сервис знает о других только необходимый минимум.

Связанное поведение должно находиться в одном месте. То есть, все части внутри сервиса должны относиться к одной и той же области. Это сильное зацепление.

Делить сервисы по ограниченным контекстам (понятие Эрика Эванса из книжки DDD) — хорошая идея.

Обычно, системы проще начинать создавать как монолитные, а потом разбивать на микросервисы. Это связно с ценой ошибки. Если система была неудачно нарезана на ограниченные конктесты, перекроить модули внутри монолита дёшево, а переделать микросервисы — дорого.

Сервисы не должны делиться по принципу «владения данными», лучше смотреть на бизнес-возможности.

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

#микросервисы

​​Суббота начинается с дайджеста статей. Насладжайтесь.

+ О 30-кратном увеличении параллелизма в Node.js — отличная история рефакторинга, который сэкономил компании 300 тысяч долларов за год;

+ Делаем HTTP-запросы, изящно деградируем (и ни единого разрыва) — хорошая статья про аккуратную работу с сетью;

+ Чем программирование сегодня отличается от программирования 20 лет назад? — очередное размышление на тему плачевного состояния нашей индустрии, но в этот раз справедливое.

И еще три англоязычные статьи:

+ Goodbye, Clean Code — Дэн Абрамов рассказывает когда нужно и когда не нужно делать код «чистым»;

+ How to move your project to TypeScript - at your own pace — статья о постепенном переводе приложения на TypeScript без большой единовременной траты времени;

+ who are you trying to impress with your deadlines? (перевод) — критика необоснованных дедлайнов, замораживания состава спринта, очень актуальная тема.

#дайджест

Собрал книги, которые считаю обязательными к прочтению в единый список с краткими описаниями.

https://read.kamyshev.me

Ставьте звездочки на гитхабе, присылайте пулл-реквесты — igorkamyshev/mustread.

Интеграция

При выборе языка общения сервисов нужно обратить внимание на следующие характеристики:
+ возможность вносить не-ломающие изменения в протокол;
+ независимость протокола от языка (технологии);
+ сокрытие деталей реализации сервиса.

С точки зрения управления бизнес-процессами, затрагивающими несколько сервисов, можно выделить два типа — оркестровый и хореографический. При оркестровом типе управления должен существовать один сервис, который бы координировал работу остальных. При хореографическом — все сервисы информируются о задаче и они сами решают как на неё реагировать. В первом типе удобнее строить синхронное взаимодействие между сервисами, при втором — асинхронное.

Оркестровый принцип управления опасен тем, что провоцирует разработчиков создать «божественные» сервисы, которые знают слишком многое, зато он простой. При хореографическом принципе эта проблема решается, но бизнес-процесс становится не таким явным. Чтобы отслеживать прогресс такого процесса нужно строить более сложную систему мониторинга. Технически реализовывать системы построечные на хореографическом принципе сложнее, но это даст больше гибкости в будущем.

#микросервисы

Какие софт-скилы нужны

Сейчас популярно мнение, что софт-скилы для разработчика супер-важны. Иногда, они даже важнее технический экспертизы. Есть две проблемы:
1. непонятно, какие скилы нужны;
2. непонятно, как их развивать;

Андрей Смирнов нашел интересный рецепт выбора самых важных навыков и сделал доклад The state of soft skills. Он классный, посмотрите.

#softskills

Сегодня дайджеста не будет, простите. Я в мини-отупске и не хотел его готовить. 🙄

Говорить в мире собеседника

Мой опыт работы начался с фриланса. Неотъемлемой частью было общение с заказчиками: сбор требований, согласование работы, решение проблем вроде сдвинутых сроков.

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

Объясню на примере. Представьте, что человеку нужно сделать сайт, а он в этом ничего не понимает. Он нанимает специалиста и в какой-то момент интересуется, как продвигается работа. Ему отвечают:

> У меня возникли проблемы с модулем кеширования страниц в WordPress, почитал StackOverflow, там рекомендуют обновиться до PHP 7, тем более в нём появились декларации типов, которые очень полезны в разработке. Я обновил PHP, но из-за этого пришлось решать проблемы с новым механизмом обработки ошибок. К счастью, как раз сегодня закончил с этим разбираться и доделал главную страницу, двигаюсь дальше!

Что из этого понятно заказчику:

> доделал главную страницу, двигаюсь дальше!

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

Чтобы не совершать этих ошибок, можно пользоваться двумя приёмами:

1. Отвечать на вопросы максимально коротко, не погружаясь в детали. Собеседник при необходимости переспросит или уточнит важные ему детали.
2. В разговоре ставить себя на место собеседника и стараться оценить, будете ли вы ему понятны.

Это сильно упростит жизнь вам и всем, с кем вы будете разговаривать.