Похвастаюсь. Делаем с Федей аудит одного крупного финансового сервиса. Сегодня был третий день встреч с техдиром.
Каждый фиолетовый прямоугольник — это довольно большой сервис (отдельный репозиторий), над которым работает своя команда.
На схеме примерно треть, а то и четверть всей системы. Базы по много терабайт, тысячи интеграций — вызывает уважение, да что говорить, восхищение, что всё это работает и приносит пользу и деньги. 😍
Готовил вчера отчет по техническому аудиту для одного нашего клиента. Хочу поделиться с вами абзацем, где мы объясняем трудности программирования на пальцах:
… «Лапша в бизнес-логике». Бизнес-логика в приложении — это цепочка вызова команд. Эти цепочки часто содержат больше 7 шагов. Это больше, чем человек может уместить в голове. Чтобы решить эту проблему, люди описывают цепочки в одном месте, последовательно: одна строчка — один шаг бизнес-процесса (пример на руби). В нашем проекте, сейчас, это не так. Логика бизнес-процессов кочует из файла в файл. Пример: … — в попытке отследить бизнес-логику платежей мы «прыгнули» по коду 11 (!) раз. Это бесчеловечно. …
Мне очень нравится, что мы с Федей привлекаем экспертов себе в помощь. Я уже писал об Антоне Давыдове, но если вдруг пропустили — вот его канал в телеге. Кайфую каждый раз, когда делаю что-то вместе с Антоном.
Segment — очень классный сервис, который собирает данные аналитики и раскидывает по десятку доступных интеграций, которые вы выберете. Этакий мультиплексер аналитических данных.
Они рассказывают, как уткнулись в проблемы производительности, выделили отдельные задачи в микросервисы и стало лучше. В течении года число похожих друг-на-друга микросервисов выросло до 140(!) и начались серьезные проблемы менеджмента зависимостей и деплоя. Тогда они собрали все сервисы обратно в один четкий монолит и опять задышали свободно.
Отличный пример, который показывает, что каждому инструменту (и подходу) — своё время и место. Включайте мозги, не идите на поводу у хайпа.
Программисты любят приводить аналогию строительных блоков. Мол «соберём из готового». По моему опыту - обычно, «блоки» мало похожи на Лего и гораздо больше - на этот вот прекрасный конструктор :)
Хорошая полемическая статья (aka trolling) на на тему «чем плох REST».
1. Переводить сложные операции на язык, в котором всего 4 глагола - то ещё развлечение.
2. В парадигме REST неестественно передавать изменения машины состояний, а это часто необходимо и ошибки на этом фронте могут быть фатальны.
3. Коммуникация ошибок и других особых состояний: «всегда HTTP 200 OK, а ошибка в теле» или придумаем свои коды?
https://medium.com/@pakaldebonchamp/rest-is-the-new-soap-97ff6c09896d
Мой вывод: парадигмы, правила и концепции - это наши рабочие инструменты. Не человек и дела для инструментов, но наоборот. Каждой задаче - свой инструмент. Черт, кажется это просится в инстаграм глубокомысленные цитаты. Сорян.
Рассказываем, как устроены подкасты в Медузе https://dev.meduza.io/eff4c68d24f2
Составляем карту технологических зависимостей Медузы.
Это схема того, где искать поломку, если что-то вдруг идет не так. Продуктов и сервисов становится так много, что в скоро связи между ними перестанут помещаться в голову без препаратов.
Посередине слева — полный список «пользовательских view»: то, откуда можно читать Медузу. Web, iOS, Android, Instant Articles, etc. 20 пунктов.
Ряд сверху — список зависимостей для каждого View. Зависимости есть от внутренних сервисов и от внешних.
Завтра будем составлять список зависимостей для внутренних сервисов — там уже будут базы данных, серверы и прочие низкоуровневые элементы.
Где лучше составлять такие схемы? Я пока остановился на Scapple. Кстати, эта же компания уже много лет производит очень мощную программу для писателей Scrivener — ведь не всем писателям нравится WordStar.
Извините, что не хайрез. Смысл, надеюсь, понятен.
Я сейчас пишу пост про пуши и прекрасный Google Firebase, а тут такая вот свежая страшилка про SaaS в целом и Firebase, в частности.
Компания написала систему автоматизации умного дома, довольно успешную, установила её на десятки тысяч домов по всему миру. В каждом доме, программа запрашивала определенный файлик раз в минуту с серверов Firebase, чтобы определить, нужно ей что-то делать или нет. И всё было классно, пока Firebase не поменял какие-то кишочки и не начал биллить весь TLS трафик, а не только полезный payload.
Счет в Firebase вырос с 25$ в месяц (так было несколько лет) до 1750$ в месяц и продолжает расти. Способа обновить программу у пользователей, чтобы она не использовала Firebase — не существует (IoT, маленькие железки). Техподдержка Firebase сначала что-то отвечала, потом просто пропала с радаров.
Дальше автор статьи предлагает делать свои прокси перед любыми SaaSами. Помню, обещал такое сделать в Медузе примерно полгода назад, когда Слек сломался.
P.S. Этот пост я написал на прошлой неделе, с того времени поднялся хайп на hackernews. Firebase, конечно же, вышел на связь (сам founder & CEO Firebase отметился в medium replies) и всё быстро починил. Такой вот уровень техподдержки.
У строителей под моим окном классическая «микросервисная архитектура приложения». У них есть 3 сервиса — полый бур, сверлящий дырку в земле, бетономешалка, не дающая бетону застыть и насос, закачивающий бетон из мешалки в отверстие, сверлимое буром.
Красным на картинке отмечены места, в которых один сервис «передает» бетон другому. Там должны быть подходящие отверстия, крепления и допустимое предельное давление бетона (чтобы это всё не разорвало) — это API. API — договоренности, по которым сервисы общаются друг с другом.
Допустим, можно было бы сделать убер-машину, которая умеет все — сверлить, качать и мешать. Засыпаете бетон, вставляете сверла и она делает вам готовые заполненные бетоном дырки — это была бы «монолитная архитектура приложений». Её было бы сложнее транспортировать по улицам и, наверное, ей нужен был бы очень крутой инженер для обслуживания.
В случае разделения машины на части мы можем выбрать разных производителей отдельных частей, достаточно, чтобы все они соблюдали стандарты и поэтому могли работать вместе.
