Cегодня я поговорю о том, как важно иметь настоящее уникальное торговое предложение, и что без него и 100 млн $ делать на международном рынке нечего.

Наша поддержка с давних пор испытывала неудобство при отслеживании обращений пользователей в группе комьюнити в Телеграм. Когда сразу много пользователей одновременно пишут на разные темы в одном месте, легко упустить какое то из сообщений. Оно просто уплывает в ленте, пока мы разбираемся с другими обращениями.

Мы написали небольшую CRM. В ней все обращения пользователей должны раскладываться по своим тредам, ничего не теряется и удобно хранится служебная информация.

Код проекта CRM мы выкладываем в открытый доступ на GitHub, как Open Source.

Не всегда код должен работать непрерывно. И обидно арендовать целый сервер, когда скрипт работает 10 минут в день. Особенно сервер с большим количеством ОЗУ и CPU.

В этой статье мы расскажем, как запускать скрипты экономически эффективнее, чем на VDS, и как настроить работу кода по расписанию.

Всем привет!

Самостоятельное создание ноды HTTP Request может быть сложной задачей. Нужно самостоятельно искать и указывать эндпоинт, прописывать body для запроса и проставлять нестандартный заголовок авторизации, что совершенно неудобно и сложно для многих пользователей.

По вышеописанной причине мы решили разобраться в этой проблеме, и опубликовать собственную комьюнити-ноду n8n-nodes-amvera-inference, которая сможет помочь пользователям, без сложностей, работать с нашим Inference API нужной модели.

В статье мы расскажем и про саму разработку комьюнити-ноды, и про её установку с настройкой.

Вы когда-нибудь хотели построить замок? Не знаю, как с замком, но я, как предприниматель, всегда хотел создать ров, который сможет защитить компанию от конкурентов. Ведь замок без рва и крепкой стены, это не твой замок.

С каждым годом создавать продукты становится все проще и проще. Иногда я узнаю о совершенно новой, революционной технологии или стартапе, но чуть стоит копнуть, как оказывается, что еще пять-шесть стартапов делают примерно то же. А в мире, где много компаний делает примерно одинаковый продукт, примерно одинакового качества, и всего несколько месяцев отделяет первопроходца от последователей, компании должны существовать на грани рентабельности, но это не всегда так. И возникает вопрос, что же отделяет победителей от проигравших.

Сегодня я попробую разобраться в этом на конкретных примерах технологических компаний и приемов, которые они используют. А именно в том, как создаются “рвы”, которые в мире называются устоявшимся термином moat.

Работа без логов, это как вождение автомобиля вслепую. Ехать можно, но недолго и не туда.

Почти в каждом проекте логи нужны. И нужны инструменты, которые умеют с ними работать. А с этим исторически у нас была проблема.

В облаке Amvera, проекты пользователей, в большинстве своём, небольшие. А инструменты на рынке, такие как Elasticsearch очень требовательны к выделяемым ресурсам и сложны в настройке.

Странно поднимать телеграм-бота, который потребляет 100 мб. оперативной памяти и ставить для его логов Elastic на 16 Гб.

Логичным решением является создание мультиарендной системы. Когда мы собираем логи в какой-то большой базе данных, и каждому пользователю даём доступ только к его логам. Звучит замечательно, но на практике реализовать это не так легко. На создание приемлемого решения у нас ушло несколько итераций. И мы хотим поделиться опытом, чтобы другие не наступали на наши грабли и могли сделать сразу хорошо.

Много было сказано про Serverless в нагрузках без сохранения состояния. Действительно, когда у вас есть контейнеры или функции их легко почти мгновенно масштабировать и нет большой разницы, на какой именно машине это делать.

Но данные имеют очень конкретную привязку к диску, на котором размещены. Что создает немало сложностей к самой концепции бессерверных вычислений.

В этой статье я хочу показать, где бессерверная архитектура может быть применима, и рассмотрю несколько новых, и весьма перспективных решений в этой области, таких как Neon, Warpstream и TiDB.

