Вопросы и ответы — Java / Spring Developer — Cloud

Все вопросы

В этой статье:

➤ Какие существуют основные облачные решения для Java разработки и их аналоги для обычной инфраструктуры
➤ Какие существуют основные облачные решения от Amazon для Java разработки
➤ Какие существуют основные облачные решения от Google для Java разработки
➤ Какие существуют основные облачные решения от Microsoft для Java разработки
➤ Как можно оптимизировать cloud решение с точки зрения затрат
➤ Как работают servless решения
➤ Как работает Git LFS (Large File Storage)
➤ Как работать с субмобулями Git

➤ Какие существуют основные облачные решения для Java разработки и их аналоги для обычной инфраструктуры

▲К списку вопросов▲

➤ Какие существуют основные облачные решения от Amazon для Java разработки

Amazon EC2 (Elastic Compute Cloud):
Предоставляет масштабируемые виртуальные серверы для запуска приложений. EC2 позволяет вам создавать и управлять экземплярами виртуальных машин (инстансов), на которых можно развертывать свои приложения, такие как микросервисы, веб-серверы, базы данных и другие компоненты.Amazon EC2 (Elastic Compute Cloud)

Amazon Elastic Kubernetes Service (EKS) / Amazon Elastic Container Service (ECS):
Используются для оркестрации контейнеров. Если вы используете Docker для микросервисов, то эти сервисы помогут в автоматизации деплоя, управления и масштабирования контейнеров.

Amazon API Gateway:
Предоставляет возможность создания, публикации, управления и защиты API для микросервисов. Работает в связке с AWS Lambda или ECS.

AWS Lambda:
Если вам нужны serverless функции для небольших задач или отдельных микросервисов, Lambda может помочь вам запускать код без необходимости управления серверами.

Amazon RDS (Relational Database Service):
Для управления реляционными базами данных, такими как PostgreSQL, MySQL или Oracle. AWS берет на себя управление инфраструктурой, резервное копирование и масштабирование.

Amazon DynamoDB:
NoSQL база данных для микросервисов, требующих высокой скорости работы и гибкости структуры данных. Отлично подходит для приложений с неструктурированными данными.

Amazon SQS (Simple Queue Service):
Асинхронная очередь сообщений для взаимодействия между микросервисами. Позволяет микросервисам обмениваться сообщениями, избегая потерь данных и сбоя при высокой нагрузке.

Amazon SNS (Simple Notification Service):
Служба рассылки уведомлений. Используется для публикации и доставки сообщений между микросервисами, либо для рассылки push-уведомлений, email или SMS.

Amazon Elastic Load Balancing (ELB):
Для балансировки нагрузки между вашими микросервисами. AWS ELB автоматически распределяет входящий трафик между несколькими экземплярами приложения.

AWS IAM (Identity and Access Management):
Управление доступом и политиками безопасности для сервисов и ресурсов AWS. Полезен для микросервисной архитектуры с распределенным доступом.

AWS CloudWatch:
Для мониторинга логов, метрик и алертов ваших микросервисов. Позволяет настраивать наблюдение за состоянием сервисов, а также выявлять и исправлять сбои.

Amazon S3 (Simple Storage Service):
Объектное хранилище для хранения статических файлов, данных или бэкапов. Используется как централизованное хранилище для микросервисов, если им нужно хранить или делиться файлами.

AWS Step Functions:
Оркестрация и управление процессами выполнения нескольких микросервисов. Позволяет строить и управлять сложными бизнес-процессами с использованием микросервисов.

AWS Secrets Manager:
Управление секретами, такими как API ключи, пароли, токены и т.д. Это упрощает безопасное хранение и доступ к секретам, необходимым для работы микросервисов.

Amazon Aurora:
Высокопроизводительная реляционная база данных, совместимая с MySQL и PostgreSQL, которая используется для высоконагруженных приложений в микросервисной архитектуре.

▲К списку вопросов▲

➤ Какие существуют основные облачные решения от Google для Java разработки

