Монолит ⚔️ Микросервисы

Заметил, что многие свысока смотрят на монолит, наивно полагая, что микросервисная архитектура — это серебряная пуля. Я обсуждал этот вопрос с ex-CTO Яндекс.Еды (у которых монолит на PHP), а также моим ex-коллегой в Твиттере, который работал с кучей микросервисов в HeadHunter. Вот выводы, к которым мы пришли:

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

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

3. Последний аргумент, который все еще оставался — с микросервисами получается более чистая архитектура. Во-первых, судя по статье от AWS — это не так, неправильная архитектура на микросервисном уровне может еще сильнее по вам ударить. Во-вторых, архитектуру можно лечить и другими более простыми способами — например периодическими архитектурными ревью

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

On-demand эволюция

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

Когда мы начинали писать первый код, веб-сервер у нас крутился на одном инстансе в tmux’е, а релиз мы делали так: (1) git pull (2) остановить сервер (3) заново запустить. Легко и быстро: никаких лишних докеров и кубернетисов. Релиз делается за 5 секунд. Со временем мы стали обрастать большим количеством сервисов, которые все вместе поддерживать стало очень напряжно, да и для отказоустойчивости хотелось бы взять второй сервер. На поддержание такой инфраструктуры уходило уже слишком много времени, и лишь в этот момент мы смигрировали в кубер

Другой пример — тестирование. С самого начала мы покрывали код на бекенде и бизнес-логику юнит-тестами, потому что на практике уже через месяц все начинает ломаться. Однако, мы не помешаны на них. Безусловно, написание e2e тестов принесло бы дополнительную пользу, однако, на данном этапе багов, которые мы бы ими поймали, очень немного, поэтому сейчас мы не инвестируем в их написание

Третий пример — использование сторонних сервисов. Изначально мы использовали SaaS решение для трекинга наших авто. Но со временем поняли, что это очень связывает наши руки, да и не дешево стоит. В результате через год мы перешли на опенсорс решение, которое самостоятельно разворачиваем и имеем полную свободу

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

The most important graphic you can read today. ChatGPT thru the lens of Dunning-Kruger effect.

Q: Какие технологии ты считаешь перспективными, чтобы я смог в них развиться?

A: Короткий ответ такой — те, в которых ты крутой специалист. Например, найти грамотного старшего разработчика — не такая уж простая задача, при том, что джунов — пруд пруди. Так что ценность разработчика не сильно возрастет, если он будет знать всего понемногу

А чтобы стать крутым специалистом в какой-то области, ты должен понять свои сильные стороны и выбрать из них те, которые тебе особо нравятся. Именно в такой области ты сможешь обогнать других и стать неоценимым специалистом

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

Кто-то мог понять этот пост как "не нужно следить за трендами". Обязательно нужно! Но важно иметь фокус, во всех областях крутым специалистом не стать

Сегодня натолкнулся на видео — мол культ продуктивности вреден. Автор утверждает, что он “подсел” на это в течение 3 месяцев: стал рано просыпаться, делать зарядку и т.д., после чего почти на год (!) потерял вкус к жизни и вообще очень плохо работал. Вывод который он делает — развивайтесь качественно, а не количественно. Работайте умнее, а не больше

Звучит красиво, но я не согласен. И вот почему:
- Качество не противоречит количеству, если все правильно делать. Сэкономленное время не обязательно нужно работать — его можно потратить на себя, семью и т.д. Если же количество противоречит качеству, то да, тут нужно что-то менять
- Вся эта ситуация мне напомнила следующее: после первой тренировки у человека болит все тело, а силы еще не прибавилось. “Значит не работает” — думает он и забрасывает ходить в зал
- Вообще, если возникает какой-то побочный эффект, то прежде чем говорить "не работает", нужно поглубже покопаться и понять, а почему оно так происходит. Может ты что-то не так делаешь, а может это и вовсе норма, которую нужно перетерпеть

P.S. Если человек становится сектантом продуктивности, ради которой готов жертвовать всем, то это неправильно. Продуктивность — лишь средство к достижению более важных целей

Вспомнил одну золотую мысль, которую я услышал на тренинге по проведению интервью в Фейсбуке: “90% интервьюируемых не попадут к нам на работу, однако, наша задача — произвести на них хорошее впечатление. Почему это важно? Потому что люди формируют мнение о компании и работе в ней в первую очередь по своему общению с рекрутером и интервьюерами. Поэтому, даже если человек тупит и вы понимаете, что он не пройдет, попытайтесь сгладить его опыт, чтобы он ушел от вас не раздавленным, а напротив счастливым и посоветовал бы своим друзьям податься к нам”

Анти-пример этого правила, который приходит на ум — Яндекс (хотя может за последние годы что-то изменилось). Люди хейтили его (в довоенное время) в первую очередь за то, что они не просто провалили интервью, а потому что интервьюер вел себя надменно или высокомерно. В итоге Яндекс себе создал имидж гиков-зазнаек

❌ Неправильная стратегия фриланса ❌

