круто. но вообще графики в google sheets дефолтные уже покрывают 90% требований, так что использовать что-то внешнее это лишние телодвижения. d3.js это красиво, конечно

jinx

а они починили там уже все? там какая-то херня с ними на запуске была

а не, перепутал, сорри

@classmethod скажи пожалуйста, если не секрет, а как у тебя организован ci/cd для serverless (и не для serverless тоже:) )?
Используешь ли что-то специальное, или может быть просто кастомный код который AWS SDK дергает, или километры cloud formation, или может что-то ещё? Как оно вообще выглядит концептуально?
Сори за много вопросов, но я знаю что у тебя это точно есть и наверняка все сделано хорошо:)

При соблюдении влажности и температурного режима 30 лет гарантия сохранности данных https://www8.hp.com/uk/en/campaigns/storage-media/lto-media.html

Спасибо, в Гугл я умею:)

Ты даже вопрос свой забыл?

У меня был долгий путь чтобы понять как не нужно делать CI/CD для serverless приложений. Правда я до сих пор не уверен, что подход описаный ниже является правильным, но мне его удалось проверить в бою в кровавом enterprise и в стартапах.

Первый делом разделяем resource provisioning и deployment.

Когда мы впервые деплоим приложение или поднимаем dev environment под проект, то используя CloudFormation template создаем новый стек.  На этом шаге наша цель создать пустые ресурсы, необходимые IAM сущности и зарезервировать имя стека.

Весь код проходит через ci пайплайн: build -> test -> scan -> pack. Полученные артефакты подают в бинарный репозиторий или S3.

Депломеймент построен на базе AWS Step Function + свои вспомогательные лямбды, аналог aws lambda update-function-code для лямбд и aws update-service —force-new-deployment для ECS

Step Function был выбран потому что процесс деплоймента в некоторые окружения может занимать несколько дней и требовать ручного аппрува.

Если в CloudFormation шаблонах нет никаких изменений, то сразу деплоим артефакты. А вот если CF шаблон изменился, то вначале нам нужно перед внести изменения стек. Для этого создаем CloudFormation Change Set.

В нижних окружениях change-set применяются автоматически, а для всего что выше staging окружения опс должен посмотреть на change set и одобрить изменения. Пока ждем аппрува step function стоит на паузе.

В кровавом enterprise у нас была договоренность, что ничего автоматически не аппрувится, если меняются IAM сущности. Поэтому вся команда ждала несколько дней очередного мудака из InfoSec, который с важным видом нажимал на кнопку Approve.

Благодаря тому что  CloudFormation поддерживает nested stacks, то мы смогли отдельно вынести все что не относится к IAM и трогали IAM политики только в случае необходимости.

InfoSec своего добились - вместо того чтобы мы команда создавала  least privileges политики для новых ресурсов, команда стала создавать IAM с широкими правами лишь бы не быть заблокированной.

👍

Вопрос я помню, но «не развлекался ли» не подразумевает вопрос «сколько оно живет», если только это не история из личного опыта. Комментарий про время хранения дан вообще исключительно для контекста. К тому же и так понятно же, что если я смотрел на LTO, то я знаю сколько оно живет.

Спасибо за столь подробный ответ! Очень полезно.

Помните, я спрашивал, что у нас сегодня вместо MS Access? Вот очень большой список DBaaS, в том числе опенсорсных: https://news.ycombinator.com/item?id=26534846

а на aws cdk не смотрели ? мы полгода назад озадачились такой же задачей и в целом CDK очень разумно моделирует то что у вас описано выше, но удобнее писать код  на  typescript, чем yaml CF...

у нас пока нету такого rigorous процесса ревью, потому что devops и infosec - это одни и те же люди. но в целом он умеет и диффы генерить - чтобы посмотреть что меняется и умеет блокировать обновление если изменяется iam политика или что-то касающееся безопасности. Ну и в целом - похожее разделение, правила именования стеков и разделение на инфраструктурные стеки, стеки приложений, стеки деплоя + фиксированные имена stack outputs помогают неплохо организовать разрастающуюся поверхность сервисов aws и их взаимных интеграций.

Был опыт с Troposphere и Pulumni,  и CDK проходит через те же грабли. Это сделано программистами для программистов. Если дать программисту такой инструмент в руки, то он будет паттерны проектирования внедрять, а если devops будет код на TS писать, то он вряд ли будет реюзабельным и читабельным для разработчиков.  

Эти технологии прикольно использовать когда у вас IaaC пишут люди которые умеют и в программирование и в operations.  Так сказать SRE здорового человека.

=) ну да, у нас все "погроммисты" и в общем пишем читабельный код. Ну насколько TS  код может быть вообще читабельным =)

Доброго дня. Хотелось бы попросить совета по выбору инструмента: есть сейчас команда из нескольких ML-разработчиков, которой нужно стало работать с достаточно ресурсоемкими архитектурами. Раньше своих карточек + колаба + нескольких серверов вполне хватало, а сейчас появились проблемы с выделением ресурсов на обучение и организацией работы.
Нужно, в общих терминах, скачивать приватное репо с гитхаба, устанавливать зависимости, выполнять код для обучения модели и отдавать файл с весами разработчику - т.е. стандартный цикл. Хочется а) возможность гибкого ввода в использование ресурсов (чтобы арендованные карточки можно было, например, распределять между разработчиками внутри команды) и б) отсутствия капризной экосистемы (например, Azure по умолчанию имеет достаточно навязчивые представления о том, что и какими инструментами разработчики будут в ней делать).

типа https://www.cortex.dev/?

я тут крутую ORM нашел!)

https://github.com/pemistahl/grex