Из каждого утюга трубят про то, что ИИ, AGI и т.д. изменит все, и мои уши устали от этого.

Поэтому решил на цифрах разобраться так ли это. Нынешний хайп является пузырём, или новой трансформирующей волной. И сопоставимо ли появление LLM с появлением ПК, интернета и переходом на мобильные устройства. Доводы будем подкреплять расчетом. 

И начнем мы с анализа текущих инвестиций в ИИ.

Недавно мы столкнулись с волной спама. И написали антиспам бота, который удаляет спам сообщения и помогает блокировать нарушителей.

Я решил выложить этот небольшой проект в открытый доступ, чтобы вы, даже не обладая навыками программирования, смогли защитить свою группу от спамеров. Цель статьи, чтобы любой мог защитить свою группу, перетянув несколько файлов в интерфейсе и задав несколько элементарных настроек за три минуты.

В статье вы найдете

• ссылку на файлы проекта;

• инструкцию, как его запустить без навыков программирования.

Бот умеет удалять спам сообщения, отправлять их на модерацию и дообучаться в случае ошибок.

Коллеги, нашему облаку Amvera — сервису для легкого и удобного хостинга проектов — исполнилось два года. Раз в год, традиционно, я подвожу итоги (год нулевой, год первый) и откровенно рассказываю о сложностях развития своего IT‑проекта. Вдруг вы задумали сделать стартап — а почитаете меня, передумаете, пойдете нормально зарабатывать в серьезной конторе…

Сегодня я расскажу: 

• об инвестициях — и стоит ли их привлекать,

• о бесполезности платной рекламы,

• какое «дно» Яндекс.Директ,

• и о том, что «продукт решает».

Раньше я считал, что публичные облака дорогие, и как я заблуждался! Да что говорить, многие мои знакомые так и считают. Но я попробую объяснить, почему это совсем не так, и я изменил свое мнение!

Сеть Kubernetes — это сложная и увлекательная тема, наполненная множеством подвижных частей. Одним из ключевых компонентов, обеспечивающих сетевую связность и взаимодействие различных элементов кластера, является CNI (Container Networking Interface).

CNI  - это спецификация, разработанная CNCF (Cloud Native Computing Foundation) для стандартизации процесса подключения сетевых интерфейсов к контейнерам. CNI обеспечивает гибкость и адаптивность сетевой инфраструктуры, позволяя интегрировать различные сетевые решения в Kubernetes.

Давайте подробнее разберем, что такое Container Network Interface?

Kubernetes, ставший де-факто стандартом для оркестрации контейнеров, значительно упрощает развертывание, масштабирование и управление контейнеризированными приложениями. Однако, по мере роста и усложнения инфраструктуры, требования к сетевым возможностям также увеличиваются. В современных распределенных системах, где различные микросервисы взаимодействуют друг с другом, критически важно обеспечить безопасность, производительность и надежность сетевых коммуникаций. Здесь на помощь приходят продвинутые сетевые функции Kubernetes, такие как:

В июле 2024 вышла версия Kubernetes 1.31, в которой были окончательно устранены встроенные интеграции облачных провайдеров.

Начиная с версии Kubernetes v1.7, проект Kubernetes преследовал амбициозную цель удаления встроенных интеграций облачных провайдеров. Хотя эти интеграции сыграли важную роль в раннем развитии и росте Kubernetes, их удаление было обусловлено двумя ключевыми факторами: растущей сложностью поддержания собственной поддержки для каждого облачного провайдера в миллионах строк кода Go и желанием сделать Kubernetes по-настоящему независимой от поставщика платформой.

После многих релизов, все интеграции облачных провайдеров были успешно перенесены из основного репозитория Kubernetes во внешние плагины. В дополнение к достижению первоначальных целей, удалось значительно оптимизировать Kubernetes, удалив около 1,5 миллионов строк кода и уменьшив двоичные размеры основных компонентов примерно на 40%.