Google Kubernetes Engine (GKE):
управляемый сервис для оркестрации контейнеров на базе Kubernetes. Это один из самых популярных вариантов для микросервисной архитектуры, где каждый микросервис запускается как контейнер. GKE позволяет легко управлять и масштабировать контейнеризированные Java приложения, обеспечивая автоматическое развертывание и балансировку нагрузки.

Cloud Run:
платформа для запуска контейнеризированных приложений без управления инфраструктурой. Сервис полностью управляемый, и вы платите только за использованные ресурсы. Подходит для небольших микросервисов, не требующих полного управления Kubernetes кластерами.

App Engine:
платформа без серверов (PaaS), предназначенная для автоматического масштабирования приложений. Поддерживает Java и позволяет разрабатывать микросервисы без забот о серверах и их настройке. Это отличное решение для микросервисов, где важна простота и скорость разработки.

Google Cloud Functions:
сервис бессерверных функций (Function as a Service, FaaS), позволяющий запускать небольшие фрагменты Java-кода в ответ на события (например, HTTP-запросы или сообщения из других сервисов). Хорошо подходит для микросервисной архитектуры, где нужно быстро и просто реализовать маленькие компоненты или обработчики событий.

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

Cloud SQL:
управляемая реляционная база данных для MySQL, PostgreSQL и SQL Server. Обеспечивает высокую доступность, автоматическое резервное копирование и масштабирование. Это отличный выбор для микросервисов, которым требуются традиционные реляционные базы данных.

Cloud Firestore и Datastore:
NoSQL базы данных с высокой доступностью, предназначенные для хранения неструктурированных данных. Firestore может быть отличным выбором для микросервисов, которым нужна гибкость в структуре данных.

Google Cloud Storage:
объектное хранилище для хранения данных, файлов, статических ресурсов и медиа. Используется для хранения больших объемов данных, к которым могут обращаться различные микросервисы.

Google Cloud Spanner:
масштабируемая распределенная реляционная база данных с высокой доступностью и поддержкой транзакций. Подходит для глобальных микросервисов, где требуется работа с большими объёмами данных с низкой задержкой.

Google BigQuery:
масштабируемая аналитическая платформа (data warehouse), оптимизированная для работы с большими объемами данных. Поддерживает SQL-запросы для анализа данных, которые могут генерироваться микросервисами, и используется для обработки и анализа данных в реальном времени.

Google Cloud Load Balancing:
сервис балансировки нагрузки, позволяющий распределять входящий трафик между несколькими микросервисами или инстансами, развернутыми в Google Cloud. Поддерживает балансировку как для HTTP(S), так и для TCP/UDP трафика.

Cloud Monitoring (ранее Stackdriver):
система мониторинга и логирования, которая позволяет отслеживать производительность микросервисов, анализировать логи и настраивать алерты. Это помогает контролировать состояние микросервисов и своевременно реагировать на инциденты.

Secret Manager:
сервис для безопасного управления секретами (API-ключами, паролями и конфиденциальными данными), необходимыми для микросервисов. Поддерживает шифрование и строгие политики контроля доступа.

Anthos:
платформа гибридного и многооблачного управления, которая позволяет развертывать и управлять микросервисами на разных платформах (GKE, другие облака, собственная инфраструктура) с единым управлением и политиками безопасности.

Traffic Director:
управляемый сервис для динамической балансировки нагрузки и управления трафиком на уровне приложения. Поддерживает интеграцию с Envoy для реализации сервисной сети (service mesh).

VPC Service Controls:
сервис для защиты микросервисов от нежелательного доступа, который позволяет настраивать контрольные границы между разными сервисами Google Cloud и устанавливать правила доступа.

▲К списку вопросов▲

➤ Какие существуют основные облачные решения от Microsoft для Java разработки

Azure Kubernetes Service (AKS):
управляемый сервис для оркестрации контейнеров на базе Kubernetes. Это отличное решение для развертывания и управления контейнеризированными Java приложениями, обеспечивая автоматическое развертывание, масштабирование и управление контейнерами.

