Согласен, в сухом остатке: очень много разнообразной, сложноформализуемой работы, которую кто-то должен делать. Тут можно сразу развенчать миф, что желающих не так уж много. Некоторым людям это нравится, потому что в с другой стороны это дает возможность в большем масштабе влиять на происходящее.
В среду выйдет продолжение статьи, там будет больше подробностей о мотивации и о сложностях подобной работы.
Привет! Разумеется один человек это все в один момент времени не сможет делать, особенно в большом отделе. Скорее я осветил максимально полный список направлений и активностей, в которые staff-инженеры в компании вовлечены.
Про человек-оркестр соглашусь, но с некоторыми оговорками:
речи не идет о том, чтобы закрывать все эти задачи одним человеком, можем на это смотреть как на "каталог возможностей", или что ждет "сеньорного разработчика на этой позиции" 😀
про работу руками (hands-on): у многих инженеров есть внутреннее желание продолжать этим заниматься, чтобы сохранялась накопленная экспертиза и не отрываться от реальности. Другое дело, что силами одного человека не всегда возможно достигать масштабных изменений, и это в противовес мотивирует инженера на "придумай, оцени, докажи, выбей, поуправляй"
стафф-инженер - это не всегда про фичи, в статье есть примеры технических инициатив, которые сняли технологические блокеры дальнейшего развития. Правда чтобы дальше пилить больше фич 😂 . Но тем не менее, цель любого бизнеса - заработать денег. Цель любого нанятого инженера - помочь с технической стороны в этом вопросе.
Добрый вечер. Я учел ваше мнение, и добавил ссылку на ресурс, посвященный EventStorming'у. Буду рад конструктивным замечаниям, вопросам или предложениям.
Благодарю. Внес правки в текст, чтобы не вводить читателя в заблуждение! Справедливости ради отмечу, что "избранное" (которое я упростил до "сердечек") - один из сервисов, использующих "стандарт": так же принимает X-AUTH-IDENTITYзаголовок.
Еще любопытный момент: с перспективы перевода самого монолита на "стандарт", он становится всего лишь одним из сервисов, пользующихся заголовками. Клиентская часть его логики абстрагируется от аутентификации, логически декомпозируя монолит на 2 части: для обслуживания аутентификации и для обслуживания бизнес-логики.
И в догонку - не рассматривали вариант начать с отделения сервиса аутентификации?
Масштаб изменений при выносе сервиса аутентификации сразу, на мой взгляд, значительно больше (исследование, прототип, реализация, внедрение). Нужен более обстоятельный поход и большее количество временных затрат. Поэтому пошли эволюционным способом, развивая, что есть:
распутали логику аутентификации в монолите
обособили ее, и отвязали сервисы (в том числе и сам монолит)
а дальше пошли по пути выделения сервиса аутентификации
Ретроспективно скажу, что такой подход себя оправдал и позволил выиграть время. Наступить при этом на множество граблей: предварительно завести клиентский трафик по API-гейтвей, систематизировать многогранную логику аутентификации и т.д. - что в любом случае пришлось бы делать.
В этом смысле предлагаемый вариант, это часть плана решения вопроса аутентификации, с большим фокусом на практический результат. Но все лишь часть.
Спасибо за комментарий. Пример самого сервиса действительно может показаться простым. В реальности кейса, который стал толчком к изменениям, другой (это инструмент для работы с партнерами). Я хотел избежать долгого погружения читателя в бизнес-логику сфокусировать с большей степени на самом решении, для чего сознательно изменил пример. К тому же оригинальной задачей было вынести сервис из монолитного приложения, что тоже смещает фокус.
Но после внедрения "решения на базе монолита" пошла волна независимых реализаций сервисов, который могли обслуживать клиентский трафик, при пользуясь результатом аутентификации. В этом плане решение в большей степени стало энейблером для запусков новых сервисов, нежели декомпозиции и выноса старых.
Привет! Навеяло настальгией! Хорошие были времена!
Как прочитаю - вернусь с обновлениями :)
Добрый день. Спасибо за ценный комментарий, дополнение и наводку на книгу.
Подскажите, какая получается эффективность отдачи тепла в систему отопления, из 1кВт, потребяемого майнором?
Добрый день! Я в таком ключе не думал. Но соглашусь, что под "ростом" имеется ввиду не только техническое (и не сколько техническое) направление.
Привет! Спасибо за комментарий.
Согласен, в сухом остатке: очень много разнообразной, сложноформализуемой работы, которую кто-то должен делать. Тут можно сразу развенчать миф, что желающих не так уж много. Некоторым людям это нравится, потому что в с другой стороны это дает возможность в большем масштабе влиять на происходящее.
В среду выйдет продолжение статьи, там будет больше подробностей о мотивации и о сложностях подобной работы.
Привет! Разумеется один человек это все в один момент времени не сможет делать, особенно в большом отделе. Скорее я осветил максимально полный список направлений и активностей, в которые staff-инженеры в компании вовлечены.
Привет! Спасибо за вопрос. Fellow инженера еще ни одного формально нет.
А по staff+ ветке точной статистики нет, примерно 1-3% инженеров.
Привет! Спасибо за комментарий.
Про человек-оркестр соглашусь, но с некоторыми оговорками:
речи не идет о том, чтобы закрывать все эти задачи одним человеком, можем на это смотреть как на "каталог возможностей", или что ждет "сеньорного разработчика на этой позиции" 😀
про работу руками (hands-on): у многих инженеров есть внутреннее желание продолжать этим заниматься, чтобы сохранялась накопленная экспертиза и не отрываться от реальности. Другое дело, что силами одного человека не всегда возможно достигать масштабных изменений, и это в противовес мотивирует инженера на "придумай, оцени, докажи, выбей, поуправляй"
стафф-инженер - это не всегда про фичи, в статье есть примеры технических инициатив, которые сняли технологические блокеры дальнейшего развития. Правда чтобы дальше пилить больше фич 😂 . Но тем не менее, цель любого бизнеса - заработать денег. Цель любого нанятого инженера - помочь с технической стороны в этом вопросе.
Добрый вечер. Я учел ваше мнение, и добавил ссылку на ресурс, посвященный EventStorming'у. Буду рад конструктивным замечаниям, вопросам или предложениям.
Насколько понятно про Pact я еще ни разу не читал!
Нарисовал в Миро, тема - стандартный цвет плюс прозрачность.
Еще коллеги порекомендовали интересный тулинг https://excalidraw.com/, но я пока не пробовал.
Благодарю. Внес правки в текст, чтобы не вводить читателя в заблуждение! Справедливости ради отмечу, что "избранное" (которое я упростил до "сердечек") - один из сервисов, использующих "стандарт": так же принимает
X-AUTH-IDENTITYзаголовок.Еще любопытный момент: с перспективы перевода самого монолита на "стандарт", он становится всего лишь одним из сервисов, пользующихся заголовками. Клиентская часть его логики абстрагируется от аутентификации, логически декомпозируя монолит на 2 части: для обслуживания аутентификации и для обслуживания бизнес-логики.
Масштаб изменений при выносе сервиса аутентификации сразу, на мой взгляд, значительно больше (исследование, прототип, реализация, внедрение). Нужен более обстоятельный поход и большее количество временных затрат. Поэтому пошли эволюционным способом, развивая, что есть:
распутали логику аутентификации в монолите
обособили ее, и отвязали сервисы (в том числе и сам монолит)
а дальше пошли по пути выделения сервиса аутентификации
Ретроспективно скажу, что такой подход себя оправдал и позволил выиграть время. Наступить при этом на множество граблей: предварительно завести клиентский трафик по API-гейтвей, систематизировать многогранную логику аутентификации и т.д. - что в любом случае пришлось бы делать.
В этом смысле предлагаемый вариант, это часть плана решения вопроса аутентификации, с большим фокусом на практический результат. Но все лишь часть.
Спасибо за комментарий. Пример самого сервиса действительно может показаться простым. В реальности кейса, который стал толчком к изменениям, другой (это инструмент для работы с партнерами). Я хотел избежать долгого погружения читателя в бизнес-логику сфокусировать с большей степени на самом решении, для чего сознательно изменил пример. К тому же оригинальной задачей было вынести сервис из монолитного приложения, что тоже смещает фокус.
Но после внедрения "решения на базе монолита" пошла волна независимых реализаций сервисов, который могли обслуживать клиентский трафик, при пользуясь результатом аутентификации. В этом плане решение в большей степени стало энейблером для запусков новых сервисов, нежели декомпозиции и выноса старых.