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

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

Примером может служить PHPSESSID: xyjaez1081lze23, lang: en.

Давайте разберемся в этом на примере. Предположим, вы пошли в магазин и принесли оттуда посуду. Придя домой, вы обнаруживаете, что один из них сломан. Тогда вы идете к владельцу магазина и рассказываете ему о своей проблеме. Но, к вашему ужасу, он отвечает, что не знает вас. Таково было исходное состояние HTTP без файлов cookie. Веб-сервер не узнает вас при любом раскладе.

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

Это перевод статьи Дмитрия Костика и Миколы Моржан из Percona. С их помощью посмотрим, в какой степени можно автоматизировать горизонтальное масштабирование баз данных MongoDB, MySQL и PostgreSQL в Kubernetes и как это сделать?

Если 20-21 года можно назвать «годами удалёнки», то 2022 можно назвать годом релокации. Если раньше мысль о переезде посещала меня в формате «ну когда-нибудь потом, перееду в тепло ближе к пенсии», то после февраля этого года, когда зарубежные компании начали сворачивать бизнес в России, заказчики — сокращать бюджеты, а деньги со счёта в банке можно ждать неделями — вопрос о переезде в другую страну встал ребром. Причём не с целью «переждать», а как минимум для небольшой адаптации за рубежом, для возможного переезда уже на ПМЖ.

В качестве такой первой остановки выбрал Сербию (почему именно её расскажу дальше). Если вас тоже посещали/посещают мысли уехать — переходите под кат, там я делюсь своими критериями выбора страны,  деталями переезда и сведениями, которые удалось узнать у уже переехавших.

Как и многие разработчики, впервые столкнувшиеся с нагрузочным тестированием, я начал с JMeter. Для ознакомления и простых сценариев JMeter полностью меня устраивал, но с усложнением задач и потребностью в большем контроле я начал задумываться о поиске более удобной альтернативы. Особенно хотелось чтобы инструмент легко адаптировался или уже был адаптирован под экосистему .NET.

В этой статье мы рассмотрим NBomber как легкую для освоения альтернативу JMeter, а также постараемся ответить на вопрос "Почему я должен проводить нагрузочное тестирование именно с NBomber ?".

Эта статья предназначена для .NET разработчиков, которые хотят пополнить свой инструментарий удобным инструментом для нагрузочного тестирования, а также тем кто рассматривает альтернативы JMeter для экосистемы .NET.

Давайте признаем, что теперь все люди в России будут жить в новой реальности, где счет в банке за границей - не блажь, а необходимость. Не только для приема платежей из-за границы, но и для привычных всем штук: оплаты товаров онлайн, покупки билетов (на сайтах авиакомпаний), оплаты в сторах, беспроблемных переводов и т.д. Даже если сегодня все санкции снимут, виза с мастеркардом вернутся, ЦБ все разрешит - инерция этих процессов, и тем более риски, которые несут контрагенты из России - на многие годы.

Дисклеймер: я не консультант по этой теме, просто имею собственный опыт 10+ летнего номадизма, который наложил на небольшой опрос и текущие перспективы, и хочу поделиться. Буду рад любым уточнениям, возможностям, рассказам об опыте в комментариях. В обычной жизни являюсь сооснователем YC-стартапа.

В предыдущей публикации мы рассмотрели некоторые базовые вопросы относительно потоков и пулов потоков и готовы двигаться дальше. Давайте проведём эксперимент и найдём правильный объём работы для пула потоков. Чтобы его издержки не давлели над объёмом полезной работы

⚠️ Материал средней сложности

С другой стороны, показанные примеры доказывают, что на производительность сильно влияет гранулярность элементов работы. Имеется ввиду, конечно же, длительность работы делегатов. Чтобы достичь хороших показателей, гранулярность работы не может быть абы какой: она должна быть правильной. И помимо планирования задач на ThreadPool, планировать их можно также как через TPL так и через какой-либо свой собственный пул потоков. Например, если взять обычный ThreadPool, то можно примерно измерить издержки алгоритмов ThreadPool в тактах Time Stamp Counter счётчика времени (можно, конечно и в чём-то более привычном типа микросекунд, но там на многих сценариях вполне могут быть нули)

Эта текст покрывает ответы на некоторые совсем базовые вопросы и вместе с тем сразу погружает в проблематику получения ответа на вопрос: "как работать лучше? однопоточно, многопоточно или многопоточно, но на ThreadPool?". Ответ на этот вопрос может изначально показаться очень простым и понятным, однако реальность совершенно иная: всё как и везде сильно зависит от ситуации: от типа задачи, от её размера, от прочих условий, которые так просто в голову сами собой не придут.

А потому мы пройдёмся в первую очередь по IO-/CPU-bound операциям, стоимости создания потока, базовым основам работы пула потоков (но только основы), а далее -- углубимся в анализ чёрного ящика: от чего зависит производительность пула потоков? Каков объём работы приемлим для того чтобы в него планировать?

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

Также отмечу, что материал постепенно переходит от начального уровня сложности 🥤 через ⚠️ средний уровень к ☠️ высокому, о чём вы сможете узнать по пиктограммам.

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

Если пару лет назад шли вопросы о том, какой фреймворк выбрать, то сейчас все задаются вопросом: “Как оттуда выбраться”.  Давайте разберемся с тем как это произошло, и что стоит делать, чтобы не попасть в жернова фронтенд фреймворка.

