Как архитектор-консультант в Red Hat, я имел возможность поработать над множеством проектов для наших клиентов. У каждого из них есть свои особенности, которые, однако, имеют некоторые общие черты. Большинство клиентов хотят знать, как скоординировать запись в несколько систем одновременно. Ответ на этот вопрос обычно включает подробное объяснение двойной записи, распределенных транзакций, современных альтернатив, а также возможных сценариев сбоев и недостатков каждого подхода. Как правило, именно в этот момент заказчик понимает, что разделение монолитного приложения на микросервисы - долгий и сложный путь, обычно требующий компромиссов.
В идеальном мире можно просто взять исходный код монолита, разделить его код между микросервисами и, соединив их между собой, получить ту же систему, но на новой архитектуре. В жизни так не происходит никогда. Жизнь вносит множество сложностей в эту идеальную картинку. Какие конкретно сложности могут увеличить бюджет перехода на микросервисы в два-три раза?
Я опишу факторы, которые затягивают процесс перехода на микросервисы и делают его сильно дороже, чем ожидалось вначале. Вы получите чеклист для оценки этих факторов и будете более реалистично считать бюджет перехода.
В Одноклассниках запросы пользователей обслуживает более 200 видов уникальных типов сервисов. Многие из них совмещают в одном JVM-процессе бизнес-логику и распределенную отказоустойчивую базу данных Cassandra, превращая обычный микросервис в микросервис с состоянием. Это позволяет нам строить высоконагруженные сервисы, управляющие сотнями миллиардов записей с миллионами операций в секунду на них.
Какие преимущества появляются при совмещении бизнес-логики и БД? Какие нюансы надо учесть, прибегая к такому подходу? Что с надёжностью и доступностью сервисов? Расскажем подробно об этом всём.
Комментарии в соцсетях — это как чипсы: начал читать, остановиться невозможно. Но в ОК до 2024 года они были плоскими — вместо структурированного диалога под постом пользователи видели бесконечную ленту сообщений, где ответы терялись в хронологическом порядке. Представьте: под постом про котиков кто-то спросил про корм, но ответ на вопрос появился в самом низу, через 500 комментариев с обсуждением хвостатых. Найти ответ на вопрос в такой системе, если он вообще существует, — тот ещё квест.
Меня зовут Александр Косницкий. Я разработчик в компании ОК. В этой статье я расскажу, как мы переходили с линейной структуры отображения комментариев к древовидной: с чего начали, с чем сталкивались и что получили в результате.
Большая боль разработчиков, которые приходят на новый проект — для развертывания сервиса локально нужно пообщаться минимум с десятком людей, не говоря уже про интеграцию с CI/CD-сервером. В один момент мы решили реализовать это удобнее, заодно сократив время онбординга новых сотрудников.
При этом мы хотели получить не только быстрый ввод новых сервисов в эксплуатацию и минимальное время развертывании любого сервиса локально — мы хотели, чтобы все наши сервисы использовали более или менее одинаковые версии библиотек, настройки линтеров и конфигурацию. А поскольку мы финтех, то должен был сохраняться высокий уровень безопасности, а риск человеческих ошибок — снижаться.
Меня зовут Олег Чуркин. Я больше 10 лет занимаюсь разработкой на Python и сейчас руковожу разработкой нового процессинга платежей в QIWI. Расскажу, как мы реализовали boilerplate-шаблон для сервисов — на примере небольшого стартапа внутри нашей большой компании.
KubeGraf — это плагин для Grafana, который собирает данные с кластера Kubernetes и приложений внутри него, а затем показывает их на красивых и понятных графиках. В феврале этого года вышел релиз 1.5, и стало известно, что предыдущие версии скачали более 250 тысяч раз! Мы расспросили Сергея Спорышева, создателя плагина и директора направления DevOps-продуктов в ITSumma, об истории создания плагина, факапах и причинах популярности.
Всем привет. Меня зовут Нещадин Иван, и я расскажу про оптимизацию одного из микросервисов Авито на Go. История построена вокруг различных инструментов, которые доступны в языке, и пойдёт от простых примеров к более сложным.
Со временем, каждый проект растет и реализовывать новый функционал в существующий монолит становится все сложнее, дольше и дороже для бизнеса.
Один из вариантов решения данной проблемы — использование микросервисной архитектуры. Для новичков или для тех, кто впервые сталкиваются с данной архитектурой, может быть сложно понять, с чего начать, что нужно делать, а что делать не стоит.
Сейчас OpenTelemetry — это самый быстрорастущий проект CNCF. Опытом внедрения этого набора инструментов для отладки и анализа производительности распределённых систем поделился тимлид платформенной команды Норвежского управления труда и социального обеспечения. В переводе под катом вас ждёт тернистый путь от первых коммитов до реального применения OpenTelemetry в production, а также планы команды на будущее.
