Мы у себя уж который год пытаемся внедрить Istio по требованиям корпоративной архитектуры, но никто пока так и не понял, зачем. Ресурсов сожгли тонну, выхлоп нулевой. Можете привести конкретный пример, что вам дал Istio такого, что без него прям очень сложно сделать? В начале статьи было озвучено:
гибкость и управляемость - и упомянута балансировка. Но обычно перед экземплярами систем в разных ЦОДах стоят глобальные балансировщики (в том числе аппаратные), никакой Istio там не нужен.
наблюдаемость - но для этого есть всякие Прометеи\Графаны\ELK и т.д, который могут собирать кучу информации помимо трафика. Что-то взять из сетевого трафика тоже может быть полезно, но если микросервисы журналируют себя, то анализ сетевого трафика становится не таким уж необходимым. А нагружает систему наверняка неслабо.
безопасным - вот этот пункт я вообще не понял. Проверка сертификата другой стороны подключения делается на раз-два почти в любом языке программирования и без Istio.
Допускаю, что так, наверное, бывает. Но поделюсь своим опытом. Я примерно 15 лет проработал в заказной разработке - ни разу заказчик не требовал кардинально снизить оценку. Торговля всегда идёт, но не "за 2 часа вместо 2 дней", а процентов за 20 стоимости. Все понимают, что снижение срока всегда означает как минимум повышение стоимости и риска, снижение качества. Если вдруг не понимают - что ж, бывает, расходимся.
Сейчас работаю в продуктовой разработке с жёсткими дедлайнами и постоянными "влётами" - то же самое. Практически все известные мне большие косяки связаны не с требованием сделать быстро, а с банальной ленью и отсутствием опыта. Вместо того, чтобы подумать день и сделать за неделю, разработчик сделал за три дня, а потом переделывает по чуть-чуть годами. Ну да, формально он сэкономил на первом этапе, но заказчику такая экономия не видна на фоне остальных этапов разработки.
Молодцы, что улучшаете UX, но по моему опыту использования, основная проблема продуктов МойОфис не в нём. Она в производительности и стабильности работы. Попробуйте открыть обычный файлик со сметой или планом работ строк этак на 10 000. Что, не дождались? Ну тогда и UX побоку.
Мой опыт разработки в "кровавом энтерпрайзе" показывает, что чуть ли не единственное реальное удобство использования микросервисов не технологическое, а организационное - с ними проще "отвязывать" релизные циклы команд друг от друга. Остальные декларируемые удобства за свои 25 лет разработки не встречал почти никогда:
1) Разный техстэк? Возможно, но крупной организации логично его унифицировать во избежание бардака.
2) Независимое масштабирование и изоляция нагрузки? Хороший аргумент, но на практике стараются закладывать ресурсы с запасом и ставить ограничители частоты запросов на всё что можно ради выполнения SLA, подписанного кровью перед бизнесом.
Если очень надо разделять части функциональности, можно сделать несколько "систем", а не "микросервисов". Технически разница небольшая, хотя могут быть нюансы с точки зрения производственного процесса компании (например, системы могут требовать специального учёта и согласования, а микросервисы нет). Но опять же, это не про технологию, а про управление процессом разработки.
Примерно в то время был на относительно серьёзном мероприятии по блокчейну, на котором присутствовали представители бизнеса РФ и государства. На прямой вопрос о будущем блокчейна в целом и крипты в частности опытные люди лишь пожимали плечами. Дескать, крипта есть, но к ней вопросов много (налогообложение, половина майнеров в Китае...), а в остальном применение блокчейна под большим вопросом, ни одного реально полезного применения не видно. На ура обсуждались только вопросы "построить мега-крипто-ферму в Сибири".
Интересно, что сейчас обсуждают по AI на подобных мероприятиях...
Посмотрел на кейс Кока-Колы и прослезился. В масштабах столь крупной компании снижение стоимость произошло с "ноль" до "ноль невзъеженный" - вряд ли там кто-то всерьёз воспринимает такие числа. Подозреваю, что стоимость миграции превысила экономию на порядки - попробуйте в крупной компании открыть проект, выбить бюджет, найти подрядчика, подписать договоры разработки и сопровождения...
Вспомнилась молодость, как мы продавали крупному забугорному клиенту "модное облачное решение", которое в итоге обошлось ему на порядки дороже одного выделенного сервера с простеньким Java-приложением. Но все довольны, бюджет освоен, пресс-релиз сделан, все молодцы. А то, что система постоянно падает из-за специфики сетевых настроек, принципиально ограничиваемых облачной интеграционной платформой - ну так про то большим боссам можно просто не говорить.
Работаю в "кровавом энтерпрайзе" (финансовые компании размером >5000 чел) - уж не знаю, считается ли это "взрослым бизнесом". Не видел ни одной удачной попытки качественно нормировать работу разработчика. Повторяющиеся однотипные работы (например, задачи поддержки) нормировать получается. Разработка, выходящая за рамки "набросать типовой отчётик" или "сверстать страничку по макету" обычно содержит слишком много неизвестных как технических, так и по постановке задачи. А люди при этом в своём опыте и производительности могут отличаться в разы даже в рамках одного грейда.
Все усредняют, деваться некуда, все разбираются с аналитикой и компетенциями разработчиков. Вот только оценке, будь то часы или сторипоинты, это мало помогает.
В пользу отказа от Excel можно привести ещё и аргументы безопасности: например, аудит изменений, разделение прав доступа. Ну и потребность в продвинутом UI, конечно.
"Например, слова «hello» и «helo» имеют много общих триграмм" - я насчитал ровно одну общую (hel). Не сильно много, или я что-то не так понял.
Соглашусь с автором - для не сильно сложных случаев поиска PostgreSQL хватит. Я в некоторых своих проектах текстовый поиск делал прямо на СУБД, несмотря на фантазии заказчика о хитром нечётком поиске. В итоге получалось, что обычного поиска по LIKE с нормализацией запроса (замена похожих символов на один, перевод в латиницу, вырезание посторонних символов) хватает за глаза.
Разработчики любят пихать какой-нибудь ElasticSearch для любого поиска, не представляя, в какой ад может превратиться поддержка поискового индекса в актуальном состоянии. При том, что продвинутый поиск может никогда и не понадобиться.
Всё чаще замечаю, что Хабр читать очень неприятно - на вроде бы техническую статью льётся куча ненависти. Писали статью о надёжности и производительности, а в комментах "говно", "чужие кости", "дно". Какое отношение это имеет к CDN, не ясно.
С нетерпением жду статьи о каком-нибудь устройстве автомобиля с комментами вроде "колёса-дно", "зачем автомобиль, если жизнь полный отстой".
Толпа умных людей, это в первую очередь толпа. ИТ-шный "энтерпрайз" - один из вариантов толпы. Все умные, высокооплачиваемые, все всё понимают, но на выходе получается хрень из-за постоянной несогласованности.
С другой стороны, в этом есть плюс - в отдельных случаях можно конкурировать с гигантами своим небольшим решением.
Независимо от уникальности есть ещё такая штука как ошибка ввода. И изменение законов. И хранение в БД удалённых значений. И ошибка постановки задачи. В-общем, да, синтетические ключи рулят.
Для некоторых компаний критична загрузка офисов для создания проходимости в близлежащих магазинах\ресторанах (которые принадлежат тем же компаниям или требуются по условиям аренды) и поддержания своего статуса. Грубо говоря, если уже арендовал и оплатил офис на 5 лет, то деваться особо и некуда - надо гнать туда людей.
Справедливости ради, не все гонят в офис - последние 15 лет работаю в финтехах (в том числе "биг") чисто на удалёнке (с опциональным посещением офиса).
"еды всякой просто тонна, конфеты завались сникерс, марс, баунти просто коробками стоит" - как там у народа с ожирением, диабетом и прочими плюшками такого питания? Понятно, что никто не заставляет всё это есть. Но интересно, насколько людям удаётся сопротивляться искушению.
Чем конструкция существенно отличается от любого другого генератора, где провод вращается в магнитном поле? Да и Википедия говорит про чрезвычайную неэффективность такого генератора.
Так речь только о шифровании. Про незащищённые концы соединения, обмен ключами и хранилища речи не идёт. А крадут скорее всего именно там. Но да, требования безопасности бывают очень формальные, раздутые, требовательные к ресурсам. К сожалению, раздолбайство, некомпетентность или злой умысел конечного исполнителя бумажкой так просто не прикрыть.
Годами использовал биндинги в WinForms, а его нет, оказывается :) Работал он не идеально, но работал. Проблема у WinForms была в другом - он на каждый элемент управления создавал окно Windows, из-за чего сложные формы тормозили. Интереса ради как-то сделал форму с большим количеством полей ввода на WinForms и такую же на HTML - HTML-форма в Google Chrome работала гораздо быстрее WinForms.
В-общем, если не нужны изыски отрисовки, то даже "голый" WinForms без специальных стилизованных элементов управления способен решать многие задачи (кроме разве что табличного ввода - он без доработки напильником не работал).
Мы у себя уж который год пытаемся внедрить Istio по требованиям корпоративной архитектуры, но никто пока так и не понял, зачем. Ресурсов сожгли тонну, выхлоп нулевой. Можете привести конкретный пример, что вам дал Istio такого, что без него прям очень сложно сделать? В начале статьи было озвучено:
гибкость и управляемость - и упомянута балансировка. Но обычно перед экземплярами систем в разных ЦОДах стоят глобальные балансировщики (в том числе аппаратные), никакой Istio там не нужен.
наблюдаемость - но для этого есть всякие Прометеи\Графаны\ELK и т.д, который могут собирать кучу информации помимо трафика. Что-то взять из сетевого трафика тоже может быть полезно, но если микросервисы журналируют себя, то анализ сетевого трафика становится не таким уж необходимым. А нагружает систему наверняка неслабо.
безопасным - вот этот пункт я вообще не понял. Проверка сертификата другой стороны подключения делается на раз-два почти в любом языке программирования и без Istio.
Допускаю, что так, наверное, бывает. Но поделюсь своим опытом. Я примерно 15 лет проработал в заказной разработке - ни разу заказчик не требовал кардинально снизить оценку. Торговля всегда идёт, но не "за 2 часа вместо 2 дней", а процентов за 20 стоимости. Все понимают, что снижение срока всегда означает как минимум повышение стоимости и риска, снижение качества. Если вдруг не понимают - что ж, бывает, расходимся.
Сейчас работаю в продуктовой разработке с жёсткими дедлайнами и постоянными "влётами" - то же самое. Практически все известные мне большие косяки связаны не с требованием сделать быстро, а с банальной ленью и отсутствием опыта. Вместо того, чтобы подумать день и сделать за неделю, разработчик сделал за три дня, а потом переделывает по чуть-чуть годами. Ну да, формально он сэкономил на первом этапе, но заказчику такая экономия не видна на фоне остальных этапов разработки.
Молодцы, что улучшаете UX, но по моему опыту использования, основная проблема продуктов МойОфис не в нём. Она в производительности и стабильности работы. Попробуйте открыть обычный файлик со сметой или планом работ строк этак на 10 000. Что, не дождались? Ну тогда и UX побоку.
Интересно, для чего вообще сейчас пилить новую соцсеть при обилии уже имеющихся... В любом случае, спасибо за честность.
Мой опыт разработки в "кровавом энтерпрайзе" показывает, что чуть ли не единственное реальное удобство использования микросервисов не технологическое, а организационное - с ними проще "отвязывать" релизные циклы команд друг от друга. Остальные декларируемые удобства за свои 25 лет разработки не встречал почти никогда:
1) Разный техстэк? Возможно, но крупной организации логично его унифицировать во избежание бардака.
2) Независимое масштабирование и изоляция нагрузки? Хороший аргумент, но на практике стараются закладывать ресурсы с запасом и ставить ограничители частоты запросов на всё что можно ради выполнения SLA, подписанного кровью перед бизнесом.
Если очень надо разделять части функциональности, можно сделать несколько "систем", а не "микросервисов". Технически разница небольшая, хотя могут быть нюансы с точки зрения производственного процесса компании (например, системы могут требовать специального учёта и согласования, а микросервисы нет). Но опять же, это не про технологию, а про управление процессом разработки.
Примерно в то время был на относительно серьёзном мероприятии по блокчейну, на котором присутствовали представители бизнеса РФ и государства. На прямой вопрос о будущем блокчейна в целом и крипты в частности опытные люди лишь пожимали плечами. Дескать, крипта есть, но к ней вопросов много (налогообложение, половина майнеров в Китае...), а в остальном применение блокчейна под большим вопросом, ни одного реально полезного применения не видно. На ура обсуждались только вопросы "построить мега-крипто-ферму в Сибири".
Интересно, что сейчас обсуждают по AI на подобных мероприятиях...
Посмотрел на кейс Кока-Колы и прослезился. В масштабах столь крупной компании снижение стоимость произошло с "ноль" до "ноль невзъеженный" - вряд ли там кто-то всерьёз воспринимает такие числа. Подозреваю, что стоимость миграции превысила экономию на порядки - попробуйте в крупной компании открыть проект, выбить бюджет, найти подрядчика, подписать договоры разработки и сопровождения...
Вспомнилась молодость, как мы продавали крупному забугорному клиенту "модное облачное решение", которое в итоге обошлось ему на порядки дороже одного выделенного сервера с простеньким Java-приложением. Но все довольны, бюджет освоен, пресс-релиз сделан, все молодцы. А то, что система постоянно падает из-за специфики сетевых настроек, принципиально ограничиваемых облачной интеграционной платформой - ну так про то большим боссам можно просто не говорить.
Работаю в "кровавом энтерпрайзе" (финансовые компании размером >5000 чел) - уж не знаю, считается ли это "взрослым бизнесом". Не видел ни одной удачной попытки качественно нормировать работу разработчика. Повторяющиеся однотипные работы (например, задачи поддержки) нормировать получается. Разработка, выходящая за рамки "набросать типовой отчётик" или "сверстать страничку по макету" обычно содержит слишком много неизвестных как технических, так и по постановке задачи. А люди при этом в своём опыте и производительности могут отличаться в разы даже в рамках одного грейда.
Все усредняют, деваться некуда, все разбираются с аналитикой и компетенциями разработчиков. Вот только оценке, будь то часы или сторипоинты, это мало помогает.
Институтский преподаватель поделился способом проверки знаний студентов: просит их найти определение в Википедии или чат-боте и указать ошибки в нём.
В пользу отказа от Excel можно привести ещё и аргументы безопасности: например, аудит изменений, разделение прав доступа. Ну и потребность в продвинутом UI, конечно.
"Например, слова «hello» и «helo» имеют много общих триграмм" - я насчитал ровно одну общую (hel). Не сильно много, или я что-то не так понял.
Соглашусь с автором - для не сильно сложных случаев поиска PostgreSQL хватит. Я в некоторых своих проектах текстовый поиск делал прямо на СУБД, несмотря на фантазии заказчика о хитром нечётком поиске. В итоге получалось, что обычного поиска по LIKE с нормализацией запроса (замена похожих символов на один, перевод в латиницу, вырезание посторонних символов) хватает за глаза.
Разработчики любят пихать какой-нибудь ElasticSearch для любого поиска, не представляя, в какой ад может превратиться поддержка поискового индекса в актуальном состоянии. При том, что продвинутый поиск может никогда и не понадобиться.
Всё чаще замечаю, что Хабр читать очень неприятно - на вроде бы техническую статью льётся куча ненависти. Писали статью о надёжности и производительности, а в комментах "говно", "чужие кости", "дно". Какое отношение это имеет к CDN, не ясно.
С нетерпением жду статьи о каком-нибудь устройстве автомобиля с комментами вроде "колёса-дно", "зачем автомобиль, если жизнь полный отстой".
Толпа умных людей, это в первую очередь толпа. ИТ-шный "энтерпрайз" - один из вариантов толпы. Все умные, высокооплачиваемые, все всё понимают, но на выходе получается хрень из-за постоянной несогласованности.
С другой стороны, в этом есть плюс - в отдельных случаях можно конкурировать с гигантами своим небольшим решением.
Независимо от уникальности есть ещё такая штука как ошибка ввода. И изменение законов. И хранение в БД удалённых значений. И ошибка постановки задачи. В-общем, да, синтетические ключи рулят.
Так зачем цвет выбирают-то? Кому и какой профит от этого?
Для некоторых компаний критична загрузка офисов для создания проходимости в близлежащих магазинах\ресторанах (которые принадлежат тем же компаниям или требуются по условиям аренды) и поддержания своего статуса. Грубо говоря, если уже арендовал и оплатил офис на 5 лет, то деваться особо и некуда - надо гнать туда людей.
Справедливости ради, не все гонят в офис - последние 15 лет работаю в финтехах (в том числе "биг") чисто на удалёнке (с опциональным посещением офиса).
"еды всякой просто тонна, конфеты завались сникерс, марс, баунти просто коробками стоит" - как там у народа с ожирением, диабетом и прочими плюшками такого питания? Понятно, что никто не заставляет всё это есть. Но интересно, насколько людям удаётся сопротивляться искушению.
Чем конструкция существенно отличается от любого другого генератора, где провод вращается в магнитном поле? Да и Википедия говорит про чрезвычайную неэффективность такого генератора.
Так речь только о шифровании. Про незащищённые концы соединения, обмен ключами и хранилища речи не идёт. А крадут скорее всего именно там. Но да, требования безопасности бывают очень формальные, раздутые, требовательные к ресурсам. К сожалению, раздолбайство, некомпетентность или злой умысел конечного исполнителя бумажкой так просто не прикрыть.
Годами использовал биндинги в WinForms, а его нет, оказывается :) Работал он не идеально, но работал. Проблема у WinForms была в другом - он на каждый элемент управления создавал окно Windows, из-за чего сложные формы тормозили. Интереса ради как-то сделал форму с большим количеством полей ввода на WinForms и такую же на HTML - HTML-форма в Google Chrome работала гораздо быстрее WinForms.
В-общем, если не нужны изыски отрисовки, то даже "голый" WinForms без специальных стилизованных элементов управления способен решать многие задачи (кроме разве что табличного ввода - он без доработки напильником не работал).