Технологический прогресс не стоит на месте, особенно если это касается области IT. Еще в 2014 году, когда Google открыл исходный код проекта Kubernetes, который вобрал в себя лучшее из Borg и Omega - внутренних систем Google, его мало кто знал и использовал. Но прошло 7 лет и K8S (он же Kubernetes) стал успешным open-source проектом, который используется по всему миру. В большинстве компаний инфраструктура построена на K8S - от маленьких проектов до огромных кластеров и облаков, которые обеспечивают бесперебойную доступность сервисов. Давайте коснемся Kubernetes и расскажем, как им пользоваться на практике. Но сначала надо спросить, а что такое этот ваш Kubernetes и для чего он собственно нужен. Подойдет ли он для ваших проектов.

Эта статья будет полезна, если вы начинаете проект, который может перерасти в HL (HighLoad) или у вас уже есть проект, который имеет высокую нагрузку. Каждый пункт этого чек-листа поможет избежать определенных проблем, возникающих в процессе эксплуатации таких систем. И хотя некоторые пункты могут показаться довольно очевидными, а иные даже лишними, я рекомендую ознакомиться со всем списком, т.к. судя по статьям на хабре, периодически с некоторыми из этих проблем встречаются компании, которые уже обрели некоторую популярность. Дополняя систему каким то компонентом довольно просто забыть о таких вещах, как KeepAlive между двумя сервисами, а процессы изменения и дополнения в IT происходят постоянно.

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

Как архитектор-консультант в Red Hat, я имел возможность поработать над множеством проектов для наших клиентов. У каждого из них есть свои особенности, которые, однако, имеют некоторые общие черты. Большинство клиентов хотят знать, как скоординировать запись в несколько систем одновременно. Ответ на этот вопрос обычно включает подробное объяснение двойной записи, распределенных транзакций, современных альтернатив, а также возможных сценариев сбоев и недостатков каждого подхода. Как правило, именно в этот момент заказчик понимает, что разделение монолитного приложения на микросервисы - долгий и сложный путь, обычно требующий компромиссов.

Наделяем наш медиацентр еще одной возможностью - управление торрент-клиентом и его загрузками из мессенджера Telegram через чат-бота. Теперь вы не будете ограничены лишь локальной домашней сетью. Управлять загрузками на домашнем сервере из любой точки мира? Легко!

В преддверии запуска Вечерней школы по Kubernetes, в этот раз для разработчиков, подготовили интервью с Павлом Селивановым архитектором в Mail.ru Cloud Solutions и Марселем Ибраевым CTO Слёрма. Речь пойдет о том, какие конкретно знания нужны разработчику в компаниях с Kubernetes, Павел и Марсель поделятся кейсами из своей практики.

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

В основе этого списка — мой личный опыт, и чтобы избежать предвзятости, я расскажу и об альтернативных инструментах, чтобы вы могли всё сравнить и принять решение, исходя из своих потребностей. Постараюсь дать информацию сжато и привести источники, чтобы при желании вы могли изучить всё самостоятельно. Описывая инструменты для различных задач разработки ПО, я хотел ответить на вопрос: «Как я могу сделать X в Kubernetes?»

Фото Ricardo Gomez Angel, Unsplash.com

Используем метрики для отправки уведомлений через Slack

В предыдущей статье мы задеплоили оператор Prometheus с помощью helm-чарта и на примере набора сервисов увидели, как можно собирать метрики через prom-client и экспортеры. Как вы помните, цель observability (наблюдаемости) — узнать статус системы, поэтому нужные люди должны получать уведомления, когда значения метрик выходят за установленные пределы. Для этого надо настроить алерты.

На современных картах все больше появляется 360 аэроснимков, которые принято называть "Сферические панорамы". Почти каждый владелец БПЛА с камерой может создавать свою собственную сферу. Разбираем подробный способ создания 360 панорамы с помощью бюджетного дрона DJI Mini 2.

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

На нашей конференции SmartData ведущий разработчик в Яндексе Максим Стаценко рассказал про плюсы и минусы различных решений для хранения данных: облака или железо, Hadoop, Vertica, ClickHouse, Exasol, Greenplum, Teradata и не только.

Работая в крупных компаниях, Максим попробовал много решений, сравнил их на одинаковых данных и задал вопросы их разработчикам и поставщикам. 

Видео и расшифровка доклада — под катом. Далее повествование будет от лица Максима.

Мой уход из Яндекса, как не потерять мотивацию за полгода подготовки в FAANG и реджект в Google.

Приветствую всех любителей Infrastructure as Code.

Как я уже писал в предыдущей статье, я люблю заниматься автоматизацией инфраструктуры. Сегодня представляю вашему вниманию вариант построения GitOps для реализации подхода Monitoring as Code.

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

Oracle, придя на рынок облачных сервисов, активно привлекает новых клиентов. И одним из инструментов такого привлечения являются Always Free сервисы - зарегистрировавшийся клиент может пользоваться каким-то достаточно ограниченным набором ресурсов, как это следует из названия, бесплатно и неограниченно во времени. В список этих ресурсов входит два compute инстанса (каждый 2 ядра, 1GB RAM, 45GB HDD), которые можно использовать подо что угодно, но в нашем случае мы можем построить на них полностью бесплатный OpenVPN-сервер, буквально не умея практически ничего, кроме тыкания в кнопку Next. Чем мы и займемся.