Около десяти лет назад микросервисы получили первое признание. С тех пор масса фирм воспользовалась услугами облачных провайдеров и перенесла свои сервисы к ним. А некоторые из них даже успели разочароваться в облачных технологиях и вернулись к традиционной схеме монолита (или почти к ней).
Эта статья - не попытка уговорить вас на перенос вашего монолита в облако или отговорить от этого. Это попытка описать мифы по поводу такого переноса.
29 апреля в Санкт-Петербурге состоится первый открытый митап Почтовых технологий — цифровой «дочки» Почты России.
Почему «на набережной»? Дело в том, что мероприятие пройдёт в гибридном формате — первые 50 зарегистрировавшихся смогут бесплатно посетить его вживую в нашем питерском офисе на Аптекарской набережной. Для остальных будет доступна онлайн-трансляция.
29 апреля мы поговорим о DevOps. Как создавать отказоустойчивые приложения на базе Kubernetes? Своим опытом поделятся три эксперта из Почтатеха, Yandex.Cloud и IT-one.
Привет, друзья.
Меня зовут Alex Versus и сегодня с вами посмотрим шаблон Singleton, реализацию на языке Golang.
Какая суть?
Одиночка - относится к порождающим шаблонам. Гарантирует:
Всем привет! Меня зовут Виталий, я разработчик в компании Web3Tech. В этом посте я представлю основные концепции и конструкции платформы Spring Cloud Stream для поддержки и работы с брокерами сообщений Kafka, с полным циклом их контекстного unit-тестирования. Мы используем такую схему в своем проекте всероссийского электронного голосования на блокчейн-платформе Waves Enterprise.
Являясь частью группы проектов Spring Cloud, Spring Cloud Stream основан на Spring Boot и использует Spring Integration для обеспечения связи с брокерами сообщений. При этом он легко интегрируется с различными брокерами сообщений и требует минимальной конфигурацией для создания event-driven или message-driven микросервисов.
В этой статье мы не откроем ничего нового об устройстве монолита и микросервисной архитектуры. Про это сказано немало слов, написано ещё больше. Мы расскажем о том, как через это прошла наша компания и какие преимущества и недостатки микросервисной архитектуры мы для себя обнаружили.
Привет, Хабр! В комментариях к статьям из нашего хаба часто спорят: полезна ли Serverless. Хочу поднять флаг миротворца — и сказать, что бессерверная технология меняет весь рабочий процесс и взгляд на разработку. Для этого есть несколько причин.
Serverless смещает оплату в сторону подхода pay-as-you-go: вы платите столько, сколько израсходовано процессорного времени (плюс-минус 100 мс). Вы не ждёте запуска сервера, не распределяете нагрузку и не заморачиваетесь с техобслуживанием. Задача написана — задача исполнена. С другой стороны, возникают проблемы холодного старта, а многим проектам не подходит отсутствие чёткого контроля контейнера. В этой статье я расскажу, в каких именно случаях может пригодиться Serverless и когда к ней надо присмотреться.
Хотите добиться нестандартного поведения от aspnet core? Мне вот понадобилось добавить прозрачную поддержку Json Rpc. Расскажу о том, как я искал решения для всех хотелок, чтобы вышло красиво и удобно. Может быть, вам пригодятся знания о разных точках расширения фреймворка. Или о тонкостях поддержки Json Rpc, даже на другом стеке/языке.
В результате получилась библиотека, которая позволяет работать с Json Rpc, вообще не задумываясь, что он спрятан под капотом. При этом пользователю не нужно уметь ничего нового, только привычный aspnet mvc.
Интегрируя Keycloak в уже существующую систему, высока вероятность столкнуться с необходимостью во время аутентификации загружать пользователей из древней базы данных, где информация о них может храниться в довольно причудливом виде. Такая задача решается созданием собственного провайдера пользователей (User Federation Provider в терминологии Keycloak). Ниже будет представлено краткое руководство по написанию такого провайдера.
Привет!
У нас через неделю очередной онлайн-митап, на этот раз для бекендеров. Будет 2 доклада от нас (Дмитрий @kruftik Гадеев и Роман Бледнов), а также доклад от Максима Степачева, разработчика GridGain.
Всё как всегда — онлайн, бесплатно, в 19.00 МСК, будет трансляция и запись, главное зарегистрируйтесь по ссылке заранее, чтобы мы смогли прислать вам все ссылки.
Программа под катом.
Развивать систему, созданную 16 лет назад, «конечно, не подвиг, но вообще что-то героическое в этом есть» (с). От пользователей регулярно прилетают вопросы: что будете делать дальше? Каким будет Антиплагиат через несколько лет? Все правильно, все верно – нельзя позволять рутине себя засасывать настолько, чтобы не оставалось времени подумать о далеком…, о жестоком…, ну вы поняли… о будущем.
Действительно, начало весны (отчетность закончилась, а сессия еще не началась) – самое удобное время для стратегических планов. Ну а заодно и для удовлетворения любопытства наших пользователей.
Не могу сказать, что описываю совсем уж ближайшее будущее. Какие-то идеи пока находятся в обработке у наших исследователей, какие-то и вовсе пока еще «варятся в головах». Но тем не менее, описанный ниже сценарий развития системы «Антиплагиат» сейчас наиболее вероятен.
Картинку даю, слегка опережая события. Она имеет непосредственное отношение к теме статьи, но, чтобы обо всем рассказать, нужно чуть больше места.
Кадр из а/ф «Шрек 2» (англ. « Shrek 2»), DreamWorks Pictures, 2004 год
Добрая четверть моего рабочего времени за последний год ушла на обновление архитектуры Учи.ру. С ростом продуктов и количества пользователей увеличился и клубок зависимостей в монолите. Выделяя из него части и набивая на этом пути шишки, я не раз задумывался о том, как мы к этому пришли. Волей-неволей вспоминаешь, с чего все начиналось.
В этом посте я попробовал собрать историю архитектуры Учи.ру. В нем нет фрагментов кода и исчерпывающих технических подробностей. О нашем опыте выделения микросервисов для решения некоторых задач образовательной платформы — в следующих публикациях.
Общепринятые мировые практики против проведения нескольких трансформаций в компании одновременно. И все же они возможны, при соответствующей подготовке, привлечении необходимых ресурсов и правильном мониторинге результатов. Плюсами и минусами одновременных трансформаций на конференции DevOps Live 2020 поделился лидер трайба IT4IT в ОТП Банке Максим Ефимов.
В этой статье вы найдете материалы, которые были полезны при внедрении нескольких трансформаций, детальное описание процесса, а также уроки, которые вынесли для себя в банке: как позитивные, так и негативные.
Эта статья является заключительным конспектом книги «От монолита к микросервисам». Материал статьи посвящен декомпозиции БД во время процесса разложения монолита на микросервисы.
Извлечение микрослужбы не «делается» до тех пор, пока код приложения не будет работать в его собственной службе, а данные, которыми он управляет, не будут извлечены в его собственную логически изолированную БД. Однако в какой последовательности извлечения должны выполняться?
Как известно настройка и обучение моделей машинного обучения это только одна из частей цикла разработки, не менее важной частью является развертывание модели для её дальнейшего использования. В этой статье я расскажу о том, как модель машинного обучения может быть развернута в виде Docker микросервиса, а также о том, как можно распараллелить работу микросервиса с помощью распределения нагрузки в несколько потоков через Load balancer. В последнее время Docker набрал большую популярность, однако здесь будет описан только один из видов стратегий развертывания моделей, и в каждом конкретном случае выбор лучшего варианта остаётся за разработчиком.
При проектировании и планировании новой архитектуры на основе (микро) сервисов бывают моменты, когда архитекторам приходится думать о стратегии развертывания и, следовательно, задаваться вопросом: «Должны ли мы развернуть этот (микро) сервис как бессерверную функцию или лучше поместить его в контейнер? Или, быть может, лучше использовать выделенную виртуальную машину (VM)?»
Как это часто бывает в наши дни, есть только один ответ: «Это зависит от обстоятельств». Даже больше — это не только «зависит», это также может «меняться в зависимости». Сегодняшнее оптимальное решение может стать очень неоптимальным через несколько месяцев. При запуске нового приложения выбор бессерверных функций может быть целесообразен, поскольку они быстро настраиваются и требуют относительно небольших предварительных вложений.
Кроме того, их модель оплаты по мере использования (“pay per use”) очень привлекательна, когда мы не уверены, какая нагрузка придется на наше приложение. Позже, когда сервис станет зрелым и нагрузка станет предсказуемой, может оказаться целесообразным перейти к более традиционной топологии развертывания, основанной на контейнерах или выделенных серверах.
Поэтому при разработке новых систем облачной эпохи важно закладывать некоторое пространство для маневров, то бишь изменений стратегии развертывания различных (микро) сервисов с наименьшими затратами. Правильная инфраструктура в правильное время может результировать в значительной экономии на облачных расходах.
Эта статья является конспектом книги «От монолита к микросервисам». Материал статьи посвящен декомпозиции БД во время процесса разложения монолита на микросервисы.
В предыдущей статье рассмотрели способы извлечения функциональности из монолита в микрослужбы. Однако, что делать с данными? Микрослужбы работают лучше всего, когда они полностью инкапсулируют собственные механизмы хранения и извлечения данных.
Однако разложение БД — далеко не простая задача. Нам нужно учесть вопросы синхронизации данных во время перехода на микрослужбы, логической и физической декомпозиции схемы данных, транзакционной целостности, задержки и многое другое. Далее в этой статье будут рассмотрены эти вопросы.
Однако, прежде чем начнем разделять БД, мы должны рассмотреть трудности, связанные с управлением одной совместной БД.
Эта статья является конспектом книги «От монолита к микросервисам». Материал статьи посвящен шаблонам разложения монолита.
В этой статье рассмотрим различные шаблоны миграции, а также советы для внедрения архитектуры, основанной на микрослужбах. Однако, чтобы внедрение работало как надо, необходимо обеспечить продолжение работы с существующим монолитным ПО и его использование клиентами.
Вам нужны наблюдаемые микросервисы, но вы еще не знаете, как их реализовать с помощью Kubernetes? Ну что ж… возможно это именно та статья, которую вы искали.
Во-первых, давайте разберемся, что такое наблюдаемость. Этот термин возник в инженерии систем управления и был определен как «мера того, насколько хорошо могут быть определены внутренние состояния системы на основе информации о ее внешних выводах». Проще говоря, наблюдаемость подразумевает адекватное понимание системы, способствующее корректирующим действиям.
Сегодня я продолжу рассуждать о том, как мы пишем микросервисы. В прошлый раз упор был на теорию: нужно было вспомнить, как код писался раньше, понять сущность архитектуры и связи между компонентами.
Эта половина статьи сосредоточится на опыте нашей команды BellSoft. Поговорим о том, каким образом мы взаимодействуем с миром микросервисов: здесь будет и про универсальный Java-рантайм, и про крошечные контейнеры, и про Spring. Я разложу микросервис на слои, соберу в образ, запущу и покажу, что влияет на его скорость.
