ABONAMENTE VIDEO REDACȚIA
RO
EN
NOU
Numărul 148
Numărul 147 Numărul 146 Numărul 145 Numărul 144 Numărul 143 Numărul 142 Numărul 141 Numărul 140 Numărul 139 Numărul 138 Numărul 137 Numărul 136 Numărul 135 Numărul 134 Numărul 133 Numărul 132 Numărul 131 Numărul 130 Numărul 129 Numărul 128 Numărul 127 Numărul 126 Numărul 125 Numărul 124 Numărul 123 Numărul 122 Numărul 121 Numărul 120 Numărul 119 Numărul 118 Numărul 117 Numărul 116 Numărul 115 Numărul 114 Numărul 113 Numărul 112 Numărul 111 Numărul 110 Numărul 109 Numărul 108 Numărul 107 Numărul 106 Numărul 105 Numărul 104 Numărul 103 Numărul 102 Numărul 101 Numărul 100 Numărul 99 Numărul 98 Numărul 97 Numărul 96 Numărul 95 Numărul 94 Numărul 93 Numărul 92 Numărul 91 Numărul 90 Numărul 89 Numărul 88 Numărul 87 Numărul 86 Numărul 85 Numărul 84 Numărul 83 Numărul 82 Numărul 81 Numărul 80 Numărul 79 Numărul 78 Numărul 77 Numărul 76 Numărul 75 Numărul 74 Numărul 73 Numărul 72 Numărul 71 Numărul 70 Numărul 69 Numărul 68 Numărul 67 Numărul 66 Numărul 65 Numărul 64 Numărul 63 Numărul 62 Numărul 61 Numărul 60 Numărul 59 Numărul 58 Numărul 57 Numărul 56 Numărul 55 Numărul 54 Numărul 53 Numărul 52 Numărul 51 Numărul 50 Numărul 49 Numărul 48 Numărul 47 Numărul 46 Numărul 45 Numărul 44 Numărul 43 Numărul 42 Numărul 41 Numărul 40 Numărul 39 Numărul 38 Numărul 37 Numărul 36 Numărul 35 Numărul 34 Numărul 33 Numărul 32 Numărul 31 Numărul 30 Numărul 29 Numărul 28 Numărul 27 Numărul 26 Numărul 25 Numărul 24 Numărul 23 Numărul 22 Numărul 21 Numărul 20 Numărul 19 Numărul 18 Numărul 17 Numărul 16 Numărul 15 Numărul 14 Numărul 13 Numărul 12 Numărul 11 Numărul 10 Numărul 9 Numărul 8 Numărul 7 Numărul 6 Numărul 5 Numărul 4 Numărul 3 Numărul 2 Numărul 1
×
▼ LISTĂ EDIȚII ▼
Numărul 56
Abonament PDF

Serverless computing folosind Azure Functions

Denis Salanța
Development Manager @ VE Interactive



PROGRAMARE


Chiar de la începuturile industriei software, aplicațiile dezvoltate trebuiau să fie găzduite undeva pentru a putea fi executate.

Aplicațiile business erau găzduite pe un server, unde funcționau atât timp cât era nevoie de ele.

Pentru a face mentenanța și a oferi suport tehnic acestor servere, au fost create departamente noi, facilitând funcționarea lor într-un mod optim. Serverele trebuie funcționeze neîntrerupt, iar în cazul în care se identifică o problemă în operarea lor, să fie pregătit un plan de backup prin care aplicațiile să continue a fi executate așa încât activitatea de business să nu fie afectată.

Cu timpul, capacitățile fizice ale serverelor care găzduiau aplicațiile s-au îmbunătățit considerabil, concomitent cu dezvoltarea tehnologiilor de virtualizare care deveneau tot mai performante, ajungând astfel la posibilitatea rulării mai multor sisteme de operare guest (denumite și mașini virtuale) pe același server.

Astfel, odată cu creșterea numărului de mașini virtuale folosite, s-a mărit și costul operațional al hardware-ului gazdă și al sistemelor de operare oaspete: găzduirea, întreținerea și actualizarea.

Aceasta a fost perioada serverelor găzduite pe hardware în incinta companiei (on-premise) sau în colocație cu alte servere gestionate de un furnizor de servicii de găzduire, unde aplicațiile și serviciile trebuiau să funcționeze cât timp era nevoie de ele.

În ultima perioadă, odată cu rapida creștere a diferitelor businessuri, nevoie de scalare a aplicațiilor și serviciilor a devenit tot mai stringentă.

Corelat cu dezvoltarea afacerilor, se măresc și costurile de achiziție si întreținere a serverelor găzduite local.

În acest context, infrastructura bazată pe cloud s-a dovedit a fi calea de înaintare. Companii precum Amazon prin serviciul Amazon WebServices, Microsoft prin tehnologia Azure sau Google prin Compute Engine, au construit centre de date în preajma punctelor importante ale globului, oferind astfel posibilitatea businessurilor să își execute aplicațiile la o scară nemaivăzută. Majoritatea companiilor în ziua de azi, realizează efortul de migrare către o platformă ce oferă servicii IaaS (infrastructură ca serviciu).