Azure App Service:
платформа как услуга (PaaS), которая позволяет развертывать и масштабировать веб-приложения и API. Поддерживает Java и обеспечивает автоматическое управление инфраструктурой, включая обновления и масштабирование.

Azure Functions:
сервис бессерверных вычислений (Function as a Service, FaaS), который позволяет запускать фрагменты Java-кода в ответ на события. Идеален для реализации небольших микросервисов и обработчиков событий.

Azure Service Bus:
сервис обмена сообщениями, который поддерживает модель публикации/подписки и очередей сообщений. Позволяет микросервисам взаимодействовать между собой, обеспечивая надежную доставку сообщений.

Azure SQL Database:
управляемая реляционная база данных для SQL Server. Обеспечивает высокую доступность, автоматическое резервное копирование и масштабирование, что делает ее подходящим выбором для реляционных данных в микросервисах.

Azure Cosmos DB:
глобально распределенная NoSQL база данных с высокой доступностью и поддержкой различных моделей данных, включая документы и графы. Отлично подходит для хранения неструктурированных данных микросервисов.

Azure Blob Storage:
объектное хранилище для хранения больших объемов неструктурированных данных, таких как файлы, изображения и резервные копии. Используется для хранения данных, доступных микросервисам.

Azure Synapse Analytics:
аналитическая платформа, которая объединяет хранилище данных и аналитические возможности. Подходит для обработки и анализа больших объемов данных, генерируемых микросервисами.

Azure Load Balancer:
сервис балансировки нагрузки, который распределяет трафик между несколькими инстансами приложений. Поддерживает балансировку для TCP и UDP трафика и обеспечивает высокую доступность и масштабируемость.

Azure Monitor:
система мониторинга и логирования, которая предоставляет инструменты для отслеживания производительности приложений, анализа логов и настройки алертов. Помогает контролировать состояние микросервисов и реагировать на инциденты.

Azure Key Vault:
сервис для управления секретами, такими как ключи, пароли и сертификаты. Обеспечивает безопасное хранение и управление доступом к конфиденциальным данным, необходимым для работы микросервисов.

Azure Arc:
платформа для управления гибридными и многооблачными средами, позволяющая развертывать и управлять микросервисами на различных платформах и облаках с единым управлением и политиками безопасности.

Azure Application Gateway:
управляемый сервис для балансировки нагрузки на уровне приложений с поддержкой Web Application Firewall (WAF). Позволяет управлять и защищать трафик приложений, включая микросервисы.

Azure Virtual Network (VNet):
сервис для создания частных сетей в облаке. Позволяет настроить сеть, защищенную от внешнего доступа, и управлять подключениями между различными микросервисами и ресурсами в Azure.

▲К списку вопросов▲

➤ Как можно оптимизировать cloud решение с точки зрения затрат

Использование Serverless и BaaS решений:
Использование Azure Functions или Google Cloud Functions для выполнения отдельных микросервисов или функций, которые не требуют постоянной работы. Это позволяет платить только за фактическое время выполнения кода, а не за постоянно работающие виртуальные машины или контейнеры.

Автоматическое масштабирование:
Настройка автоматического масштабирования в Kubernetes (с помощью Azure Kubernetes Service (AKS) или Google Kubernetes Engine (GKE)) для управления количеством реплик микросервисов в зависимости от нагрузки. Это позволяет экономить ресурсы и платить только за необходимую мощность в периоды высокой нагрузки.

Оптимизация ресурсов контейнеров:
Настройка правильных ресурсов (CPU и память) для контейнеров в Kubernetes. Определение и настройка лимитов и запросов для ресурсов контейнеров позволяет предотвратить чрезмерное потребление ресурсов и избыточные затраты.

Выбор подходящих типов виртуальных машин:
В Amazon EC2 или Azure Virtual Machines выбирайте подходящие типы инстансов, оптимизированные под ваши задачи. Например, используйте t3.micro или t4g.micro для низконагруженных приложений или c5/m5 для высокопроизводительных задач. Использование резервированных инстансов или длительных аренды может также сократить затраты.

