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

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

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

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

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

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

Коллеги, нашему облаку 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, включаяиндексирование и оптимизацию запросов.

PostgreSQL и MySQL являются самыми популярными Open Source реляционными базами данных. И часто возникает вопрос - чем отличается PostgreSQL от MySQL? Ответ на этот вопрос позволит понять, какая из баз данных лучше подойдет вашему проекту.

В данной статье мы сравним PostgreSQL и MySQL по различным параметрам и запишем их в сравнительную таблицу.

Часто, в обзорах видов баз данных упоминают реляционные и “другие”, “NoSQL” и т.д., либо приводят самые основные типы СУБД (базы данных), забывая о редких. В данной статье я постараюсь описать максимально полно виды баз данных и привести примеры конкретных реализаций. Разумеется, статья не претендует на всеохватность и классифицировать базы данных можно по разному, в том числе по типам оптимальной нагрузки и т.д., но надеюсь, она даст базовое представление о видах СУБД и принципах их работы.

В статье мы рассмотрим следующие типы баз данных:

В последние годы растет сложность IT-инфраструктуры в компаниях и, соответственно, спрос на сервисы мониторинга ее работоспособности. Их все больше покупают, в них все чаще инвестируют. Но в данной статье мы расскажем о новом смежном тренде - Data Observability. Что это и чем она отличается от Infrastructure Observability? 

Классический мониторинг - это наблюдение за работой инфраструктуры и приложений. А Data Observability позволяет осуществлять мониторинг потоков данных (и даже бизнес-процессов) и находить в них сбои. 

Рассмотрим несколько примеров.

В книге «От нуля к единице» Питер Тиль утверждал, что лучшая инвестиция — инвестиция в будущую монополию. Монополию создать не так просто, особенно в мире, где за этим пристально следят. Но иногда удается найти способ, чтобы монополия получилась «естественным путем». И один из таких способов — стандарты. В статье я на примерах покажу, как этот прием использовали известные всем компании, чтобы получить «нерыночное» конкурентное преимущество.