Гугл с шарами явно поспешил, они использовали водород для хранения энергии, и солнечные панели для производства водорода из воды из воздуха. Ну и плюс система навигации была очень сложная и зависела от точности предсказания погоды, шар должен был постоянно менять высоту чтобы оставаться плюс/минус в одной области.
Задумка опередила свое время, но если бы все получилось то было бы очень круто, шар который может находиться в воздухе почти неограниченное время, плюс висит в одной области, ну и собирает кучу метео информации.
Сорян, но это бред. Фанатичным человек может быть в любой вещи, в питании, в спорте, да почти во всем. Так же как и верить во всякую фигню, но это все к религии не имеет никакого отношения. Так как нету и не предвидится всяких религиозных атрибутов в виде святых, священных книг и действий. В науке это в принципе невозможно.
Наоборот в киноиндустрии сейчас увеличивают количество актеров через производство сериалов, которых стало просто очень много. И скорее удел всяких ИИ и нейросетей это помощники в кинопроизводстве, ну образно говоря провести кастинг среди 10 тыс актеров проблемно, а когда будет генерация сюжетов нейросетью с этими же актерами, то это будет намного быстрее (так же можно парные/груповые кастинги проводить).
Если бы статья называлась "Что нас ждет в ближайший год" то у меня не было бы вопросов и комментариев про капитанство, 10 лет это большой срок, и за это время человечество может вернуться к каменным топорам, или может уйти в виртуальную реальность или просто наступит сингулярность. Точно можно например говорить что в ближайшие 10 лет не будет коммерческого термоядерного реактора, так как технология прям сильно сложная и передний край науки.
Не надо быть гением или предсказателем, надо просто понимать что любой новый инструмент или технология всегда используется для автоматизации какой-то рутинной деятельности, причем не важно созидательной или разрушительной. И это не про жадных капиталистов которым охота заменить куча народу на робота и не платить бабок (обычно роботы и вся автоматизация обходиться дороже ручного труда), а именно как про процесс развития и масштабирования деятельности.
И про пример с мамой, тут все просто, человек у которого плохо развито критическое мышление, всегда будет мишенью для сравнительно честного отъема материальных ценностей.
1. Наука станет полноценной религией, а новые религии станут возникать на базе науки.
Сильно сомневаюсь, религия основанная на вере, а наука на знании - это принципиально противоположные вещи.
2. Переформатирование музыкальной и киноиндустрии.
Думаю все будет с точностью до наоборот, персональные фильмы и музыка никому не нужны. Так как персональный фильм ты просто ни с кем не сможешь обсудить, или совместно посмотреть. Так же группа людей не сможет оторваться под чей-то персональный трек. Ну и физически нереально посмотреть Титаник со всеми возможными актерами, чтобы потом быть в теме и иметь возможность обсудить фильм с другими людьми. Да и смотреть фильм с одним и тем же актером неинтересно, и просто надоест, как бы этот актер не нравился.
3. Фреймворки для конструирования промптов
Это прям настолько очевидно, что вопрос завтрашнего дня, а никак не 10-ти лет.
4. Мошенничество, новые улики и новые религиозные откровения.
Тоже очевидно, что всегда новые технологии или инструменты привлекают авантюристов.
5. Zapier для нейросетей и единые API для нейронок разных типов.
Тоже очевидная штука, и тоже вопрос завтрашнего дня, а никак не 10-ти лет.
6. Контроль за удаленными сотрудниками усложнится.
Это вообще какая-то дичь странная, через 10 лет может не быть такого формата работы вообще, или удаленка может быть в какой-то виртуальной среде, где как раз эти все "подмены" будут частью виртуальной среды. Ну или просто появятся новые средства детектирования генерированного контента.
7. Национальный налог на нейросети.
Више уже отписали про это, это тоже очевидно.
8. Сайд-эффекты могут нас уничтожить — в общем-то, Матрица или SkyNet гораздо ближе, чем мы думаем.
А может наоборот? И нейросети пошли по тупиковому тупи и отдалили нас от Матрица или SkyNet? Ну и уничтожить человечество, если я правильно понял про "нас" довольно таки проблематично, есть некоторое количество людей которые сильно далеки от техники и прогресса, и могут выжить натуральным хозяйством.
9. Аналитика, психология, статистика.
Тоже очевидная штука.
Вообщем смесь какого-то капитанства плюс хочухи автора, но никак не попытка предсказать будущее.
Все с точностью до наоборот. Без DevOps лезть в облака финансово опасно, там столько подводных камней, которые просто приведут к сжиганию кучи бабла.
Пример с нейросеткой - это прям очень сильно узкая ниша, и которая появилась сильно позже облаков и всей этой облачной истерии.
можно например автоматически масштабироваться в зависимости от нагрузки
Ага, только это все маркетинговый bullshit, как только дело до этого доходит, то получаем попу, разного размера. Начиная от того что cpu/memory usage метрики не годятся для не cpu/memory bound задач - а веб как раз и не является такими задачами.
что позволит не покупать лишние сервера, которые будут 90% времени стоять незагруженными
Ага, только на практике ты вряд ли нормально настроишь лимиты, поэтому тот же гугл пытается использовать ИИ для управления ресурсами, и клиентам предлагает autopilot для решения этой задачи. Но получаеться не очень, все тоже сжигание бабла, потому как поднимает лимиты на любой чих, а вот понижать уже сам не будет. Вызвал клиент раз в месяц эндпоинт для генерации тяжелого отчета - лимиты поднялись, и все с этого момента платишь за ресурсы по новым лимитам. Если без автопилота с жесткими лимитами, то у тебя просто перегрузиться контейнер, и по F5 клиент пойдет перегружать соседний контейнер - отчет то он хочет получить.
Можно обновляться без простоя, можно плавно перестраивать архитектуру разворачивая временные схемы и уничтожая их, когда они стали ненужными и так далее.
Это все можно получить и без облаков.
И при всех плюсах у облаков достаточно минусов. И нужно прям сильно хорошо понимать зачем и почему нужно облако для запуска нагрузки в нем.
ClickHouse назвать стартапом ну это прям лихо. ClickHouse - это внутренняя разработка Яндекса и активно применялась в метрике. И только очень сильно потом стала Open Source и еще сильно позже была создана новая компания Altinity.
1-е я делал так, в контейнере основным процессом был monit он собственно отвечал за запуск cloud_sql_proxy, haproxy и приложения (причем внутри конфигов monit были свои чеки для запуска/перезапуска нужных частей и что самое главное monit позволяет задавать зависимости, ну и не менее приятное что можно слать алерты для разных событий запуска/перезапуска, ну и прям как бонус, но я это не использовал, что monit умеет собирать статистику по использованию cpu/memory и с ней работать/слать алерты). Пробы были такие, startup - успешный вызов /bin/true(контейнер запустился), liveness проба pgrep -x /usr/bin/monit(главный процесс запустился). Проба readiness хитрая, сам haproxy отвечал всегда 200 кодом, но при этом внутри был чек на /healtz ендпоинт приложения (если чек не прошел то возвращаем ошибку, если прошел то ответ от приложения). Внутри healtz и была сделана проверка на работоспособность - запрос к бд с дефолтовыми параметрами (для вашего примера запрос цены всегда одного и того же маршрута), с таймером на получение ответа, если таймер сработал раньше ответа из бд, то healtz возвращает ошибку.
Если бы внутри приложения были метрики и возможность обращения к ним, тогда бы haproxy не был бы нужен и схема была чуть проще.
Пришлось городить огород с monit, потому что в кубере нету зависимостей и порядка запуска контейнеров, стратегия перезапуска странная (перезапуск всего пода, если один из контейнеров не здоров, поэтому нельзя так просто cloud_sql_proxy запустить в виде sidecar контейнера).
2-е да в с cloud-sql-proxy все было гладко, как раз из-за наличия проб, поэтому monit нормально мониторил эту проксю, конфигурацию такого плана
check process cloud_sql_proxy with pidfile "/var/run/app/cloud_sql_proxy.pid"
start program = "/etc/init.d/start_cloud_sql_proxy"
stop program = "/bin/sh -c 'kill -s SIGTERM `cat /var/run/app/cloud_sql_proxy.pid`'"
if failed host 127.0.0.1 port 9090 protocol HTTP request "/startup" then restart
if failed host 127.0.0.1 port 9090 protocol HTTP request "/liveness" then restart
group proxy
сам /etc/init.d/start_cloud_sql_proxy не особо сложный и просто обертка для запуска с нужными параметрами, но можно было это все напрямую вставить в monit конфиг
Я думаю так, что retry budget хорош в том случае если апи выставляетесь наружу, а внутри фиксированная инфраструктура без скейлинга. Внутри же как по мне лучше использовать знание инфраструктуры и профилей нагрузок для управления трафиком и скейлинга если надо.
1-е и должно решать использованием метрик перед обращением к внешним ресурсам, если в начале /get/price сделать запрос в кеш метрик и увидеть что коннекты к базе (или другому сервису) обрабатывают с задержкой, то нету смысла делать еще один запрос, надо отдать клиенту ошибку. Да вместо базы может быть все что угодно, и если для этого есть метрика, то ее лучше использовать. Да можно по таймеру отдавать ошибку клиенту, если ответ идет дольше чем надо от базы или другого сервиса, но это только в том случае, если нету метрик.
Идея как раз в том чтобы не ждать пока мониторинг сработает, а сработает он с задержкой и из-за этого накопиться кучу запросов в очереди, а сразу используя метрики с пода решать вопрос про деградацию сервиса и отдавать нужный ответ, и просто не заставлять клиента ловить таймаут.
2-е да это нужно, для меня прям почти идеальный пример такого мультиплексор cloud-sql-proxy, потому что он собирает метрики, есть ендпоинты для проб startup, liveness, readiness и можно держать коннекты к разным базам и из-за этого можно на localhost забиндить на разные порты например основную бд и реадонли реплики.
3-е и 4-е я как раз и против скейлинга на основе cpu usage для не cpu bounded задач, надо использовать метрики которые относятся к запросам (количество ошибок, среднее, перцентили). Ну и совмещение подхода, если микросервис перегружен запросами по внутренним метрикам, то микросервис на время(например 1 мин) вывести из обслуживания(через /readiness пробу). Микросервис вернется к обработке трафика как только перемелет все входящие запросы из очереди и метрики выровняться. А для того чтобы не было массового вывода таких микросервисов из работы, скейлинг должен сработать раньше.
Да и чтобы этот самый скейлинг работает, в идеальной ситуации надо чтобы один микросервис работал с одной БД, если же с одной БД работает много микросервисов, то очень сложно угадать скейлинг какого их них приведет к падению базы. Или же просто в таком случае собирать микросервисы в микромонолиты.
Для того чтобы понять чем занимается "Инженер по тестированию", надо название должности "Quality Assurance engineer" перевести дословно как "Инженер по контролю качества" и все станет на свои места. А тестер это просто прибор, так же как и тестирование это просто процесс.
ИМХО проблема в том что нужна соответствующая инфраструктура для запуска микросервисом. И если говорить проще, то Вася был с самого начала прав, и автоскейлинг подов решил бы бы проблему storm retry.
Нужно правильно реализовать пробы, startup, readiness, liveness. Проба startup понятно, микросервис запустился, прочитал конфигурацию, прогрел кеш и сделал другие нужные действия. Сложнее дело обстоит с readiness и liveness - обработчик этих проб должен быть в своем потоке, и не блокироваться входящими соединениями. Если такие пробы будут в общем обработчике соединений, то шторм запросов просто приведет к тому что liveness не будет проходить, и контейнер будет циклически перезапускаться. В идеальной ситуации liveness проба должна всегда быть успешной если микросервис работает(это проба про работу контейнера, а не микросервиса), тоесть данная проба нужна только для перезапуска контейнера из-за фатальной ошибки. Проба readiness самая сложная, она должна проверять что микросервис работает в нужном режиме, образно говоря для примера с микросервисом цен, такая проба всегда должна делать запрос на получения цены (чтобы полностью проверить подключение к базе, подключение к редису и т.д.)
При этом есть одно но, автоскейлинг на основе % памяти/cpu работает только для простых случаев(или обычных cpu bound задач), для более сложных нужно чтобы микросервис собирал и отдавал телеметрию. И в этом случае автоскейлинг будет работать так, если например ответов с 500 больше 40% (не с пода, а со всех подов, статистику берем с сервера телеметрии), то начинаем скейлиться, например х2.
И когда нормально работает телеметрия, то ее можно уже вкрутить и в readiness пробу, образно говоря перед запросом на получения цены, проверить в данных телеметрии процент 500, и если он больше 80% например, то проба вернет fail, и соответственно на контейнер перестанет попадать трафик, контейнер всем ответит и вернется в нормальное состояние.
Понятно что цифры взял с потолка, и их надо брать из мониторинга и тюнить под свои нужды.
Prolog - 1972
SQL - 1974
Гугл с шарами явно поспешил, они использовали водород для хранения энергии, и солнечные панели для производства водорода из воды из воздуха. Ну и плюс система навигации была очень сложная и зависела от точности предсказания погоды, шар должен был постоянно менять высоту чтобы оставаться плюс/минус в одной области.
Задумка опередила свое время, но если бы все получилось то было бы очень круто, шар который может находиться в воздухе почти неограниченное время, плюс висит в одной области, ну и собирает кучу метео информации.
Потом можно морить и использовать в строительстве или искусстве.
И диод подсветки.
Вроде как раз так и было реализовано в Коболе, и почти вся "старая" мировая банковская система работала на нем.
И про perl 6...
Да и не указано что космонавты должны быть людьми, может быть опять вся свалят на Белку и Стрелку.
Нормальный план и сроки реальные, нигде же не сказано что космонавтов будут возвращать.
Сорян, но это бред. Фанатичным человек может быть в любой вещи, в питании, в спорте, да почти во всем. Так же как и верить во всякую фигню, но это все к религии не имеет никакого отношения. Так как нету и не предвидится всяких религиозных атрибутов в виде святых, священных книг и действий. В науке это в принципе невозможно.
Наоборот в киноиндустрии сейчас увеличивают количество актеров через производство сериалов, которых стало просто очень много. И скорее удел всяких ИИ и нейросетей это помощники в кинопроизводстве, ну образно говоря провести кастинг среди 10 тыс актеров проблемно, а когда будет генерация сюжетов нейросетью с этими же актерами, то это будет намного быстрее (так же можно парные/груповые кастинги проводить).
Если бы статья называлась "Что нас ждет в ближайший год" то у меня не было бы вопросов и комментариев про капитанство, 10 лет это большой срок, и за это время человечество может вернуться к каменным топорам, или может уйти в виртуальную реальность или просто наступит сингулярность. Точно можно например говорить что в ближайшие 10 лет не будет коммерческого термоядерного реактора, так как технология прям сильно сложная и передний край науки.
Не надо быть гением или предсказателем, надо просто понимать что любой новый инструмент или технология всегда используется для автоматизации какой-то рутинной деятельности, причем не важно созидательной или разрушительной. И это не про жадных капиталистов которым охота заменить куча народу на робота и не платить бабок (обычно роботы и вся автоматизация обходиться дороже ручного труда), а именно как про процесс развития и масштабирования деятельности.
И про пример с мамой, тут все просто, человек у которого плохо развито критическое мышление, всегда будет мишенью для сравнительно честного отъема материальных ценностей.
Сильно сомневаюсь, религия основанная на вере, а наука на знании - это принципиально противоположные вещи.
Думаю все будет с точностью до наоборот, персональные фильмы и музыка никому не нужны. Так как персональный фильм ты просто ни с кем не сможешь обсудить, или совместно посмотреть. Так же группа людей не сможет оторваться под чей-то персональный трек. Ну и физически нереально посмотреть Титаник со всеми возможными актерами, чтобы потом быть в теме и иметь возможность обсудить фильм с другими людьми. Да и смотреть фильм с одним и тем же актером неинтересно, и просто надоест, как бы этот актер не нравился.
Это прям настолько очевидно, что вопрос завтрашнего дня, а никак не 10-ти лет.
Тоже очевидно, что всегда новые технологии или инструменты привлекают авантюристов.
Тоже очевидная штука, и тоже вопрос завтрашнего дня, а никак не 10-ти лет.
Это вообще какая-то дичь странная, через 10 лет может не быть такого формата работы вообще, или удаленка может быть в какой-то виртуальной среде, где как раз эти все "подмены" будут частью виртуальной среды. Ну или просто появятся новые средства детектирования генерированного контента.
Више уже отписали про это, это тоже очевидно.
А может наоборот? И нейросети пошли по тупиковому тупи и отдалили нас от Матрица или SkyNet? Ну и уничтожить человечество, если я правильно понял про "нас" довольно таки проблематично, есть некоторое количество людей которые сильно далеки от техники и прогресса, и могут выжить натуральным хозяйством.
Тоже очевидная штука.
Вообщем смесь какого-то капитанства плюс хочухи автора, но никак не попытка предсказать будущее.
Выбрал Perl, из-за принципа TMTOWTDI, это максимизация не количества конструкций языка, а вариантов записи решения с использованием конструкций языка.
Все с точностью до наоборот. Без DevOps лезть в облака финансово опасно, там столько подводных камней, которые просто приведут к сжиганию кучи бабла.
Пример с нейросеткой - это прям очень сильно узкая ниша, и которая появилась сильно позже облаков и всей этой облачной истерии.
Ага, только это все маркетинговый bullshit, как только дело до этого доходит, то получаем попу, разного размера. Начиная от того что cpu/memory usage метрики не годятся для не cpu/memory bound задач - а веб как раз и не является такими задачами.
Ага, только на практике ты вряд ли нормально настроишь лимиты, поэтому тот же гугл пытается использовать ИИ для управления ресурсами, и клиентам предлагает autopilot для решения этой задачи. Но получаеться не очень, все тоже сжигание бабла, потому как поднимает лимиты на любой чих, а вот понижать уже сам не будет. Вызвал клиент раз в месяц эндпоинт для генерации тяжелого отчета - лимиты поднялись, и все с этого момента платишь за ресурсы по новым лимитам. Если без автопилота с жесткими лимитами, то у тебя просто перегрузиться контейнер, и по F5 клиент пойдет перегружать соседний контейнер - отчет то он хочет получить.
Это все можно получить и без облаков.
И при всех плюсах у облаков достаточно минусов. И нужно прям сильно хорошо понимать зачем и почему нужно облако для запуска нагрузки в нем.
Зависит от того делим мы на плюс ноль или на минус ноль.
ClickHouse назвать стартапом ну это прям лихо. ClickHouse - это внутренняя разработка Яндекса и активно применялась в метрике. И только очень сильно потом стала Open Source и еще сильно позже была создана новая компания Altinity.
Ну с микросервисами оно все дорого.
1-е я делал так, в контейнере основным процессом был monit он собственно отвечал за запуск cloud_sql_proxy, haproxy и приложения (причем внутри конфигов monit были свои чеки для запуска/перезапуска нужных частей и что самое главное monit позволяет задавать зависимости, ну и не менее приятное что можно слать алерты для разных событий запуска/перезапуска, ну и прям как бонус, но я это не использовал, что monit умеет собирать статистику по использованию cpu/memory и с ней работать/слать алерты). Пробы были такие, startup - успешный вызов
/bin/true(контейнер запустился), liveness пробаpgrep -x /usr/bin/monit(главный процесс запустился). Проба readiness хитрая, сам haproxy отвечал всегда 200 кодом, но при этом внутри был чек на /healtz ендпоинт приложения (если чек не прошел то возвращаем ошибку, если прошел то ответ от приложения). Внутри healtz и была сделана проверка на работоспособность - запрос к бд с дефолтовыми параметрами (для вашего примера запрос цены всегда одного и того же маршрута), с таймером на получение ответа, если таймер сработал раньше ответа из бд, то healtz возвращает ошибку.Если бы внутри приложения были метрики и возможность обращения к ним, тогда бы haproxy не был бы нужен и схема была чуть проще.
Пришлось городить огород с monit, потому что в кубере нету зависимостей и порядка запуска контейнеров, стратегия перезапуска странная (перезапуск всего пода, если один из контейнеров не здоров, поэтому нельзя так просто cloud_sql_proxy запустить в виде sidecar контейнера).
2-е да в с cloud-sql-proxy все было гладко, как раз из-за наличия проб, поэтому monit нормально мониторил эту проксю, конфигурацию такого плана
сам /etc/init.d/start_cloud_sql_proxy не особо сложный и просто обертка для запуска с нужными параметрами, но можно было это все напрямую вставить в monit конфиг
Я думаю так, что retry budget хорош в том случае если апи выставляетесь наружу, а внутри фиксированная инфраструктура без скейлинга. Внутри же как по мне лучше использовать знание инфраструктуры и профилей нагрузок для управления трафиком и скейлинга если надо.
1-е и должно решать использованием метрик перед обращением к внешним ресурсам, если в начале /get/price сделать запрос в кеш метрик и увидеть что коннекты к базе (или другому сервису) обрабатывают с задержкой, то нету смысла делать еще один запрос, надо отдать клиенту ошибку. Да вместо базы может быть все что угодно, и если для этого есть метрика, то ее лучше использовать. Да можно по таймеру отдавать ошибку клиенту, если ответ идет дольше чем надо от базы или другого сервиса, но это только в том случае, если нету метрик.
Идея как раз в том чтобы не ждать пока мониторинг сработает, а сработает он с задержкой и из-за этого накопиться кучу запросов в очереди, а сразу используя метрики с пода решать вопрос про деградацию сервиса и отдавать нужный ответ, и просто не заставлять клиента ловить таймаут.
2-е да это нужно, для меня прям почти идеальный пример такого мультиплексор cloud-sql-proxy, потому что он собирает метрики, есть ендпоинты для проб startup, liveness, readiness и можно держать коннекты к разным базам и из-за этого можно на localhost забиндить на разные порты например основную бд и реадонли реплики.
3-е и 4-е я как раз и против скейлинга на основе cpu usage для не cpu bounded задач, надо использовать метрики которые относятся к запросам (количество ошибок, среднее, перцентили). Ну и совмещение подхода, если микросервис перегружен запросами по внутренним метрикам, то микросервис на время(например 1 мин) вывести из обслуживания(через /readiness пробу). Микросервис вернется к обработке трафика как только перемелет все входящие запросы из очереди и метрики выровняться. А для того чтобы не было массового вывода таких микросервисов из работы, скейлинг должен сработать раньше.
Да и чтобы этот самый скейлинг работает, в идеальной ситуации надо чтобы один микросервис работал с одной БД, если же с одной БД работает много микросервисов, то очень сложно угадать скейлинг какого их них приведет к падению базы. Или же просто в таком случае собирать микросервисы в микромонолиты.
Для того чтобы понять чем занимается "Инженер по тестированию", надо название должности "Quality Assurance engineer" перевести дословно как "Инженер по контролю качества" и все станет на свои места. А тестер это просто прибор, так же как и тестирование это просто процесс.
ИМХО проблема в том что нужна соответствующая инфраструктура для запуска микросервисом. И если говорить проще, то Вася был с самого начала прав, и автоскейлинг подов решил бы бы проблему storm retry.
Нужно правильно реализовать пробы, startup, readiness, liveness. Проба startup понятно, микросервис запустился, прочитал конфигурацию, прогрел кеш и сделал другие нужные действия. Сложнее дело обстоит с readiness и liveness - обработчик этих проб должен быть в своем потоке, и не блокироваться входящими соединениями. Если такие пробы будут в общем обработчике соединений, то шторм запросов просто приведет к тому что liveness не будет проходить, и контейнер будет циклически перезапускаться. В идеальной ситуации liveness проба должна всегда быть успешной если микросервис работает(это проба про работу контейнера, а не микросервиса), тоесть данная проба нужна только для перезапуска контейнера из-за фатальной ошибки. Проба readiness самая сложная, она должна проверять что микросервис работает в нужном режиме, образно говоря для примера с микросервисом цен, такая проба всегда должна делать запрос на получения цены (чтобы полностью проверить подключение к базе, подключение к редису и т.д.)
При этом есть одно но, автоскейлинг на основе % памяти/cpu работает только для простых случаев(или обычных cpu bound задач), для более сложных нужно чтобы микросервис собирал и отдавал телеметрию. И в этом случае автоскейлинг будет работать так, если например ответов с 500 больше 40% (не с пода, а со всех подов, статистику берем с сервера телеметрии), то начинаем скейлиться, например х2.
И когда нормально работает телеметрия, то ее можно уже вкрутить и в readiness пробу, образно говоря перед запросом на получения цены, проверить в данных телеметрии процент 500, и если он больше 80% например, то проба вернет fail, и соответственно на контейнер перестанет попадать трафик, контейнер всем ответит и вернется в нормальное состояние.
Понятно что цифры взял с потолка, и их надо брать из мониторинга и тюнить под свои нужды.
На маке эти все зависимости можно поставить через macport или brew и уже потом делать кросскомпиляцию.
Хорово