Если не особо нужна защищенность, то зачем было городить проверку каждого запроса через сервис авторизации? Достаточно было классики OAuth2 - выдать JWT токет подписанный и раздать с сервиса авторизации по всем клиентам ключи. Это бы еще и отказоустойчивости добавило и latency снизило.
Да тут еще и API Gateway своей разработки + передача полномочий в микросервисы в заголовках. То есть любой кто сможет отправить запрос мимо API Gateway получит возможность действовать в сервисах от имени любого пользователя с любыми полномочиями.
На мой взгляд должны быть веские причины, чтобы писать сервер авторизации с нуля вместо использования чего-нибудь вроде spring-security-oauth2-authorization-server
ИМХО странная аналогия с колхозом на болотах и песках. Скорее тут про специализацию - эти пусть яблоки выращивают, эти птиц разводят, эти картофель и свеклу.
На мой взгляд вы зря переключаетесь между "если бы я был шеф" и "людям нравится", это разные стороны трудового договора.
Если бы вы были шеф коммерческой организации вам бы работники были нужны именно с точки зрения инструмента для заработка. А вот ЧЕМ вы будете заманивать работники кроме денег и как удерживать - это второй вопрос. И часто "сумма на руки в конце месяца" здесь будет не лучшим ответом.
Какая прекрасная ложная альтернатива. Если у компании кроме преданности и денег нечего предложить кандидату и в деньгах она не уверена, то проблема совсем даже не в кандидате.
Вероятно описанной компании просто повезло. Потому что если старший разработчик изначально не организовал всё для работы без личного вмешательства, то часто какие-то операции не то что делать никто не умеет кроме него, так даже доступа нет.
В продукт надо запиливать фичи из которых только 15-20% идут потом в рост.
Можно находить компромиссы с PO, чтобы запиливать MVP фичи "по-быстрому", но так чтобы потом их рефактор "в 2-3 раза дороже" был управляемым? Например, договориться, что фича реализуется изолированно и не выпускается из тестовой группы на основную массу, пока не переписана качественно.
Чтобы единственный зам. директора, да еще и по операционке имел возможность управлять всей компанией за директора - это прям ОЧЕНЬ странная конструкция. А директор тогда зачем?
Ну 10+ прям необязательно. Для начинающего девопса на мой взгляд 1-2+ вполне уже норм будет, если человек постоянно новое осваивал и практический опыт имеет в эти 1-2 года.
3-5+ это уже очень хороший уровень можно наработать, практически на передний край выйти по уровню знаний.
Другое дело, что некоторым стаж не помогает. Не так давно собеседовал человека с опытом 25+ лет, он был ведущим разработчиком, руководил командой разработки, и он не понимает что такое транзакции в БД.
Ну допустим, а если там не просто контейнер + бд, а уже целый набор всякого добра, типа NoSQL serverless базы, s3-хранилища, sns-топики для доставки уведомлений об изменениях + несколько serverless-лямбд и это под api gateway всё и load balancer'ом, и это достаточно часто меняется - это всё еще администирование или уже куда-то в разработку начинает просачиваться?
Вы так пишете, как будто этот "стык" нынче толщиной с волос.
На мой же взгляд с распространинием концепии IaC + инструментов контейнеризации + развитием CI/CD там всё вообще размылось и этот "стык" может охватывать до 25% всей разработки.
Вот допустим мы настраиваем пайплайн так, что на каждый MR в репозитории кода будет поднят свой контейнер в AWS Fargate с версией системы для ревью и создана отдельная БД с тестовыми данными - это что по вашему? Разработка? Администрирование?
Тогда мои извинения, я это видимо не так понял тут:
Умом-то я, разумеется, понимал всех обратившихся ко мне в личку людей, автоматически трансформируя фразу "нужен девопс" в "процессы в нашей команде предполагают тесное взаимодействие между отделами, и сейчас мы ищем человека, который взял бы на себя часть работы по эксплуатации"
···················· Каждый должен заниматься своим делом
Если такой инженер бывает, то зачем чего-то трансформировать? Почему не может быть его "своим делом" работать на стыке между админами и разработкой?
Возможно потому что не все компании догадываются или могут себе позволить привлекать специалистов уровня AWS Certified Solutions Architect – Professional и AWS Certified DevOps Engineer – Professional, которые понимают возможные варианты решения тех или иных задач и плюсы/минусы каждого, включая стоимость решения.
Если не особо нужна защищенность, то зачем было городить проверку каждого запроса через сервис авторизации? Достаточно было классики OAuth2 - выдать JWT токет подписанный и раздать с сервиса авторизации по всем клиентам ключи. Это бы еще и отказоустойчивости добавило и latency снизило.
Да тут еще и API Gateway своей разработки + передача полномочий в микросервисы в заголовках. То есть любой кто сможет отправить запрос мимо API Gateway получит возможность действовать в сервисах от имени любого пользователя с любыми полномочиями.
Ну такое себе...
На мой взгляд должны быть веские причины, чтобы писать сервер авторизации с нуля вместо использования чего-нибудь вроде spring-security-oauth2-authorization-server
ИМХО странная аналогия с колхозом на болотах и песках. Скорее тут про специализацию - эти пусть яблоки выращивают, эти птиц разводят, эти картофель и свеклу.
Условная вероятность.
На мой взгляд классическая ошибка выжившего ;)
На мой взгляд вы зря переключаетесь между "если бы я был шеф" и "людям нравится", это разные стороны трудового договора.
Если бы вы были шеф коммерческой организации вам бы работники были нужны именно с точки зрения инструмента для заработка. А вот ЧЕМ вы будете заманивать работники кроме денег и как удерживать - это второй вопрос. И часто "сумма на руки в конце месяца" здесь будет не лучшим ответом.
Вероятно вы потенциальный шеф некоммерческой организации? Поскольку:
Какая прекрасная ложная альтернатива. Если у компании кроме преданности и денег нечего предложить кандидату и в деньгах она не уверена, то проблема совсем даже не в кандидате.
Вероятно описанной компании просто повезло. Потому что если старший разработчик изначально не организовал всё для работы без личного вмешательства, то часто какие-то операции не то что делать никто не умеет кроме него, так даже доступа нет.
Даже интересно из описанного - а СТО в компании чем занимался? За организацию разработки отвечали сами джуны?
А что если...
В продукт надо запиливать фичи из которых только 15-20% идут потом в рост.
Можно находить компромиссы с PO, чтобы запиливать MVP фичи "по-быстрому", но так чтобы потом их рефактор "в 2-3 раза дороже" был управляемым? Например, договориться, что фича реализуется изолированно и не выпускается из тестовой группы на основную массу, пока не переписана качественно.
?
И чтобы руководитель отдела продаж подчинялся тому, кто сконцентрирован на внутренней части? Да вы верно шутите?
Чтобы единственный зам. директора, да еще и по операционке имел возможность управлять всей компанией за директора - это прям ОЧЕНЬ странная конструкция. А директор тогда зачем?
Надо более четко формулировать желания, да.
Ну 10+ прям необязательно. Для начинающего девопса на мой взгляд 1-2+ вполне уже норм будет, если человек постоянно новое осваивал и практический опыт имеет в эти 1-2 года.
3-5+ это уже очень хороший уровень можно наработать, практически на передний край выйти по уровню знаний.
Другое дело, что некоторым стаж не помогает. Не так давно собеседовал человека с опытом 25+ лет, он был ведущим разработчиком, руководил командой разработки, и он не понимает что такое транзакции в БД.
Ну допустим, а если там не просто контейнер + бд, а уже целый набор всякого добра, типа NoSQL serverless базы, s3-хранилища, sns-топики для доставки уведомлений об изменениях + несколько serverless-лямбд и это под api gateway всё и load balancer'ом, и это достаточно часто меняется - это всё еще администирование или уже куда-то в разработку начинает просачиваться?
Вы так пишете, как будто этот "стык" нынче толщиной с волос.
На мой же взгляд с распространинием концепии IaC + инструментов контейнеризации + развитием CI/CD там всё вообще размылось и этот "стык" может охватывать до 25% всей разработки.
Вот допустим мы настраиваем пайплайн так, что на каждый MR в репозитории кода будет поднят свой контейнер в AWS Fargate с версией системы для ревью и создана отдельная БД с тестовыми данными - это что по вашему? Разработка? Администрирование?
Тогда мои извинения, я это видимо не так понял тут:
Если такой инженер бывает, то зачем чего-то трансформировать? Почему не может быть его "своим делом" работать на стыке между админами и разработкой?
Автор утверждает, что не бывает "девопс-инженер", это методология.
А у меня нет проблем с DevOps Engineer, я по нему к сертификации готовлюсь сейчас.
Возможно потому что не все компании догадываются или могут себе позволить привлекать специалистов уровня AWS Certified Solutions Architect – Professional и AWS Certified DevOps Engineer – Professional, которые понимают возможные варианты решения тех или иных задач и плюсы/минусы каждого, включая стоимость решения.
В итоге в облака едет что попало и как попало.