Всем привет! Недавно я написал Discord бота для World of Warcraft гильдии. Он регулярно забирает данные об игроках с серверов игры и пишет сообщения в Discord о том что к гильдии присоединился новый игрок или о том что гильдию покинул старый игрок. Между собой мы прозвали этого бота Батрак.
Сегодня расскажем, как переводили на микросервисы монолитное решение. Через наше приложение круглосуточно проходит от 20 до 120 тысяч транзакций в сутки. Пользователи работают в 12 часовых поясах. В то же время функционал добавлялся много и часто, что довольно сложно делать на монолите. Вот почему системе требовались устойчивая работа в режиме 24/7, то есть HighLoad, High Availability и Fault Tolerance.
Мы развиваем этот продукт по модели MVP. Архитектура менялась в несколько этапов вслед за требованиями бизнеса. Первоначально не было возможности сделать всё и сразу, потому что никто не знал, как должно выглядеть решение. Мы двигались по модели Agile, итерациями добавляя и расширяя функциональность.
Иллюстрация @alvaro_sanchez
Некоторое время все сходили с ума по микросервисам. Невозможно было открыть любимый новостной агрегатор и не увидеть, чтобы какая-то неизвестная вам доселе компания рассказывает о спасении своего инженерного отдела с помощью микросервисов. Возможно, вы даже сами работали в компании, которую захватил ажиотаж крохотных, магических маленьких сервисов, которые решат все проблемы большой, запущенной, полной легаси кодовой базы.
Естественно, в реальности все оказалось совсем наоборот. Когда смотришь назад, на произошедшее, то зрение оказывается ближе к 100%, чем когда смотришь с надеждой в будущее.
Я хочу рассказать о некоторых важных заблуждениях и подводных камнях движения за микросервисы с точки зрения человека, который работал в компании, убежденной в идее целительных свойств микросервисов. Я не хочу, чтобы выводом этой статьи для вас стало "микросервисы == плохо", но в идеале я хотел бы, чтобы вы задумались о проблемах когда будете решать, подходит ли вам микросервисная архитектура.Читать полностью »
Нормальное взаимодействие участников Netflix обеспечивается архитектурой микросервисов и привязано персонально к каждому из наших более чем 80 миллионов участников. Сервисы принадлежат разным командам (группам), каждая из которых имеет свой собственный цикл разработки и релиза. Это означает, что необходимо иметь постоянно действующую и компетентную группу тестирования интеграции, обеспечивающую выполнение сквозных стандартов качества в ситуации, когда микросервисы вводятся в действие каждый день децентрализованно.
В качестве группы тестирования интеграции разрабатываемых продуктов мы обязаны не снижать скорость введения нового, обеспечивая в то же время контроль качества и быструю обратную связь для разработчиков. Каждая группа разработчиков отвечает за качество поставляемого ею продукта. Нашей задачей является бесперебойная работа с различными техническими группами с упором на сквозную функциональность и координацию деятельности групп. Мы представляем собой небольшую группу специалистов по тестированию интеграции в организации, насчитывающей более 200 разработчиков.
Быстрый ввод новых разработок при необходимости обеспечении требуемого качества создаёт интересные задачи для нашей команды. В настоящей статье мы рассмотрим три такие задачи:
1. Тестирование и мониторинг высокорейтинговых показов (High Impact Title = HIT = хит)
2. A/B-тестирование
3. Глобальный запуск
Читать полностью »
Евгений (Джим) Брикман является автором книги «Hello, Startup» («Привет, стартап») и основателем компании «Atomic Squirrel», которая специализируется на помощи стартапам. До этого он больше десяти лет работал в таких компаниях, как Linkedln, TripAdvisor, Cisco Systems, Thomson Financial. Он также имеет степени бакалавра и магистра компьютерных наук Корнелльского университета.
Представьте себе, ваша работа состоит в том, чтобы все автомобили на автостраде ехали быстрее. Что произошло бы, если бы вы просто сказали всем водителям вдавить до упора педаль газа?
Ясно, что результатом была бы катастрофа. И, всё же, это — точно тот тип отношений, который многие разработчики пытаются реализовать, стремясь создать программное обеспечение быстрее. Здесь несколько из причин, почему они делают так:
«Мы пытаемся быть действительно динамичными, поэтому мы не тратим время напрасно на разработку структуры или документации.»
«Я должен отправить это на производство немедленно, поэтому у меня нет времени писать тесты!»
«У нас не было времени автоматизировать что-либо, поэтому мы просто развёртываем наш код вручную.»
Для автомобилей на автостраде вождение с высокой скоростью требует особого внимания к обеспечению безопасности. Чтобы можно было вести автомобиль быстро, на нём должны быть соответствующие устройства, например, тормоза, ремни и подушки безопасности, сберегающие водителя, если что-то пойдёт не так.
Для программного обеспечения динамичность также требует обеспечения безопасности. Есть разница между достижением разумных компромиссов и устремлённостью вперёд вслепую без мыслей об осторожности. Должны быть механизмы обеспечения безопасности, которые минимизируют потери при неблагоприятном развитии событий.Читать полностью »
