Привет.
Это история о том, как я писал балансировщик нагрузки для телеграм‑ботов, на полпути понял, что телеграм тут вообще ни при чём, выкинул половину проекта — и теперь у меня Rust‑конструктор, из которого одинаково собирается реверс‑прокси, самодельный ngrok, мост HTTP → RabbitMQ → Kafka и тот самый балансировщик ботов, с которого всё началось.
Проект называется tgin. Раньше это был Telegram Gateway Interface, теперь — Traffic Gateway Interface.
Некоторое время назад я был участником команды, реализующей решение, на базе которого можно развернуть internal development platform. В первую очередь мы ориентировались на крупный enterprise с командами разработки от 150 человек, которым важны унификация, контроль, снижение когнитивной нагрузки на команды, безопасная разработка. Сегодня же хотел бы поделиться своими рассуждениями о платформах разработки немного под другим углом — не с учётом команд и процессов разработки (IDP всё-таки заточены в первую очередь решать проблемы в этой области), а с точки зрения зрелости самого разрабатываемого решения.
Когда мы впервые увидели AI-чаты, это выглядело впечатляюще. Они писали код, помогали с документацией, объясняли архитектурные решения.
Это было хорошо. Но довольно быстро стало понятно главное:
Для реальной работы этого недостаточно.
Даже сложная и продуманная технологическая система не застрахована от инцидентов — это касается любых инфраструктур, от железнодорожных и коммунальных до IT. Поэтому инженерам, которые обеспечивают надёжность систем, важно не только предотвращать проблемы, но и минимизировать их влияние за счёт хорошего антикризисного (или DR) плана.
Привет, %Username%! Меня зовут Михаил Слотин, я главный архитектор в РСХБ-Интех (технологическая дочка Россельхозбанка) и один из создателей Частного Облака (ЧО) РСХБ. Сегодня расскажу вам, как мы работали над ЧО, почему потребовалось создавать новое решение вместо покупки готового и как мы сделали больше, чем планировали. Особо полезна, на мой взгляд, статья будет архитекторам и ИТ-менеджерам. Надеюсь, она поможет определиться, начать свою разработку или нет.
Примечание: данная статья является переводом на русский язык оригинальной статьи «DevOps tools are not only for DevOps. Building test automation infrastructure from scratch». Однако все иллюстрации, ссылки, цитаты и термины сохранены на языке оригинала, чтобы избежать искажения смысла при переводе на русский язык. Желаю вам приятного изучения!
Читая различные каналы и рассылки, я часто встречаю статьи о конкретных «болях» и проблемах, возникающих при росте компании, когда надежность и масштабируемость выходят на первый план. Эта статья — иная. Здесь нет подробного разбора конкретных архитектурных решений или пошагового руководства по изменению инженерной культуры. Скорее, это взгляд сверху на те вызовы, которые возникают при эксплуатации распределенных систем, и отправная точка, которая поможет сориентироваться в потоке терминов, аббревиатур и технологий.
Предлагаю вашему вниманию перевод статьи, написанной инженером из Uber.
* * *
В последние несколько лет я создавал и обслуживал большую распределённую систему платежей в Uber. За это время я многое узнал о концепциях распределённых архитектур и на своём опыте выяснил, насколько трудно создавать и обслуживать высоконагруженные системы с высокой доступностью. Построение такой системы — работа интересная. Мне нравится планировать, как система будет обрабатывать рост трафика в 10-100 раз, обеспечивать надёжность данных вне зависимости от аппаратных сбоев. Однако эксплуатация большой распределённой системы дала мне неожиданный опыт.
Читать полностью »
Представлять инфраструктуру в виде кода в повторяемом текстовом формате — простая лучшая практика для систем, с которой не нужно мышевозить. За этой практикой закрепилось название — Infrastructure as Code, и пока что для ее осуществления, особенно в AWS, есть два популярных инструмента: Terraform и CloudFormation.
Сравниваю опыт работы с Terraform и CloudFormation
До прихода в Twitch (он же Amazon Jr.) я трудился в одном стартапе и года три использовал Terraform. На новом месте я тоже вовсю использовал Terraform, а потом компания продавила переход на все а-ля Amazon, включая CloudFormation. Я усердно разрабатывал лучшие практики и для того, и для другого, и оба инструмента использовал в очень сложных рабочих процессах в масштабах организации. Позднее, вдумчиво взвесив последствия перехода с Terraform на CloudFormation, я убедился, что Terraform, наверное, — лучший выбор для организации.
P4 — это язык программирования, предназначенный для программирования правил маршрутизации пакетов. В отличие от языка общего назначения, такого как C или Python, P4 — это предметно-ориентированный язык с рядом конструкций, оптимизированных для сетевой маршрутизации.
P4 — это язык с открытым исходным кодом, лицензируемый и поддерживаемый некоммерческой организацией, которая называется P4 Language Consortium. Он также поддерживается Open Networking Foundation (ONF) и Linux Foundation (LF) — двумя крупнейшими зонтичными организациями в проектах с открытым исходным кодом в области сетевых технологий.
Привет, друзья. В эту пятницу мы собираем в Mail.ru наш второй @OpenStack Meetup, на котором:
Встреча пройдёт 22 февраля (пятница) в 19:00 в московском офисе Mail.ru Group (Ленинградский проспект, д. 39, стр. 79).
Регистрация обязательна и закрывается 20 февраля в 23:59 (или раньше, если закончатся места).
Читать полностью »
