Большое чтиво, все разжевано, но внимание уделили только самому приложению (и остались вопросы), а про остальные части жизненного цикла сказано мало. Я бы добавил еще несколько тем:

1. Идемпотентность. Что будет, если один и тот же файл импорта загрузится несколько раз?
2. Что будет с данными из 2 файлов импорта одновременно?
3. Стоит ли обрабатывать импорты отдельными воркерами, которые можно горизонтально масштабировать?
4. Тротлинг, кеш.
5. Что будет делать CI при изменении версий зависимостей? Может лучше делать сборку через werf?
6. При человеческой структуре и обвязке проекта (CI, тесты, semver, env-переменные) совсем не сказали про 12 factor app.
7. В статье уделено время масштабированию, асинхронной обработке данных, но забыли рассказать о том, что постгрес плодит 1 процесс на 1 соединение. Было бы круто и про pg_bouncer упомянуть.
8. Написали про health check и про несколько экземпляров для горизонтального масштабирования, а потом бац — деплой докер композом через анзибл. Как узнать, что деплой прошел успешно? Как откатиться?
9. Очень мало написано про инфраструктуру. Сделали сервис, а что с ним дальше? Есть ли какой-то балансировщик перед ним? Что делать с zero-downtime deploy?

Почему промышленный стандарт не подходит в автопромышленность? Не могли бы вы раскрыть подробнее почему не Ethercat?

Привет! Так и не получается запустить чарт со стенделон кликхаусом. Отправлял вам ишью https://github.com/flant/loghouse/issues/146, но уже неделю ответа нет. Куда лучше писать?

в зависимостях нет ничего ужасного, есть есть надежный и удобный менеджер зависимостей. В расте он есть, в линусе/мак ос х он есть, а вот в винде — нет.

Для себя вижу 3 проблемы в эмбеддед расте:

1. Отвратительная документация и оформление репозиториев пакетов. Для запуска проекта используется несколько пакетов, у которых есть зависимости. У всех этих пакетов абсолютно одинаковый ридми на гитхабе (под копирку) и совсем непонятно что и как использовать.

   
   

2. Нет поддержки CAN-шины. Было уже 3 попытки написать поддержку CAN в embedded hal, но пока безуспешно. Было большое обсуждение, почему rust embedded еще нельзя использовать в боевых системах и отсутствие CAN — это один из пунктов.

   
   

3. Группа разработчиков из embedded rust — это как закрытый тайный орден, который общается в matrix. Хочешь что-то обсудить — разбирайся с matrix и кривыми клиентами.

   
   

4. Нет приличной RTOS, tockOS и RTFM не в счет.

   
   

НО, все 4 недостатка говорят только о текущем состоянии. Зато уже изначально есть terminal workflow (привет CI, автоматизация релизов и прочие вещи, полезные в IoT), который прекрасно работает на windows, mac и linux. И работать с такой инфраструктурой гораздо приятнее, чем с родными инструментами STM.

Вообще, остается добавить дефолтных файлов конфигурации для дебага в VS Code в cortex-m-quickstart + документацию и будет вообще отлично!

Спасибо за новую версию! Где можно найти документацию по запуску логхауса с внешним кластером кликхауса? Как-то не очень получается запустить helm chart с clickhouse.external true.

Error: unable to build kubernetes objects from release manifest: error validating "": error validating data: [ValidationError(Endpoints.subsets[0].ports[0]): unknown field "targetPort" in io.k8s.api.core.v1.EndpointPort, ValidationError(Endpoints.subsets[0].ports[1]): unknown field "targetPort" in io.k8s.api.core.v1.EndpointPort]
helm.go:75: [debug] error validating "": error validating data: [ValidationError(Endpoints.subsets[0].ports[0]): unknown field "targetPort" in io.k8s.api.core.v1.EndpointPort, ValidationError(Endpoints.subsets[0].ports[1]): unknown field "targetPort" in io.k8s.api.core.v1.EndpointPort]

Или лучше на гитхаб?