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

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

Сегодня я попробую разобраться в этом на конкретных примерах технологических компаний и приемов, которые они используют. А именно в том, как создаются “рвы”, которые в мире называются устоявшимся термином 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 есть целый ряд нюансов и возможностей наступить на грабли.

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

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

Open-Source почти везде. Почти в каждом проекте и информационной системе встречается какая-то часть кода, распространяемая под open-source лицензией. И это не просто небольшие фрагменты кода, а полноценные, зрелые, высококачественные продукты, которые развиваются и поддерживаются большими (и дорогими) командами. В данной статье я постараюсь разобраться в бизнес-моделях “бесплатного” софта.

Настало время подводить первые итоги: сервису Amvera Cloud исполнился год. Меня зовут Кирилл Косолапов, я основатель проекта. В этой статье я хочу рассказать, с какими сложностями мы столкнулись и как их преодолели (или не совсем).

Коротко о нас

Мы разрабатываем облако, в котором проекты можно развертывать и обновлять через PUSH в мастер-ветку GIT. Это проще, чем использование VPS (виртуальных машин). 

Начнем с того, что мы открыли регистрацию в облаке Amvera Cloud примерно год назад - 7 ноября. 

Что у нас было: 

Когда проект создан, его требуется где-то разместить, чтобы он работал 24/7. В статье мы изучим два способа деплоя приложения на облачный сервер. В первом сценарии мы рассмотрим деплой через отправку кода в выделенный Git-репозиторий. Во втором сценарии мы осуществим аналогичную операцию, но загрузим файлы через графический интерфейс. Оба способа предполагают деплой буквально за 5-10 минут. 

В качестве примера приложения возьмем API для TODO-заметок на языке Python. Вы можете подобным способом перенести на хостинг любой свой сайт или бот, написанные на Java, Node.JS и т.д.

Вот код самого приложения.

Дети часто задаются вопросом - кто сильнее, кит или слон? каратист или боксер? В этой статье мы попробуем ответить на на похожий вопрос, сравнив SQL (ну или почти SQL) базу данных PostgreSQL и NoSQL базу данных MongoDB. И понять, для каких проектов лучше подойдет реляционная PostgreSQL, а для каких MongoDB.

Данное сравнение также важно, потому что, учитывая новый функционал, MongoDB стала обладать некоторыми качествами SQL СУБД, включая многодокументные ACID-транзакции, вторичный индекс и расширенные возможности запросов. А PostgreSQL расширяет возможности работы с JSON, включаяиндексирование и оптимизацию запросов.