Lucrez în outsourcing, unde principiul principal poate fi descris prin sintagma „vinde mult, fă-o repede”. Cu cât o facem mai repede, cu atât vom câștiga mai mult. Și, este de dorit ca totul să funcționeze nu pe cârje și muci, ci cu un nivel acceptabil de calitate. Vă voi povesti despre experiența mea când a fost necesară dezvoltarea unui serviciu promoțional într-o perioadă scurtă de timp.
Dat: cont root pe AWS, fără restricții privind alegerea stivei de tehnologie, un backend și o lună pentru dezvoltare.
obiectiv: implementați un serviciu promoțional în care utilizatorii încarcă de la unu până la patru videoclipuri cu o durată de la una până la patru secunde, care sunt apoi încorporate în seria video originală.
decizie
Să-ți scrii propriul serviciu de biciclete într-un timp atât de scurt nu este o idee bună. În plus, pentru ca serviciul să facă față sarcinii și pentru ca toată lumea să primească râvnitul videoclip, va fi necesară infrastructură. Și de preferat nu cu prețul din avion. Prin urmare, ne concentrăm imediat pe soluții gata făcute cu personalizare minimă.
Soluția standard pentru lucrul cu video este FFmpeg, un utilitar de consolă multiplatformă care, prin argumente, vă permite să tăiați și să supraîncărcați audio. Tot ce mai rămâne de făcut este să scrieți un înveliș și să îl eliberați în viață. Scriem un prototip care unește două videoclipuri împreună și... începe distracția. Biblioteca se bazează pe .NET Core 2, ar trebui să ruleze pe orice mașină virtuală, așa că luăm o instanță AWS EC2 și totul va funcționa
Text ascunsnu, nu va funcționa
.
Deși FFmpeg simplifică sarcina, pentru o soluție cu adevărat funcțională trebuie să creați o instanță EC2 și să proiectați o infrastructură de rețea pentru aceasta, inclusiv un Load Balancer. Sarcina simplă de implementare de la zero devine „puțin” mai complicată, iar infrastructura începe să ceară bani imediat - în fiecare oră suma pentru timpul de execuție este retrasă din contul clientului.
Serviciul nostru nu implică procese de lungă durată, nu necesită o bază de date relațională mare și voluminoasă și se potrivește perfect într-o arhitectură bazată pe evenimente cu un lanț de apeluri de microservicii. Soluția sugerează de la sine - putem abandona EC2 și putem implementa o aplicație adevărată fără server, cum ar fi Image Resizer standard bazat pe AWS Lambda.
Apropo, în ciuda antipatiei evidente ale dezvoltatorilor AWS pentru .NET, aceștia acceptă .NET Core 2.1 ca timp de execuție, care oferă o gamă completă de oportunități de dezvoltare.
Și cireasa de pe tort - AWS oferă un serviciu separat pentru lucrul cu fișiere video - AWS Elemental MediaConvert.
Esența muncii este incredibil de simplă: luăm un link S3 către videoclipul de ieșire, scriem prin AWS Console, .NET SDK sau pur și simplu JSON ceea ce vrem să facem cu videoclipul și apelăm la serviciu. El însuși implementează cozi pentru procesarea cererilor primite, încarcă rezultatul în S3 și, cel mai important, generează un eveniment CloudWatch pentru fiecare schimbare de stare. Acest lucru ne permite să implementăm declanșatoare lambda pentru a finaliza procesarea video.
Iată cum arată arhitectura finală:
Întregul backend este găzduit în două lambda. Un altul este pentru rotirea videoclipurilor verticale, deoarece o astfel de muncă nu poate fi realizată într-o singură trecere.
Vom plasa partea frontală sub forma unei aplicații SPA scrisă în JS și compilată prin pug într-o găleată S3 publică. Pentru a descărca videoclipurile în sine, nu avem nevoie de niciun cod de server - trebuie doar să deschidem punctele finale REST pe care ni le oferă S3. Singurul lucru este să nu uitați să configurați politicile și CORS.
Capcane
- AWS MediaConvert, dintr-un motiv necunoscut, aplică doar sunetul fiecărui fragment video separat, dar avem nevoie de o melodie veselă din întregul screensaver.
- Videoclipurile verticale trebuie procesate separat. AWS nu-i plac barele negre și pune rolele la 90°.
Patinoar ușor
În ciuda întregii frumusețe a Statess, trebuie să urmăriți ceea ce trebuie făcut cu videoclipul: lipiți sau adăugați sunet la secvența video finală. Din fericire, MediaConvert acceptă trecerea metadatelor prin Joburile sale și putem folosi oricând un steag simplu de forma „isMasterSoundJob”, analizând aceste metadate în orice etapă.
Serverless permite perfect lucrul cu NoOps - o abordare care presupune inutilitatea unei echipe separate responsabile de infrastructura proiectului. Prin urmare, a fost o problemă mică - implementăm soluția pe AWS fără participarea administratorilor de sistem, care oricum au întotdeauna ceva de făcut.
Și pentru a accelera toate acestea, automatizăm cât mai mult posibil scriptul de implementare pe AWS CloudFormation, care vă permite să implementați cu un singur buton direct din VS. Drept urmare, un fișier de 200 de linii de cod vă permite să lansați o soluție gata făcută, deși sintaxa CloudFormation poate fi șocantă dacă nu sunteți obișnuit cu aceasta.
În total
Serverless nu este un panaceu. Dar va face viața mult mai ușoară în situații cu trei limite: „resurse limitate – pe termen scurt – bani puțini”.
Caracteristicile aplicațiilor potrivite pentru serverless
- fără procese de lungă durată. Limita API Gateway este de 29 de secunde, limita lambda este de 5 minute;
- descris de arhitectura Event-Driven;
- se descompune în componente slab cuplate, cum ar fi SOA;
- nu necesită multă muncă cu starea dumneavoastră;
- scris în .NET Core. Pentru a lucra cu .NET Framework, veți avea nevoie de cel puțin Docker cu timpul de execuție corespunzător.
Beneficiile abordării Serverless
- reduce costurile de infrastructură;
- reduce costul livrării soluției;
- scalabilitate automată;
- dezvoltare la vârful progresului tehnologic.
Dezavantaje, cu un exemplu concret
- Urmărirea și înregistrarea distribuite - rezolvate parțial prin AWS X-Ray și AWS CloudWatch;
- depanare incomodă;
- Pornire la rece când nu există încărcătură;
- Interfața AWS ostilă pentru utilizator este o problemă universală :)
Sursa: www.habr.com