Atunci când e nevoie sau se dorește, pornirea serverelor realizată de infrastructura cloud ajută businessul în a depăși limitările de găzduire în servere locale ale furnizorilor de servicii.

Următorul nivel de abstractizare a tehnologiei de găzduire a severelor este platforma ca serviciu (PaaS - platform as a service). Pentru a ajuta businessurile în a nu fi ocupate cu actualizări de sisteme de operare sau de infrastructură, pe piață au apărut furnizori de servicii PaaS.

Există numeroase variante de servicii PaaS, cum ar fi baze de date, autentificare sau chiar aplicații oferite ca un serviciu. În cadrul acestor platforme, ți se oferă posibilitatea configurării unor variabile precum opțiunile de scalare și conectarea către terțe dependențe așa încât printr-o simplă configurare businessul să dețină anumite beneficii care ar fi costat săptămâni de dezvoltare pentru a fi implementate și lansate în producție.

Cu toate acestea, pentru a lansa un nou serviciu web, luând ca exemplu un endpoint HTTP, ar trebui ca respectiva aplicație să fie scrisă într-un mediu de dezvoltare local, apoi să se efectueze pașii necesari pentru a pregăti codul de a fi executat într-un mediu de producție. Toate acestea, fără a uita de implementarea mecanismelor de dirijare a cererilor, a autentificării sau a autorizării cererilor către endpointul dorit a fi expus.

În alți termeni, oare nu ar fi mai bine ca o companie să fie interesată de scrierea logicii care deservește funcționarea businessului?

Aici e momentul în care intervine serverless, care nu ține doar de abstractizarea serverelor pe care rulează codul, deoarece lucrul acesta este acoperit deja de serviciile PaaS. Lucrul pe care serverless îl aduce în plus e, eliminarea noțiunii de server de aplicații, cum ar fi: Apache, nginx sau IIS.

Astfel, codul care descrie logica dorită de business și care reacționează la diferite evenimente cum ar fi inserarea unui rând nou într-o tabelă sau a unui mesaj nou într-o coadă sau un rând nou într-un fișier Excel, poate fi scris într-o manieră cu adevărat serverless.

Ce este Serverless?

Termenul serverless este un termen impropriu, deoarece nu poți avea o aplicație serverless fără a fi până la urmă găzduită pe un server.

Fiind un termen nou inventat, voi folosi o definiție enunțată de Martin Fowler, în care el definește arhitectura serverless ca fiind:

[..] aplicații care depind în mod deosebit de servicii oferite de terți (supranumite si Backed as a Service sau "BaaS") sau depind de un cod sursă care este executat în containere temporare (Function as a Service or "FaaS")

Se pot identifica două tipuri de arhitecturi serverless:

BaaS - Aceasta a fost prima aplicare a termenului de arhitectură serverless, înțelegând aplicații complexe care se conectează la baze de date accesibile prin internet, precum Parse, Auth0.

FaaS - Execuția logicii aplicației, fără a avea grija configurării sau administrării unor servere de găzduire sau a serverelor de aplicații, pe containere stateless și invocarea pe bază de evenimente. Amazon oferă servicii FaaS prin AWS Lambda, Microsoft prin Azure Functions și Google prin Cloud Functions.

Cum se diferențiază o arhitectură tradițională față de o arhitectură serverless?

O aplicație client tradițională bazată pe trei nivele, arată de obicei în felul următor:

În imaginea de deasupra observăm o aplicație web tipică, monolit.

O abordare serverless ar arăta în felul următor, dacă am dori să rescriem aplicația monolit descrisă anterior:

  1. Serviciul de autentificare e acum delegat unei terțe părți, el putând fi oferit sub forma unei platforme BaaS.
  2. Pentru stocarea produselor, se poate utiliza un alt furnizor de servicii BaaS.
  3. Componente ale logicii de business care există într-o arhitectură tradițională pe partea de server, pot fi acum delegate clientului, respectiv browserului: managementul sesiunilor, navigarea între pagini sau procesarea unor date returnate dintr-o bază de date și afișarea lor pe ecran.
  4. Parte din funcționalitate va continua a fi deservită pe partea de server, cum ar fi procesarea unor calcule intensive sau a unui set mare de date. Funcția de căutare ar putea fi accesată printr-un Portal de API-uri, prin cereri bazate pe HTTP. Se poate reutiliza codul sursă originar aplicației monolit în momentul în care mutăm codul către furnizorii de servicii FaaS Azure Functions sau AWS Lambda, deoarece oferă un număr larg de limbaje de programare pe care le pot executa, cum ar fi .NET, Java sau Python.
  5. Funcționalitatea de cumpărare poate fi înlocuită cu o altă funcție FaaS expusă prin Portalul de API-uri.

Având această privire de ansamblu asupra arhitecturii serverless, putem să luăm ca exemplu practic, Azure Functions, serviciul FaaS oferit de Microsoft și să vedem cât de rapid poate fi folosit.

