Некоторое время назад у нас возникла задача организовать возможность создания 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 позволяет осуществлять мониторинг потоков данных (и даже бизнес-процессов) и находить в них сбои. 

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

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

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

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

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

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

Чтобы понять, насколько революционным был их подход, давайте просто вспомним, что Heroku создала в 2007-2011 году. Я могу назвать как минимум 3 вещи - контейнеры, serverless и доставку кода через push в GIT. Во многом современный технологический ландшафт был вдохновлен решениями Heroku, увидевшими свет 15 лет назад.

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

Начало истории Heroku

В 2007 году трое разработчиков Ruby — Джеймс Линденбаум, Адам Виггинс и Орион Генри — основали Heroku. Поначалу это был редактор кода в браузере. Проект вызывал “ВАУ эффект”, но не сильно вовлекал пользователей. С этим проектом основатели даже прошли Y Combinator. В ходе доработки платформы разработчики сделали, как им тогда казалось, второстепенную фичу - возможность разворачивать приложения из мастер ветки привязанного GitHub. Цель была простая - дать возможность разработчикам сразу понять, как работает их код. Почему фича казалась второстепенной? На тот момент GitHub только появился, и делать интеграцию с ним было далеко не очевидной идеей. 

Но однажды, анализируя то, как пользователи используют проект, основатели Heroku заметили, что многие клиенты используют только функцию развертывания приложений через push в GIT. И с этого момента началась новая страница развития сервиса.

В последнее время я вижу много хайпа вокруг Kubernetes. Кажется, что он везде и всюду, а если кто-то его еще не использует, то он безнадежно отстал. Но странно принимать решение о внедрении технологии только на основе ее популярности в СМИ. Давайте разберемся: а вот лично вам правда нужен K8S?

Для чего используют Kubernetes? 

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

Тогда сформулируем вопрос иначе: а вам правда нужны микросервисы? И потом вернемся к предыдущему вопросу.

Достоинств у микросервисной архитектуры много. Например: 

Далеко не все в России знают про компанию Splunk. Splunk разрабатывает IT-сервисы (программы для сбора и обработки логов, SIEM системы и т.д.) и зарабатывает около 3 млрд.$ в год. У нас данная американская компания известна, прежде всего, двумя вещами:

• Ее продукты стоят как “чугунный мост”. Средний чек Splunk - несколько сотен тысяч долларов в год.

• Подключив несколько сотен корпоративных клиентов в России, Splunk ушла с российского рынка одним днем в 2019 году, оповестив клиентов в пресс-релизе. После чего все в горящем режиме переходили на Elastic и другие решения.

Данная статья будет как раз о первом пункте - неадекватной цене, и почему лучше так не делать (хотя уходить одним днем тоже не лучшая идея). Материалы для статьи мы случайно нашли, когда выбирали решение для анализа логов. История показалась нам весьма интересной.

С появлением в 2020 году нейронной сети GPT3 и других архитектур – трансформеров, генерируемые тексты стали невероятно правдоподобными. Такими правдоподобными, что отдельно взятый текст, не несущий большой смысловой нагрузки, стало сложно отличить от написанного человеком. В статье мы разберем подход к определению сгенерированных текстов. И заодно выясним, является ли, по мнению алгоритма, Пушкин (и другие деятели искусства) искусственной нейронной сетью.

Суть подхода

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

Шаг 1 – выбираем архитектуру

Тренд последних лет в обработке естественных языков (NLP) - использование нейронных сетей. А если смотреть более узко, то - нейронных сетей архитектуры «трансформер», включающих блок внимания «attention». Суть подхода в том, чтобы использовать при кодировке как в энкодере эмбединга (вектор признаков на выходе слоя нейронной сети), так и в декодере, механизм «attention», позволяющий учитывать взаимосвязь между словами и «фокусировать внимание» нейронной сети только на контексте, имеющем значение для слова.

Одной из архитектур на основе трансформеров является ruBERT, его и возьмем. Но для чистоты эксперимента попробуем также использовать и более старый подход, а именно LSTM нейронную сеть.

Возможно, у вас была (или есть) потребность развернуть свой IT-проект, будь то простой бот, сайт, приложение или сложный высоконагруженный сервис. И, возможно, вы пользовались для этого AWS, MS Azure или другими провайдерами публичных облаков. 

Тогда вы знаете, что для использования таких облачных решений нужно иметь весьма «глубокие карманы». Так, чтобы развернуть обычный сервис распознавания речи на 20 потоков вы заплатите Яндексу за виртуальные машины и за СУБД 43500 руб. в месяц (расчет на основе нашего ASR). И это еще достаточно простой, пусть и требовательный к CPU сервис.  Кажется, облачные услуги должны быть более доступны с финансовой точки зрения. 

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

Ошибка первого и второго рода

Для оценки банковского скоринга используется стандартная ROC AUC кривая!