Микросервисы 🔎

Ко мне подошел Flatiron Coach, который работает в отделе взаимоотношений с сотрудниками, по поводу компании, которая интересовалась моим резюме и хотела пройти собеседование. Мне очень понравилось интервью, и я смог задать вопросы, которые дали отличное понимание.

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

Микро. Услуги. Какие? 👀

Архитектура микросервисов позволяет нам создавать высокомасштабируемые, гибкие приложения, разбивая приложение на отдельные службы, которые реализуют определенные бизнес-функции. Эти службы, часто называемые «слабосвязанными», затем можно создавать, развертывать и масштабировать независимо.

Каждый отдельный сервис взаимодействует с другими сервисами через API, что позволяет писать их на разных языках или с использованием разных технологий (хотя многие практики не одобряют этого). Это не похоже на монолитную архитектуру, где сервисы замысловато взаимосвязаны и только масштабируются вместе.

Почему микросервисы? 🤔

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

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

Вызов преимуществ 🙌🏼

• Свобода самостоятельно разрабатывать и развертывать сервисы.
• Может быть разработан довольно небольшой командой.
• Код для разных сервисов может быть написан на разных языках.
• Простая интеграция и автоматическое развертывание (с использованием инструментов непрерывной интеграции с открытым исходным кодом).
• Легко понять и изменить для разработчиков, что может помочь новому члену команды быстро стать продуктивным.
• Разработчики могут использовать новейшие технологии.
• Код организован вокруг бизнес-возможностей.
• Когда требуется изменение в определенной части приложения, можно изменить и повторно развернуть только соответствующую службу.
• Лучшая изоляция сбоев: отказ одного микросервиса не мешает работе других сервисов.
• Легко масштабировать и интегрировать со сторонними сервисами.
• Никаких долгосрочных обязательств в отношении фиксированных стеков технологий.

• Из-за распределенного развертывания тестирование может стать сложным и утомительным.
• Увеличение количества услуг может привести к информационным барьерам.
• Поскольку это распределенная система, это может привести к дублированию усилий.
• Когда количество сервисов увеличивается, интеграция и управление целыми продуктами могут усложняться.
• Помимо нескольких сложностей монолитной архитектуры, разработчикам приходится иметь дело с дополнительной сложностью распределенной системы.
• Требуется гораздо больше общения и сотрудничества между разными командами (это не всегда может быть так просто).