Azure Functions

Azure Functions este o soluție care permite într-un mod foarte facil executarea unor bucăți de cod de mici dimensiuni ("funcții") în internet. Poți scrie codul care rezolvă o anumită problemă de business, fără a te îngrijora de detaliile legate de infrastructura pe care se va executa. Codul sursă poate fi scris într-o varietate de limbaje de programare, cum ar fi: C#, F#, Nodejs, Python sau PHP.

Caracteristici

Acestea ar fi principalele beneficii ale Azure Functions:

Scenarii obișnuite în care poate fi utilizat Azure Functions

  1. Procesare dependentă de timp - executarea unei funcții de ștergere sau procesarea de taskuri după un anumit orar.

  2. Serviciile Azure de procesare a evenimentelor - reacționarea la evenimente transmise către Azure Event Hub. Folosit cu precădere în aplicații de instrumentare a evenimentelor, a prelucrării fluxurilor de lucru sau în scenarii de Internet of Things (IoT).

  3. Procesarea evenimentelor provenite din SaaSuri - Azure Functions oferă posibilitatea integrării mecanismelor de declanșare bazate pe evenimente ce au loc într-o alta platformă de tip SaaS, cum ar fi un nou fișier salvat în OneDrive ca declanșator al funcției.

  4. Aplicații web bazate pe arhitectura serverless - Azure Functions poate fi motorul unei aplicații web de tip single page application (SPA).

  5. Backend pentru aplicații mobile - o aplicație pe un dispozitiv mobil ar putea captura o imagine care mai apoi ar putea apela o funcție Azure pentru a putea încărca imaginea într-un blob storage. O a doua funcție Azure ar putea fi declanșată de acea încărcare așa încât să redimensioneze imaginea la valori care să fie potrivite cu dispozitivele mobile.

  6. Procesare în timp real - de exemplu, dispozitive IoT ar putea transmite mesaje către Azure Stream Analytics, care mai apoi să apeleze o funcție Azure, pentru a procesa mesajul respectiv.

  7. Mesagerie în timp real realizată programatic - Integrarea Bot Framework cu o funcție Azure pentru a procesa un mesaj provenit de la Cortana Analytics.

Limbaje de programare suportate care pot fi folosite pentru a scrie funcții Azure:

Mecanisme de declanșare

(* - Răspunsul de tip HTTP este declanșat de o cerere HTTP)

Preț

Prețuri efective începând cu 1 Ianuarie, 2017

\Subvențiile gratuite se aplică doar abonamentelor plătite.*

Care este tehnologia care stă la baza Azure Functions?

Azure Functions sunt construite pe baza App Service.

Creează prima ta funcție Azure

Pentru început, navighează la adresa functions.azure.com și autentifică-te pentru a accesa o subscripție gratis sau apasă pe butonul verde "Try It For Free".

Selectează Timer ca scenariu, JavaScript pentru limbajul de programare și selectează butonul Create this function.

Alege apoi un furnizor de servicii de autentificare.

După ce te vei autentifica, în scurt timp vei fi întâmpinat de editorul care îți va permite să scrii codul sursă al funcției.

În meniul din stânga, Integration, poți accesa punctele de integrare cum ar fi orarul cron pentru funcțiile declanșate la un anumit interval orar sau detaliile de conectare la containerele Blob Storage. În secțiunea Manage sunt disponibile cheile de autentificare precum și valorile de mediu specifice funcției. Pentru a vedea metricele rezultate în urma execuției funcției, se poate accesa ecranul Monitor din meniu.

În secțiunea Function app settings se pot gestiona setări cum ar fi CORS și metadatele SWAGGER, pentru funcții declanșate de cereri HTTP - care se comportă precum APIuri. Tot în acest meniu, se realizează conectarea la servere centralizate de gestionare a codului sursă (GitHub, VSTS, etc.) precum și configurarea unui proces de deployment continuu.

Mergând înapoi în meniul develop, se poate inspecta structura fișierelor prin View Files, din meniul de sus.

În mod obișnuit, o funcție Azure scrisă în limbajul JavaScript are următoarea structură:

După ce apeși Run funcția este executată, iar în cadrul ferestrei log poți observa rezultatul.

Concluzie

Conceptul de arhitectură serverless este încă într-o fază incipientă. E fascinant de urmărit companii precum Amazon, Microsoft, Google sau altele, în modul în care vor continua să aducă inovație în acest domeniu. În același timp, o mare provocare ne este lansată și nouă, programatorilor, și anume: cum putem adăuga arhitectura serverless în opțiunile disponibile rezolvării problemelor ridicate de business.

În aceeaşi ediţie ... (56)

▼ TOATE ARTICOLELE ▼

Conferință TSM

NUMĂRUL 147 - Automotive

Sponsori

  • Accenture
  • BT Code Crafters
  • Accesa
  • Bosch
  • Betfair
  • MHP
  • BoatyardX
  • .msg systems
  • P3 group
  • Ing Hubs
  • Cognizant Softvision
  • Colors in projects