Мы придерживаемся такого мнения, что если сама команда Docker’а пишет такие статьи-разборы, значит, у её аудитории есть запрос на такую информацию.
Ещё хочется отметить, что площадки вроде того же блога у Docker’а или Хабра — это своего рода фильтр: люди приходят сюда с определенными запросами и желаниями, надеясь получить уже готовую информацию, сконцентрированную в одном тексте. Конечно, можно и самому пройтись глазами по документации или вбить свой вопрос GPT-шке. Но если есть и такой способ найти нужную информацию, как чтение статей, то почему бы и нет?
Мы в свою очередь просто хотели поделиться чем-то полезным :)
Спасибо за комментарий. Мы не можем выходить за рамки содержания оригинальной статьи, так как у нас перевод, но это хороший материал для написания следующих статей.
Оба, похоже, пытаются предоставить решение одной и той же проблемы, однако разработаны исходя из разных философий и каждый сосредоточен на определенных инструментах Hashicorp.
Это неизвестно не бизнесу, а автору статьи. У оутсорса (если только речь не о прототипах на коленке для проверки идей) вагон недостатков. Например:
* незнание разработиками производственного окружения, для которого разрабатывается проект
* отсутствие контроля качества кода со стороны заказчика
* огромные пробемы с продолжением разработки при смене оутсорсера или переходе на собственную команду
* зависимость заказчика от финансового положения оутсорсера и его аппетитов
* проблемы с отладкой невоспроизводимых на стороне разработчика ошибок
Опять же это плохой аутсорс, который не думает как правильно построить процессы и как работать с клиентом. Первый пункт относится непосредственно к инфраструктуре и он вполне решаем. 2,3 пункт относятся к разработке, за них ничего не могу сказать. 4 пункт - опять же плохой аутсорс, договор подписывается на берег и не меняется в процессе. 5 - опять к разработке.
Сам найм стоит порядка 3X. Если опять же учитывать изменение перформинга команды на период адаптации, то выйдет 8-10X. Почитать можно тут.
Вообще похоже на рекламную пропаганду. Работал как то в аутсорсинге, там была методичка для бизнесменов: как плохи свои итшники и как хорошо аутсорсинг. Так что с такой статьёй вам надо не на хабр а на бизнес фм. Тут все воспринимают аутсорсинг так как он того заслуживает.
Цель данной статьи это узнать: почему заказчики не выбирают аутсорс и больше склоняются в сторону собственных команд. Сожалею, что вы это прочитали больше как рекламный пост, я старался избежать этого.
Соглашусь, в этом всегда есть риск. Но здесь важно качественно выбрать аутсорс команду, которая дорожит своей репутацией и не подведет вас как заказчика.
Это почти всегда дороже чем нанять свою комманду.
А вот тут не соглашусь. Если,
1. Взять среднюю стоимость специалиста 2. То, сколько мы потратим за найм 3. Оценим все риски ошибки найма в долгосрочной перспективе 4. То, что нужно будет учитывать адаптацию и изменение перформинга команды на период адаптации
То ценник при работе со своей командой будет значительно дороже (речь опять же про DevOps исключительно), нежели с аутсорсом.
Нет прямой связи с разработчиками, а фидбяк от них очень важен, ведь клиент не всегда знает как сделать лучше, а аутсорсеру не выгодно упрощать задачи, скорее наоборот сделать так как просят, а потом ещё и переделать.
У разработчиков часто нет мотивации делать лучше потому что никаких бонусов за это не предвидиться, бонусы ограничены заработком аутсорс фирмы. Тоесть надо писать так чтоб как можно дольше можно было доить заказчика.
Здесь могу лишь сказать, что вы сталкивались с плохим аутсорсом.
Ну а плюсы очевидны на маленьких проектах.
Можно запилить концепт не тратясь на комманду и организацию процессов, а если оно выстрелит, то уже с кучей бабла можно и самим переписать всё.
Спасибо за ваш комментарий!
Мы придерживаемся такого мнения, что если сама команда Docker’а пишет такие статьи-разборы, значит, у её аудитории есть запрос на такую информацию.
Ещё хочется отметить, что площадки вроде того же блога у Docker’а или Хабра — это своего рода фильтр: люди приходят сюда с определенными запросами и желаниями, надеясь получить уже готовую информацию, сконцентрированную в одном тексте. Конечно, можно и самому пройтись глазами по документации или вбить свой вопрос GPT-шке. Но если есть и такой способ найти нужную информацию, как чтение статей, то почему бы и нет?
Мы в свою очередь просто хотели поделиться чем-то полезным :)
А о чём бы вы хотели почитать?
Спасибо за комментарий! Предложенная вами тема действительно актуальна, возьмём на заметку.
Здравствуйте! Совсем скоро выйдет вторая часть.
Спасибо за комментарий. Мы не можем выходить за рамки содержания оригинальной статьи, так как у нас перевод, но это хороший материал для написания следующих статей.
Верное дополнение, спасибо!
верно, это identity providers
Здесь не подскажем, нет данных по сравнению этих инструментов.
Как полную замену нет, можно использовать как дополнения друг к другу.
Оба, похоже, пытаются предоставить решение одной и той же проблемы, однако разработаны исходя из разных философий и каждый сосредоточен на определенных инструментах Hashicorp.
Принято, спасибо!
Спасибо, что обратили внимание) Мы немного поправили, постараемся внимательнее вычитывать следующие публикации.
Спасибо)
Согласен)
Подойдет) Но я так понимаю, хочется почитать же реальный опыт на эту тему.
Хорошее замечание, попробуем подыскать перевод, где это будет представлено в полном объеме
А какой негативный опыт был с git-crypt? Опишите?
Никто никому не врет, а просто делимся опытом.
Опять же это плохой аутсорс, который не думает как правильно построить процессы и как работать с клиентом. Первый пункт относится непосредственно к инфраструктуре и он вполне решаем. 2,3 пункт относятся к разработке, за них ничего не могу сказать. 4 пункт - опять же плохой аутсорс, договор подписывается на берег и не меняется в процессе. 5 - опять к разработке.
Сам найм стоит порядка 3X. Если опять же учитывать изменение перформинга команды на период адаптации, то выйдет 8-10X. Почитать можно тут.
Цель данной статьи это узнать: почему заказчики не выбирают аутсорс и больше склоняются в сторону собственных команд. Сожалею, что вы это прочитали больше как рекламный пост, я старался избежать этого.
Соглашусь, в этом всегда есть риск. Но здесь важно качественно выбрать аутсорс команду, которая дорожит своей репутацией и не подведет вас как заказчика.
А вот тут не соглашусь. Если,
1. Взять среднюю стоимость специалиста
2. То, сколько мы потратим за найм
3. Оценим все риски ошибки найма в долгосрочной перспективе
4. То, что нужно будет учитывать адаптацию и изменение перформинга команды на период адаптации
То ценник при работе со своей командой будет значительно дороже (речь опять же про DevOps исключительно), нежели с аутсорсом.
Здесь могу лишь сказать, что вы сталкивались с плохим аутсорсом.
Речь опять же про разработчиков, а не про DevOps.