Компания Google представила стабильный релиз платформы Knative 1.0, предназначенной для создания инфраструктуры бессерверных вычислений, развёртываемой поверх системы контейнерной изоляции на базе платформы Kubernetes. Кроме Google в разработке Knative также принимают участие такие компании, как IBM, Red Hat, SAP и VMware. Выпуск Knative 1.0 ознаменовал стабилизацию API для разработки приложений, который отныне не будет меняться и сохранит обратную совместимость. Код проекта написан на языке Go и распространяется под лицензией Apache 2.0...Подробнее: https://www.opennet.dev/opennews/art.shtml?num=56102
А естьь что нибудь такое, но с состоянием (например, банальный счётчик этих событий)? Или это как то выражается хитро?
А состояния в облаке :) В каком-то data lake или object storage или база в виде PaaS. Потом возникает еще вопрос как latency уменьшить, но зачем об этом думать при разработке?
Вообще serverless придумали для предельной экономии на выч. ресурсах, когда на latency уже глубоко пофиг.
Бессерверные типа у клиента?
Бессерверные на самом деле сервер то есть, но он не какой то выделенный процесс(ы), а динамически создаваемые контейнер (запускается каждый раз новый) по требованию (событию)
Вопрос только, чем это лучше загрузки по PXE, или, наконец, разливки виртуалок??
За каждый уровень ненужной абстракции от аппаратных ресурсов, имхо, нужно наказывать новым кругом ада.
Разливать целую виртуалку, чтобы запустить полумегабайтный бинарник, который проработает пару секунд? Боюсь, ваш круг будет 4294967295-м.
>Разливать целую виртуалку, чтобы запустить полумегабайтный бинарник, который проработает пару секунд? Боюсь, ваш круг будет 4294967295-м.И зачем VM разливать на каждый запуск? Смузихлёбы cron переизобрели, ещё и такой монструозный?
Если клиентов мало, то это всё ненужный бред - запускай задачу в кроне.
Если клиентов много, то твой сервер не должен постоянно глушить клиентов.Программный крон есть и в любой вменяемой среде (java ee, шпринг итд)
serverless - это вообще враньё, кубернейтс сам по себе монстр, ещё и крутится в линуксе, который тоже непростой. Хочешь проще - юзай bare metal + свой язык программирования без докеров и прочих мусорных контейнеров. Я так и делаю, кстати...
> Если клиентов мало, то это всё ненужный бред - запускай задачу в кроне.Вы, наверное, никогда в жизни не видели опытных программистов.
Иначе бы они вам за "запускай в кроне" все пальцы бы пообломали, и вы бы не смогли написать сюда про этот эталонный антипаттерн.
Я думаю дело не в этом, просто масштаб не тот. Для домашнего сервера с одной прогой можно и bare metal. Если зарплату платят за бесконечное ручное поддержание bare metal, то можно так вручную работать сколько угодно.
> Вопрос только, чем это лучше загрузки по PXE, или, наконец, разливки виртуалок??
> За каждый уровень ненужной абстракции от аппаратных ресурсов, имхо, нужно наказывать новым
> кругом ада.Время запуска дольше в 1000 раз. Время возврата ЦПУ и пвмяти в тыс. раз хуже. Сам по себе ЦПУ и память оч. не эффек. отдаются целиуом в ВМ для работы операционки.
Как раз конт-ы уменьшение числа абстракций и реш-е вопроса норм. и _быстро_ давать и возврашать ресурсы.
Так для задач есть давным-довно другие решения. Забыл как называются проги. И лоад балансеры и раздатчики и очередь разноса задач на серваки - всё это было уже десятки лет.
Эти решения мозга требуют, а не тык-тык-тык, вот и...
Понять, как работает knative, зачем он нужен и чем отличается от обычных балансировщиков нагрузки - требует ещё больше мозга.
Неудивительно, что в этом обсуждении таких участников крайне мало.
Начинать следует не с "как", а с "зачем".
Далее может случиться, что оно вообще не нужно.
Мой случай. Не вижу применения.
"Действительно, микроскопы не нужны. Орехи можно колоть и камнем." - похоже, тоже ваш случай.
Судя по вашим рассуждениям - как раз таки ваш, похоже.
Для задач уже лет 200, как есть MathCAD.
Это, типа, очередной идиотизм, как responsive для адаптивных страничек. Что поделать, засилье мартышек в IT...
Wrong. Knative - это не FaaS. Knative - это платформа для организации асинхронных коммуникаций для приложений, которые это делать из коробки не умеют или не хотят. В knative нет никакой возможности задеплоить функцию без сборки контейнера на локальной или удаленной магине. Для справки, в список настоящих FaaS фреймворков входят: kubeless, Apache OpenWhisk, Fission и еще некоторые другие менее популярные фреймворки
Но они же в описании не только про приложения, но и про отдельные функции пишут:
"Knative Serving builds on Kubernetes to support deploying and serving of applications and functions as serverless containers."
Ну, если функцию в контейнере можно считать функцией, то да.
А вот товарищ выше так не считает.
А вот API как всегда оказался совсем не API а корявым REST API?Но конечно, зачем об этом писать в новости. Современные обезьянки девляпсы вообще не понимают как может быть чтото другое.
Обнаружил на днях что модные тайм серис базы данных, которые рекламируют как решения для хай лоада, используют мать его http.Вот тут то ли я старею, то ли мир рехнулся окончательно.
Если HTTP/1.1 чересчур текстов и недостаточно бинарен, всегда можно использовать HTTP/2.Или у вас какие-то другие требования к протоколам для хайлоада, акромя пресловутой бинарности?
Сколько можно этому удивляться?HTTP достаточно навороченный из коробки, чтобы позволять совершать очень разнообразные запросы -- с параметрами и со всякой сопутствующей метаинформацией. Он позволяет всякие разные режимы ответа, с фиксированной длиной или chunked, сжатие если чё можно подключить. Опять же криптографически можно прикрыть канал, если надо. Можно упаковать несколько запросов в одно соединение, или открыть несколько соединений. Можно использовать кукисы, чтобы идентифицировать агента, который разные запросы отсылает по разным соединениям, то есть прерывающаяся сессия -- это не проблема. С http знакомо всё сетевое оборудование, и, скорее всего, пропускает его без проблем.
И хрен бы с ним, всё это (за исключением номера порта <1000 -- с этим могут быть проблемы) несложно написать в спецификацию своего на коленке созданного протокола, но к http прилагается куча уже готовых библиотек, как клиентских, так и серверных. _Любых_ библиотек, на любой вкус, под любой язык программирования. Можно даже с целым фреймворком, причём тут тоже есть выбор, вне зависимости от того, какой язык программирования ты выберешь. Можно балансировать нагрузку готовыми инструментами. Тебе не надо писать аж целый nginx, если тебе вдруг понадобится прокси или ревёрс-прокси.
Я не представляю себе, насколько острым должен быть рецидив NIH-синдрома, чтобы начать пилить аж целый новый протокол со всеми сопутствующими библиотеками, фреймворками и инструментами. Не, ну если требования какие-нибудь сильно неподходящие для http, типа двустороннего обмена сообщениями по три байта каждый... Но даже здесь у http есть web-socket'ы.
> рекламируют как решения для хай лоада, используют мать его http
> базы данныхЭто базы данных, у них узкое место -- вовсе не парсинг http. Ты можешь словить приступ NIH синдрома, проделать всё, что написано выше, запилить специально заточенный на скорость разбора бинарный протокол, и получить прирост производительности, который будет невозможно выделить из статистического шума.
А вот если на твоей нагрузке вдруг парсинг http станет узким местом, то вот тогда ты разработаешь альтернативный протокол, и добавишь в свой сервер опцией для тех, кому действительно надо. И даже нельзя сказать, что в результате ты будешь проделывать лишнюю работу (типа сначала на http реализовал, а потом на своём протоколе). На http реализовывать -- это настолько просто, что дополнительные затраты на разработку будет невозможно выделить из статистического шума (в том случае, если ты повторишь всё это действо достаточное количество раз, чтобы можно было бы считать статистику).
Предлагаете с MySQL через http работать?А чтож сразу недодумались так делать, странно. Наверное смузи не хватило.
То что какой-то мускуль тебует для общения не http-это пережиток прошлого.
> Предлагаете с MySQL через http работать?А как? Выставлять MySQL наружу, стучись кто хочет? От всяких там MitM как отбиваться?
> А чтож сразу недодумались так делать, странно.
Ничего странного. Когда запиливали MySQL, http не был развит до современного уровня. Стандарт HTTP/1.0 был опубликован в 1996 году, HTTPS в 2000, а MySQL явил себя свету в 1995. Но даже если бы MySQL создавали бы в 2000, это было ещё не тот уровень поддержки http софтом, который делает http безальтернативным выбором почти всегда. Вот в 2010 можно было подумать об этом.
Каким образом у вас http и безопасность сочетаются, мне непонятно.
Вы точно http ни с чем не перепутали?
Да у всех хттп(с) и безопасность сочетаются. Притом настолько, что веб-сервера аж выпускают в интеренет! Притом, что внутри сети - можно гонять чистый нешифрованный хттп, а для выхода наружу - завернуть в хттпс каким-нибудь нжинксом.
>А как? Выставлять MySQL наружу, стучись кто хочет? От всяких там MitM как отбиваться?а шо TLS в мускуле отменили?
Когда-то доступ к реляционным СУБД через SQL, а значит, и через сеть, задумывался и для клиентских мест. В банкоматах, например. Но тогда еще не было http.
Да и вообще разработчики не очень задумывались о таких вещах, как неавторизованный доступ или MitM.
> Предлагаете с MySQL через http работать?
> А чтож сразу недодумались так делать, странно. Наверное смузи не хватило.В Постгре уже есть.
> А вот если на твоей нагрузке вдруг парсинг http станет узким местом, то вот тогда ты разработаешь альтернативный протокол, и добавишь в свой сервер опцией для тех, кому действительно надо.Это, скорее всего, опять будет приступом NIH, потому что уже есть gRPC с protobuf, работающий поверх HTTP/2. Можно запилить произвольную структуру данных и написать для нее спеку, код упаковщика и распаковщика будет генерироваться автоматически.
Стареешь. В базах самое сложное-это выполнить операцию с данными. По какому протоколу получить данные запроса и отдать данные результата неважно. И чем этот протокол универсальнее и "страндартнее", тем лучше. Этого не осознают только копролиты родом из прошлого века. Вернее, в эпоху их появления тех самых достаточно "стандартных" протоколов просто небыло, поэтому городили какие-то свои, уникальные.
Базы разные бывают.
База данных временных рядов оптимизированная на запись вполне себе может и хттп ощутить.А http не стандартный.
Это протокол для передачи гипертекстовых документов, разросшийся в монстра для обслуги современных браузеров.При этом нынче их несколько сортов включая quic.
Идиотизм ситуации уже в том, что данные для запроса в бд нужно в uri кодировать.
> База данных временных рядов оптимизированная на запись вполне себе может и хттп ощутить.Тогда придется заливать данные в несколько потоков, о ужас!
> Идиотизм ситуации уже в том, что данные для запроса в бд нужно в uri кодировать.
Идиотизм, если это надо делать руками.
То, что при использовании бинарного протокола запрос приходится кодировать в бинарный вид, вас не смущает?
> Тогда придется заливать данные в несколько потоков, о ужас!Причём тут какие-то потоки вообще?
> То, что при использовании бинарного протокола запрос приходится кодировать в бинарный вид,
> вас не смущает?Я ничего про бинарные потоки не говорил. Пусть текстовые будут.
Кстати, текстовые протокол, внезапно, сидит поверх бинарного. То есть у вас уже как минимум один лишний уровень абстракций который нужно декодировать.
Но дело же не в том что хттп тектовый, а в том что это наркомания и идиотизм.
> Причём тут какие-то потоки вообще?При том, что если bulk insert заливается в 100 потоков по HTTP/2, то даже при не очень оптимальном парсере он будет быстрее, чем один поток бинарного протокола.
> Кстати, текстовые протокол, внезапно, сидит поверх бинарного.
Ага, ведь каждая буква - это байт. А в юникоде - даже несколько, кошмар!
Нужно срочно запретить использование текста в ЭВМ!!!1 Почему? Ну, потому что> это наpкомания и идиoтизм.
> Ага, ведь каждая буква - это байт. А в юникоде - даже
> несколько, кошмар!
> Нужно срочно запретить использование текста в ЭВМ!!!1 Почему? Ну, потому чтоВот ЭТО - наpкомания и идиoтизм.
Вы спорите с воображаемым вами адептом бинарных протоколов. Меня вы просто игнорируете.
А, не заморачивайтесь. Если предполагаемый сферический парсер в вакууме на каком-нибудь питоне писан, то да, там без 100 потоков не обойтись.
Э-э-э, с чего бы блджад.
У потоков так-то вообще ещё накладные расходы есть.
Мы не говорим про обработку данных потока - она распараллеливается без проблем вообще, только про анвраппинг.
>При том, что если bulk insert заливается в 100 потоков по HTTP/2, то даже при не очень оптимальном парсере он будет быстрее, чем один поток бинарного протокола.че за бред?
Скорее всего это не бред, а опыт работы с косорыло написанным парсером, в котором разбор данных совмещён с их заливкой в хранение. Всё в одно рыло, в один поток, естественно. Типично для всяких питоноподелок.
Поделить на ноль, простите, на разбор и далее очереди сохранения, которые независимо растаскиваются в хранилку - это уже слишком сложно.
Это ещё не смешно, и даже не страшно.
Смешно и страшно становится когда на эти модные дазы банных реально пытаешься приличную нагрузку завести. Внезапно оказывается, что их надо либо масштабировать на 10-кратные (бывает и больше) всем разумным потребностям задачи ресурсы, ну либо они просто ложатся.
Короче если у тебя нет миллио... энтерпрайза с бездонным бюджетом, можно идти на... мимо.
>Смешно и страшно становится когда на эти модные дазы банныхбиг-дейта, ваши рсубд по определению не решают этих задач
То, что эти ребята обзывают бигдейтой - в основном просто баззворд.
Данные нескольких сотен тысяч ежеминутных или около метрик с сети за год - ни разу не бигдейта.
А моднявые перделки под ними ложатся.
Видел, как от такого ложится Zabbix с MySQL backend. Это достаточно моднявые пeрделки?
Influx ложится гораздо раньше, личный опыт.
В итоге выбрано немножко другое решение: сливать из MySQL в RRD, и дальше отрисовывать из RRD.
Работает уже много лет без проблем в пределах одной не очень жирной виртуалки.
Вот спасибо за наводку кстати.Нужно хранить(и несложно запрашивать) несколько терабайт постоянно дописывающейся финансовой информации, стал перебирать новомодные решения и что-то во всём разочаровался, похоже на мускле остановлюсь.
> Данные нескольких сотен тысяч ежеминутных или около метрик с сети за год
> - ни разу не бигдейта.сотен тысяч метрик? у заббикса калькулятор есть, посчитайте какой объем получиться
Зачем мне калькулятор, если я и так в курсе, сколько получится - оно у меня работает.Number of items (enabled/disabled/not supported) 710250 340402 / 365957 / 3891
И какой объём я тоже в курсе, но калькулятор ваш не менее бесполезен, потому что ещё сжатие есть, и разные варианты хранения.
Немножко топчика, чтобы не голословно.top - 19:41:37 up 74 days, 9:34, 1 user, load average: 0.70, 1.58, 2.19
Tasks: 351 total, 4 running, 347 sleeping, 0 stopped, 0 zombie
%Cpu0 : 2.7 us, 0.3 sy, 0.0 ni, 96.7 id, 0.0 wa, 0.3 hi, 0.0 si, 0.0 st
%Cpu1 : 1.7 us, 0.7 sy, 0.0 ni, 97.0 id, 0.0 wa, 0.3 hi, 0.3 si, 0.0 st
%Cpu2 : 3.7 us, 0.3 sy, 0.0 ni, 95.0 id, 0.0 wa, 0.3 hi, 0.3 si, 0.3 st
%Cpu3 : 3.0 us, 4.3 sy, 0.0 ni, 92.4 id, 0.0 wa, 0.3 hi, 0.0 si, 0.0 st
%Cpu4 : 1.3 us, 0.7 sy, 0.0 ni, 98.0 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
%Cpu5 : 5.3 us, 1.0 sy, 0.0 ni, 92.1 id, 0.0 wa, 1.0 hi, 0.7 si, 0.0 st
%Cpu6 : 2.0 us, 4.0 sy, 0.0 ni, 93.4 id, 0.0 wa, 0.3 hi, 0.0 si, 0.3 st
%Cpu7 : 4.3 us, 4.7 sy, 0.0 ni, 91.0 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
%Cpu8 : 1.3 us, 0.7 sy, 0.0 ni, 97.7 id, 0.0 wa, 0.3 hi, 0.0 si, 0.0 st
%Cpu9 : 2.0 us, 2.3 sy, 0.0 ni, 95.7 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
%Cpu10 : 2.3 us, 3.7 sy, 0.0 ni, 94.0 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
%Cpu11 : 2.3 us, 1.3 sy, 0.0 ni, 96.4 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
MiB Mem : 32087.3 total, 641.0 free, 18311.1 used, 13135.2 buff/cache
MiB Swap: 0.0 total, 0.0 free, 0.0 used. 10582.5 avail MemPID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
1199 mysql 20 0 22.9g 15.0g 6352 S 10.6 47.9 99204:44 /usr/sbin/mariadbd
3998729 zabbix 20 0 932168 34156 22528 R 7.0 0.1 0:00.21 /opt/httpd/bin/httpd -f /etc/httpd/php73/httpd.conf -DFOREGROUND
2090 zabbix 20 0 4783976 1.2g 1.1g S 3.0 3.7 1777:29 /usr/sbin/zabbix_server: history syncer #7 [processed 0 values, 0 triggers in 0.000064 sec, idle 1 sec]
2085 zabbix 20 0 4781980 1.2g 1.1g S 2.3 3.7 1773:30 /usr/sbin/zabbix_server: history syncer #2 [processed 0 values, 0 triggers in 0.000104 sec, idle 1 sec]
2091 zabbix 20 0 4784592 1.2g 1.1g S 2.3 3.7 1751:07 /usr/sbin/zabbix_server: history syncer #8 [processed 0 values, 0 triggers in 0.000064 sec, idle 1 sec]
2089 zabbix 20 0 4782632 1.1g 1.1g S 2.0 3.7 1770:55 /usr/sbin/zabbix_server: history syncer #6 [processed 0 values, 0 triggers in 0.000065 sec, idle 1 sec]
2154 zabbix 20 0 4724032 694012 679660 S 1.7 2.1 1877:26 /usr/sbin/zabbix_server: trapper #4 [processed data in 0.057868 sec, waiting for connection]
2087 zabbix 20 0 4771716 1.1g 1.1g R 1.0 3.6 1780:20 /usr/sbin/zabbix_server: history syncer #4 [processed 21 values, 59 triggers in 0.006304 sec, syncing history]
2152 zabbix 20 0 4733984 707520 683084 R 0.7 2.2 1868:29 /usr/sbin/zabbix_server: trapper #2 [processing data]
...
> Зачем мне калькулятор, если я и так в курсе, сколько получится -
> оно у меня работает.
> Number of items (enabled/disabled/not supported) 710250 340402 / 365957 / 3891
> И какой объём я тоже в курсе, но калькулятор ваш не менее
> бесполезен, потому что ещё сжатие есть, и разные варианты хранения.размер таблиц и период хранения
Очередная муть для оптимизации расходов на специалистов.
А затем данные случайно утекают, система валится глобально на сутки, датацентры горят.
Все это прекрасно реализуется на старой доброй сишке, написанной бородатыми прогерами и за makeinstall-енной не менее бородатыми админами. Был бы нужный радиус кривизны рук - проблемы придут сами.
За мейкинсталлами - это к любителям CI со смузи, в докерок из-под рута, потому что иначе не получается, а потом ещё внезапно редисы с монгами голой задницей в сеть торчат, потому что понадобились, а васян с интернетиков, собиравший образ для быстрого деплоя в два тыка 5 конечностью по клавиатуре, про авторизацию забыл.
если это помогает выкинуть из профессии таких как ты, значит, продукт нужный
> если это помогает выкинуть из профессии таких как ты, значит, продукт нужныйНе помогает. Так что получается ненужный.
Смотря о какой профессии речь. Если речь идёт про бородатых олдскульщиков, пишущих простые сайты на PHP для выкладывания на shared hosting с апачом через FTP - пожалуйста, там вы будете к месту.
> Смотря о какой профессии речь. Если речь идёт про бородатых олдскульщиков, пишущих
> простые сайты на PHP для выкладывания на shared hosting с апачом
> через FTPНет, речь не о них.
Тогда о какой? Профессии серьёзного разработчика или админа за серьёзные деньги от вас достаточно надёжно защищает входной порог для эрудиции (способность читать документацию и понимать абстрактные концепции).
Остаётся предположить, что речь идёт о профессиях, далёких от IT.
В молодости я работал в фирме производящей и поставляющей средства защиты информации. Обслуживали и гос структуры (в том числе силовые) и частные.Но все же в итоге ушел в сторону ИТ, закончил университет и занимался анализом клинических исследований, теперь большая часть моих интересов лежит в области ИИ.
Если вас интересует моё отношение с системой из новости, то я скорее буду проектировать нечто подобное чем этим пользоваться. Вполне вероятно кто-то из моих студенческих друзей к этому Knative руку и приложил.
Но, как я недвусмысленно дал понять, меня такие штуки не сильно интересует в принципе, я не думаю что это верное направление развития информационных технологий и инфраструктуры в целом.
Ну вот знаете вы теперь допустим, и что вам с этого?
P.S. В контейнерах есть нюанс: потом нужно много народу на поддержку. Может потому и пилят что-то типа сабжа поверх уже существующего.
Дык, бесплатно только первая доза контейнеров.
А дальше уже деваться некуда.
Поэтому прежде чем выбирать решения - есть смысл думать. Да, это сложно, я в курсе.
Я хочу для самообразования запихать простого телеграм бота в AWS lambda, если заработает то смогу детальней тут рассуждать, но даже абстрактно, это в разы дешевле на старте со всех сторон
> Я хочу для самообразования запихать простого телеграм бота в AWS lambda, если
> заработает то смогу детальней тут рассуждать, но даже абстрактно, это в
> разы дешевле на старте со всех сторонВы не туда видимо его пихаете.
Нужно делать бота имитирующего работу программиста(или иного ИТ специалиста) для всевозможных метрик. То есть чтобы он юлозил мышкой, митинги принимал, вносил правки в жиру.
Ну, для сисадмина(девопса) будет немного по другом но идея ясна, главное понимать корпоративные метрики.
И тогда можно работать сразу от 3х до 10ти работах.
Заодно бота который ищет работу в случае когда работодатель на одной из работ замечает бота.>AWS lambda
Забавная штука, правда уже с главной страницы возникает один вопрос - что это такое, на который Амазон упорно не хочет давать ответа. Обилие маркетингового буллщита на квадратный миллиметр текста зашкаливает.
!Безсерверные! вычисления на !серверах! амазона онли 9.99 лол.А так да, для всяких телеграмм ботов и прочей ерунды очень удобно.
>>AWS lambda
> Забавная штука, правда уже с главной страницы возникает один вопрос - что
> это такое, на который Амазон упорно не хочет давать ответа.не знаю даже как тут помочь - сам я доки почитал, туториалы и примеры, какая-то картинка в голове сложилась.
Можно у яндекс.клауда почитать, идея там общая, построение фраз слегка другое
Этой новости точно место на OpenNet? Выглядит как реклама коммерческого сервиса, да ещё без пометки "на правах рекламы".
Наоборот, это это полностью открытый аналог коммерческих сервисов. Код открыт, а платформа решает проблему vendor lock-а и позволяет создать аналог serverless облаков на своём оборудовании.
Свободный ли он?
от тебя - да
Я понимаю когда такие решения применяются в интерпрайзах, грамотно, а потому оправданно, но самое досадное видеть, как бобики-фаловеры пихают такие тяжелые вещи куда не попадя, главное на хайпе, что они следуют новшествам, а реально - все равно что на фуре на работу ездить...
Так и не понял что это и что делает.
Что мне не нравится в Knative - это добавление дополнительного уровня абстракций над абстракциями кубы. К имеющимся Pod-ReplicaSet-Deployment-Service-Ingress добавляются очень хитро переплетенные с ними Configuration-Revision-Service(*)-Route (* - это не тот Service, его просто так назвали).В этом плане KEDA нравится куда больше - занимается чисто eventing-ом, не пытаясь вмешиваться в процессы деплоя.
Ждём платформу беспроцессорных вычислений.
Так и не пойму, как конкретно я могу это использовать? Под какую задачу? Вот, к примеру, веду софт по складской аналитике на Delphi под win7/10. Скажу, что для этого проекта облако вообще не вперлось, но тем не менее хочу найти какую то причину, чтобы окунуться в океан смузи.
Да вы true veteran Unix developer, не парьтесь из-за этой хипcтоты. Вы труЪ и без неё.
Это как "старт-стоп энджин" на светофоре чтоль? Если это так... сомнительная нужность, что то, что это!
Представьте, что бензин стоит в сто раз дороже, чем сейчас (аналогия с весьма завышенным ценником на вычислительные мощности в AWS). Всё еще сомнительная?