Lavoro in outsourcing, dove il principio fondamentale può essere descritto con la frase “vendi molto, fallo velocemente”. Più velocemente lo faremo, più guadagneremo. Ed è auspicabile che tutto funzioni non con stampelle e moccio, ma con un livello di qualità accettabile. Ti racconterò la mia esperienza quando è stato necessario sviluppare un servizio promozionale in un breve periodo di tempo.
data: account root su AWS, nessuna restrizione sulla scelta dello stack tecnologico, un backend e un mese per lo sviluppo.
obiettivo: implementare un servizio promozionale in cui gli utenti caricano da uno a quattro video della durata da uno a quattro secondi, che vengono poi incorporati nella serie di video originali.
Soluzione
Scrivere il proprio servizio di bicicletta in così poco tempo non è una buona idea. Inoltre, affinché il servizio possa far fronte al carico e affinché tutti possano ricevere l'ambito video, sarà necessaria un'infrastruttura. E preferibilmente non con il prezzo dell'aereo. Pertanto, ci concentriamo immediatamente su soluzioni già pronte con una personalizzazione minima.
La soluzione standard per lavorare con i video è FFmpeg, un'utilità console multipiattaforma che, tramite argomenti, consente di tagliare e sovraincidere l'audio. Tutto ciò che resta da fare è scrivere un involucro e rilasciarlo nella vita. Scriviamo un prototipo che unisce due video insieme e... inizia il divertimento. La libreria è basata su .NET Core 2, dovrebbe funzionare su qualsiasi macchina virtuale, quindi prendiamo un'istanza AWS EC2 e tutto funzionerà
Testo nascostono, non funzionerà
.
Sebbene FFmpeg semplifichi l'attività, per una soluzione realmente funzionante è necessario creare un'istanza EC2 e progettare un'infrastruttura di rete per essa, incluso un bilanciatore di carico. Il semplice compito di implementare da zero diventa "un po'" più complicato e l'infrastruttura inizia immediatamente a richiedere denaro: ogni ora l'importo per il tempo di esecuzione viene prelevato dall'account del cliente.
Il nostro servizio non prevede processi Long-Running, non richiede un database relazionale grande e grasso, e si inserisce perfettamente in un'architettura event-based con una catena di chiamate a microservizi. La soluzione suggerisce se stessa: possiamo abbandonare EC2 e implementare un'applicazione true-serverless, come il Image Resizer standard basato su AWS Lambda.
A proposito, nonostante l'ovvia antipatia degli sviluppatori AWS per .NET, supportano .NET Core 2.1 come runtime, il che offre una gamma completa di opportunità di sviluppo.
E la ciliegina sulla torta: AWS fornisce un servizio separato per lavorare con file video: AWS Elemental MediaConvert.
L'essenza del lavoro è incredibilmente semplice: prendiamo un collegamento S3 al video in uscita, scriviamo tramite AWS Console, .NET SDK o semplicemente JSON cosa vogliamo fare con il video e chiamiamo il servizio. Esso stesso implementa le code per l'elaborazione delle richieste in entrata, carica il risultato su S3 stesso e, soprattutto, genera un evento CloudWatch per ogni modifica di stato. Ciò ci consente di implementare trigger lambda per completare l'elaborazione video.
Ecco come appare l'architettura finale:
L'intero backend è ospitato in due lambda. Un altro è per la rotazione dei video verticali, poiché tale lavoro non può essere eseguito in un unico passaggio.
Posizioneremo il front sotto forma di applicazione SPA scritta in JS e compilata tramite pug in un bucket S3 pubblico. Per scaricare i video stessi, non abbiamo bisogno di alcun codice server: dobbiamo solo aprire gli endpoint REST forniti da S3. L'unica cosa è non dimenticare di configurare policy e CORS.
Insidie
- AWS MediaConvert, per qualche motivo sconosciuto, applica l'audio solo a ciascun frammento video separatamente, ma abbiamo bisogno di una canzone allegra dall'intero salvaschermo.
- I video verticali devono essere elaborati separatamente. AWS non ama le barre nere e mette i rulli a 90°.
Pista di pattinaggio facile
Nonostante tutta la bellezza di Stateless, devi tenere traccia di ciò che deve essere fatto con il video: incollare o aggiungere audio alla sequenza video finita. Fortunatamente, MediaConvert supporta il passaggio di metadati attraverso i suoi lavori e possiamo sempre utilizzare un semplice flag del modulo "isMasterSoundJob", analizzando questi metadati in qualsiasi fase.
Serverless consente perfettamente di lavorare con NoOps, un approccio che presuppone l'inutilità di un team separato responsabile dell'infrastruttura del progetto. Pertanto è stata una cosa da poco: distribuiamo la soluzione su AWS senza la partecipazione degli amministratori di sistema, che comunque hanno sempre qualcosa da fare.
E per accelerare tutto questo, automatizziamo il più possibile lo script di distribuzione su AWS CloudFormation, che ti consente di eseguire la distribuzione con un solo pulsante direttamente da VS. Di conseguenza, un file di 200 righe di codice ti consente di implementare una soluzione già pronta, anche se la sintassi di CloudFormation può essere scioccante se non sei abituato ad essa.
In totale
Il serverless non è una panacea. Ma renderà la vita molto più semplice in situazioni con tre limiti: “risorse limitate – a breve termine – pochi soldi”.
Caratteristiche delle applicazioni adatte per Serverless
- senza processi di lunga durata. Il limite rigido di API Gateway è 29 secondi, il limite rigido lambda è di 5 minuti;
- descritto dall'architettura Event-Driven;
- si scompone in componenti liberamente accoppiati come la SOA;
- non richiede molto lavoro con la tua condizione;
- scritto in .NET Core. Per lavorare con .NET Framework, avrai comunque bisogno almeno di Docker con il runtime appropriato.
Vantaggi dell'approccio Serverless
- riduce i costi delle infrastrutture;
- riduce il costo di fornitura della soluzione;
- scalabilità automatica;
- sviluppo all’avanguardia del progresso tecnologico.
Svantaggi, con un esempio specifico
- Tracciamento e registrazione distribuiti: parzialmente risolti tramite AWS X-Ray e AWS CloudWatch;
- debug scomodo;
- Avvio a freddo quando non c'è carico;
- L'interfaccia utente ostile di AWS è un problema universale :)
Fonte: habr.com