Есть ровно два варианта - либо вы продаёте игру, либо нечто иное. Во втором случае ваша ЦА - не игроки, и в соответствии с этим развиваются все механики, эээ, продукта.
Мне гораздо чаще встречались другие варианты развития событий:
Разработчик всё делает в IDE, в том числе компиляцию и запуск приложения - поэтому когда дело доходит до выкатки в какое-то общее окружение, время тратится на преодоление тезиса "у меня на компе, под 32-битной виндой с пятью версиями JDK - всё работает".
Разработчик копипастит в Dockerfile содержимое первых ссылок "spring boot dockerfile ubuntu" или ответ слегка галлюцинирующего ChatGPT, делая триста слоёв и образ размером 500 мегабайт + само приложение.
Хороший разработчик наверняка, загуглив, очень быстро сможет набросать работоспособный конфиг для Докера, Композа и даже Куба. Но нюанс в том, что работоспособности в некоторых случаях недостаточно - и вот на это может уйти довольно много времени, которое можно было потратить значительно продуктивнее, отдав задачи, связанные с инфраструктурой - эксплуатации, безопасностью - айтисекам и так далее.
Методология Devops вовсе не предполагает, что разработчик непременно должен тратить свой время на написание конфигов Докера, Хелм-чартов и прочей обвязки, собственно, приложения. Если, конечно, он не один в поле - но в таких вырожденных случаях странно вообще говорить о каких-то методологиях :)
Кажется, проблема преувеличена. Не так часто, на мой взгляд, приходится добавлять в докерфайлы что-то принципиально новое. А если часто - есть различные практики, упрощающие прототипирование, та же "3 Musketeers".
Это уж безотносительно того, что заботиться о прямоте докерфайлов, контейнеризации вообще и CI должны сотрудники эксплуатации, а не разработки.
Поправьте меня, если я не прав - но имхо, какого-то прозрачного для пользователя фоллбэка там не предполагается.
Если клиент отправил в пакете ClientHello сообщение о том, что поддерживает ECH extension и со стороны сервера ECH реализован, дальнейший хэндшейк либо будет проходить с использованием ECH, либо соединение будет разорвано.
Да, вы правы - но я как-то подсознательно имел в виду, что приложение у нас не одно, а следовательно - сэкономить можно на одинаковых "нижних спринговых" слоях.
Теперь, когда уже можно никому не объяснять основания блокировок (это я про ТСПУ), может быть что угодно. Но блокировка протокола HTTPS, из-за которой перестанут работать вполне легитимные сайты - это будет пробитие нового дна.
Пока сайты с ECH - исключения, а не правило, возможно. Но надеюсь, что когда технология достигнет повсеместного внедрения, кишка заблокировать 80% интернета кое у кого всё-таки станет тонка.
Могу рассказать со своей админской кочки, как это выглядит.
Когда в компании не хватает разработчиков - работа, пусть криво-косо, медленно, с накоплением техдолга, но делается. Поэтому и существует возможность искать квалифицированных и низкооплачеваемых по полгода.
Когда уходят сотрудники эксплуатации, случается три этапа:
Их быстренько заменяют товарищами, просящими в три раза меньше.
Что-то ломается, товарищи из п. 1 не могут с этим справиться оперативно или вообще.
Менеджмент получает по шапке, рекрутёры отправляются броадкастить релевантный народ, предлагая златые горы (но удалёнка всё ещё из РФ).
Странно, начав с упоминания Спринга, не рассказать в результате о Layered Jars, который потенциально даст гораздо большую экономию, чем чистка кэшей пакетов и прочие общеизвестные вещи.
Никто особо не рвётся, но у некоторых, например, ипотека осталась в рублях, родителя пожилые, которым надо помогать и всякое такое. Пусть не в качестве основного источника дохода, но почему бы и нет?
Не жалейте. Чтобы получить квалифицированных соискателей на свои вакансии, не "шкрябая по дну", им достаточно всего лишь прекратить свою фигню с "удалёнкой из РФ".
Я уже смирился с тем, что в голове у менеджмента и HR, DevOps == системный администратор Linux + k8s в облаке, SDLC == ересь, но что такое SRE в головах HR? Root + DBA ?
Терминология гуляет, как не на свои, даже в докладах на профильных конференциях - а вы хотите от столь далёких профессий чёткого понимания :)
TLDR: манипуляции, реклама, подписка, buy2play, манипуляции...
Есть ровно два варианта - либо вы продаёте игру, либо нечто иное. Во втором случае ваша ЦА - не игроки, и в соответствии с этим развиваются все механики, эээ, продукта.
Повезло админам, работающим с вами, завидую им :)
Мне гораздо чаще встречались другие варианты развития событий:
Разработчик всё делает в IDE, в том числе компиляцию и запуск приложения - поэтому когда дело доходит до выкатки в какое-то общее окружение, время тратится на преодоление тезиса "у меня на компе, под 32-битной виндой с пятью версиями JDK - всё работает".
Разработчик копипастит в Dockerfile содержимое первых ссылок "spring boot dockerfile ubuntu" или ответ слегка галлюцинирующего ChatGPT, делая триста слоёв и образ размером 500 мегабайт + само приложение.
Хороший разработчик наверняка, загуглив, очень быстро сможет набросать работоспособный конфиг для Докера, Композа и даже Куба. Но нюанс в том, что работоспособности в некоторых случаях недостаточно - и вот на это может уйти довольно много времени, которое можно было потратить значительно продуктивнее, отдав задачи, связанные с инфраструктурой - эксплуатации, безопасностью - айтисекам и так далее.
Методология Devops вовсе не предполагает, что разработчик непременно должен тратить свой время на написание конфигов Докера, Хелм-чартов и прочей обвязки, собственно, приложения. Если, конечно, он не один в поле - но в таких вырожденных случаях странно вообще говорить о каких-то методологиях :)
После загрузки я разлочиваю Keepass, без этого ничего невозможно делать - ни по SSH никуда не зайти, ни на сайт залогиниться :)
Кажется, проблема преувеличена. Не так часто, на мой взгляд, приходится добавлять в докерфайлы что-то принципиально новое. А если часто - есть различные практики, упрощающие прототипирование, та же "3 Musketeers".
Это уж безотносительно того, что заботиться о прямоте докерфайлов, контейнеризации вообще и CI должны сотрудники эксплуатации, а не разработки.
Ну победили и победили. Может, хоть теперь качеством поиска займётесь, особенно не по рунету?
Закончится это опять блокировкой локалхоста, даже не сомневаюсь.
Судя по грустным глазам на фотографиях - действительно что-то недоговорено :)
Поправьте меня, если я не прав - но имхо, какого-то прозрачного для пользователя фоллбэка там не предполагается.
Если клиент отправил в пакете ClientHello сообщение о том, что поддерживает ECH extension и со стороны сервера ECH реализован, дальнейший хэндшейк либо будет проходить с использованием ECH, либо соединение будет разорвано.
Да, вы правы - но я как-то подсознательно имел в виду, что приложение у нас не одно, а следовательно - сэкономить можно на одинаковых "нижних спринговых" слоях.
Теперь, когда уже можно никому не объяснять основания блокировок (это я про ТСПУ), может быть что угодно. Но блокировка протокола HTTPS, из-за которой перестанут работать вполне легитимные сайты - это будет пробитие нового дна.
Ну, так это причина и следствие - тот же nginx не поддерживает, потому что openssl и прочие криптобэкенды (пока) не поддерживают.
Пока сайты с ECH - исключения, а не правило, возможно. Но надеюсь, что когда технология достигнет повсеместного внедрения, кишка заблокировать 80% интернета кое у кого всё-таки станет тонка.
Могу рассказать со своей админской кочки, как это выглядит.
Когда в компании не хватает разработчиков - работа, пусть криво-косо, медленно, с накоплением техдолга, но делается. Поэтому и существует возможность искать квалифицированных и низкооплачеваемых по полгода.
Когда уходят сотрудники эксплуатации, случается три этапа:
Их быстренько заменяют товарищами, просящими в три раза меньше.
Что-то ломается, товарищи из п. 1 не могут с этим справиться оперативно или вообще.
Менеджмент получает по шапке, рекрутёры отправляются броадкастить релевантный народ, предлагая златые горы (но удалёнка всё ещё из РФ).
Тревожный сигнал. На этом фоне радует, что добавление ECH в openssl, кажется, сдвинулось с мёртвой точки.
Странно, начав с упоминания Спринга, не рассказать в результате о Layered Jars, который потенциально даст гораздо большую экономию, чем чистка кэшей пакетов и прочие общеизвестные вещи.
В релоцированных конторах не так много вакансий, а зарплаты в местных, честно говоря, удручают.
Никто особо не рвётся, но у некоторых, например, ипотека осталась в рублях, родителя пожилые, которым надо помогать и всякое такое. Пусть не в качестве основного источника дохода, но почему бы и нет?
Не жалейте. Чтобы получить квалифицированных соискателей на свои вакансии, не "шкрябая по дну", им достаточно всего лишь прекратить свою фигню с "удалёнкой из РФ".
Терминология гуляет, как не на свои, даже в докладах на профильных конференциях - а вы хотите от столь далёких профессий чёткого понимания :)
Hidden text