Hacker News Digest

Автор сократил свои расходы на облачные услуги в 10 раз, переведя все проекты с AWS на самостоятельное хостинг, при этом улучшив производительность в 2 раза. Его месячный счет AWS снизился с $1,400 до менее $120, а инфраструктура стала мощнее. Автор утверждает, что страх перед управлением серверами обходится компаниям в 10 раз дороже, чем необходимо.

Многие разработчики в индустрии облаков заинтересованы в сохранении компаний на облачных платформах, так как их зарплаты зависят от сложности инфраструктуры. Облачные инженеры и DevOps специалисты не чувствуют финансовой боли от переплат, так как тратят чужие деньги, и заинтересованы в поддержании vendor lock-in.

Перейдя на Hetzner, автор получил доступ к серверам с 80 ядрами менее чем за $190 в месяц, в то время как аналогичные экземпляры в AWS стоят $2,500-$3,500 (в 13-18 раз дороже). Даже с резервированием экземпляров AWS остается в 7 раз дороже. Для небольших проектов доступны VPS с 8 ядрами и 32 ГБ ОЗУ за $50 в месяц.

• Обсуждение в основном свелось к тому, что для большинства проектов хостинг в облаке (AWS, GCP, Azure) в 2024 году оказывается дороже, чем аренда bare-metal в Hetzner/OVH, и что это не всегда оправдано.
• Участники споров подчеркнули, что «облако» всё ещё полезно для MVP, стартапов и сценариев с непредсказуемым трафиком, но при этом критикуют его стоимость для устойчивых рабочих нагрузок.
• Несколько человек упомянули, что большие компании могут позволить себе облако, потому что у них есть команды и бюджет на инфраструктуру и DevOps, тогда как мелкий бизнес и индивидуальные разработчики вынуждены искать более дешёвые решения.
• Также было отмечено, что важно различать «облако» как способ разработки (CI/CD, managed services) и как способ хостинга (IaaS), и что первое может быть дешевле, чем второе.

• Компании ищут инженеров для работы с AI/ML, включая роли Senior Machine Learning Engineer, ML Scientist и разработчиков для создания AI-инструментов в различных областях, таких как биология, недвижимость и безопасность.
• Предлагаются позиции в software development, включая Full Stack, Backend, Frontend и MLOps инженеров, с использованием технологий Python, Kotlin, TypeScript, Rust и других, для удаленной, гибридной или офисной работы.
• Есть вакансии в сфере облачных технологий и инфраструктуры, такие как Cloud Engineer, SRE и DevOps, с фокусом на AWS, GCP, Azure и управление масштабируемыми системами.
• Несколько ролей связаны с разработкой в нишевых областях: квантовые вычисления, 3D-моделирование, финансовые технологии (алготрейдинг), видеоигры и управление цепочками поставок.
• Предложения включают позиции разного уровня, от начинающих до ведущих инженеров и архитекторов, с вариантами визовой поддержки, релокации и конкурентными зарплатами в диапазоне от $120k до $240k+ в зависимости от опыта и локации.

• Разработчики ищут удалённую работу, многие открыты к релокации, предпочитают гибридный формат или готовы к редким командировкам.
• Основные технологические стеки включают Python, JavaScript/TypeScript, React, Node.js, облачные платформы (AWS, GCP) и контейнеризацию (Docker, Kubernetes).
• Специализации варьируются от full-stack, data engineering и машинного обучения до дизайна продуктов и UX/UI.
• Ключевые интересы: работа с LLM, AI-агентами, компьютерным зрением, распределёнными системами и дизайн-системами.
• Многие кандидаты имеют опыт более 10 лет, опыт построения масштабируемых продуктов и решения сложных бизнес-задач.

PlanetScale запустил общедоступную версию своей управляемой базы данных для Postgres, завершив этап приватного тестирования. Сервис предлагает миграцию с других провайдеров Postgres через гайды и поддержку sales-команды для сложных случаев. Компания уже пять лет развивает Vitess для MySQL, а теперь переносит этот опыт на Postgres, объединяя производительность своей платформы Metal с гибкостью Postgres.

Сотни компаний, включая Convex и Supermemory, уже используют PlanetScale для Postgres в продакшене, отмечая улучшение скорости и масштабируемости. Анонсирован также будущий инструмент Neki — решение для шардинга Postgres, построенное на принципах Vitess, но спроектированное с нуля для специфики Postgres; его открытую версию планируют выпустить позже.

• Успешная миграция на PlanetScale Postgres с улучшением производительности запросов и оперативной поддержкой команды, включая помощь в решении возникших проблем.
• Критика недостаточной ясности описания продукта и цен на сайте для новых пользователей, а также отсутствия бесплатного тарифа для тестирования.
• Вопросы о технических деталях: масштабировании записи (горизонтальное шардирование через Neki), использовании эфемерных дисков NVMe в GCP, поддержке расширений Postgres и сравнении с конкурентами (Aurora, Supabase).
• Положительные отзывы от пользователей бета-тестирования о высокой производительности и надежности продукта в production-среде.
• Объяснения от команды PlanetScale о архитектуре (репликация для надежности вместо сетевых дисков) и планах по развитию (горизонтальное масштабирование через Neki).