Использование Spot Instances и Preemptible VMs:
В AWS можно использовать Spot Instances, а в Google Cloud — Preemptible VMs для выполнения менее критичных задач. Эти инстансы стоят значительно дешевле по сравнению с обычными инстансами, но могут быть прерваны в любой момент.

Оптимизация хранения данных:
Для хранения данных используйте подходящее хранилище в зависимости от типа данных. Например, используйте Google Cloud Storage или Azure Blob Storage для неструктурированных данных и Amazon S3 для хранения резервных копий. Выбирайте уровни хранения (например, холодное хранение) для редко используемых данных.

Настройка кеширования:
Использование кеширования на уровне приложений или с помощью сервисов вроде Redis (Azure Cache for Redis или Google Cloud Memorystore) для уменьшения нагрузки на базу данных и снижения затрат на запросы.

Мониторинг и управление затратами:
Использование инструментов мониторинга и управления затратами, таких как Google Cloud’s Operations Suite (ранее Stackdriver) или Azure Cost Management, для отслеживания использования ресурсов и анализа затрат. Эти инструменты помогают выявить неэффективные расходы и оптимизировать использование ресурсов.

Снижение числа обращений к базе данных:
Использование стратегий кэширования и агрегации данных, чтобы минимизировать количество запросов к базе данных и снизить затраты на запросы и хранение.

Правильное управление жизненным циклом ресурсов:
Настройка автоматического удаления ненужных ресурсов и временных инстансов после завершения задач. Например, использование Auto Scaling групп с политиками удаления инстансов после их использования или по расписанию.

Сценарий:

Предположим, у вас есть микросервисная архитектура на базе Google Cloud или AWS с несколькими микросервисами, которые взаимодействуют через API и обрабатывают разный объем трафика в течение дня. Вы хотите сократить расходы, оптимизируя использование ресурсов.

Шаги оптимизации:

Использование Cloud Run для нерегулярных сервисов:
Некоторые микросервисы могут не требовать постоянного запуска, особенно если они используются лишь в ответ на определенные события (например, асинхронные задачи). Вместо развертывания этих микросервисов в Kubernetes или на виртуальных машинах, их можно перенести на Google Cloud Run или AWS Fargate.
Это позволит платить только за время, когда сервисы действительно выполняются. Например, обработчики событий или функции могут запускаться в ответ на HTTP-запросы или сообщения из очередей (Google Pub/Sub, Amazon SQS).

Использование Spot/Preemptible Instances для некритичных задач:
Некоторые микросервисы могут выполнять задачи, которые не критичны к времени завершения и могут быть приостановлены. Для таких задач можно использовать AWS Spot Instances или Google Preemptible VMs, которые значительно дешевле стандартных виртуальных машин.
Spot инстансы или Preemptible VMs стоят на 70-90% дешевле и могут быть использованы для фоновых задач, таких как анализ данных, пакетная обработка, или рендеринг.

Автоматическое масштабирование ресурсов:
Настройка автоматического горизонтального масштабирования в Kubernetes (GKE в Google Cloud или AKS в Azure) позволяет поднимать больше инстансов микросервисов только тогда, когда это действительно необходимо (например, при резком увеличении трафика), и автоматически уменьшать количество инстансов в периоды низкой нагрузки.
Это помогает избегать переплаты за вычислительные мощности в периодах низкой активности, когда достаточны минимальные ресурсы.

Оптимизация контейнеров в Kubernetes (GKE, AKS, EKS):
При использовании Kubernetes, важно правильно задавать ресурсные лимиты и запросы для контейнеров. Если контейнеры слишком сильно «просят» ресурсов (CPU, память), это ведет к избыточным затратам. Если ресурсы настроены слишком низко — это может привести к деградации производительности.
Правильная настройка CPU и памяти для каждого микросервиса позволяет максимально эффективно использовать ресурсы без их избыточного резервирования.