Особенно если вы начинающий специалист, самое важное для вас, как говорила моя бабушка 😅: «поработать на авторитет, чтобы он потом работал на тебя». Конечно, можно постараться сделать свою работу «на минималках», но это не заслужит мою рекомендацию. А именно с хороших рекомендаций получают крутые проекты. Не забываем, что реальный рост EPAM-а начался именно с качественной работы, что потом повлекло за собой серию мощных рекомендаций

Так что если фрилансите — делайте это от души, и финансы не заставят себя ждать

Не раз замечал, что некоторые начинающие фаундеры постоянно смотрят и аргументируют стартапами-старичками: “а вот в Фейсбуке так-то”, “а вот в Гугле то-то”, “а вот Убер делал так”. И все бы хорошо, но есть несколько проблем:

- Взять решение 15+ летнего стартапа и применить на начинающий стартап подобно тому, как вы положите 40-килограммовую штангу на младенца. Логичнее уж тогда смотреть на гигантов в начале их пути
- 2010 год отличается от 2023, за последние 13 лет случилось много всего. С одной стороны стартапы стало делать намного проще, с другой стороны и конкуренция возросла

Перенимайте подходы, перенимайте мышление, никогда тупо не копируйте: всегда проводите сквозь призму времени и пространства, адаптируя под свой конкретный случай

P.S. Навеяно после просмотра недавнего видео от YC

Вчера узнал, что на паре по бизнесу в Назарбаев Университете UvU разбирают как пример отечественного стартапа 🚀

Следующий этап — Stanford Graduate School of Business 😎

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

Сами в UvU мы советуемся и с нашими инвесторами, и с хорошими друзьями, а также привлекаем менторов там, где самим не хватает экспертизы

В общем, будьте более открытыми: делитесь, общайтесь и спрашивайте советов, а также умейте слушать, особенно когда люди искренне желают вам успеха

Последние несколько недель проводил много интервью и еще раз убедился в трех тезисах:

1. Увеличивай воронку. Это кажется очевидным, но кол-во раз, которые я напарывался на те же грабли, рассматривая исключительно круг друзей, или только подписчиков своего канала, сложно сосчитать. Используйте все каналы и все возможности. Вы не знаете, откуда придет классный кандидат

2. Обложка имеет значение. Чем красивее у вас резюме, тем больше мне хочется пригласить вас на собеседование

3. Не важно какое было резюме, решение принимается исключительно по результатам собеседований. Очень часто было так, что резюме у человека топовое, а начинаешь собеседовать — вообще не шарит. И наоборот, естественно, тоже

Маркетплейсы — это сложно

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

1. Многие не умеют распознавать маркетплейсы. Uber, AirBnB, Amazon, HeadHunter — все это примеры маркетплейсов: с одной стороны есть “покупатели”, кто хочет получить какую-то услугу, с другой стороны “продавцы”, которые эту услугу предоставляют

2. Самая большая сложность и основная задача во всех маркетплейсах — уровнять спрос с предложением. Какими именно инструментами: приложением, сайтом, телеграм чатом и т.п. — не так важно

3. Анти-паттерн, который я заметил — люди думают, что чем больше пользователей, тем лучше, тем самым распыляясь во множество направлений. Обычно это приводит лишь к тому, что покупатели не могут найти интересующих их продавцов и наоборот, в итоге маркетплейс “затухает”

Если бы я строил маркетплейс, например, конкурента HeadHunter, то мои шаги были бы следующими:
- Выбрал бы какой-то узкий сегмент, например, стажировки
- Понял бы, что тут важнее: спрос или предложение. В данном случае спрос
- Поисследовал, а с какими проблемами сталкиваются работадатели в поиске стажеров. Например — очень большое число заявок, много времени уходит на отбор
- Придумал бы, как вместо просмотра 100 заявок сократить работу нанимающему до просмотра 15 лучших заявок. Сначала бы реализовал это в каком-то ручном режиме
- Собирал бы всевозможные данные: отзывы, результаты интервью, результаты стажировок и т.п.
- Строил бы автоматический скоринг стажеров и потихоньку двинулся бы либо в сторону джунов, либо в сторону расширения кол-во компаний, которые берут себе стажеров

☣️ Токсичное ревью

Дело было в далеком 2018 году, к тому времени я уже пол года работал в Фейсбуке, когда к нам присоединился новый разработчик. Он был феноменальным кодером с большим опытом создания распределенных систем. Никто так не умел ловить рейс-кондишены, как это делал он

И все бы хорошо, но было у него одно “но” — невероятно строгие и opinionated ревью. Описать их можно примерно так: “мне все равно, но код должен быть идеальным”. Мы могли с ним целый час сидеть и обсуждать, как именно нужно назвать переменную, потому что без этой детали ревью не двигалось с места. Проблема усугублялась еще тем, что в силу его талантливости, он делал ревью качественно и находил мельчайшие баги, да и сам он любил этот процесс. Со временем, это привело к тому, что он монополизировал ревью в нашей команде: через него проходило 80-85% всего кода

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

