Сразу не понял какого аниме это описание

error.stack

Рубрика #мюсли Знаете, почему сервисы больших IT гигантов безбожно тормозят на фоне крайне высокой сложности попасть туда работать программистом? Казалось бы, туда идут "лучшие из лучших", все должно работать максимально оптимизированно — ведь они знают, как развернуть бинарное дерево! Все потому, что там не знают разницы между реальной масштабируемостью и видимостью масштабируемости. Вместо простого рабочего решения айтишники больших компаний соревнуются в максимальном усложнении систем. Отчасти потому, что их так научили, отчасти потому, что чем сложнее поддерживать систему, тем ценнее они как единственный кадр, знающий, что происходит. Предположим, хочет условный член манги поднять простой сайт с текстовой документацией. Он накатывает кубернетисы, лоадбалансеры, гейтвеи, где-то ещё докер закинет, 2-5 сервисов аналитики (включая бажную и неповоротливую внутреннюю), редис умудряется впихнуть — да ещё и десяток-другой технологий. Ну а что? Все же так делают — это стандарт в индустрии! Что делает инди-разработчик? Бандлит сайт, который весит 20кб, запуливает его на GitHub Pages и запускает кеш через Cloudflare. Все — сайт мгновенно и быстро доступен из любой точки мира, упасть он физически не может, а стоит это дело $0 в месяц. Все летает. Такого никогда не будет в манге, просто потому, что там не знают: меньше — лучше. Это правило относится как к созданию продуктов, так и к разработке, так и ко всему остальному в жизни. Собственно говоря, поэтому я каждый год вынужден отклонять приглашения на принципал роли в мангу — я знаю, что там работают разворачиватели бинарных деревьев на кубернетисах, а не разумные разработчики, которые запускают продукты. Update: видео в тему. Спасибо @manwatermelon!

у тебя еще более-менее нормальный стек :) ты с инженерами из манги не работал, похоже

Спасибо) Это именно вопрос - как захостить что то такое, используя Github pages? Или это просто удобный сервис именно для фронта?

только для статики

А можно туда заливать что-то без гит клиента? Ту же статику. А то я сейчас aws s3 пользуюсь, может тоже альтернатива)

Рубрика #мюсли Знаете, почему сервисы больших IT гигантов безбожно тормозят на фоне крайне высокой сложности попасть туда работать программистом? Казалось бы, туда идут "лучшие из лучших", все должно работать максимально оптимизированно — ведь они знают, как развернуть бинарное дерево! Все потому, что там не знают разницы между реальной масштабируемостью и видимостью масштабируемости. Вместо простого рабочего решения айтишники больших компаний соревнуются в максимальном усложнении систем. Отчасти потому, что их так научили, отчасти потому, что чем сложнее поддерживать систему, тем ценнее они как единственный кадр, знающий, что происходит. Предположим, хочет условный член манги поднять простой сайт с текстовой документацией. Он накатывает кубернетисы, лоадбалансеры, гейтвеи, где-то ещё докер закинет, 2-5 сервисов аналитики (включая бажную и неповоротливую внутреннюю), редис умудряется впихнуть — да ещё и десяток-другой технологий. Ну а что? Все же так делают — это стандарт в индустрии! Что делает инди-разработчик? Бандлит сайт, который весит 20кб, запуливает его на GitHub Pages и запускает кеш через Cloudflare. Все — сайт мгновенно и быстро доступен из любой точки мира, упасть он физически не может, а стоит это дело $0 в месяц. Все летает. Такого никогда не будет в манге, просто потому, что там не знают: меньше — лучше. Это правило относится как к созданию продуктов, так и к разработке, так и ко всему остальному в жизни. Собственно говоря, поэтому я каждый год вынужден отклонять приглашения на принципал роли в мангу — я знаю, что там работают разворачиватели бинарных деревьев на кубернетисах, а не разумные разработчики, которые запускают продукты. Update: видео в тему. Спасибо @manwatermelon!