Эта миграция была сложной и длительной из-за многочисленных затронутых компонентов и критических путей кода, которые полагались на встроенные интеграции для пяти первоначальных поставщиков облачных услуг: Google Cloud, AWS, Azure, OpenStack и vSphere. Для успешного завершения этой миграции пришлось построить четыре новые подсистемы с нуля:

Какие тектонические силы создают по-настоящему успешные технологические компании? Я проанализировал причины успеха компаний с капитализацией свыше 100 млрд.$ и выделил для себя пять моделей, которые отличают данные фирмы от всех остальных. Об этом и будет данная статья.

Начну с того, что у этих компаний есть нечто общее - все они работают на больших концентрированных рынках, где “победитель получает все”. И все они вывели свои флагманские продукты в “окно возможностей”, когда рынок еще не был занят, и при этом превзошли конкурентов. 

Разница в том, как именно данные компании победили в конкурентной борьбе и создали достаточный барьер, чтобы отгородиться от новых конкурентов и закрыть “окно” для входа других предпринимателей. 

Я уверен, что выделенные мной стратегии применимы и для менее крупного бизнеса, который работает на меньших рынках. Но одно можно сказать точно: все из проанализированных мной компаний используют как минимум одну из данных стратегий создания монополии или олигополии на рынке.

Итак, перечислим данные стратегии/эффекты.

IT-сектор отличается гипермасштабируемостью. Вам достаточно написать софт, отладить маркетинг, и вы можете продавать свой продукт по всему миру, не думая о логистике, хранении и производстве. Это приводит к тому, что часто победитель получает все. На рынке есть место только для одной компании. А побочный эффект - что зарплаты разработчиков часто превышают зарплаты во многих других отраслях, ведь за победу в глобальном лидерстве можно и нужно хорошо платить. Но насколько просто, и возможно ли вовсе, построить глобального IT-лидера, находясь в России? 

Даже переформулирую вопрос. Почему подавляющее большинство успешных технологических компаний создаются всего в одном месте - Силиконовой долине? Ведь в других местах люди не менее талантливы и трудолюбивы чем там.

Лично для себя я выделил следующие причины.

OpenAI блокирует доступ к сервисам пользователям из России. И если вы написали приложение (бот, сервис), которое взаимодействует с их API, вам приходилось разворачивать его на зарубежных облаках. Либо платить посредникам, предоставляющим услуги по проксированию запросов, что и дорого, и небезопасно. Мы решили это исправить и сделали технологию проксирования. Она помогла нам самым неожиданным образом, когда Docker Hub заблокировал пользователей из России.

30 мая 2024 Docker Hub заблокировал пользователей из России, что повлияло на многие сервисы и проекты. В том числе на наш. В статье будет несколько способов оперативно получить доступ к Docker Hub из России.

Некоторое время назад у нас возникла задача организовать возможность создания managed баз данных. Сложность данной задачи в том, что нам надо развертывать и управлять тысячами баз данных PostgreSQL, которые обеспечивают репликацию, бэкапы, мониторинг и другие полезные пользователям функции. При этом в ядре нашей системы лежит Kubernetes, в котором запускаются приложения пользователей. И по ряду факторов нам требовалось запускать базы данных внутри кластера.

Чтобы не изобретать велосипед, мы решили рассмотреть известные операторы, позволяющие разворачивать базы данных PostgreSQL в Kubernetes и управлять ими.

Главная рекомендация - отказаться от лимитов!

А теперь подробнее.

Когда у вас много пользователей используют один кластер Kubernetes, возникает вопрос - как задать квоты, чтобы и приложениям хватало ресурса, и не случилось ситуации, когда из-за одного прожорливого соседа страдают все поды на ноде? 

Начну с того, что самым распространенным способом является задание request и limit по CPU и RAM. С оперативной памятью все достаточно просто - при превышении потребления, OMM-Killer остановит процесс. А вот с CPU есть целый ряд нюансов и возможностей наступить на грабли.

Это происходит из-за того, что ресурс процессора делится не долями, а по времени. 

Это можно представить так