Самый близкий по сути проект к тому, что я имел в виду под
heroku-подобный serverless контейнер
видимо, https://caprover.com/. Но у него недостатки такие (дальше цитаты из мануалов):
(Simple Setup) The recommended method to install CapRover is via DigitalOcean one-click app. CapRover is available as a One-Click app in DigitalOcean marketplace.
даунгрейдить virtual server до serverless не имеет никакого смысла. Ни технически, ни финансово.
(Run Locally) Note that this is an advanced process. Some of the concepts used in this section are not easy for the beginners. In order to run CapRover on your local machine (just for testing and development) you need Docker installed on your machine.
а это уже совершенно недопустимо. Инсталляция на любой платформе (или как минимум на популярных) должна сводиться к самому типичному для этой платформы способу установки прикладного ПО. То есть на Ubuntu -- apt install, на Маке -- brew install или перетаскиванием *.dmg, на Windows -- кликом на *.exe и т. д.
А вот что можно запросто выбросить из списка фич, так это поддержку баз данных. Уже и так создан миллион сервисов персистентности для serverles apps.
Ну и, конечно, я бы с удовольствием присоединился к проекту, но только если весь код будет распространяться под свободной лицензией (пермиссивной или копилефт, не принципиально).
Не вижу особой разницы. В том и другом случае ресурсы не простаивают, только штуки типа folding@home привлекают пользователей гуманистическим посылом, а ваша идея, как я понимаю, заключается в том, чтобы понемногу отдавать свои простаивающие мощности за возможность кратковременно, на пике мощности, использовать чужие.
Мне очень нравится ваша идея в таком виде.
Только кубернетисы, конечно, для этого не подойдут, а подойдёт какой-нибудь heroku-подобный serverless контейнер. Я не смотрел в эту сторону раньше, не знаю, существуют ли такие, или нужно будет писать своё.
И надо будет немножко повозиться с определением эквивалента мощности. Плюс понадобятся некие централизованные ресурсы для сведения баланса, пробития NAT, распределения лямбд по контейнерам, ну и для организационных целей. Тут можно будет просто продавать часть ресурсов за деньги при необходимости. Лучше оформить это как нон-профит, при этом нужен будет ещё какой-то свой сервис, чтобы автоматически публиковать бюджет. Как-то так.
Я бы не слишком надеялся на Интел. Летом 2021 он выдал по ОЕМ-каналам неадекватный Iris Xe DG1 (совместим только с процессорами Intel, и то далеко не со всеми поколениями, ужасного качества драйвера, производительность на уровне мобильных аналогов), и у меня нет оснований надеяться, что Arc будет чем-то лучше, по крайней мере, на старте. Если рынок готов поглотить любое убожество, зачем стараться?
А ведь мы отлично живём без видеокарт! Я имею в виду тенденции в игровой индустрии. Дискретке в моём десктопе уже 5 лет от роду, причём это не хай энд, а так -- типичный середнячок. Но все современные AAA-игры работают без проблем. Видел на ютубе прохождение God of War на встройке Athlon 3000G. Понимаете, к чему я клоню? Если бы не дефицит чипов, нас уже развели бы на один-два бессмысленных апгрейда.
В статье описаны некоторые реальные проблемы фреймворка, но натяжек и вкусовщины в ней, наверное, больше. Я не хочу разбирать статью от начала до конца, скажу только за один пункт, на котором я уже привычно теряю терпение в последние годы.
Не конфигурируйте Django через переменные среды. Никогда. На это есть достаточно причин.
Django основан на WSGI, WSGI -- это расширение CGI, а в CGI env vars используются для связи с веб-сервером/прокси. Они уже заняты, и по стандарту, и исторически. Неужели надо придумывать ещё какие-то "де факто", чтобы использовать вещь не по назначению?
Переменные среды хранят текст. Для Perl или Bash в этом нет никакой проблемы, но для Python приходится писать парсер/валидатор, который будет дополнительным (и совершенно ненужным) источником ошибок и уязвимостей в вашем приложении.
Переменные среды -- это диагностическая информация, а многие инструменты имеют привычку показывать диагностику при сбоях. Таким образом утекло уже достаточно секретов.
Конфигурация -- это код. Любая достаточно сложная система конфигурирования однажды вырастает в динамический ЯП, иногда даже Тьюринг-полный. Зачем изобретать новый ЯП? Просто пишите конфигурацию на Python.
Как же тогда конфигурировать Django-приложение, если не через файлы среды? Ответ прост: конфигурируйте его через файлы конфигурации.
Если у вас один проект/сервер, храните *.py-файл с секретами вне репозитория, а при установке копируйте его на место (вручную или скриптом, например, Fabric хорош для создания маленьких деплой-скриптов) и импортируйте в основной файл конфигурации.
Если у вас большой проект, то те инструменты для CI/CD, которые вы уже используете, наверняка позволяют шаблонизировать файлы конфигурации. Храните секреты в файлах конфигурации CI/CD или в специальных хранилищах секретов, и внедряйте их через шаблоны в конфиги при деплое.
В багтрекере сквирела уже не первый год висит пара-тройка багов, подобных этому. Может, и именно этот. Приоритет у них ниже некуда, почти wontfix, потому что "сквирел не предназначен для выполнения недоверенного кода". И вообще, сквирел -- проект одного человека, да и тот кмк выгорел.
Для меня самым явным свидетельством развития технологии является её положение на рынке. Я не агитирую за убийство животных как неотъемлемую часть человеческой культуры. Я готов питаться любой вкусной, полноценной и доступной пищей, независимо от её происхождения.
Но давайте посмотрим на технологии, о которых вы говорите в своей статье, через потребительские характеристики соответствующих товаров.
Вкус. По вкусу "растительное мясо" даже не напоминает натуральное мясо, а напоминает скорее низкокачественные мясные продукты, в которые для удешевления добавляются растительные добавки. Что, в принципе, логично.
Диетические свойства. Растения не содержат некоторых витаминов и незаменимых аминокислот. Конечно, можно их добавить и в привычные растительные продукты, если "поиграть" с генами, но ГМО сейчас -- жупел, и на это никто из производителей не пойдёт. Использовать вещества животного, микробиологического или синтетического происхождения? Это скажется отрицательно на себестоимости.
А по себестоимости "растительное мясо" и так проигрывает натуральному.
То есть о превосходстве по сумме потребительских характеристик даже говорить не стоит. Значит, агитировать потребителя пока рано, надо серьёзно работать над технологиями.
К сожалению, тенденция, которую я вижу в вашей статье -- это стремление перекроить рынок, воспользовавшись идеологией вместо технологии. Наклеив "зелёный" ярлык и воспользовавшись эмоциональным давлением. Это грустно. И это так или иначе просматривается сейчас и по всем другим направлениям, которых вы коснулись: энергетика, транспорт и т. д.
Ну, это я так образно выражаюсь. Почку-не почку, но повыкручивать руки друг другу в судах можно.
Открытый код без лицензии -- опасно. Я так закоммичу что-нибудь, а вы потом прикрутите лицензию, в которой каждый коммитер обязан продать почку.
Проприетарные: Google Firebase, Azure SQL Database, SashiDo. Открытые: Parse, Strapi.
Самый близкий по сути проект к тому, что я имел в виду под
видимо, https://caprover.com/. Но у него недостатки такие (дальше цитаты из мануалов):
даунгрейдить virtual server до serverless не имеет никакого смысла. Ни технически, ни финансово.
а это уже совершенно недопустимо. Инсталляция на любой платформе (или как минимум на популярных) должна сводиться к самому типичному для этой платформы способу установки прикладного ПО. То есть на Ubuntu --
apt install, на Маке --brew installили перетаскиванием *.dmg, на Windows -- кликом на *.exe и т. д.А вот что можно запросто выбросить из списка фич, так это поддержку баз данных. Уже и так создан миллион сервисов персистентности для serverles apps.
Ну и, конечно, я бы с удовольствием присоединился к проекту, но только если весь код будет распространяться под свободной лицензией (пермиссивной или копилефт, не принципиально).
Не вижу особой разницы. В том и другом случае ресурсы не простаивают, только штуки типа folding@home привлекают пользователей гуманистическим посылом, а ваша идея, как я понимаю, заключается в том, чтобы понемногу отдавать свои простаивающие мощности за возможность кратковременно, на пике мощности, использовать чужие.
Мне очень нравится ваша идея в таком виде.
Только кубернетисы, конечно, для этого не подойдут, а подойдёт какой-нибудь heroku-подобный serverless контейнер. Я не смотрел в эту сторону раньше, не знаю, существуют ли такие, или нужно будет писать своё.
И надо будет немножко повозиться с определением эквивалента мощности. Плюс понадобятся некие централизованные ресурсы для сведения баланса, пробития NAT, распределения лямбд по контейнерам, ну и для организационных целей. Тут можно будет просто продавать часть ресурсов за деньги при необходимости. Лучше оформить это как нон-профит, при этом нужен будет ещё какой-то свой сервис, чтобы автоматически публиковать бюджет. Как-то так.
https://github.com/BOINC/boinc не оно?
Карл Маркс и Фридрих Энгельс -- это не муж и жена, а четыре совершенно разных человека.
Я бы не слишком надеялся на Интел. Летом 2021 он выдал по ОЕМ-каналам неадекватный Iris Xe DG1 (совместим только с процессорами Intel, и то далеко не со всеми поколениями, ужасного качества драйвера, производительность на уровне мобильных аналогов), и у меня нет оснований надеяться, что Arc будет чем-то лучше, по крайней мере, на старте. Если рынок готов поглотить любое убожество, зачем стараться?
А ведь мы отлично живём без видеокарт! Я имею в виду тенденции в игровой индустрии. Дискретке в моём десктопе уже 5 лет от роду, причём это не хай энд, а так -- типичный середнячок. Но все современные AAA-игры работают без проблем. Видел на ютубе прохождение God of War на встройке Athlon 3000G. Понимаете, к чему я клоню? Если бы не дефицит чипов, нас уже развели бы на один-два бессмысленных апгрейда.
Здорово. А форк публичный? Можно посмотреть?
А вы заметили, как любое описание софта без ссылки на исходники воспринимается как скам?
В статье описаны некоторые реальные проблемы фреймворка, но натяжек и вкусовщины в ней, наверное, больше. Я не хочу разбирать статью от начала до конца, скажу только за один пункт, на котором я уже привычно теряю терпение в последние годы.
Не конфигурируйте Django через переменные среды. Никогда. На это есть достаточно причин.
Django основан на WSGI, WSGI -- это расширение CGI, а в CGI env vars используются для связи с веб-сервером/прокси. Они уже заняты, и по стандарту, и исторически. Неужели надо придумывать ещё какие-то "де факто", чтобы использовать вещь не по назначению?
Переменные среды хранят текст. Для Perl или Bash в этом нет никакой проблемы, но для Python приходится писать парсер/валидатор, который будет дополнительным (и совершенно ненужным) источником ошибок и уязвимостей в вашем приложении.
Переменные среды -- это диагностическая информация, а многие инструменты имеют привычку показывать диагностику при сбоях. Таким образом утекло уже достаточно секретов.
Конфигурация -- это код. Любая достаточно сложная система конфигурирования однажды вырастает в динамический ЯП, иногда даже Тьюринг-полный. Зачем изобретать новый ЯП? Просто пишите конфигурацию на Python.
Как же тогда конфигурировать Django-приложение, если не через файлы среды? Ответ прост: конфигурируйте его через файлы конфигурации.
Если у вас один проект/сервер, храните *.py-файл с секретами вне репозитория, а при установке копируйте его на место (вручную или скриптом, например, Fabric хорош для создания маленьких деплой-скриптов) и импортируйте в основной файл конфигурации.
Если у вас большой проект, то те инструменты для CI/CD, которые вы уже используете, наверняка позволяют шаблонизировать файлы конфигурации. Храните секреты в файлах конфигурации CI/CD или в специальных хранилищах секретов, и внедряйте их через шаблоны в конфиги при деплое.
Самая важная концепция, которую я усвоил на примере этого поста -- gatekeeping. Своих различаем, чужих не пущаем.
DeaDBeeF
Дежавю. Вроде как пару дней назад видел эту статью.
В багтрекере сквирела уже не первый год висит пара-тройка багов, подобных этому. Может, и именно этот. Приоритет у них ниже некуда, почти wontfix, потому что "сквирел не предназначен для выполнения недоверенного кода". И вообще, сквирел -- проект одного человека, да и тот кмк выгорел.
https://neos.com/
Цукерберг опоздал, у нас уже есть Neos. Все фурфаги уже там.
Для меня самым явным свидетельством развития технологии является её положение на рынке. Я не агитирую за убийство животных как неотъемлемую часть человеческой культуры. Я готов питаться любой вкусной, полноценной и доступной пищей, независимо от её происхождения.
Но давайте посмотрим на технологии, о которых вы говорите в своей статье, через потребительские характеристики соответствующих товаров.
Вкус. По вкусу "растительное мясо" даже не напоминает натуральное мясо, а напоминает скорее низкокачественные мясные продукты, в которые для удешевления добавляются растительные добавки. Что, в принципе, логично.
Диетические свойства. Растения не содержат некоторых витаминов и незаменимых аминокислот. Конечно, можно их добавить и в привычные растительные продукты, если "поиграть" с генами, но ГМО сейчас -- жупел, и на это никто из производителей не пойдёт. Использовать вещества животного, микробиологического или синтетического происхождения? Это скажется отрицательно на себестоимости.
А по себестоимости "растительное мясо" и так проигрывает натуральному.
То есть о превосходстве по сумме потребительских характеристик даже говорить не стоит. Значит, агитировать потребителя пока рано, надо серьёзно работать над технологиями.
К сожалению, тенденция, которую я вижу в вашей статье -- это стремление перекроить рынок, воспользовавшись идеологией вместо технологии. Наклеив "зелёный" ярлык и воспользовавшись эмоциональным давлением. Это грустно. И это так или иначе просматривается сейчас и по всем другим направлениям, которых вы коснулись: энергетика, транспорт и т. д.