Количество пользователей и RPS сути дела не меняет? По сути, под капотом действий DO и CF те же самые действия, просто B2C / B2B cloud решения. Одно дело, когда у меня 63к RPS, а другое, когда 100 пользователей в день (:

да, там все то же самое (но только сильно облегченное) под капотом, если мы говорим про Cloudflare + у них CDN по всему миру + они бесплатные

В разгар нефтяного кризиса 1970-х в США Лиз Кармайкл представила Dale — трёхколёсный автомобиль будущего. Он расходовал всего литр бензина на 30 км, разгонялся до 130 км/ч и стоил $2000. Обещания были слишком хорошими, но никого это не смутило: депозиты отправлялись, бумаги компании скупались. К 1975 году выяснилось, что у фирмы нет даже прототипа, а сама Лиз — это фальшивомонетчик Джерри Дин Майкл, которого ФБР ищет больше 10 лет vc.ru/transport/324009

А это уже приносили? https://youtu.be/3t6L-FlfeaI

просто ощущение, что это либо несуществующий аудит, либо тот самый фанговский (или любой энтерпрайз) внутренний аудит... ради аудита — и из-за которого все сервисы больших компаний такие низкосортные с точки зрения производительности

скорее всего человек именно про внутренний аудит и говорит

А самое плохое в больших компаниях — невозможно от этого аудита избавиться из-за бюрократии. В итоге мы и получаем то, что я описал в посте.

+ никому не нужно менять то, "что не сломано"

+ никому не нужно менять то, "что не сломано"

Рубрика #мюсли Знаете, почему сервисы больших IT гигантов безбожно тормозят на фоне крайне высокой сложности попасть туда работать программистом? Казалось бы, туда идут "лучшие из лучших", все должно работать максимально оптимизированно — ведь они знают, как развернуть бинарное дерево! Все потому, что там не знают разницы между реальной масштабируемостью и видимостью масштабируемости. Вместо простого рабочего решения айтишники больших компаний соревнуются в максимальном усложнении систем. Отчасти потому, что их так научили, отчасти потому, что чем сложнее поддерживать систему, тем ценнее они как единственный кадр, знающий, что происходит. Предположим, хочет условный член манги поднять простой сайт с текстовой документацией. Он накатывает кубернетисы, лоадбалансеры, гейтвеи, где-то ещё докер закинет, 2-5 сервисов аналитики (включая бажную и неповоротливую внутреннюю), редис умудряется впихнуть — да ещё и десяток-другой технологий. Ну а что? Все же так делают — это стандарт в индустрии! Что делает инди-разработчик? Бандлит сайт, который весит 20кб, запуливает его на GitHub Pages и запускает кеш через Cloudflare. Все — сайт мгновенно и быстро доступен из любой точки мира, упасть он физически не может, а стоит это дело $0 в месяц. Все летает. Такого никогда не будет в манге, просто потому, что там не знают: меньше — лучше. Это правило относится как к созданию продуктов, так и к разработке, так и ко всему остальному в жизни. Собственно говоря, поэтому я каждый год вынужден отклонять приглашения на принципал роли в мангу — я знаю, что там работают разворачиватели бинарных деревьев на кубернетисах, а не разумные разработчики, которые запускают продукты. Update: видео в тему. Спасибо @manwatermelon!

Рубрика #мюсли Знаете, почему сервисы больших IT гигантов безбожно тормозят на фоне крайне высокой сложности попасть туда работать программистом? Казалось бы, туда идут "лучшие из лучших", все должно работать максимально оптимизированно — ведь они знают, как развернуть бинарное дерево! Все потому, что там не знают разницы между реальной масштабируемостью и видимостью масштабируемости. Вместо простого рабочего решения айтишники больших компаний соревнуются в максимальном усложнении систем. Отчасти потому, что их так научили, отчасти потому, что чем сложнее поддерживать систему, тем ценнее они как единственный кадр, знающий, что происходит. Предположим, хочет условный член манги поднять простой сайт с текстовой документацией. Он накатывает кубернетисы, лоадбалансеры, гейтвеи, где-то ещё докер закинет, 2-5 сервисов аналитики (включая бажную и неповоротливую внутреннюю), редис умудряется впихнуть — да ещё и десяток-другой технологий. Ну а что? Все же так делают — это стандарт в индустрии! Что делает инди-разработчик? Бандлит сайт, который весит 20кб, запуливает его на GitHub Pages и запускает кеш через Cloudflare. Все — сайт мгновенно и быстро доступен из любой точки мира, упасть он физически не может, а стоит это дело $0 в месяц. Все летает. Такого никогда не будет в манге, просто потому, что там не знают: меньше — лучше. Это правило относится как к созданию продуктов, так и к разработке, так и ко всему остальному в жизни. Собственно говоря, поэтому я каждый год вынужден отклонять приглашения на принципал роли в мангу — я знаю, что там работают разворачиватели бинарных деревьев на кубернетисах, а не разумные разработчики, которые запускают продукты. Update: видео в тему. Спасибо @manwatermelon!

Срочно нужен эксперимент, манга-way против инди-way, посмотреть, кто первый канет в небытие

Срочно нужен эксперимент, манга-way против инди-way, посмотреть, кто первый канет в небытие

уже: templates.borodutch.com

Я про знатный ддос

Я про знатный ддос

https://t.me/golden_borodutch/5301

0 конфигурации, $0 заплачено, отбита крупная ддос атака

0 конфигурации, $0 заплачено, отбита крупная ддос атака

лоадбалансеров нет

(у меня нет)

Для пачки из 10 микросервисов докер и лоадбалансер тоже будут лишними?

Рубрика #мюсли Знаете, почему сервисы больших IT гигантов безбожно тормозят на фоне крайне высокой сложности попасть туда работать программистом? Казалось бы, туда идут "лучшие из лучших", все должно работать максимально оптимизированно — ведь они знают, как развернуть бинарное дерево! Все потому, что там не знают разницы между реальной масштабируемостью и видимостью масштабируемости. Вместо простого рабочего решения айтишники больших компаний соревнуются в максимальном усложнении систем. Отчасти потому, что их так научили, отчасти потому, что чем сложнее поддерживать систему, тем ценнее они как единственный кадр, знающий, что происходит. Предположим, хочет условный член манги поднять простой сайт с текстовой документацией. Он накатывает кубернетисы, лоадбалансеры, гейтвеи, где-то ещё докер закинет, 2-5 сервисов аналитики (включая бажную и неповоротливую внутреннюю), редис умудряется впихнуть — да ещё и десяток-другой технологий. Ну а что? Все же так делают — это стандарт в индустрии! Что делает инди-разработчик? Бандлит сайт, который весит 20кб, запуливает его на GitHub Pages и запускает кеш через Cloudflare. Все — сайт мгновенно и быстро доступен из любой точки мира, упасть он физически не может, а стоит это дело $0 в месяц. Все летает. Такого никогда не будет в манге, просто потому, что там не знают: меньше — лучше. Это правило относится как к созданию продуктов, так и к разработке, так и ко всему остальному в жизни. Собственно говоря, поэтому я каждый год вынужден отклонять приглашения на принципал роли в мангу — я знаю, что там работают разворачиватели бинарных деревьев на кубернетисах, а не разумные разработчики, которые запускают продукты. Update: видео в тему. Спасибо @manwatermelon!

только монолит, ломать — так всё разу

https://t.me/golden_borodutch/5301

(у меня нет)

Но есть у..?

CF и GH :)

