---
title: "Java Spring – Cloud"
url: "https://romankryvolapov.com/bg/java-spring-cloud/"
description: "Облачните услуги на AWS, Google Cloud и Azure за Java приложения: съответствия между аналозите, оптимизация на разходите, serverless, Git LFS и субмодули."
language: bg
published: 2024-08-13
updated: 2026-11-13
---
## Кои са основните облачни решения за Java разработка и техните аналози за обикновена инфраструктура

|   |   |   |   |
| --- | --- | --- | --- |
| **Amazon Web Services** | **Google Cloud** | **Microsoft Azure** | **Аналог без облак** |
| EC2 (Elastic Compute Cloud) | Google Compute Engine (GCE) | Azure Virtual Machines (VMs) | VMware, KVM, VirtualBox |
| EKS/ECS (Kubernetes/Containers) | Google Kubernetes Engine (GKE) | Azure Kubernetes Service (AKS) | Kubernetes на локален сървър |
| API Gateway | Google Cloud Endpoints | Azure API Management | Kong, NGINX, Apache |
| AWS Lambda | Google Cloud Functions | Azure Functions | Serverless Framework (за локално стартиране) |
| Amazon RDS | Google Cloud SQL | Azure SQL Database | PostgreSQL, MySQL на локален сървър |
| Amazon DynamoDB | Google Cloud Firestore / Bigtable | Azure Cosmos DB | MongoDB, CouchDB, Cassandra |
| Amazon SQS | Google Cloud Pub/Sub | Azure Queue Storage | RabbitMQ, Apache Kafka, ActiveMQ |
| Amazon SNS | Google Cloud Pub/Sub | Azure Notification Hubs | RabbitMQ с push известия, имейл услуги |
| Elastic Load Balancing (ELB) | Google Cloud Load Balancing | Azure Load Balancer | HAProxy, NGINX |
| IAM (Identity and Access Management) | Google Cloud IAM | Azure Active Directory (AD) | FreeIPA, OpenLDAP, Kerberos |
| CloudWatch | Google Cloud Operations (Stackdriver) | Azure Monitor | Prometheus, Grafana, ELK Stack |
| Amazon S3 | Google Cloud Storage | Azure Blob Storage | MinIO, Ceph, FTP сървъри |
| AWS Step Functions | Google Cloud Workflows | Azure Logic Apps | Apache Airflow, Cadence, Conductor |
| Secrets Manager | Google Secret Manager | Azure Key Vault | HashiCorp Vault, KeePass |
| Amazon Aurora | Google Cloud Spanner | Azure SQL Database Managed Instance | PostgreSQL, MySQL с репликация |

## Кои са основните облачни решения от Amazon за Java разработка

**Amazon EC2 (Elastic Compute Cloud):**\
Предоставя мащабируеми виртуални сървъри за стартиране на приложения. EC2 ви позволява да създавате и управлявате екземпляри на виртуални машини (инстанции), върху които можете да внедрявате свои приложения, като микроуслуги, уеб сървъри, бази данни и други компоненти.

**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 известия, имейли или 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.

## Как може да се оптимизира облачно решение от гледна точка на разходите

**Използване на 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% в сравнение с обикновените инстанции, ако сте готови да фиксирате използването на инстанциите за дълъг период (например за една или три години).\
Това съществено намалява разходите за постоянните услуги, особено за критично важните микроуслуги.

## Как работят serverless решенията

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

**Как работи Serverless:**

**Автоматично управление на инфраструктурата:**\
В serverless модела разработчикът не се занимава със създаването и управлението на сървъри. Облачният доставчик (например AWS, Google Cloud, Azure) динамично управлява сървърите, мащабира ресурсите в зависимост от натоварването и автоматично освобождава ресурсите, когато приложението не се използва.\
**Пример:** Когато към serverless функция постъпи заявка, доставчикът автоматично отделя необходимата изчислителна мощност и стартира функцията. Щом заявката бъде обработена, ресурсите се освобождават.

**Плащане според реалното използване:**\
Едно от главните предимства на serverless е, че плащате само за реално използваното време за изпълнение на кода и обема ресурси. Това се различава от традиционните модели, при които плащате за заделени сървъри, независимо колко интензивно се използват.\
**Пример:** При AWS Lambda или Google Cloud Functions плащате за броя заявки и за времето за изпълнение на кода (например в милисекунди), а не за постоянно работещи сървъри.

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

**Автоматично мащабиране:**\
Serverless решенията се мащабират автоматично според текущото натоварване. Когато няколко потребители се обръщат към приложението едновременно, serverless платформата автоматично стартира допълнителни екземпляри на функциите, за да обслужи заявките им. Когато натоварването намалее, ресурсите се освобождават автоматично.\
**Пример:** Ако имате уеб приложение на базата на 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:**\
също предоставят serverless решения с възможност за мащабиране и поддръжка на различни събития, включително HTTP заявки, промени в Azure Cosmos DB, събития в Azure Storage, публикации в опашки и много други.

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

```kotlin
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:**

```bash
git lfs install
```

**Настройване на проследяването на големи файлове:**\
След това автоматично се създава файлът .gitattributes, в който се записват правилата за проследяване.

```bash
git lfs track "*.bin"
```

**Как правилно да изтеглите проект с LFS файлове, ако те не са се заредили:**

**При обикновено клониране:**\
малките файлове ще се заредят веднага\
вместо големите файлове първо ще се изтеглят „връзки-заместители“ (нещо като текстове от вида oid sha256:)

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

```bash
git lfs pull
```

## Как се работи със субмодулите на Git

Субмодулите на Git са механизъм, който позволява в хранилище да се включват други хранилища като подпроекти. Те са много полезни, например когато проектът зависи от други библиотеки, които се развиват отделно.

**Какво е важно да помним:**\
Субмодулът е привързан към конкретен комит на включеното хранилище, а не към последното състояние на клона.\
Ако променяш нещо вътре в субмодула – трябва да влезеш в папката на субмодула, да направиш там git commit и да го публикуваш (push) отделно.

**Добавяне на субмодул:**\
Това ще създаде папката libs/library и ще клонира в нея външното хранилище.\
Ще се появи файлът .gitmodules – в него Git съхранява информацията за субмодулите.

```bash
git submodule add <URL на хранилището> <път_къде_да_се_клонира>
```

**Клониране на проект със субмодули:**\
Когато се клонира проект, съдържащ субмодули, те по подразбиране не се изтеглят! Трябва:

```bash
git clone <URL на хранилището>
git submodule update --init --recursive

# или

git clone --recurse-submodules <URL на хранилището>
```

**Обновяване на субмодулите:**\
Ако във включения проект са се появили промени

```bash
git submodule update --remote --merge

# или за конкретен субмодул

cd път/към/субмодула
git fetch
git merge origin/main
```

[ Copyright: Roman Kryvolapov ](https://t.me/RomanKryvolapov)