Использование managed баз данных с автоматическим масштабированием:
Используйте managed базы данных, такие как Google Cloud SQL, Amazon RDS или Azure SQL, с включенной функцией автоматического масштабирования. Это позволит базе данных автоматически увеличивать или уменьшать вычислительную мощность в зависимости от нагрузки.
Вы платите только за фактически использованные ресурсы и избегаете необходимости вручную настраивать или поддерживать сервера базы данных.

Настройка холодного и горячего хранилища:
Для хранения данных используйте несколько уровней хранения. Например, данные, к которым редко обращаются, можно хранить в более дешевых решениях (холодное хранилище), таких как Google Cloud Coldline Storage или Amazon S3 Glacier. Горячие данные, к которым часто обращаются, можно хранить в Google Cloud Storage или Amazon S3 Standard.
Это помогает снизить затраты на хранение данных, не влияя на производительность работы с часто используемыми данными.

Использование Pub/Sub или SQS для асинхронной обработки:
Асинхронная обработка через очереди сообщений (например, Google Pub/Sub или AWS SQS) позволяет микросервисам взаимодействовать друг с другом без необходимости в постоянном активном подключении. Это позволяет временно приостанавливать неактивные микросервисы и запускать их только тогда, когда приходит новое сообщение.
Асинхронная архитектура снижает потребление ресурсов, так как микросервисы работают только при необходимости, а не постоянно.

Мониторинг использования и затрат:
Используйте встроенные инструменты мониторинга, такие как Google Cloud Monitoring или AWS CloudWatch, для анализа использования ресурсов и затрат. Они помогают выявить неиспользуемые или слабо загруженные ресурсы, которые можно оптимизировать или удалить.
Регулярный анализ метрик помогает оперативно выявлять неэффективные ресурсы и оптимизировать их использование.

Кеширование данных:
Для уменьшения нагрузки на базы данных и ускорения работы микросервисов внедрите систему кеширования с помощью Redis или Memcached (например, Google Cloud Memorystore или AWS ElastiCache). Это позволяет кешировать часто запрашиваемые данные и уменьшить количество обращений к базам данных.
Кеширование сокращает затраты на базы данных, снижает задержки и улучшает производительность.

Выбор резервированных инстансов:
Для сервисов, которые должны работать постоянно, рассмотрите использование резервированных инстансов в AWS или аналогичных решений в других облаках (например, Committed Use Contracts в Google Cloud). Это позволяет получить скидки до 75% по сравнению с обычными инстансами, если вы готовы зафиксировать использование инстансов на долгосрочный период (например, на один или три года).
Это существенно снижает затраты на постоянные сервисы, особенно для критически важных микросервисов.

▲К списку вопросов▲

➤ Как работают servless решения

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

Как работает Serverless:

Автоматическое управление инфраструктурой:
В serverless модели разработчик не занимается созданием и управлением серверов. Облачный провайдер (например, AWS, Google Cloud, Azure) динамически управляет серверами, масштабирует ресурсы в зависимости от нагрузки и автоматически освобождает ресурсы, когда приложение не используется.
Пример: Когда запрос поступает на серверless-функцию, провайдер автоматически выделяет необходимые вычислительные мощности и запускает функцию. Как только запрос обработан, ресурсы освобождаются.

Оплата по факту использования:
Один из главных преимуществ serverless заключается в том, что вы платите только за фактически использованное время выполнения кода и объем ресурсов. Это отличается от традиционных моделей, где вы оплачиваете выделенные сервера, независимо от того, насколько интенсивно они используются.
Пример: В случае с AWS Lambda или Google Cloud Functions вы платите за количество запросов и за время выполнения кода (например, за миллисекунды), а не за постоянно запущенные серверы.

Событийно-ориентированная архитектура:
Serverless решения часто строятся вокруг событийной архитектуры, где код (функции) выполняется в ответ на определенные события. События могут быть вызваны HTTP-запросами, изменениями в базе данных, публикацией сообщений в очереди или загрузкой файлов в облачное хранилище.
Пример: Функция может быть вызвана, когда пользователь загружает файл в хранилище (например, Amazon S3 или Google Cloud Storage), и серверless функция автоматически обрабатывает этот файл, например, сжимает его или изменяет формат.