Bottlefire — превращает Docker-образы в единый исполняемый файл с микро-VM на Firecracker.
Запуск без root и настроек, где есть KVM.

curl -fL https://bottlefire.dev/run/

Собирается утилитой bake, внутри: сеть, порты, shared-папки.

Цены
Публичные образы — бесплатно.
Pro: 5 $/мес, 20 ГБ «активных» образов, любые регистри.

curl -fL -H "Authorization: Bearer …" -o app \
  https://images.bottlefire.dev/ghcr.io/org/app:1.0

Нужен больше или ECR/GCP — пишите.

Спонсорство от 50 $/мес — публикуй свои образы для всех.

• Участник спросил, можно ли «заморозить» microVM в bottlefire и возобновить позже — ответ: Firecracker умеет снимки, но в текущем формате пока не реализовано.
• Вопрос о запуске microVM в обычном облаке:部分 провайдеры (GCP, DigitalOcean) уже позволяют запускать Firecracker.
• Сеть у bake устроена через SOCKS5-прокси поверх tun2socks, используя сетёвой стек хоста.
• Проект по сути обёртка bake: с KVM можно запустить любой Docker-контейнер без установки Docker.
• Участники сравнили с docker2exe/dockerc, обсудили GUI-оболочку, 9p для rootfs и возможность адаптации под Apple Hypervisor.framework.

Rug-pull и вилки: кто кого в OSS

• В облаке всё решают гиганты (AWS, GCP, Azure); разработчики и пользователи — без прав.
• Компания-владелец проекта может «рвануть коврик»: сменить лицензию на закрытую, чтобы загнать облачных конкурентов.
• Пример: Elastic → SSPL, MongoDB → SSPL, Sentry → новая лицензия.
• Ответ — вилка (fork), но она требует людей и денег; без спонсора умирает.
• AWS форкнул Elasticsearch → OpenSearch: набрал контрибьюторов с нуля, теперь живёт.
• Puppet ушёл в Perforce и закрыл код → родилась OpenVox.
• Вывод: однокомпаночные проекты рискованны; выбирайте те, где власть распределена, или сразу готовьтесь вилковать.

• CLA = право перелицензировать → «rug pull» возможен; DCO такого не даёт.
• Elasticsearch, Redis, Mongo и др. перелицензировались не от банкротства, а чтобы ограничить конкурентов и поднять доход.
• Пользователи чувствуют «предательство»: проект начинали под FOSS-лицензией, привлекли вклад и клиентов, потом закрыли код.
• Форки (OpenSearch, Valkey) спасают, но требуют новой инфраструктуры и сообщества; большинство просто делают «снапшот» и уходят.
• Проблема устойчивости: без денег проект умрёт, но нынешняя модель дарения дарит прибыль крупным облакам, а не разработчикам.

• 20+ специалистов из 4 континентов ищут удалённую работу; большинство — full-stack, DevOps, ML/AI и мобильные разработчики.
• Регионы: США (Austin, SF, NYC, Florida), Латинская Америка (Буэнос-Айрес, Богота, Медельин), Европа (Лондон, Осло, Хорватия), Азия (Бангкок, Ханой), Африка (Лагос) и др.
• Ключевые стеки: Rust/Go/Python, React/Node, AWS/GCP, Docker/K8s, LLM/AI-инструменты, iOS/Android, а также редкие — DSP, C++, embedded.
• Готовность к релокации: ~30 % «да», ~60 % «только удалённо», остальные — «возможно при убедительном предложении».
• Уровни: от стажёров и new-grad до 20-летних ветеранов и CTO; многие предоставляют портфолио и рекомендательные письма.

Codemia
Подготовка к систем-дизайн-интервью через практику:
Начать | Блог | Системный дизайн

Юридика
Условия | Конфиденциальность | Контакт

Соцсети
Twitter | LinkedIn

• Обсуждение подтверждает: для HPC, высоконагруженных и чувствительных к задержкам систем NUMA-распределение критично, и ручное pinning процессов/потоков к нужным узлам остаётся основным способом добиться стабильной производительности.
• В публичных облаках (AWS, GCP) NUMA-топология скрыта, VM часто выглядят как однонодовые UMA; полезны lscpu, lstopo, cpu-latency, но настроек управления NUMA почти нет.
• Сообщество делится инструментами: mpibind, sched_ext, DAMON, fake NUMA, идеями эмуляции NUMA даже на Raspberry Pi 5.
• Kubernetes уже умеет NUMA-affinity, но вручную выбирать 64-ядерный инстанс вместо 96-ядерного (чтобы не пересекать сокеты) всё равно приходится самим.
• Крайняя альтернатива — односокетные серверы с NPS=1: «равномерно медленно», но без головной боли.