Java Spring — Cloud

Які існують основні хмарні рішення для 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