Автоматическое масштабирование:
Serverless решения автоматически масштабируются под текущую нагрузку. Когда несколько пользователей одновременно обращаются к приложению, серверless платформа автоматически запускает дополнительные экземпляры функций, чтобы обслужить их запросы. Когда нагрузка уменьшается, ресурсы автоматически освобождаются.
Пример: Если у вас есть веб-приложение на базе Google Cloud Functions, и одновременно поступает 1000 запросов, Google Cloud автоматически создаст необходимое количество контейнеров, чтобы обработать эти запросы параллельно.

Поддержка множества языков:
Serverless платформы обычно поддерживают разные языки программирования, такие как Java, Python, JavaScript (Node.js), Go и другие. Это позволяет разработчикам выбрать наиболее подходящий язык для задачи, не ограничивая себя инфраструктурными вопросами.
Пример: AWS Lambda поддерживает Java, Python, Node.js, Go и другие языки, так что разработчики могут писать функции на языке, который им удобен.

Основные компоненты serverless:

Функции (Functions):
Куски кода, которые выполняются в ответ на события. Это основа serverless-приложений. Например, в AWS это функции Lambda, в Google Cloud — Cloud Functions, в Azure — Azure Functions.

События (Triggers):
Механизм, который вызывает выполнение функции. Это может быть HTTP-запрос, изменение данных в базе данных, сообщение в очереди или другое событие, поддерживаемое провайдером.

Сервисы (Back-end services):
Бессерверные приложения могут использовать дополнительные сервисы, такие как базы данных, очереди сообщений, системы аутентификации и другие, которые предоставляются облачным провайдером. Эти сервисы также управляются облаком и оплачиваются по мере использования.

Примеры serverless решений:

AWS Lambda:
позволяет запускать функции в ответ на такие события, как HTTP-запросы (через API Gateway), изменения в базе данных (например, Amazon DynamoDB), публикации в очередях сообщений (например, Amazon SQS), загрузки файлов (Amazon S3) и т.д. Lambda автоматически масштабируется и освобождает ресурсы по завершению выполнения функции.

Google Cloud Functions:
работает аналогично AWS Lambda и поддерживает множество типов событий: HTTP-запросы, изменения в базах данных (Cloud Firestore), публикации в Pub/Sub, загрузки файлов в Cloud Storage и т.д.

Azure Functions:
также предоставляют серверless-решения с возможностью масштабирования и поддержки различных событий, включая HTTP-запросы, изменения в Azure Cosmos DB, события в Azure Storage, публикации в очередях и многие другие.

Вот пример серверлес-функции на AWS Lambda с использованием Kotlin. Функция будет обрабатывать HTTP-запросы через API Gateway и возвращать простое сообщение, аналогично примеру на JavaScript.

import com.amazonaws.services.lambda.runtime.Context
import com.amazonaws.services.lambda.runtime.RequestHandler
import com.amazonaws.services.lambda.runtime.events.APIGatewayProxyRequestEvent
import com.amazonaws.services.lambda.runtime.events.APIGatewayProxyResponseEvent


class LambdaHandler : RequestHandler<APIGatewayProxyRequestEvent, APIGatewayProxyResponseEvent> {

  
    override fun handleRequest(
        input: APIGatewayProxyRequestEvent,
        context: Context
    ): APIGatewayProxyResponseEvent {
        // Получаем параметр "name" из запроса
        val name = input.queryStringParameters?.get("name") ?: "World"
        val responseMessage = "Hello, $name!"
        // Формируем ответ
        val response = APIGatewayProxyResponseEvent()
        response.statusCode = 200
        response.headers = mapOf("Content-Type" to "application/json")
        response.body = """{"message": "$responseMessage"}"""
        return response
    }
    
}

Описание:

LambdaHandler:
это основной класс, который реализует интерфейс RequestHandler для обработки запросов.

APIGatewayProxyRequestEvent:
объект, содержащий входные данные HTTP-запроса, такие как параметры запроса, тело и заголовки.

