Получить публичный из приватного легко. Обратно, вычислить приватный из публичного, на обычном компьютере невозможно
Это к хешам относится.
Для пары ключей - ключи эквивалентны, и назначение "приватный", "публичный" чисто номинальное. И из одного (любого) получить второй считается очень сложным.
для манипуляций, например, с ansible запускаю в отдельном окружении, где нет bash истории, важных ssh ключей, и прочего. потом git push. и git pull в приватном окружении, где агенты не запускаются.
зы
знаю что некоторые параноят, и секретами объявляют имена пользователей и ip-адреса, тут увы...
Я понимаю ваш оптимизм и желание попробовать новое. Как говорится, велкам. ;)
Но лично мне вы не продали идею со смешанным хранением данных в memory/drive. Мои эксперименты показали, что важные сервисы, связанные с деньгами должны быть persistence only. Их можно обкладывать кешами различной природы и сложности, но за понимание важности durability, иногда, приходится расплачиваться условно "потом и кровью".
А если вспомнить, что ограничение в 1-2К фин. операций, это же при условии апдейта одного объекта. А такой кейс крайне специфичен, с одной стороны. С другой, при апдейте непересекающихся объектов, лимит вырастает до 10-15К. А я не знаю фин.систем, где бы было недостаточно 10-15К. Хотя допускаю, что они есть. ;)
Насколько я понял, вы сделали аля in-memory database с поддержкой ledger dsl, где история лежит в обычной rdbms.
Соответственно, у этого решения есть свои плюсы и минусы.
Плюсы - скорострельность по исполнению фин операций. Что логично, если все в памяти.
Минусы - давно известны для любого in-memory решения.
как дешево обеспечить конкурентный доступ к объектам. насколько я понял, у вас это решено через однопоточность (как в redis, tarantool, voltdb и т.д.)
в целом к однопоточности вопросов нет, до тех пор пока данных не становится сильно больше чем помещается в memory для одного сервера. что в этом случае делать, тоже уже давно известно, нужно часть данных скидывать в обычную rdbms. и вот тут начинаются разные сложности. уверен, кто эксплуатировал подобные решения, смогут рассказать много историй из своего опыта.
Мое имхо, с учетом современного железа, потюненный Postgres дает плюс минус 50K TPS.
Финансовых транзакций, примерно 10-15К.
Есть еще задержки от блокировки объектов из-за конкуренции, тогда скорость падает до 1-2К при плохом раскладе. Вполне допускаю что есть игроки для кого 1-2K фин. операций - это мало, и им нужны альтернативы, допустим в виде qazna ;)
Анти‑Agile акцентирует внимание на том, чтобы в начале проекта были зафиксированы четкие требования, что минимизирует вероятность изменений в будущем.
Если у вас есть четкие требования в самом начале, которые гарантировано не будут меняться, Agile вам не нужен. Беда лишь в том, что такая ситуация - относительная редкость. Соответственно приходится придумывать что-то, когда точно известно только одно - требования будут меняться.
В Agile команды работают над небольшими итерациями и могут менять направление в зависимости от фидбэка. В анти‑Agile акцент делается на планировании всей работы заранее.
По сути следствие предыдущего утверждения. Да, если требования зафиксированы, можно запланировать весь скоуп и далее просто бежать по нему.
Остальные утверждения - очень спорные.
Agile поощряет изменения и адаптацию, тогда как анти‑Agile требует строгого следования заранее установленным процессам и графикам.
Нет.
В Agile очень строгий метапроцесс - процесс непрерывных измерений и улучшений. Все производные процессы от главного метапроцесса (сбор требований, разработка, тестирование, и т.д.) - да, адаптируются. Но метапроцесс - очень формализован. И отказ от его формализованности влечет за собой все проблемы аджайла.
Agile подразумевает, что команды сами определяют, как работать, тогда как в анти‑Agile каждая команда имеет четко определенные роли и обязанности.
Agile декларирует, что ответственность команды за конкретный сервис должна быть всеобъемлющей. Отсюда и проистекает некоторая вторичность ролей. Т.е. условно бекендер или тестировщик не могут сказать - я не могу запрофилировать sql-запрос, это не моя проф.область, поэтому чтобы решить проблему ищите ДБА. На сервисе есть проблема - команда без оглядки на свои роли, ищет решение.
Когда у вас микросервисы, и хочется иметь одну точку управления схемами со всех микросервисов. Вот тогда, да, GraphQL проявляется во всей красе. Правда не достается бесплатно, есть свои ограничения.
Если у вас один сервис, то особого преимущества REST vs GQL нет.
Сертификат пользователя («фактор владения», расположен в хранилище сертификатов компьютера пользователя, можно сделать не экспортируемым)
Фактор владения приватным ключом!
Сертификат всего лишь свидетельство владения приватным ключом, в котором указано кому выдано свидетельство и кем. У сертификата не может быть фактора владения, т.к. сертификаты публичны.
В относительно простых процессах, без большой нагрузки, без требований по доступности, без требований по TTM, (критерии можно дальше продолжать) - Camunda вполне ок.
Если любой из критерием выше не выполняется - я сегодня Camunda'у из списка вычеркну.
Это не значит, что Camunda не может нагрузку держать. Если ее долго и мучительно тюнить - вполне может. Правда в этот момент приходит осознание, что без Camunda'ы во втором случае было бы легче, но выпиливать ее уже никто не даст, кучу усилий закопали в ее тюнинг.
вы сейчас про работу приложения на устройстве пользователя, к аутентификации на удаленном сервисе это никакого отношения не имеет.
в общем случае, да, было бы хорошо контролировать целостность софта на устройстве пользователя. но задача, опять же в общем случае, нерешаема, т.к. устройство контролирует только сам пользователь. нет никаких надежных способов ограничивать доступ к устройству. sony ps и iphone ломают несмотря на серьезные усилия производителей.
Встречал реализации, где для аутентификации вместо подписи отправлялся сертификат.
Т.е. аутентификация осуществлялась по предъявлению сертификата ;)))
зы
еще встречал реализации подписи файла, где подписывалось уникальное имя файла, а не содержимое файла. и авторы такого подхода утверждали, что все ок, т.к. имя файла уникально и секретно, а-ля хеш файла ;))
Это к хешам относится.
Для пары ключей - ключи эквивалентны, и назначение "приватный", "публичный" чисто номинальное. И из одного (любого) получить второй считается очень сложным.
все секреты лежат в секретах.
для манипуляций, например, с ansible запускаю в отдельном окружении, где нет bash истории, важных ssh ключей, и прочего. потом git push. и git pull в приватном окружении, где агенты не запускаются.
зы
знаю что некоторые параноят, и секретами объявляют имена пользователей и ip-адреса, тут увы...
так mcp это не другой интерфейс, это второй уровень абстракции за curl.
т.е. curl (или его аналог) все еще нужен, но что передать и как распарсить - вот тут mcp и пригодился. а дальше jq, awk и прочее.
Я понимаю ваш оптимизм и желание попробовать новое. Как говорится, велкам. ;)
Но лично мне вы не продали идею со смешанным хранением данных в memory/drive. Мои эксперименты показали, что важные сервисы, связанные с деньгами должны быть persistence only. Их можно обкладывать кешами различной природы и сложности, но за понимание важности durability, иногда, приходится расплачиваться условно "потом и кровью".
А если вспомнить, что ограничение в 1-2К фин. операций, это же при условии апдейта одного объекта. А такой кейс крайне специфичен, с одной стороны. С другой, при апдейте непересекающихся объектов, лимит вырастает до 10-15К. А я не знаю фин.систем, где бы было недостаточно 10-15К. Хотя допускаю, что они есть. ;)
Насколько я понял, вы сделали аля in-memory database с поддержкой ledger dsl, где история лежит в обычной rdbms.
Соответственно, у этого решения есть свои плюсы и минусы.
Плюсы - скорострельность по исполнению фин операций. Что логично, если все в памяти.
Минусы - давно известны для любого in-memory решения.
как дешево обеспечить конкурентный доступ к объектам. насколько я понял, у вас это решено через однопоточность (как в redis, tarantool, voltdb и т.д.)
в целом к однопоточности вопросов нет, до тех пор пока данных не становится сильно больше чем помещается в memory для одного сервера. что в этом случае делать, тоже уже давно известно, нужно часть данных скидывать в обычную rdbms. и вот тут начинаются разные сложности. уверен, кто эксплуатировал подобные решения, смогут рассказать много историй из своего опыта.
Мое имхо, с учетом современного железа, потюненный Postgres дает плюс минус 50K TPS.
Финансовых транзакций, примерно 10-15К.
Есть еще задержки от блокировки объектов из-за конкуренции, тогда скорость падает до 1-2К при плохом раскладе. Вполне допускаю что есть игроки для кого 1-2K фин. операций - это мало, и им нужны альтернативы, допустим в виде qazna ;)
Ночные остановки сейчас мало связаны с отчетами.
Сейчас остановки из-за обязательных операций, типа начислить проценты, начислить пени, и .т.д. Они не выполняются мгновенно на большой выборке.
Но в большинстве случаев - сейчас конечный пользователь про это не знает. Переводы с карты на карту работают 24/7 для конечных пользователей.
зачем kafka, если у вас есть таблица outbox_payments, которая выполняет по сути роль кафки?
да нет никаких чудес, идемпотентность - это только один нюансов.
надежная платежная логика основана на локах. есть некоторые частные случаи, когда можно обойтись без локов, в обмен на ... (и тут разные опции).
Я видел множество инсталляций SQL Server, которые были развернуты неспециалистами, и просто работали.
Я видел множество инсталляций Postgres, которые были развернуты неспециалистами, и просто работали.
Но почти не видел инсталляций Oracle (Express не беру в расчет), имхо как раз Oracle требуется внимание спеца, начиная с этапа развертывания.
Единственное справедливое утверждение:
Если у вас есть четкие требования в самом начале, которые гарантировано не будут меняться, Agile вам не нужен. Беда лишь в том, что такая ситуация - относительная редкость. Соответственно приходится придумывать что-то, когда точно известно только одно - требования будут меняться.
По сути следствие предыдущего утверждения. Да, если требования зафиксированы, можно запланировать весь скоуп и далее просто бежать по нему.
Остальные утверждения - очень спорные.
Нет.
В Agile очень строгий метапроцесс - процесс непрерывных измерений и улучшений. Все производные процессы от главного метапроцесса (сбор требований, разработка, тестирование, и т.д.) - да, адаптируются. Но метапроцесс - очень формализован. И отказ от его формализованности влечет за собой все проблемы аджайла.
Agile декларирует, что ответственность команды за конкретный сервис должна быть всеобъемлющей. Отсюда и проистекает некоторая вторичность ролей. Т.е. условно бекендер или тестировщик не могут сказать - я не могу запрофилировать sql-запрос, это не моя проф.область, поэтому чтобы решить проблему ищите ДБА. На сервисе есть проблема - команда без оглядки на свои роли, ищет решение.
Вся преимущество GraphQL в федерации.
Когда у вас микросервисы, и хочется иметь одну точку управления схемами со всех микросервисов. Вот тогда, да, GraphQL проявляется во всей красе. Правда не достается бесплатно, есть свои ограничения.
Если у вас один сервис, то особого преимущества REST vs GQL нет.
Неделя войны микрорепа vs монорепа объявляется открытой!
Фактор владения приватным ключом!
Сертификат всего лишь свидетельство владения приватным ключом, в котором указано кому выдано свидетельство и кем. У сертификата не может быть фактора владения, т.к. сертификаты публичны.
Я бы сказал, наоборот.
В относительно простых процессах, без большой нагрузки, без требований по доступности, без требований по TTM, (критерии можно дальше продолжать) - Camunda вполне ок.
Если любой из критерием выше не выполняется - я сегодня Camunda'у из списка вычеркну.
Это не значит, что Camunda не может нагрузку держать. Если ее долго и мучительно тюнить - вполне может. Правда в этот момент приходит осознание, что без Camunda'ы во втором случае было бы легче, но выпиливать ее уже никто не даст, кучу усилий закопали в ее тюнинг.
Расскажите, какие есть способы контроля целостности ПО на устройстве пользователя, которым может доверять удаленный сервис?
вы сейчас про работу приложения на устройстве пользователя, к аутентификации на удаленном сервисе это никакого отношения не имеет.
в общем случае, да, было бы хорошо контролировать целостность софта на устройстве пользователя. но задача, опять же в общем случае, нерешаема, т.к. устройство контролирует только сам пользователь. нет никаких надежных способов ограничивать доступ к устройству. sony ps и iphone ломают несмотря на серьезные усилия производителей.
ITIL и COBIT?
Это что.... ;)))
Встречал реализации, где для аутентификации вместо подписи отправлялся сертификат.
Т.е. аутентификация осуществлялась по предъявлению сертификата ;)))
зы
еще встречал реализации подписи файла, где подписывалось уникальное имя файла, а не содержимое файла. и авторы такого подхода утверждали, что все ок, т.к. имя файла уникально и секретно, а-ля хеш файла ;))
не надо.
достаточно проверять валидность подписи, и валидность сертификата(-ов), включая полномочия.
Выше странный спор, что выгоднее.
Все равно, что спорить, что выгоднее: своя машина, каршеринг или такси.
В зависимости от контекста, может быть выгоднее любая из опций. Это относительно легко считается и принимается решение.