Cloud vs Self-Hosted Вечная дилемма что выбрать: использовать облачные сервисы или всё развернуть на своих серверах. Это снова вопрос компромиссов. У каждого подхода есть свои плюсы и минусы. Можно комбинировать два подхода и не уходить в крайности. Например, использовать виртуальную машину на AWS на которой хостить базу данных вместо использования managed-решения. Например, self-hosted PostgreSQL вместо Amazon RDS. Облачные сервисы избавляют команду от операционного управления, например, не нужно самостоятельно следить за обновлениями, патчами безопасности или высокой доступностью тех или иных сервисов. Порой вам даже не нужно думать о масштабировании, за вас это делает облачный провайдер. Взамен вы платите более высокую цену, получаете менее гибкий сервис и возможный vendor lock. Например, управляемый Apache Airflow от AWS это черный ящик и если что-то идёт не так, то сложно понять причину, необходимо тратить время на общение со службой поддержки, которая больше напоминает бездушных роботов. Также существуют облачные решения, которые невозможно развернуть самостоятельно, например Amazon Redshift. Если вы строите свой Data Warehouse на базе Redshift, то получаете vendor lock. Self-hosted решения зачастую гибче и дешевле, но приходится нести бремя обслуживания. Порой специалисты, способные качественно обслуживать self-hosted сервисы стоят дороже чем их обслуживание в облаках. Но всегда необходимо оценивать как краткосрочные планы так и долгосрочное видение. В моменте self-hosted подход может быть дороже, но в долгосрочном плане выгоднее. Также могут существовать административные ограничения, которые не позволяют использовать облака. Например, требование к хранению персональных данных на территории конкретного государства. Распределённые системы Приложение в обслуживание которого задействованы 2 и более машины является распределённым. В текущих реалиях распределённые системы это обыденность: — Данные на 1 машину уже не помещаются, их нужно размазать на несколько (Data Sharding) — Нагрузка на приложение растёт и его необходимо масштабировать и обеспечивать высокую доступность (Fault-tolerance, high-availability) — Обслуживание с минимальными задержками (Latency) — Соответствие законодательным нормам, когда данные пользователей хранятся в соответствующем регионе или стране (Legal compliance) Проблемы распределённых систем — Взаимодействие между машинами происходит по сети и в любой момент может быть обрыв связи — Задержки в передаче данных, даже несмотря на то, что 2 машины могут быть в одном дата-центре, передача данных между ними всё равно будет медленнее нежели если бы данные были лишь на одной — Отладка проблем в распределённой среде сложнее, для этого придуманы инструменты Observability (сбор логов и метрик по работе систем) Микросервисы и Serverless Микросервисы реализуют идею decoupling для команд разработки. Группа людей может заниматься конкретным сервисом и использовать технологический стек по своему усмотрению. Сервис в этом случае является изолированным юнитом одной большой системы. Но всё не так прекрасно как на бумаге. У микросервисов есть множество подводных камней: — Сложности взаимодействия между системами (транзакции, согласованность данных) — Зоопарк технологий — Общее усложнение системы (мониторинг, тестирование, деплой) Если нет острой необходимости внедрять микросервисную архитектуру, то делать этого не стоит. Они могут быть неплохим решениям для большой организации, но в небольших компаниях лучше идти по более простому пути (монолит). Serverless Ещё один архитектурный подход при котором разработчики оперируют функциями и не думают об инфраструктуре на которой запускается их код (Function as a Service, FaaS). Примеры: Amazon Lambda, Google Cloud Functions. Удобно использовать там, где нагрузка варьируется потому что при резком росте FaaS дают гибкость и легко масштабируются. Но работа с функциями порой требует пересмотра привычного подхода к разработке приложений, и на мой взгляд, сильно привязывает к конкретному провайдеру облачных технологий.