В статье это упоминается, что nginx free не поддерживает интеграцию с keycloak.
На самом деле ручная проверка токена в коде ( signature, exp, iss & etc ) даст мнимое улучшение производительности по сравнению с отправкой в keycloak, который сделает это сам. Плюс возможен кейс, когда токен пользователя отозван ( например, закрыли доступ, поменяли атрибуты или еще что-то). Тогда без проверки на уровне кейклока это не решить.
Либо же выпускать короткоживущие токены, например, на 1 мин, и забить на лаг в 1 мин в таких моментах. Но с точки зрения производительности - это самая большая нагрузка на auth service, так как именно генерация токена самая сложная операция.
Действительно, при разработке решений я стараюсь не привязываться к конкретному облачному провайдеру, более того, желательно иметь возможность запустить все решение в тестовой / демо версии на обычном голом железе без каких-либо технологий со стороны облачного провайдера, используя только open-source решения. В идеале, чтобы можно было все запустить из обычного docker compose.
Например:
Lambda могут быть завернуты в свои docker контейнеры с разными триггерами ( cron, sqs consumer, http server и т д) -- фактически получается имитация лямбды функции
SQS можно заменить на ElasticMQ
S3 можно заменить на minio
Вместо Congnito можно использовать Keycloak
и т.д.
Localstack при этом я не использую, чтобы точно отмежеваться от AWS.
Это добавляет больше работы, вопросов с тестированием и т.д., но есть 2 больших плюса:
легко разрабатывать локально
нет зависимости от облачного провайдера
Далее в существующий код уже добавляется обвязка для конкретных сервисов, например, реальные Lambda с триггерами по http и т.д.
В результате решение может быть перенесено на любую платформу.
Касательно, Terraform. В целом согласен, как мне кажется, было бы хорошо, чтобы остался только Terraform как стандарт. Но я думаю, что для этого еще надо несколько лет. AWS CDK более зрелое решение, уже вторая версия, пусть и только под AWS. Terrafrom еще только 0.19.0. Хотя возможно, что все будет так как и с react-native, где релизной версии полноценной нет, но cотни тысяч приложений уже разработаны и давно хорошо работают.
Тут я с вами не соглашусь, так как у меня довольно большой опыт работы с другими облачными провайдерами, а именно: Digital Ocean, GCP, Yandex Cloud. Какие-то недостатки есть у каждого, но и плюсы свои тоже есть. Например, Digital Ocean предлагает очень понятную ценовую политику. А Яндекс просто дешевле.
На мой взгляд, AWS реально очень выгодно использовать, если:
решение уже зрелое, понятна текущая потребность в ресурсах, а так же прогноз на ближайшие 1-3 года, тогда предоплаченные планы делают AWS самым дешевым решением из всех
есть потребность в специальных инструментах, например, AWS Athena или что-то подобное, чего нет у конкуретнов / работает хуже
небольшие стартапы, тогда AWS Free Tier может немного сэкономить денег
— Камеры не вариант, так как суммарно точек обхода обычно тысячи, если не десятки тысяч
— Обходчиков никто не заменит, даже автоматика, так как на предприятиях, на которых внедряют такие системы, оборудование и тех процессы очень и очень дорогие, потери никогда не будут сопоставимы с зарплатой инженеров. Автоматика не может все определить.
— RFID (NFC / UHF) метки могут быть заменены на QR метки
В целом решение — это первый этап для автоматизации. Переходить сразу с журналов на камеры и т.д. — это нереально.
Спасибо за статью. Какие существенные отличия от FreeRTOS?
Последний релиз в 2021 году. Похоже, что больше не поддерживается.
В статье это упоминается, что nginx free не поддерживает интеграцию с keycloak.
На самом деле ручная проверка токена в коде ( signature, exp, iss & etc ) даст мнимое улучшение производительности по сравнению с отправкой в keycloak, который сделает это сам. Плюс возможен кейс, когда токен пользователя отозван ( например, закрыли доступ, поменяли атрибуты или еще что-то). Тогда без проверки на уровне кейклока это не решить.
Либо же выпускать короткоживущие токены, например, на 1 мин, и забить на лаг в 1 мин в таких моментах. Но с точки зрения производительности - это самая большая нагрузка на auth service, так как именно генерация токена самая сложная операция.
Добрый день, если вы про js, то в этом нет необходимости, так как это проверяет Keycloak при
auth_request /authСпасибо, я не совсем так вопрос понял.
Действительно, при разработке решений я стараюсь не привязываться к конкретному облачному провайдеру, более того, желательно иметь возможность запустить все решение в тестовой / демо версии на обычном голом железе без каких-либо технологий со стороны облачного провайдера, используя только open-source решения. В идеале, чтобы можно было все запустить из обычного docker compose.
Например:
Lambda могут быть завернуты в свои docker контейнеры с разными триггерами ( cron, sqs consumer, http server и т д) -- фактически получается имитация лямбды функции
SQS можно заменить на ElasticMQ
S3 можно заменить на minio
Вместо Congnito можно использовать Keycloak
и т.д.
Localstack при этом я не использую, чтобы точно отмежеваться от AWS.
Это добавляет больше работы, вопросов с тестированием и т.д., но есть 2 больших плюса:
легко разрабатывать локально
нет зависимости от облачного провайдера
Далее в существующий код уже добавляется обвязка для конкретных сервисов, например, реальные Lambda с триггерами по http и т.д.
В результате решение может быть перенесено на любую платформу.
Касательно, Terraform. В целом согласен, как мне кажется, было бы хорошо, чтобы остался только Terraform как стандарт. Но я думаю, что для этого еще надо несколько лет. AWS CDK более зрелое решение, уже вторая версия, пусть и только под AWS. Terrafrom еще только 0.19.0. Хотя возможно, что все будет так как и с react-native, где релизной версии полноценной нет, но cотни тысяч приложений уже разработаны и давно хорошо работают.
Тут я с вами не соглашусь, так как у меня довольно большой опыт работы с другими облачными провайдерами, а именно: Digital Ocean, GCP, Yandex Cloud. Какие-то недостатки есть у каждого, но и плюсы свои тоже есть. Например, Digital Ocean предлагает очень понятную ценовую политику. А Яндекс просто дешевле.
На мой взгляд, AWS реально очень выгодно использовать, если:
решение уже зрелое, понятна текущая потребность в ресурсах, а так же прогноз на ближайшие 1-3 года, тогда предоплаченные планы делают AWS самым дешевым решением из всех
есть потребность в специальных инструментах, например, AWS Athena или что-то подобное, чего нет у конкуретнов / работает хуже
небольшие стартапы, тогда AWS Free Tier может немного сэкономить денег
Хотя скорее то, что вы описываете — это Upwork или другие трекеры, которые каждый шаг мониторят.
— Камеры не вариант, так как суммарно точек обхода обычно тысячи, если не десятки тысяч
— Обходчиков никто не заменит, даже автоматика, так как на предприятиях, на которых внедряют такие системы, оборудование и тех процессы очень и очень дорогие, потери никогда не будут сопоставимы с зарплатой инженеров. Автоматика не может все определить.
— RFID (NFC / UHF) метки могут быть заменены на QR метки
В целом решение — это первый этап для автоматизации. Переходить сразу с журналов на камеры и т.д. — это нереально.