handleRequest:
метод, который обрабатывает входящий запрос. Он извлекает параметр name из строки запроса и возвращает приветственное сообщение.

APIGatewayProxyResponseEvent:
объект, который возвращает ответ с HTTP-статусом, заголовками и телом ответа в формате JSON.

Деплой в AWS Lambda:
Напишите и скомпилируйте Kotlin код (используйте Gradle для сборки в .jar файл).
В AWS Lambda создайте новую функцию и загрузите скомпилированный .jar.
Настройте API Gateway для вызова функции через HTTP.

Достоинства serverless решений:

Минимальные затраты на управление инфраструктурой: Нет необходимости управлять серверами или их конфигурациями.
Оплата по факту использования: Вы платите только за время выполнения кода и за использованные ресурсы.
Автоматическое масштабирование: Serverless приложения автоматически подстраиваются под нагрузку.
Быстрая разработка и запуск: Разработчики могут сосредоточиться на написании кода, а не на настройке серверов.

Недостатки serverless решений:

Ограничения по времени выполнения: У serverless функций обычно есть ограничения на время выполнения (например, в AWS Lambda — 15 минут).
Задержка холодного старта: Иногда первая инициализация функции может занять больше времени, чем последующие вызовы (так называемый «cold start»).
Ограниченная гибкость: Serverless платформы ограничены возможностями и конфигурациями, предлагаемыми облачными провайдерами. Некоторые приложения могут нуждаться в специфической настройке, недоступной в serverless моделях.
Vendor lock-in: Зависимость от конкретного облачного провайдера и его сервисов может усложнить перенос приложения на другую платформу.

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

▲К списку вопросов▲

➤ Как работает Git LFS (Large File Storage)

Обычный git плохо справляется с очень большими файлами (например .bin, .so, .ckpt, .pt, .jpg, .zip больше 100MB).

Git LFS решает эту проблему так:

Что происходит:
Когда ты добавляешь в репозиторий большой файл (например model.bin), Git LFS вместо самого файла сохраняет только маленький «плейсхолдер» — текстовый файл с указанием, где найти реальный файл.
Реальный файл отправляется отдельно в специальное облачное хранилище GitHub LFS.
Когда другой человек клонирует репозиторий, git lfs автоматически скачает большие файлы отдельно.

Установить Git LFS:

git lfs install

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

git lfs track "*.bin"

Как правильно скачать проект с LFS-файлами, если они не загрузились:

При обычном клонировании:
маленькие файлы сразу загрузятся
вместо больших файлов сначала скачаются «ссылки-заглушки» (типа текстов типа oid sha256:)

Если после клона LFS-файлы не загрузились автоматически (например, иногда бывает в старых версиях Git), нужно сделать:

git lfs pull

▲К списку вопросов▲

➤ Как работать с субмобулями Git

Субмодули Git — это механизм, который позволяет в репозитории подключать другие репозитории как подпроекты. Они очень полезны, например, когда проект зависит от других библиотек, которые развиваются отдельно.

Что важно помнить:
Субмодуль привязан к конкретному коммиту подключённого репозитория, а не к последнему состоянию ветки.
Если меняешь что-то внутри субмодуля — нужно заходить в папку субмодуля, делать там git commit, пушить отдельно.

Добавить субмодуль:
Это создаст папку libs/library и склонирует туда внешний репозиторий.
Появится файл .gitmodules — в нём Git хранит информацию о субмодулях.

git submodule add <URL репозитория> <путь_куда_клонировать>

Клонировать проект с субмодулями:
Когда кланируется проект, содержащий субмодули, они по умолчанию не подтягиваются! Нужно:

git clone <URL репозитория>
git submodule update --init --recursive

// или

git clone --recurse-submodules <URL репозитория>

Обновить субмодули:
Если в подключённом проекте появились изменения

git submodule update --remote --merge

// или для конкретного субмодуля

cd путь/к/субмодулю
git fetch
git merge origin/main

▲К списку вопросов▲

Copyright: Roman Kryvolapov