но кубернетис я все равно разверну...

Я КУБЕРНЕТИС РАЗВЕРНУ

И СНОВА

@purplenoodlesoop кста, я купил гречневое молоко

Ну, какой-то абстрактный вопрос (: зачем тогда кэшировать страничку, если она и так работает? Быстрота ответа? Тогда понижается отказоустойчивость. Не понижается? Но добавили же новый элемент. Либо лыжи у меня не туда едут (:

Ну, какой-то абстрактный вопрос (: зачем тогда кэшировать страничку, если она и так работает? Быстрота ответа? Тогда понижается отказоустойчивость. Не понижается? Но добавили же новый элемент. Либо лыжи у меня не туда едут (:

Согласен. Очень согласен. Cloudflare ведь тогда тоже дополнительный элемент и должен понижать отказоустойчивость системы.

Согласен. Очень согласен. Cloudflare ведь тогда тоже дополнительный элемент и должен понижать отказоустойчивость системы.

Cloudflare — это часть "уже работает"

Cloudflare — это часть "уже работает"

А, погоди, мы потеряли контекст. Ты запускал в GCS или AWS когда-нибудь серверы?

Тогда я вообще не понял вопроса. А если сразу сделать с кубернетисом — он ведь тоже будет частью “уже работает”

++

А, погоди, мы потеряли контекст. Ты запускал в GCS или AWS когда-нибудь серверы?

В Heroku только

heroku — это антипод (что тоже нехорошо) AWS и GCS :)

heroku — это антипод (что тоже нехорошо) AWS и GCS :)

В Heroku только

глянь видос в посте, все поймешь

heroku — это антипод (что тоже нехорошо) AWS и GCS :)