Самое смешное, в 2022, когда я уже 2 года как не работал в Фейсбуке, мой близкий друг перешел в мою экс-команду и напоролся на ту же токсичность от человека, которого я в свою очередь мурыжил жестким ревью. Мой друг был вне себя от ярости: “он придирается к таким глупым мелочам и заставляет делать все только так, как он сам захочет. Это невыносимо!” — признался он

Вывода тут два:
1. Безусловно, иногда нужно делать очень скурпулезное ревью, но иногда дать ошибиться тоже окей — человек получит ценный опыт, иногда нужно сделать тяп-ляп (особенно в стартапах). Всегда нужно держать в уме бизнес-контекст и подбирать правильный подход
2. Нужно следить за культурой в команде, выявлять и пресекать токсичность на ранних стадиях, иначе последствия могут быть достаточно печальными

Можно ли победить Яндекс.Go на рынке Казахстана?

TL;DR. Это практически невозможно. И вот почему:

Исторические аргументы
1. Не какой-то там местечковый стартапчик, но сам Uber пытался зайти на рынок России и проиграл Яндексу. Если что, это случилось в 2018 году
2. В 2021 году китайский гигант Didi пытался зайти на рынок Казахстана, Яндекс не пожалел десятков миллионов долларов и рынок отбил

Бизнесовые аргументы
3. Ride Hailing — это капитало-интенсивный бизнес. Не достаточно просто иметь технологии. Важно иметь доступ к капиталу, чтобы в случае чего переманивать к себе водителей бонусами, как мы видели это с Didi, да и как было в других войнах типа Uber vs Lyft. Если у вас переманили водителей, то никому вы не нужны
4. А еще у Яндекса есть программа лояльности Яндекс.Плюс. И если ты не предоставляешь такой же спектр продуктов (доставка еды, самокаты и т.п.), то пользователи, в силу того, что это выгодней, будут естественно перетекать в инфраструктуру Яндекса
5. Может Kaspi тогда потягается за этот рынок? Не уверен, и вот почему: вы знали, что heat map, который Яндекс показывает водителям, чтобы стимулировать их правильное распределение, у каждого водителя уникальный? Это просто одна из тысяч подобных фичей. Мы уж не говорим о картах и погоде. У Яндекса куча крутых технологий мирового уровня

Игра не по правилам
6. Известно также, что Яндекс может и будет грязно играть. Допустим, один мой товарищ работал в Яндексе над разработкой алгоритма по отслеживанию водителей: пользуются ли те другими аггрегаторами или нет. И вот представьте себя на месте водителя: он может пойти в казахстанский стартап и "помочь родине" (хотя чем именно — не ясно), но вдруг он узнает, что как только водители начинают пользоваться другими приложениями — их банят. И он тот час же выкидывает все эти мысли из головы, потому что ему нужно семью кормить

Политика
Единственный вариант, который я вижу — вмешательство правительства, но тут есть две проблемы:
7. Вмешательство правительства в бизнес — плохой знак для иностранных инвесторов. Если Яндекс выкинут, то может и другие стартапы тоже кикнут, поэтому рискованно вкладывать деньги в этот рынок
8. Россия через Яндекс до некоторой степени контролирует Казахстан и собирает кучу данных. Ну и политический рычаг на Казахстан у нее огроменный. Поэтому подобные телодвижения со стороны правительства могут привести к непредсказуемым последствиям

Так что да, тягаться с Яндексом в лоб — подобно самоубийству

Сделать — не сделать — сделать — не сделать — взял НЕ сделал 😩

Два сильных разработчика очень интересовались нашим стартапом и хотели у нас поработать, однако мы были лишь "запасным планом", опцией Б. Так получилось, что опция А, более рискованная и более денежная, в обоих случаях накрылась медным тазом. Теперь они приходят ко мне, а мы уже наняли других сильных ребят. Хедкаунта больше нет

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

Hack of the Week

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

Решение: по умолчанию отключил уведомления во всех чатах (как личных так и общих) за исключеним избранных: родители, жена, фаундеры UvU, команда разработки, дежурства. Причем на каждую группу чатов я поставил разные звуки, чтобы легко определять критичность на слух и реагировать в течение 5 секунд / 1 минуты / 5 минут

Плоды: кроме того, что я пофиксил две проблемы выше, оказалось, что у меня снизилась телеграм-привязанность, когда я заходил в мессенджер, чтобы проверить: "а ничего ли там важного/интересного не случилось?"

Периодически общаюсь с командой мемасами. А вы как к такому относитесь?

Самое время напомнить о 76 годах израильской оккупации

Мы просим Аллаха, чтобы Он защитил народ Палестины

Пока что возьму перерыв в написании каких-либо постов

🇵🇸 #Palestine || 500 Palestinians were killed by an Israeli air strike that bombed The Baptist Hospital in Gaza 17.10.23 By @alijadallah66

خمسمائة شهيد في قصف الاحتلال للمستشفى المعمداني في غزة