Zhvillimi I Mikroserviseve Në Infrastrukturë Të Kontinjerizuar

University of Business and Technology in Kosovo UBT Knowledge Center

Theses and Dissertations Student Work

Winter 2-2021

ZHVILLIMI I MIKROSERVISEVE NË INFRASTRUKTURË TË KONTINJERIZUAR

Agnesa Saliaga

Follow this and additional works at: https://knowledgecenter.ubt-uni.net/etd

Part of the Computer Sciences Commons

Programi për Shkenca Kompjuterike dhe Inxhinierise

ZHVILLIMI I MIKROSERVISEVE NË INFRASTRUKTURË TË KONTINJERIZUAR Shkalla Bachelor

Agnesa Saliaga

Shkurt / 2021 Prishtinë

Programi për Shkenca Kompjuterike dhe Inxhinierise

Punim Diplome Viti akademik 2013 – 2014

Agnesa Saliaga

ZHVILLIMI I MIKROSERVISEVE NË INFRASTRUKTURË TË KONTINJERIZUAR Mentori: Dr. Besnik Qehaja

Shkurt / 2021

Ky punim është përpiluar dhe dorëzuar në përmbushjen e kërkesave të pjesshme për Shkallën Bachelor

Abstrakti

Kjo temë bazohet në aplikimin e metodologjive më të mira të punës duke përdorur veglat e përshtatshme për krijimin, testimin, versionimin dhe lansimin e ciklit të zhvillimit të një softueri dhe adaptimin e tij në mjedisin e kontinjerizuar, qoftë ai i hostuar në infrastrukturën tonë apo atë cloud. Në këtë punim këto teknologji do të elaborohen me fokus të madh praktik, duke prezentuar zgjidhje të ndryshme për pjesë të sfidave që shfaqen. Këto sfida elaborohen specifikisht përmes veglave që do të përdoren dhe aplikacionit që do ta lansojmë. Nga skenaret e lartëpërmendura nxirren dhe vizualizohen rezultatet të cilat mund të shërbejnë si orjentues në projektimin më të mirë të zhvillimit të ciklit të aplikacioneve .

Fjalët kyçe: Testimi Aplikacioneve, Virtualizimi Rrjetit, Teknologjitë e komunikimit, Rrjeti Tradicional, DevOps, Automizimi I Zhvillimit, Rrjetet Cloud.

Mirënjohje

Dua të falenderoj të gjithë stafin e "Kolegjit UBT" për mundësinë dhe mbështetjen e dhënë gjatë viteve të studimit, dhe një falenderim i veçantë për profesorin Dr. Besnik Qehaja i cili mentoroj temën e diplomës dhe më mbështeti me këshillat dhe rekomandimet e tij.

Falenderoj të gjithë shoqërinë, të cilët gjatë këtyre viteve të studimit më mundësuan të mësojë shumë çka prej tyre, dhe vazhdimisht më mbështeten në arritjen e qëllimeve të mija.

Dhe për fund, një falenderim i veçantë për familjen dhe të dashurin tim, të cilët asnjëherë nuk u ndalën së besuari në mua dhe gjithmonë gjeta kurajon për të vazhduar rrugëtimin e nisur.

Ju faleminderit të gjithëve!

PËRMBAJTJA

LISTA E FIGURAVE……………………………………………………………………IV FJALORI i TERMAVE …………………………………………………………………VI

1 HYRJE ...... 1

2 SHQYRTIMI i LITERATURËS ...... 5

3 MIKROSERVISET DHE ARKITEKTURA ...... 8

3.1 ARKITEKTURA E ORIENTUAR NE SERVISE ...... 8 3.2 ARKITEKTURA E MIKROSERVISEVE ...... 10 3.3 DIZAJNIMI I MIKROSERVISEVE ...... 13 3.3.1 FAKTORET E DIZAJNEVE ...... 13 3.3.2 KONSIDERIMET ...... 15 3.3.3 KONCEPTI I DIZAJNIT ...... 17 3.4 Application Programming Interaces (API) ...... 22

4 DEKLARIMI i PROBLEMIT ...... 26

5 METODOLOGJIA ...... 27

6 KONTINJERET DHE INFRASTRUKTURA HOSTUESE ...... 28

6.1 ORKESTRIMI I KONTINJERËVE DHE DOCKER ...... 32 6.2 VIRTUALIZIMI ...... 35 6.2.1 VIRTUALIZIMI I HARDUERIT ...... 35 6.3 KONTINJERIZIMI ...... 38 6.4 CLOUD SERVICES ...... 40

7 PËRSHKRIMI i EKSPERIMENTIT ...... 42

7.1 IMPLEMENTIMI I PROJEKTIT DHE TE GJETURAT ...... 45 7.2 SFIDAT ...... 60

8 REZULTATET ...... 62

9 PËRFUNDIMI ...... 66

10 REFERENCAT ...... 68

III

LISTA E FIGURAVE

Figura 1 – Ligji i Amdahl dhe Gunther mbi tezen se si throughput varet nga rritja e numrit të fuqisë procesorike...... 2 Figura 2: Arkitektura e Infrastrukturës së bazuar në kontinjerë ...... 5 Figura 3: Adaptimi I Docker nga Datadog klientët në vitet 2013 deri 2017 ...... 6 Figura 4: Shembull i një seti të mikroserviseve, të cilat janë të fokusuara në zona dhe detyra të ndryshme...... 12 Figura 5: Black Box Testing ...... 24 Figura 6: Krahasimi ndermjet Makines Virtuale dhe Kontinjerit...... 29 Figura 7: Performanca ndermjet makinave per ekzekutimin e kontinjereve ...... 31 Figura 8: Virtualizimi duke perdorur perkthimin binary ...... 36 Figura 9: Virtualizimi duke perdorur paravirtualizimin ...... 37 Figure 10: Virtualizimi duke perdorur virtualizimin e harduerit ...... 38 Figure 11: Arkitektura e organizimit te kontinjereve ...... 39 Figure 12: Instalimi I Boot2Docker...... 42 Figura 13: Kërkimi I imazheve në Docker Registry...... 43 Figura 14: Ekzekutimi I kontinjerëve në docker engine...... 44 Figura 15: Output I ekzekutimit të kontinjerit në docker engine ...... 44 Figura 16: Krijimi i VM në të cilin hostohet docker engine ...... 46 Figura 17: Alokimi i resurseve për instalimin e VM për docker ...... 47 Figura 18: Verifikimi i sistemit operativ dhe build number ...... 48 Figura 19: Azhurimi i sistemit operativ Linux me paketet e fundita...... 49 Figura 20: Verifikimi i ngarkimit të servisit të docker ...... 49 Figura 21: Krijimi i repozitoriumit për aplikacionin në Github ...... 52 Figura 22: Klonimi i repozitoriumit në serverin lokal ...... 53 Figura 23: skedari kryesor në të cilin gjindet kodi main.go ...... 54 Figura 24: Skedari view në të cilin paraqitet output për klientin e uebshfletuesit ...... 55

Figura 25: Skedari view në të cilin paraqitet output në rast se nuk kemi përzgjedhur API Endpoint të duhur ...... 55 Figura 26: Skedari në të cilin gjendet Dockerfile ...... 57 Figura 27: Procesi ku bëhet build imazhi i docker kontinjerit ...... 59 Figura 28: Ekzekutimi i docker container me komandën run ...... 59 Figura 29: Enkapsulimi i docker imazhit në të cilin hostohet kodi ...... 62 Figura 30: Paraqitja e rrjetit të docker kontinjerit në të cilin hostohet kodi ...... 63 Figura 31: Përgjigja e aplikacionit kur bëjmë request në endpointin për prodhim ...... 63 Figura 32: Ruajtja perzistente e të dhënave nga thirrjet e bëra nga API endpointet ...... 64 Figure 33: Përgjigja e aplikacionit kur bëjmë request në endpointin për shumë ...... 64 Figure 34: Ruajtja perzistente e të dhënave nga thirrjet e bëra nga API endpointi për mbledhje ...... 64

FJALORI i TERMAVE

SDN Software-Defined Network AWS Amazon Web Services NFV Network-Function Virtualization OS Operating System VLAN Virtual Local Area Network VPN Virtual Private Network API Application Programming Interface NOS Network Operating System WAN Wide Area Network NIC Network Interface Card VM Virtual Machine QoS Quality of Service RTT Round-Trip Time CI/CD Continuous Integration / Continous Delivery VC Versioning Control

1 HYRJE

Evoluimi i shërbimeve moderne të cloud ka ndryshuar drastikisht mënyren se si zhvilluesit zhvillojnë dhe lansojnë aplikacionet. Në Top 10 trendet e strategjisë së Teknologjisë (Gartner Research, 2015), ceket që - Aplikacionet e miksuara dhe arkitektura e serviseve janë ato çka e mundësojnë lansimin e aplikacioneve dhe shërbimeve në mjedise fleksibile dhe dinamike të hapësirës digjitale. Kjo arkitekturë do të shërbejë për nevojat e shfrytëzuesve për një kohë, pasi kërkesat ndryshojnë me kohën. Ajo bashkon shumë burime të informatave, pajisjeve, aplikacioneve, shërbimeve dhe mikroserviseve në një arkitekturë fleksibile ku aplikacionet shtrihen ndërmjet shumë pajisjeve fundore dhe koordinohen njëra me tjetrën që të prodhojnë një experience të vazhdueshme digjitale. IT në vazhdimësi do të dorëzojë shërbime si pjesë e shërbimeve të cloud-it në aplikacionet e përziera dhe arkitekturën e sherbimeve, të mbeshtetura nga arkitekturat e aplikacioneve të definuara nga softueri (software-defined applications), kontinjerët dhe mikroserviset. IT ka nevojë për një mendësi të frymës së DevOps që të bëjnë bashkë zhvillimin dhe operacionet në mbështetje të zhvillimit të vazhduar dhe integrimit/dorëzimit të vazhduar.

Arkitektura e Softuerit ka përjetuar një interesim të zgjuar s inga ana akademike, njëashtu dhe nga ana e Industrisë së Softuerit. Kanë ekzistuar dhe më parë variacione të arkitekturës së softuerit për sisteme të shpërndara duke përfshirë por jo limituar në arkitekturën e Common Object Request Broker Architecture (CORBA), Distributed Component Object Model (DCOM) si dhe Service Oriented Architecture (SOA). Shumica e këtyre dizajneve janë drejtuar nga konzorciume të vendorëve të mëdhenj të softuerit dhe kanë pasë gjithnjë përkrahje nga komuniteti për softuerët me kod të hapur (Open Source Code Community).

Është vërtetuar që bllokimi i çfarëdoshëm, çdo kund në sistem do të ketë impakt të konsiderueshëm për shkak të:

• Grindjes (Contentation) – duke pritur për rradhën ose resurset e bashkëndara • Ndërprerjës (Crosstalk) – për shkak të vonesës që të dhënat të jenë konsistente.

Ligji i Amdahl-it na tregon që maksimumi i shpejtësisë së përdorur duke përdorur P processorë për një fraksion të paralelizuar F të programit, është i limituar nga fraksioni I mbetur (1-F) I programit që ekzekutohen në seri, në njërin nga processorët ose në mënyrë redundate në të gjithë procesorët. Duke u bazuar në një studim [1], bllokimi rrjedhimisht do të ulte konkurrencën pasi sistemi do të rritej shume, dhe ajo qëndron e vërtetë edhe në ditët e sotme. Ligji i Gunther-it në mënyrë të famshme i referohet si Ligji Universal I Shkallëzimit (Universal Scalability Law) dhe grafikisht paraqitet në figurën e mëposhtme (Fig 1.).

Figura 1 – Ligji i Amdahl dhe Gunther mbi tezen se si throughput varet nga rritja e numrit të fuqisë procesorike [1]. Virtualizimi ndihmon në optimizimin dhe utilizimin e resurseve të disponueshme fizike duke trajtuar ato si resurse logjike ose virtuale të cilat mund të alokohen në mënyrë dinamike gjatë rrugës. Së fundmi, niveli I teknologjisë së virtualizimit të sistemit operativ, p.sh Linux Kontinjerët kanë fituar një popularizim të shquar duke u bërë si mënyra e preferuar e plasimit të aplikacionit. Duke utilizuar principet e virtualizimit të sistemit operativ, kontinjerët ofrojnë ndërveprim të shkelqyer. Megjithëse Makinat Virtuale dhe Linux Kontinjerët përdorin teknika të virtualizimit, Makinat Virtuale kanë një overhead shumë më të madh për shkak të emulimit të harduerit krahasuar me Linux Kontinjerët [2]. Kontinjerët zvogëlojnë koston e emulimit duke shtyer shtresat e virtualizimit nga hardueri në nivelin e sistemit operativ.

Së fundmi, populariteti I Linux Kontinjerëve ka sjellë një zhvendosje të paradigmës [9]. Të gjithë janë duke planifikuar kontinjerizimin e aplikacioneve ekzistuese. Kontinjerizimi është process I ofrimit të një ambienti specific të aplikacionit me të gjitha librarit, shënimet dhe konfigurimet e nevojshme përmes Linux Kontinjerëve [3]. Sidoqoftë, ekzistojnë disa sfida gjatë performimit të kontinjerizimit: 1. Çfarë informacione janë të nevojshme të kontinjerizohet një aplikacion. 2. Si të rimodelojme arkitekturën ekzistuese për të mbështetur arkitekurën e bazuar në kontinjerë. 3. Cilat udhezime duhen ndjekur gjatë krijimit të një Linux Kontinjeri. Në këtë temë, ne targetojmë këto sfida duke sjelle një përafrim që do të adresojë këto probleme. Përafrimi ynë i propozuar pritet që shfrytëzuesi të ndjekë një seri të hapave për të kompletuar procesin e migrimit. Sidoqoftë, secili hap gjatë performimit manual mund të jetë i konsumueshëm në aspektin kohor dhe mund të ndodhin shumë gabime [2]. Ne do të propozojme një framework të automatizuar që përndjekë përafrimin tonë për ta bërë kontinjerizimin e aplikacionit sa më të lehtë. Duke u bazuar në limitimin e veglave ekzistuese, ne definojmë një seri të kërkesave për framework-un tonë: - Framework-u duhet të jetë i pavarur nga platforma. Ajo duhet të përkrahë secilën nga distribucionet e sistemeve Operative të Linux, si Ubuntu, Fedora, CentOS (ose RedHat në hapësira komerciale/enterprise, etj. - Framework-u duhet të jetë i pavarur nga vendori. Ajo duhet të përkrahe secalin nga Vendorët e Linux Kontinjerëve, si Docker, Rkt, LXC, Containerd, etj. - Framework-u duhet të jetë i pavarur nga ofruesit e sherbimeve të cloud. Ajo duhet të përkrahë secalin nga ofruesit, si Amazon Web Services, Google Cloud Platform, Azure, etj. - Framework-u duhet të jetë i pavarur nga hipervisori. Ajo duhet të përkrahë secalin nga hypervisorët, si KVM, VMware ESXi, XenServer, ProxMox, Virtualbox, etj. - Framework-u duhet të lejojë që shfrytëzuesi mund të ketë interaksion dhe të vendosë se çfarë ndodhë në secalin hap.

Për të dizajnuar një framework që përkrahë të gjitha nga këto kërkesa, ne do të studijojmë funksionalitetin e secilës nga këto vegla, mënyrën e operimit dhe limitimet e tyre [3]. Ne do të përdorim këto të gjetura të zhvillojmë një framework të ri përkitazi me implementimin e një prototipit të tij. Kontribuimi kryesor në këtë temë, është si në vijim: • Ne do të rishiqojmë mundësitë dhe limitimet e përafrimeve ekzistuese. • Ne propozojmë një procedurë të detajuar hap pas hapi për kontinjerizimin e aplikacionit të bazuar në një sistem të Linux OS. • Ne propozojmë një framework përkitazi me implementimin e një prototipit të tij. • Ne performojmë dy raste studimi, dhe vlerësojmë efektivitetin e përafrimit tonë përskaj të avantazheve të nxjerra nga to.

Pjesa tjetër e kësaj teme është e organizuar si në vijim: Kapitulli i dytë përmban shqyrtimin e literaturës së komplet punës së bërë në fushën e kontinjerizimit të aplikacioneve dhe veglave të përdorura për ta arritur atë. Kapitulli i tretë përmban shqyrtimin e arkitekturës së bazuar në mikroserviseve dhe do të prekim një pjesë të historisë se si ka filluar përdorimi i kontinjerëve. Kapitulli i katërt përshkruan përafrimin e propozuar së bashku me frameworkun e automatizuar. Kapitulli i pestë përshkruan implementimin e prototipit të frameworkut. Kapitulli i gjashtë vlerëson efektivitetin e përafrimit tonë të propozuar dhe frameworkun. Kapitulli i shtatë sumarizon benefitet dhe fushëveprimin e ardhshëm të solucionit tonë.

2 SHQYRTIMI i LITERATURËS Virtualizimi i serverëve dhe deponisë së të dhënave ka marrë shumë vëmendje në lidhje me përmirësimin e efiçiencës, dhe përdorimit të lehtë të resurseve të disponuara, duke i grumbulluar apo duke i ndarë ato sipas nevojave të kërkesës. Kjo ide është zgjeruar në komponentën e rrjeteve, për të përdorur të njejtat avantazhe duke i grumbulluar, apo duke i ndarë resurset e rrjetit. Ndarja e Rrjetit lejon përkrahjen e disa shfrytëzuesve në izolim, ndërsa grumbullimi i resurseve lejon që aplikacionet të marrin më shumë brezë të gjerësisë, memorie, etj. Me zhvillimin e teknologjisë dhe nevojave për tu adaptuar në kërkesa për ndryshime të shpejta, dhe njëkohësisht në krijimin e një ambienti në të cilën serviset ndahen nga njëra tjetra duke qenë të pavarura dhe në rast të një mosfunksionimi të servisi mos të ndikohet I gjithë shërbimi, është para nevoja përdorimi I kontinjerëve. Kontinjerët janë të lehtë dhe kryesisht të vegjël. Ata nuk kanë një gjendje persistente, dhe shënimet nuk janë të parapara të ruhen mrenda një kontinjeri. Kontinjerët janë iniciuar në bazë të nevojës ku bëhet implementimi I vetëm një instance të një aplikacioni, dhe nuk ka varrëshmeri nga sistemi operativ, pasi ai përdor vetëm kernelin e sistemit operativ që e bën një aplikacion funksional dhe operativ.

Figura 2: Arkitektura e Infrastrukturës së bazuar në kontinjerë [4]

Definimi i strukturës së projektimit dhe krijimit të një problemi në të cilën do të trajtohet tema është gjendur duke marrë parasyshë zhvillimin e trendit të kalimit të shërbimeve nga aplikacionet tradicionale në aplikacione të kontinjerizuara, si dhe në të njejtën kohë edhe fleksibiliteti i hostimit të shërbimeve në infrastruktura hibride qofshin ato në cloud apo në infrastruktura lokale (on-premises). Sot, shumë kompani janë duke përdorë aplikacione të kontinjerizuara. Në një hulumtim nga DataDog [5] bazuar në mbi 10,000 kompani dhe 185 milionë kontinjerë që janë aktivë në botë, tregon rëndësinë e kontinjerëve dhe adaptimin e tij, ku nga ky hulumtim nxirret se 40% e klientëve kanë adaptuar Docker kontinjerët brenda një viti.

Figura 3: Adaptimi I Docker nga Datadog klientët në vitet 2013 deri 2017 [5]

Në këtë tezë është propozuar një mjedis në cilin do të observohet krijimi i një infrastrukture për të hostuar aplikacionet e kontinjerizuara, krijimin e kontinjerëve, dhe mundësinë e migrimeve të aplikacioneve tradicionale në ato të kontinjerizuara. Duke kuptuar funksionalitetin dhe limitimet e secilit nga veglat, ne do të adresojmë këto probleme:

- Sistemet ekzistuese nuk mbledhin të gjitha informatat për kontinjerizimin e aplikacionit. Në përafrimin tonë, ne do të agregojmë të gjitha informatat që sistemi ekzistues dështon ta bëjë. - Sistemet ekzistuese nuk i përmbahen praktikave më të mira gjatë krijimit të imazhit të kontinjerit. Në përafrimin tonë, ne do të ndjekim praktikat më të mira sic ceken në seksionin 3.3.2 - Sistemet ekzistuese janë të lidhura me vendorë specific të kontinjerizimit të aplikacioneve (Docker). Në përafrimin tonë do të kemi mundësinë që të zgjedhim përdorimin e pavarur nga vendor për krijimin e imazheve të kontinjerëve. - Sistemet ekzistuese nuk e lejojnë shfrytëzuesin të marrë pjesë procesin e migrimit. Në përafrimin tonë, shfrytëzuesi do të mund të ketë interaksion dhe të marrë vendime se çfarë duhet të ndodhë në secalin nga hapat. Aspektet kryesore të kësaj teze janë: Vlerësimi i performancës dhe efikasitetit të zhvillimit ku për bazë do të ketë shkallëzueshmërinë e rritjes së shërbimeve, redundanca dhe përballimi i fluksit më të madh të kërkesave, kalueshmëria e mjediseve, çështjet e kontrollit të sigurisë dhe analizimi i parametrave gjatë testimit.

3 MIKROSERVISET DHE ARKITEKTURA

Arkitektura e mikroserviseve osë thjesht mikroserviset janë një metodë distinctive e zhvillimit të sistemeve softuerike të cilat në thelb kanë fokusimin e krijimit të një moduli me një funksionalitet të vetëm, me një ndërfaqe dhe operacion të mirë-definuar. Ky trend ka krijuar një popularitet të madh në vitet e fundit, pasi Enterpriset (Bizneset e mëdha) kanë tendenca të bëhen më agjile dhe lëvizin kah fryma e DevOps dhe testimi I vazhdueshëm.

3.1 ARKITEKTURA E ORIENTUAR NE SERVISE

Origjina e arkitekturës së mikroserviseve shtrihet në një dizajn më të gjërë softuerik të quajtur “Service-Oriented Architecture” – (SOA). Në SOA, aplikacioni ndahet ne komponente që ofrojnë servise përmes protokolleve në rrjet. Ko-operimi I këtyre serviseve krijojnë funksionalitetin e të gjithë sistemit. Principi fundamental është që të ketë varrësi sa më të vogel ndërmjet tyre që është e mundur. Përafrimi më tradicional është arkitektura monolitike, ku aplikacioni është një shtresë e madhë softuerike. Bazuar në Cerny-n [6] dhe Lammervo-n [7], SOA është parë si një zgjidhje industriale nga shumë kompani gjigande. Aplikacionet e kompanive gjigande kanë tendencyë të rriten shumë dhe atë në mënyre komplekse, që vjen deri në pikën ku kanë nevojë për një arkitekturë softuerike. Ndarja e aplikacioneve në njësi më të vogla, në drejtim të sistemeve të shpërndara ka vërtetuar menaxhimin dhe lansimin shumë më të lehtë. Lammervo thekson, që SOA është shpesh e përdorur në web zhvillim. Tendencat komerciale kanë bërë që të avancohet ideja fillestare e kësaj nevoje por në të njejtën kohë e ka limituar atë në përdorimin biznesor. Shumë vendor kanë tentuar ti enkorporojnë web aplikacionet e tyre të shpërndara së bashku, dhe SOA I ka lejuar ata që të bashkëpunojnë në këtë aspect. Definicionet për protokollet e komunikimit në rrjet nga W3C (World Wide Web Consortium) dhe organizatat tjera kanë luajtur një rol kyq në dizajn procesin e SOA-së. Për më shumë, Xiao [8] propozon që SOA promovon agjilitetin e bizneseve në përgjithësi. Kompanitë janë në gjendje të I përgjigjen në mënyrë të vazhdueshme ndryshimeve që biznesi ka nevojë sot duke përdorur përafrimin e SOA-së. SOA mundëson integrimin e aseteve të

ndryshme softuerike në mënyrë të menaxhimit të proceseve të brendshme ose ndërmjet organizatave. Nuk është fizibile të shërbehen faqet statike të HTML për shfletues të desktopëve më. Pajisjet mobile sic janë telefonët dhe tabletën kanë përvetësuar një pjesë dermuese të kohës së lirë të njerëzve, por në të njejtën kohë edhe në mjediset e punës. Në mënyrë që të kemi një përmbajtje të knaqshme dhe dinamike të ndërfaqes së shfrytëzuesit, shfrytëzuesit fundorë presinë një User Experience (UX) intuitive dhe interactive. Industria sheh një varg adaptimesh në ndryshimet e reja, që hap mundësinë për modele të reja arkitekturale. Eventualisht kompanitë filluan ta shohin potencialin e SOA-së jo vetëm ndërmjet bizneseve, por edhe mrenda aplikacioneve të tyre të brendshme. Serviset vetvetiu ende varen nga një pjesëe vogël monolite dhe nga protokolet e rrjetit. Implementimi I aseteve të nënvizuara, sado që të mirë-strukturuara që ishin, nuk ishin shumë të rëndësishme. Fokusi ishte në rutimin logjik ndërmjetësues dhe komunikimin ndërmjet serviseve, të cilat kishin aftësinë të reagonin në ngjarje të cilave nuk iu dihej arsyetimi. Me fjalë të tjera, principi quhej “serviset e thjeshta dhe kanalet e menqura” [8]. Për monitorimin dhe logimin e serviseve, kjo do të ishte një mundësi e mrekullueshme pasi ato do të mund të zhvilloheshin, të reagonin në ngjarje të tilla. Përndryshe, ky model I arkitekturës ka krijuar shumë sfida të papërshtatshme për komunikimin e bazuar në ngjarje ndërmjet komponenteve të serviseve dhe procesimit global të komunikimit të aplikacioneve. Është e përbashkët në përafrimet monolite ose SOA për të konsumuar Enterprise Service Bus (ESB) për të luajtur rolin e një shtrese ndërmjetësuese që mundëson intëgrimin e komunikimit të ofruesve të shërbimit dhe shfrytëzuesve/konsumuesve. ESB zëvendëson komunikimin point-to-point me intrastrukturën të bazuar në bus, që ofron rutimin e mesazheve, procesimin e ngjarjeve, dhe monitorimin e aktiviteteve. Ajo qëndron në mes të serviseve të ndryshme, dhe transformon mesazhet e tyre në atë menëyrë ku gjeneralizon vetëm një lloj të mesazheve që kalojnë ndërmjet bus-it. Me implementimin e ESB-së përfitojmë një throughput më të madh, siguri dh endërveprim më të shquar – por me rrezikun e të pasur potencialisht një ngushtim të ngrykës së sistemit. [9] SOA ka mbajtë të njejtat principe që kanë shtruar mënyrën e funksionimit të mikroserviseve: distribuimi I serviseve të cilat janë të lehta për krijimin dh emirëmbajtjen nga ekipe të

ndryshme. Sidoqoftë, SOA ka disa disavantazhe si psh. nuk ka një model të standardizuar të arkitekturës. Shtresat (stack) I protokoleve të ndryshme të rrjeteve dhe ESB mund të rritet në mënyrë shumë komplekse, kur shumë servise shtohen brenda sistemit. Si rezultat, implementimi I SOA fillon të ngjasojë një monoliti të komplikuar përsëri. Modifikimet mund të nevojiten që të bëhen ndryshimet në të gjithë zingjirin e serviseve jo relevante, nivelin e integrimeve ose edhe ndërfaqet, që shkakton azhurime që jepin përshtypjet e sistemit monolit dhe ngadalsojnë zhvillimin individual. Kjo shton numrin e testimeve që duhen konfirmuar funksionimin e vazhduar dhe zgjat ciklin e kohës së zhvillimeve [9].

3.2 ARKITEKTURA E MIKROSERVISEVE

Cerny sugjeron që arkitektura e mikroserviseve është një vazhdimësi e SOA-së. Mikroserviset shpesh definohen si nën kategori ose avancim I SOA-së, ose siç Netflix e definon atë: SOA e gdhendur [6]. Shpesh termet janë konfuze ose përdoren si sinonime, por në njëfar forme arkitektura e mikroserviseve mund të përshkruhet si një re-implementim I SOA-së. Sipas Cerny-t, nuk është ë drejtë të krahasohet SOA dhe mikroserviset me njëra tjetrën, pasi kjo e fundit nuk definohet plotësisht sin jë përafrim I r ii krijimit të sistemeve të distribuara. Baza themelore është e njejtë: një stil arkitektural, ku një softuer I madh dhe kompleks ndërtohet nga shumë servise më të vogla. Së bashku ato prodhojnë funksionalitetin e sistemit në tërësi. SOA dhe arkitektura e mikroserviseve ndajnë të njejtin concept të dizajnit dhe karakteristikave siç janë krijushmëria e serviseve, ndarja e lehtë, menaxhimi I cikleve të zhvillimit, dhe ripërdorimi I resurseve. Sidoqoftë, ato bashkëndajnë një mori diferencimesh dhe arrijnë qëllimet e tyrë në mënyra të ndryshme. Arkitektura e mikroserviseve merr qëllimin e SOA-së dhe e kthen në anën e kundërt të “serviseve të mençura dhe kanaleve të thjeshta”. Mikroserviset janë të mirë-definuara, pjesëë të softuerit autonome që fokusohen në përformimin e detyrave të dhëna në mënyrë të duhur. Secili mikroservis trajtohet si një aplikacion I vogël, me mendjen që ka mundësi të rritet si pavarur nga zhvillimi dhe cikli I tij I zhvillimit. Ato enkapsulojnë funksionalitete të cilat ofrojnë vlera dhe janë relevante për biznese. Detyrat e dhëna mund të jenë diçka të vogla dhe të thjeshta si p.sh. ruajtja dhe marrja e të dhënave ose mund të përmbajë operacione në focus më të madh, si p.sh. mirëmbajtja e bazës së shfrytëzuesve. Përafrimi I vetë-mbyllur krijon

një ndarje më të madhe, por si dobësi zgjëron përgjegjësitë e servisit në maje të procesit të biznesit. Mikroserviset nuk kanë ngjajshmërisht qeverisje globale ose një menaxhim të centralizuar siç është tipike në SOA. Në mundësi të performimit të detyrave të dhëna, servisi duhet të menaxhojë API-të, databazën dhe gjitha varësitë e veta kundrejt librarive të jashtme dhe resurseve tjera që funksionaliteti I tij kërkon. Më shumë mikroservise do të thotë më shumë punë administrative duke përllogaritur që do të ketë më shumë repositoriume dhe pipelines të cilat duhen të menaxhohen. Dekompozimi në servise të ndryshme determinohet bazuar në funksionalitetet logjike dhe domene të sipërfaqes, siç ilustrohen në figurën 2. Përshembull, një faqe interneti mund të ketë mikroservise të veçanta të cilat mirren eksluzivisht me regjistrimin e shfrytëzuesve, katalogjet e produkteve, dh emirëmbajtja e porosive. Fokusi nuk është në trafikun e komunikimeve (mesazhet) ndërmjet serviseve, por në dizajnin dhe funksionalitetin e mikroserviseve vetvetiu. Mikroservisi tipik softuerik përkrah shumë klientë, siç shihet në figurën e mëposhtme. API Gateway-I në mes është jo I domosdoshëm por opcional, por ëshumë shpesh e gjejmë atë për balancimin e trafikut. Ajo shërben si fasadë për serviset e brendshme dhe drejton kërkesat në instancat e disponueshme të serviseve.

Figura 4: Shembull I një seti të mikroserviseve, të cilat janë të fokusuara në zona dhe detyra të ndryshme [10]. Arkitektura e mikroserviseve promovon rritjen e modularitetit dhe autonomisë krahasuar me SOA-në. Idealisht, mikroserviset nuk kanë ndonjë varrshmëri jashta serviseve. Ato kanë një kontekst të kufizuar pasi ato nuk kanë nevojë të dijnë diçka në lidhje me implementimin apo arkitekturën e serviseve tjera. Arkitektura e mikroserviseve ka fokus në përmirësimin e zhvillimit, dërgimin dhe lansimin e proceseve duke I bërë ato njësi të pavarura dhe lejon përshkallëzimin(scaling) në bazë të nevojës. Në vend së të ndjek një nivel global të pajtueshmërisë, serviset nga secila ekspozojnë një API në botën e jashtme [10].

3.3 DIZAJNIMI I MIKROSERVISEVE 3.3.1 FAKTORET E DIZAJNEVE

Mikrosherbimet kanë nevojë për një lloj tjetër të planifikimit dhe dizajnit të përhapur se monolitet [5] [6] [7]. Një kuptim i arkitekturës dhe kërkesave për të gjithë sistemin duhet të mbetet, megjithëse shërbimet individuale zhvillohen veçmas dhe nuk ndikojnë në njëra- tjetrën. Disa gracka në lidhje me zhvillimin e mikro-shërbimit që mund të shfaqen janë kompleksiteti i tepruar dhe rreziku i ndarjes së shërbimeve shumë gjerësisht. Edhe pse ndërfaqet janë entitetet e tyre, nuk duhet të ketë asnjë arsye për t’i ndarë ato pa nevojë, përndryshe mirëmbajtja e tyre mund të jetë problematike dhe kontrollueshmëria e tyre bëhet e shkatërruar në të gjithë. Si emër, termi mikrosherbim është mashtrues sepse ideja kryesore është ndarja e shërbimeve bazuar në funksionalitete logjike sesa në madhësinë aktuale. Parashtesa “mikro” mund të tingëllojë siç sugjeron ideale për numrin maksimal të linjave të kodit, por një argument kundërshtues është se madhësia nuk duhet të jetë një vlerë në vetvete. Madhësia nuk i shërben parazgjedhur qëllimit të shërbimit dhe nuk duhet të detyrohet në një drejtim ose tjetri nëse funksionaliteti vuan prej tij. Emri ka rrjedhur nga ideja që madhësia e vogël i mban ata të përqendruar dhe të menaxhueshëm. [11] Niveli rezultues i kompleksitetit pasqyrohet nga natyra e biznesit dhe faktorë të tjerë, siç është mjedisi konkurrues dhe rregullator. Shkalla e operacioneve dhe rregullat e biznesit luajnë role kryesore. Të gjitha këto aspekte do të kenë një efekt në mënyrën se si rezulton një sistem që mbështet biznesin. Ata do të përcaktojnë se çfarë lloj entiteti të të dhënave dhe marrëdhëniet midis tyre janë të nevojshme, duke çuar përfundimisht në atë lloj API-të që duhet të përshtaten për konsumatorët. Karakteristikat e planifikuara dhe historitë e përdoruesve të shkruar gjithashtu drejtojnë procesin e dizajnit. Shtë e rëndësishme të provoni të parashikoni të gjithë përvojën e përdoruesit, veçanërisht kur aplikacioni përbëhet nga përbërës të shpërndarë. SOA përpiqet të trajtojë sfera gjithëpërfshirëse dhe të gjera të sfidave nga monolitet, por metodat zbulojnë ndryshime midis tij dhe mikrosherbimeve. SOA po përpiqet të lehtësojë një problem kompleks të arkitekturës monolit duke ndarë funksionalitetin. Përkundrazi,

problemi shmanget edhe para se të ndodhë në arkitekturën e mikroservisit me para-planifikim të plotë. Një grup shërbimesh është emëruesi i zakonshëm, por mikrosherbimet janë më të përqendruara, të kufizuara dhe evoluojnë me optimizimin lokal të rritjes. Ata synojnë të ofrojnë shkallëzim për shërbimet në internet dhe janë më të orientuar drejt ekipit sesa bazuar në tërë ndërmarrjen. Për shkak të kësaj, dizajnimi i shërbimeve është më shumë si të hartosh shumë aplikacione të vogla me ciklet e tyre të jetës dhe planet e vendosjes. Që nga fillimi, është e këshillueshme të mbani në mend se mikrosherbimet janë të zëvendësueshme dhe të azhurnueshme në mënyrë të pavarur. Zbulimi i shërbimeve të gabuara dhe mirëmbajtja e tyre është më i lehtë me vendosjen automatike, si dhe aftësitë adekuate të regjistrimit dhe monitorimit. [8] Për shkak të mentalitetit “paguaj ndërsa shkon” kur zgjedh grumbullin e teknologjisë për shërbimet, transformimi i aplikacionit është më eksperimental dhe më pak i kushtueshëm. Monitalet zakonisht kërkojnë shumë më shumë përkushtim paraprak ndaj teknologjive të zgjedhura financiarisht dhe arkitekturisht. Nëse zgjedhja e teknologjive për ndonjë pjesë të aplikacionit, të tilla si mjetet e menaxhimit të API-së, zgjidhjet e qëndrueshmërisë së të dhënave ose gjuhët e programimit po ju japin dhimbje koke, ato mund të provohen në një mikrosherbim të vogël me jetë të shkurtër dhe më pas të mbahen ose të hiqen bazuar në rezultatin dhe përvojën. Gjetja e mjeteve të dobishme duke shmangur bllokimet e teknologjisë mund të arrihet në këtë mënyrë. [11] Komunikimi ndër-shërbimi vjen mjaft i gatshëm kur përdoret protokolle të njohura si HTTP dhe koncepte të tilla si REST. Sidoqoftë, trafiku ndërmjet shërbimeve mund të rritet dhe të paraqesë kërkesa të reja për balancimin e ngarkesës. Për postimin në një drejtim, një radhë mesazhi mund të jetë një zgjidhje praktike. Radha e mesazhit mund të përshkruhet si një rrip transportieri, i cili garanton se çdo mesazh do të arrijë në destinacionin e tij kur marrësi të jetë gati për ta marrë atë. Mesazhet mund të jenë në rrugën e tyre për një kohë, por përfundimisht ato do të dorëzohen. Në varësi të zbatimit të radhës së mesazhit, disa prej tyre ofrojnë funksionalitet shtesë, siç është kthimi i mesazheve aktualisht të papërpunueshme në fund të radhës. Trafiku me dy drejtime ekspozon kërkesa të ndryshme. Monolitët zakonisht përdorin balancues të ngarkesës për të shpërndarë kërkesat në raste identike. Në arkitekturën e mikroservisit, ideja përkatëse do të ishte një portë API. Porta API është një fasadë, e cila

ofron një pamje të unifikuar të shërbimeve dhe fsheh kompleksitetin e tyre nga përdoruesi përfundimtar. Funksionon si një zyrë postare, duke dërguar kërkesat tek shërbimet e disponueshme. [10]

3.3.2 KONSIDERIMET

Kalimi në arkitekturën e mikroservisit dhe shndërrimi i metodave ekzistuese në korrespondencë me paradigmën e re mund të sjellë sfida të reja në një kompani, veçanërisht nëse ajo ka punuar për një kohë të gjatë me monolite. Të mësuarit kërkon kohë nga punonjësit dhe marrja e vendimeve për dritë-shkurtër është një rrezik. Marrja e një borxhi të madh teknik në fillim mund të dështojë në fazat e mëvonshme të zhvillimit. Kërkon planifikim të plotë për të ndarë një aplikacion ekzistues në shumë shërbime. Në varësi të ekipeve dhe projektit, mund të jetë më e lehtë të fillosh me një hibrid monolit dhe mikrosherbim duke integruar shërbime të reja në monolit një nga një ose më mirë duke i zëvendësuar ato me thirrje të reja mikroservice si në këtë projekt teze. Mund të jetë gjithashtu e arsyeshme të ndërtohet një aplikacion i ri nga e para në vend që të refaktorizohet ndonjë i vjetër. [8 f. 65-66] Arkitektura e Mikroservisit nuk nënkuptohet domosdoshmërisht për aplikacione të vogla ose projekte që sapo iniciohen sepse synon të zgjidhë problemet që lidhen me arritjen e shkallës së rritur. Nëse aplikacioni nuk është ende pranë një monoliti, zhvilluesit që janë të njohur me të janë akoma në gjendje të zbatojnë ndryshime të shpejta pa e shndërruar atë në arkitekturën e mikroshërbimit. Qasjet e reja dhe konceptet e dizajnit kthehen lehtësisht në fjalë kur zgjidhjet inovative mund të gjenden në sfida të caktuara. Përpara se arkitektura e mikroservisit të ishte e modës, kompanitë kishin një problem të vërtetë për t’u marrë me: ndërtimin e aplikacioneve të mëdha dhe të padallueshme që u zgjeruan përtej asaj që mund të menaxhonin. Popullariteti mund të përshpejtojë zhvillimin e mjeteve dhe standardeve përkatëse, por është një shpatë me dy presa, pasi trendi mund të prish reputacionin e një arkitekture premtuese. Nëse zhvilluesit vendosin ta provojnë atë në kontekste të papërshtatshme dhe rastet kur mikrosherbimet mund të mos jenë opsioni më i mirë, ata përfundojnë me dështime të projektit dhe i fajësojnë ato në modelin e arkitekturës. Të mos kuptuarit se mikro-shërbimet nuk janë plumbi i argjendtë për çdo problem është një lajm i keq për ata që përfitojnë vërtet prej tij. [10]

Shqetësime të tjera për të mbajtur vëmendjen janë çështjet e vonesës dhe varësisë. Arkitektura e mikro-shërbimit paraqet trafik të ri në rrjet dhe nëse dy shërbime që konsumojnë API-në e njëra-tjetrës po shkaktojnë vonesë, mund të jetë e arsyeshme t’i bashkoni ato në një shërbim të vetëm. Caching gjithashtu mund të sigurojë disa ndihma të para për çështjet e latentit të rrjetit. Ndoshta rreziku më i madh në mikrosherbimet është krijimi i kaq shumë prej tyre që funksionaliteti i përgjithshëm i aplikacionit bëhet i fragmentuar. Burimet nuk ndahen dhe për këtë arsye ato duhet të futen në secilin shërbim veç e veç. Burimet kumulative largohen nga përfitimet e përdorimit të modelit të mikroshërbimit në radhë të parë, duke transferuar kompleksitetin nga shërbimet në integrimin dhe konfigurimin e tyre. Pavarësisht nga implementimet dhe numri i shërbimeve, një gjë është e sigurt: përdorimi i arkitekturës së mikroservisit do të thotë vendndodhje të shumta për tu mirëmbajtur me kompletet e tyre të plota të API-ve, modeleve dhe bazave të të dhënave. Një opsion për një kompani është të marrë në konsideratë mos administrimin e infrastrukturës në vetvete, por të urdhërojë që disa prej punëve të trajtohen nga Platforma si një Shërbim (PaaS) dhe ofruesit e reve. [10] Procesi i dizajnimit shpesh përfshin fusha të tjera të lidhura gjithashtu, të cilat mund të ndikojnë në zbatimin e brendshëm të shërbimit. Për shembull, mikrosherbimi mund të përmbajë si teste njësie ashtu edhe teste integrimi. Testimi i njësisë së ekzekutimit është zakonisht më i shpejtë nga të dy dhe fushëveprimi i tyre qëndron brenda njësisë. Si pasojë, ka kuptim t’i drejtojmë ato pas çdo angazhimi në tubacion. Mund të mos jetë e përshtatshme të kryeni testet e integrimit gjatë gjithë kohës për shkak të varësisë nga shërbimet e tjera që mund të jenë gjithashtu nën zhvillim ose ndryshe të paarritshme. Drejtimi i testeve të integrimit mbase një herë në javë ose të paktën para lëshimit të versionit mund të jetë i mjaftueshëm. Ndërsa nuk është e dëshirueshme që të lejohen defektet, mjedisi i shkathët dhe ritmi i shpejtë i lëshimeve bën të mundur zhvendosjen e fokusit nga testimi intensiv i njësisë në testimin në lëshimet e kanarinës dhe monitorimin e gjerë. [11]

3.3.3 KONCEPTI I DIZAJNIT

Një metodologji e quajtur App 12-Factor [12] është botuar për të ndihmuar zhvilluesit të trajtojnë sfidat në proceset e komplikuara të zhvillimit dhe vendosjes. Qëllimi i tij është të përshkruajë praktikat më të mira për t’u ndjekur në zhvillimin e aplikacioneve në internet dhe mund të zbatohet lehtësisht edhe në projektin e mikroshërbimit. Duke e ndjekur atë, struktura e aplikacionit mbahet e shkallëzuar dhe proceset e zhvillimit më të organizuara. 12 faktorët adresojnë konsideratat e mëposhtme: Codebase: Codebase nënkupton kodin i cili formon aplikacionin. Sipas 12- Factor App, vetëm një depo ekziston ndonjëherë për një aplikacion, pasi bazat e kodeve të shumta do ta bënin atë një sistem të shpërndarë. Rishikimet e tij gjurmohen me një sistem të kontrollit të versionit (VCS) si Git ose Mercurial. Kopjet e depozitës, pavarësisht nëse ato janë në një server prodhimi apo lokalisht në laptopin e një zhvilluesi, janë vendosje në thelb të ndryshme. Duke përdorur VCS, baza e kodeve qëndron e disponueshme në një vend të centralizuar dhe historia e versioneve ruhet. Aplikacioni mund të vendoset në një mënyrë të kontrolluar, zotimet mund të përdoren për të gjurmuar se ku është futur një defekt, ose eksperimentet e dështuara mund të rikthehen. Secili zhvillues mund të marrë një klon lokal të projektit pa ndikuar në punën e të tjerëve. E gjithë kjo plotëson parimet e arkitekturës së mikroservisit për izolimin dhe proceset e shkathëta, pasi që secili mikrosherbim ka depon e vet. Riparimi i defekteve dhe lëshimi i versioneve të reja vetëm pjesëve të aplikacionit është i lehtë duke punuar me depon përkatëse dhe pastaj duke e vendosur atë përmes CI pipeline. Dependencies: Shumë gjuhë programimi kanë një sistem paketimi, i cili mund të përdoret për të instaluar biblioteka në të gjithë sistemin ose në fushën e drejtorit. Sidoqoftë, një Aplikacion me 12 Faktorë nuk duhet të mbështetet në mjedis për të përmbushur çdo varësi ose zhvilluesi t’i kalojë të gjitha manualisht gjatë instalimit. Në vend të kësaj, ato duhet të renditen në një deklaratë të deklaratës së varësisë. Izolimi i varësisë duhet të përdoret gjithashtu për të parandaluar ndonjë bibliotekë shtesë që rrjedh në aplikim. Me një manifest të duhur, të vetmet parakushte të mbetura janë koha e ekzekutimit të gjuhës, një menaxher varësie dhe një komandë përcaktuese përcaktuese për të vendosur aplikacionin në çdo mjedis të ri.

Config: Konfigurimi zakonisht përmban informacione të tilla si emrat e hostit dhe kredencialet për shërbimet e jashtme dhe bazat e të dhënave. Situata ideale është që edhe nëse konfigurimi do të ndryshonte midis vendosjeve të ndryshme, kodi i punës nuk ka nevojë të preket. Kjo mund të bëhet duke ndarë në mënyrë rigoroze vlerat e konfiguruara nga kodi dhe përjashtuar ato nga ndjekja e kontrollit të versionit. Opsionale baza e kodit mund të mbajë disa vlera të defektit për konfigurimet për të ofruar një version bazë pune. Përfitimet shtesë të konfigurimit të jashtëm përfshijnë anashkalimin më të lehtë me skedarët e tjerë të konfigurimit ose variablat e mjedisit dhe se çdo e dhënë e ndjeshme e konfigurimit mbrohet më lehtë nga kompromentimi. E keqja është se skedarët e konfigurimit, veçanërisht kur përdorin shumë metoda të ndryshme të konfigurimit të jashtëm në të njëjtin aplikacion, mund të shpërndahen përreth dhe të bëhen të vështira për t’u gjetur. Për më tepër, ndryshimi i konfigurimeve mund të kërkojë njohuri të gjuhëve specifike për t’i ndryshuar ato, gjë që lë mirëmbajtjen e mundshme për më pak anëtarë të ekipit ose kërkon më shumë kohë për mësimin e pjesës tjetër të ekipit dhe krijimin e dokumentacionit. Backing services: Operacioni kryesor i një shërbimi është të sigurojë funksionalitet, por shpesh ata kanë nevojë të konsumojnë shërbime të tjera si pjesë e funksionimit të tyre. Këto burime të jashtme quhen shërbime mbështetëse dhe ato mund të jenë gjithçka, nga mikrosherbimet e tjera te bazat e të dhënave, sistemet e radhës së mesazheve, aplikacionet e palëve të treta dhe cloud. Për të qenë në përputhje me parimet e aplikacionit 12- Factor, aplikacioni duhet të jetë në gjendje të shkëpusë dhe bashkangjisë shërbimet e konsumuara në një vendosje pa prekur kodin. Nuk ekziston asnjë dallim midis burimeve lokale dhe atyre të përdorura përmes rrjetit, vetëm konfigurimi ndryshon për të ndihmuar aplikacionin të lokalizojë shërbimet e mbështetjes. Ky faktor është i dobishëm për mikrosherbimet sepse ato kujdesen vetëm për operacionet e tyre dhe mund të integrohen me shërbime të ndryshme pa ndryshime në implementimin e brendshëm. Build, release and run: Një aplikim i përputhshëm me 12 faktorë duhet të kalojë nëpër tre faza të ndryshme për vendosjen jo-zhvillimore. Faza e ndërtimit është ajo ku një version i bazës së kodit shndërrohet në një paketë të ekzekutueshme. Faza e ndërtimit gjithashtu përpilon varësi të binareve, aseteve dhe tërheqjeve. Në fazën e lëshimit konfigurimi aktual i shtohet ndërtimit të siguruar nga faza e mëparshme. Pas kësaj, lëshimi që rezulton është gati

për mjedisin e ekzekutimit. Faza e fundit është ekzekutuar ose koha e ekzekutimit, e cila fillon proceset e aplikacionit. Çdo botim duhet të qëndrojë i pandryshueshëm pas krijimit dhe të identifikohet me një ID unike ose një numër versioni. Çdo ndryshim që zbatohet në fazën e ndërtimit krijon versionin e tyre të ri. Ndryshimet nuk mund të zbatohen as gjatë kohës së ekzekutimit dhe për këtë arsye faza e ekzekutimit mund të automatizohet ndërsa ndërtimet shkaktohen nga zhvilluesit. Nëse faza e ekzekutimit është e automatizuar, ajo duhet të mbahet sa më e thjeshtë sepse të ketë më pak pjesë lëvizëse e bën atë më pak të prirur për gabime. Mund të rindezë automatikisht serverin ose të rindezë proceset e dështuara pa kërkuar ndërveprim manual. Kjo është veçanërisht e dobishme nëse procesi dështon gjatë natës ose orëve të tjera kur nuk ka mirëmbajtës të sistemit. Process: Në rastin më të thjeshtë, zakonisht në një mjedis zhvillimi, zhvilluesi mund të ekzekutojë aplikacionin duke përdorur rreshtin e komandës dhe kohën e instaluar të gjuhës. Sidoqoftë, një vendosje e prodhimit mund të nisë si një ose më shumë procese pa shtet dhe të izoluara në mjedisin e ekzekutimit. Çdo e dhënë e vazhdueshme ruhet në një shërbim mbështetës shtetëror. Hapësira e kujtesës e një procesi mund të përdoret si një memorie e shkurtër e transaksionit, por vetëm përkohësisht. Të presësh që çdo kërkesë në të ardhmen të drejtohet në të njëjtin proces shkel parimet e 12- Factor App sepse mund të ketë shumë procese. Edhe nëse aplikacioni është nisur vetëm si një proces, ai mund të rindizet për shkak të vendosjes së re, konfigurimit të modifikuar ose mjedisit që zhvendos procesin në server të ndryshëm në çdo kohë dhe të dhënat e përkohshme humbasin. Port binding: Një Aplikim 12-Faktori është i pavarur (p.sh. brenda një kontejner), i lidhur me një port dhe ekspozon një ndërfaqe shërbimi të drejtuar në internet pa u mbështetur në injektimin gjatë kohës së ekzekutimit të një serveri të internetit. Web serveri i shtohet aplikacionit në deklaratën e varësisë. Gjatë vendosjes, një shtresë rutimi merret me delegimin e kërkesave nga emri i hostit në proceset e lidhura me portin.

Concurrency: Në Aplikacionin 12-Faktorë proceset janë qytetarë të klasit të parë dhe drejtohen nga modeli i procesit Unix për demonët e shërbimit. Shkallëzimi dhe arritja e pajtimit janë të thjeshta duke caktuar ngarkesa të ndryshme pune për lloje të ndryshme të proceseve. Për shembull, proçeset në internet trajtojnë kërkesat HTTP dhe proceset e

punëtorëve trajtojnë detyrat e sfondit që zgjasin shumë. Kjo quhet formim i procesit: shkallëzim horizontal nga llojet e procesit dhe shkallëzim vertikal duke shtuar më shumë procese në të njëjtin lloj. Formimi i procesit nuk i ndalon proceset individuale nga trajtimi i multipleksimit të tyre (p.sh. fijet brenda një VM gjatë ekzekutimit) por ofron një qasje më të kontrollueshme dhe të besueshme për shkallëzimin dhe përputhjen në vend që të shtojë gjithnjë e më shumë fije.

Disposability: Proceset e disponueshme janë të tilla që nuk kërkon përpjekje për t’i filluar ose ndaluar ato të funksionojnë. Koha e minimizuar e fillimit dhe mbyllja e hijshme janë gjithashtu të një rëndësie. Këto karakteristika lehtësojnë shkallëzimin fleksibël, shkathtësinë më të mirë gjatë zhvendosjes së proceseve dhe vendosjet pothuajse të menjëhershme pasi të bëhen ndryshime në kod ose konfigurime. Për shërbimin në internet, mbyllje e këndshme do të thotë të heqësh dorë nga dëgjimi i portit të tyre të lidhur duke refuzuar të marrësh ndonjë kërkesë të re, por të përfundosh ato të paplota para se të dalësh. Për një proces punëtor metoda është disi e ndryshme. Pas marrjes së një sinjali mbylljeje ai e kthen detyrën aktuale në radhë pune. Kjo mbështetet në detyrat që janë transaksione ose të paktën idemotente, që do të thotë se rezultati është gjithmonë i njëjtë pa marrë parasysh sa herë ekzekutohet. Një mbyllje e hijshme nuk është e mundur çdo herë për shkak të dështimeve të pajisjeve dhe aplikacioni duhet të jetë në gjendje të trajtojë përfundimin e papritur. Development and production parity: Boshllëqet tipike thelbësore gjenden në tre fusha: koha, mjetet dhe personeli. Hendeku kohor njihet kur zhvilluesit bëjnë ndryshime në kod që kërkojnë kohë të gjatë për tu prodhuar. Mjetet më të lehta se ato që përdoren në mjedisin e prodhimit mund të preferohen në zhvillim, duke rezultuar në boshllëkun e mjeteve. Hendeku i personelit krijohet kur aftësitë e ndryshme janë të kufizuara për njerëz të veçantë, të tilla si zhvilluesit që shkruajnë kod dhe inxhinierët e funksionimit që e vendosin atë. Tubacioni i duhur i vendosjes së vazhdueshme përpiqet të eleminojë këto boshllëqe midis fazave të ndryshme duke mbajtur ambiente të ndryshme sa më të ngjashëm që të jetë e mundur. Reduktimi i shndërrimeve të nevojshme të kërkuara nga ndryshimet e mjeteve zbut kohën dhe boshllëqet e mjeteve njëkohësisht. Për më tepër, qasjet e DevOps mund të ndihmojnë në zgjidhjen e hendekut të personelit, pasi zhvilluesit dhe operacionet e tjera janë të përfshirë

ngushtë në punën e njëri-tjetrit. Kur nuk është e mundur të përdoren mjetet ekzaktësisht të njëjta në barazinë e produkteve / produkteve (p.sh. kur zhvilluesit nuk janë në gjendje të zgjedhin se cilat mjete po përdor një shërbim mbështetës i palës së tretë), lloje të ndryshëm adaptorësh mund të futen në projekt për të lehtësuar hyrjen në to. Mjedise të ndryshme duhet të përdorin të njëjtin version të secilës bibliotekë dhe shërbim mbështetës për të shmangur papajtueshmërinë. Për fat të mirë, instalimi i të njëjtave mjete që po përdor prodhimi në mjedisin lokal të zhvillimit mund të bëhet me mjete paketimi të tilla si apt-get për Linux, Homebrew për Mac dhe Chocolatey për Windows, si dhe duke përdorur virtualizim të tillë si Docker dhe Vagrant. Logs: Regjistrimi përdoret për të inspektuar sjelljen e një aplikacioni operativ dhe rezultati zakonisht ruhet si skedar në një hapësirë ruajtëse të vazhdueshme. Regjistrat janë një rrjedhë e përmbledhur e ngjarjeve të marra nga të gjitha burimet e prodhimit të proceseve dhe shërbimeve mbështetëse. Ato regjistrohen për sa kohë që aplikacioni po ekzekutohet. Në mënyrë tipike, ngjarjet janë rreshta teksti që përshkruajnë ngjarjen, informacionin në lidhje me kërkesën e marrë, përgjigjen e rezultuar, vijën kohore dhe në rast se haset një gabim, gjurma e pirgut të përjashtimit. Regjistrat janë një pjesë thelbësore e aplikacionit sepse ato ofrojnë një mënyrë për të mbledhur statistika rreth asaj se si funksionon aplikacioni, si përdoret dhe çfarë ka ndodhur pak para një dështimi. Sidoqoftë, regjistrimi dhe menaxhimi i regjistrave nuk duhet të jetë shqetësim i Aplikacionit 12-Factor. Secili proces shkruan rrymën e tij në stdout. Në një mjedis lokal në zhvillim, zhvilluesi mund të vëzhgojë rrjedhën e regjistrit direkt me një terminal. Përndryshe, në fazat e mëvonshme, mjedisi i ekzekutimit drejton rrjedhat e regjistrit në vendin e duhur për shikimin dhe qëndrueshmërinë afatgjatë. Destinacioni që arkivon regjistrat nuk duhet të konfigurohet nga aplikacioni, por një shërbim i jashtëm. Përveç ruajtjes, logfiles mund të analizohen më tej në sistemin e regjistrimit, të tilla si gjenerimi i alarmeve nëse vëren anomali të sigurisë. Një shembull do të ishte numri i tepruar i dështimeve ose kërkesave në një kohë të caktuar. Në arkitekturën e mikroservisit, sistemi i regjistrimit mund të jetë gjithashtu një mikroservis i pavarur. Administration processes: Herë pas here, lind një nevojë për të ekzekutuar detyra të menazhimit të njëhershëm, të tilla si migrimet e bazës së të dhënave, ekzekutimin e skenareve ose përdorimin e një konsolë për të shikuar aplikacionin. Ato duhet të drejtohen veçmas nga

formimi i procesit të përmendur më herët, ndërsa gjithashtu janë në përputhje me barazinë e mjedisit. Kodi për ekzekutimin e detyrave të administratorit dërgohet brenda bazës së kodit për të shmangur problemet me sinkronizimin. Ato mund të thirren përmes një terminali në zhvillimin lokal, por për t’i përdorur ato në production administratori duhet të krijojë një SSH ose lidhje tjetër të ngjashme nga distanca.

3.4 Application Programming Interaces (API)

Application Programming Interfaces (API) në bazë themelore është një kontratë ndërmjet konsumuesit dhe ofruesit. Ajo definon operacionet dhe protokolet që klienti mund të përdorë të komunikojë me servisin, dhe çfarë resurse ajo mund të ofrojë. Çfarë do qoftë konsumuesi, qoftë një shfrytëzues njeri ose ndonjë servis tjetër në arkitekturën e mikroserviseve – nuk ka rëndësi. Ndërfaqja e servisit funksionon si fasadë e gjuhës neutrale, duke thjeshtësuar komunikimin ndërmjetësues, dhe duke larguar nevojën për të ditur implementimin e brendshëm të servisit. Ndërfaqet duhen të jenë të zbuluara përmes regjistrave, pa pasur nevojë për tu ditur lokacioni apo implementimi që ndodhet nën të [6]. Protokolet e rrjeteve të lehta dhe heterogjene siç është Representational State Transfer (REST), shpesh përdoren për kompozimin e ndëfaqeve të servisit në paternin e mikroserviseve. Serviset që përdorin REST quhen RESTful servise. REST nuk ka nevojë për ndonjë protocol specific, por HTTP duket që është njëra që më së shumti e përdor atë. Është një stil arkitektural për serviset e WEB, të cilat zakonisht përdorin metoda standard dhe të predefinuara. CRUD është një akronim për katër funksionet bazike të HTTP-së për manipulimin e të dhënave në deponin e të dhënave persistente: create, read, update and delete. Nganjëherë read përdoret si retrieve, update përdoret si modify, dhe delete përdoret si destroy, por ato në mënyrë të hapur janë të pasqyruara nga termet e HTTP si GET, POST, PUT dhe DELETE. Praktikat RESTful janë pa gjendje dhe kanë fokus lehtësimin e kontrollit të resurseve të web me operacione të unifikuara. REST është një zgjidhje e plotësueshme për mikroserviset, pasi ato zakonisht gjinden si servise të web-it. Me nevojën për to, protokolet e komunikimit mbahen konstante, të lehta dhe të thjeshta.

Jeff Bezos, CEO i Amazon, lëshoj një udhëzim të nevojshëm [13] në vitin 2002 ku ai vendosi udhëzime të qarta për ndërfaqet e serviseve. Në fakt, udhëzimi i tij u hoq nga vetë webfaqet e tija, por ai lejoi publikun të mbajnë ndonjë kopje potenciale që ata do të mund të kishin. 7 hapat e udhëzimit ishin si në vijim: • Të gjitha ekipet do të duhet të ekspozojnë të dhënat dhe funksionalitetet e tyre përmes ndërfaqeve të serviseve. • Ekipet duhet të komunikojnë me njëra tjetrën përmes këtyre ndërfaqeve. • Nuk duhet të ekzistojë ndonjë formë tjetër e komunikimit të interproceseve: jo lidhje direkte, jo lexim direkt i deponisë së të dhënave të ekipës tjetër, jo model i bashkëndarjes së memories, jo dyer të mbrapme (backdoors). I vetmi komunikim i lejuar është përmes thirrjeve të ndërfaqeve të serviseve përmes rrjetit. • Nuk ka rëndësi se çfarë teknologjie përdoret. HTTP, Corba, Pubsub, protokole të vetëdefinuara – nuk ka rëndësi. • Të gjitha ndërfaqet e serviseve, pa përjashtim, duhet të dizajnohen nga fillimi deri në atë pikë që mund të zgjerohen më shumë edhe nga palët e treta. • Të gjithë ata që nuk i zbatojnë udhëzimet e mëlarta do të përjashtohen. • Faleminderit; Paçit një ditë të mbarë! [13] Udhëzimi përdor termin “ekip” këtu për të referencuar serviset të cilat në mendje duhet ta kemi se një ekip do të jetë i përgjegjshëm për zhvillimin e atij servisi. Çdo shërbim në sistem i ngjan një njësie të mbyllur, e cila ka gjithçka që i nevojitet brenda. Pavarësia e lartë mundëson zgjidhje teknike të individualizuara brenda çdo mikrosherbimi. Për sa kohë që shërbimi u bindet rregullave për ekspozimin e një ndërfaqeje, implementimi i brendshëm nuk ka të bëjë me shërbime të tjera. Për shembull, ata nuk kanë pse t'i përmbahen modeleve të të dhënave të tjetrit ose strukturave të bazës së të dhënave. Në vend të tubave inteligjentë, në këtë model të ri logjika ndodh brenda shërbimeve dhe ndërfaqet synojnë të qëndrojnë të lehta. Në vend se të përdorni një ESB të centralizuar, është më e zakonshme të vendosni një radhë mesazhesh si RabbitMQ ose ZeroMQ, e cila përdor të njëjtat API. [13] Nga jashtë, mikroserviset duken si kuti të zeza të cilat zakonisht përmenden në temat që lidhen me testimin. Në testimin e kutisë së zezë, programi i ekzekutueshëm merr një hyrje, e përpunon atë dhe kthen përgjigjen siç shihet në Figurën 3. Ndryshe nga testimi i kutisë së 23

bardhë ku testuesi është i njohur me të brendshmet, testimi i kutisë së zezë synon të mbetet i shkëputur nga zbatimi i aplikacionit dhe vetëm verifikoni që rezultati korrespondon me atë që pritej bazuar në input [14].

Figura 5: Black Box Testing [14] Përdoruesi, qoftë njeri apo shërbim tjetër, nuk ka nevojë të dijë se çfarë ndodh brenda kutisë ose si funksionon programi për ta përdorur atë. Ide e ngjashme vlen për mikrosherbimet dhe ndërfaqet e tyre. Duke folur në përgjithësi, përdoruesi përfundimtar nuk njeh as se ku fillon një shërbim dhe tjetri mbaron nëse nevojiten shumëfish për të përfunduar përpunimin e kërkesës, pasi ndërfaqet e shërbimit i lidhin ato pa dyshim së bashku. Arkitektura e Mikroservisit është e përshtatshme për t'u përdorur në një kompani të orientuar drejt ekipit për shkak të pavarësisë teknike. Secili ekip mund të përqendrohet në një mikrosherbim dhe të përfitojë nga liria e zgjedhjes për teknologjitë, siç propozoi Bezos në mandatin e tij. Mundësia e përdorimit të gjuhëve të ndryshme të programimit krijon fleksibilitet, edhe pse pa kërkesa devijuese ndonjëherë është më praktike të përdoren të njëjtat rafte nëpër shërbime të shumta për shkak të konfigurimit të kërkuar të mjedisit. Sidoqoftë, kur mjediset janë instaluar tashmë ose faktori kohë për vendosjen e tyre nuk është një çështje e ngutshme, ekipet mund të përdorin pikat e forta të ndryshme të anëtarëve të tyre dhe të gjejnë mjetet e preferuara për detyrën në fjalë. Si rezultat, ekipet përfundojnë të jenë ndër-

funksionale dhe aftësitë e anëtarëve mbulojnë gamën nga ruajtja e vazhdueshme deri tek përvoja e përdoruesit. [14] Në arkitekturën e mikroservisit, mbledhja e shërbimeve të zgjuara ndryshon gjatë gjithë kohës, veçanërisht nëse shërbimet e rrëzuara rindizen automatikisht dhe paraqiten më shumë raste për bilancin e ngarkesës. Për më tepër, vendndodhja e rrjetit të tyre mund të ndryshojë gjatë kohës së ekzekutimit. Klientët përdorin mekanizmat e zbulimit të shërbimeve për të gjetur shërbimet dhe për t'u dërguar kërkesa atyre përmes një regjistri. Regjistri ka API-në e tij për shtimin dhe pyetjen e shërbimeve. Mekanizmat e zbulimit janë të ndarë përafërsisht në dy: nga ana e klientit dhe nga ana e serverit. Dallimi i vetëm midis këtyre modeleve është se në zbulimin nga ana e klientit, vetë klienti kërkon regjistrin, zgjedh një shembull të disponueshëm dhe ia dërgon kërkesën. Në zbulimin nga ana e serverit, kërkesa e klientit kalon përmes një router i cili kujdeset për këtë detyrë. Dy opsionet për regjistrimin dhe çregjistrimin e shërbimeve janë ose shërbimet regjistrohen vetë ose një përbërës i sistemit e trajton atë në varësi të grupit të mjeteve të zgjedhura. Për shembull, në Kubernetes regjistrimi i shërbimit është i integruar. [14]

4 DEKLARIMI i PROBLEMIT Qëllimi i kësaj teze është dokumentimi dhe sygjerimi i zhvillimit të mikroserviseve e cila mund të përdoret për referencim të mëvonshëm për zhvillimin dhe lansimin e aplikacioneve duke përdorur Docker Containers dhe Amazon Web Services. Teknologjitë janë në mënyrë të vazhdueshme duke u zhvilluar, të cilat ofrojnë një varg të mundësive ku dikur kanë qenë të pamundura për shkak të limitimeve teknike. Synimi i këtij projekti është utilizimi i përdorimit të teknolgjive për zhvillimin e softuerit, efikasiteti në lansimin e aplikacionit duke mos pasur parasysh ambientin se ku do të hostohet aplikacioni, dhe spjegimi i këtij procesi duke indikuar përparësitë dhe mangësit e këtyre operacioneve. Një nga sfidat më të mëdha në ambiente zhvilluese është menaxhimi i ambienteve të ndryshme e sidomos kur ekipet janë të mëdha, dhe shumë njerëz shkruajnë kodin në makinat e tyre. Shumë shpesh hasim në sfida kur aplikacioni i zhvilluar në makinat personale funksionon por kur ai aplikacion tenton të lansohet në produksion, hasim në vështirësi ku ai nuk funksionon si duhet, ka mungesa në paketa të sistemit operativ, ka mungesa në varrëshmëri të binarëve të gjuhës që shkruhet kodi, të gjitha këto sfida do të identifikohen si probleme dhe do të trajtohen përmes pyetjeve të parashtruara më poshtë. Pyetjet kërkimore luajnë një rol krucial e cila ndihmon autorin për të qëndruar në një rrugë të duhur gjatë kërkimit dhe shkrimit. Në këtë tezë, unë do të fokusohem në përgjigjen e këtyre pyetjeve kërkimore: - Cila arkitekturë softuerike nevojitet për të zhvilluar një softuer të bazuar në mikroservise? - Si të zhvillojmë një softuer të bazuar në kontinjer dhe ta lansojmë atë në serverë lokal apo ne AWS? - Çfarë platforme dhe komponente të AWS mund të përdoren për të implementuar dhe lansuar një aplikacion të bazuar në mikroservise

5 METODOLOGJIA Procedurat e kërkimit shkencor kanë për detyrë përafrimin në vlerësimin e rezultateve dhe validimin e metodave të kërkimit. Testimet e emuluara kanë nevojë të jenë të ri-përsëritshme dhe të verifikueshme, edhe nga kërkuesit tjerë. Metoda e përdorur në këtë tezë është metoda kualitative, eksperimentale e bazuar në emulator dhe testime. Shfletimi i literaturës ndërlidhet me materialin e mbledhur nga kërkuesit që kanë vlerësuar probleme të ngjajshme, duke u bazuar në literatura dhe hulumtime nga libra, revista shkencore si dhe diskutime të ngritura nën të njejtën temë. Simulatorët mund të përdoren për të adresuar mënyrën e funksionimit të teknologjive, por edhe ato kanë pikat e tyre të dobëta. Metoda më e preferuar, do të ishte në disa raste që eksperimentet të zhvillohen në sistemet aktuale (fizike), por jo gjithmonë gjatë testimit të aplikacioneve dhe matjeve të parametrave të rrjetit mund të parashihet dhe të menaxhohet trafiku i rrjetit në të njëjtën mënyrë se si duam të bëjmë testimet tona. Për këtë arsye, mënyra më e përshtatshme për adresimin e problemit tonë, mund të jetë metoda e eksperimentit përmes infrastruktures së kontinjerizuar, i cili ofron një mundësi të madhe të rritjes së performancës, testimit të qëndrueshmërise dhe rritjes potenciale të shërbimit duke shumëfishuar numrin e kontenjerëve. Kontenjerët ofrojnë krijimin e kushteve realistike të një infrastrukture të IT-së ekzistues në një hapësire punuese pasive, pa ndikuar në hapësirën e produksionit dhe duke mos përdorur overhead të sistemit operativ. Përmes sajë pastaj është e mundshme që të ofrohet shërbimi I produksionit në të cilën kontenjerët thërrasin vetëm instancën e aplikacionit dhe jo të gjitha varrëshmërite e sistemit operativ.

6 KONTINJERET DHE INFRASTRUKTURA HOSTUESE Një aplikacion monolit mund të mbështillet në një paketë instalimi por që funksionon me mikrosherbime është më e komplikuar për shkak të karakteristikave të tyre të shpërndara. Ata janë më e vështirë për të operuar se monolitet në një kuptim që menaxhimi dhe lirimi proceset trajtohen si me shumë aplikacione. Mikrosherbimet nxjerrin në pah automatizimin, shkallëzimi dhe monitorimi i pavarur. Për këto qëllime dhe për të ofruar një më elegante mënyra për vendosjen, teknologjia e kontejnerëve është shfaqur. Kontejnerët janë një koncept i ngjashëm në zhvillimin e softuerit si, për shembull, ngarkesa e anijes kontejnerët janë në jetën reale. Me kontejnerë, objekte të ngjashme mund të bashkohen për t'u formuar njësi të pavarura dhe lehtësisht të lëvizshme. Aplikimet, të tilla si mikrosherbimet, mund të ekzekutohen kontejnerë të ndarë nga aplikacionet ose infrastrukturat e tjera. Në vend të një anijeje, kontejnerët e softuerit ndajnë një platformë të përbashkët, e cila monitoron dhe kontrollon ato. [15] Kontejnerët ndryshojnë dukshëm në krahasim me modelin tradicional të instalimit të softuerit në kompjuteri në krye të sistemit operativ. Aplikacionet zakonisht shtojnë cilësimet e tyre, bibliotekat dhe drejtuesit e mjeteve që u duhen, ndonjëherë me rrezikun e gabimeve të përputhshmërisë. Një Zgjidhja e hershme për të lehtësuar menaxhimin e mikrosherbimeve të ndryshme ishte përdorimi virtual makineritë (VM). Sidoqoftë, kontejnerët kanë disa përparësi mbi to. Makinat virtuale në thelb janë kompjuterë individualë virtualë, që ndajnë burimet fizike të makinës pritëse. Ata janë shkëputur në mënyrë të përshtatshme nga njëri-tjetri dhe nikoqir siç shpjegon Kovács në [15] Për më tepër, ato lejojnë dallimin midis zgjedhjet e sistemeve operative. Një makinë mund, për shembull, të ekzekutojë Windows ndërsa tjetri po ekzekuton një server Linux. Pastaj përsëri, mjaftueshëm CPU, memorie dhe burime të tjera duhet të ndahen për ta për të arritur një performancë të kënaqshme. Ato i ngjajnë reale kompjutera fizikë, përkatësisht kërkojnë azhurnime dhe mirëmbajtje. Çdo makinë presupozon instalimin e një sistemi operativ dhe softuerit tjetër. Procesi i konfigurimit mund të automatizohet, por kur rritet numri i makinave të ndryshme virtuale, zgjidhja mund të mos jetë më e realizueshme pasi kostot rriten dhe kohën e nevojshme për të kompletimi i punës së konfigurimit shumëzohet. Alsoshtë gjithashtu e mundur të zgjerohen makinat virtuale në cloud, pasi shërbimet cloud zakonisht bazohen në to. Përdorimi i shërbimeve cloud është një mënyrë për të transferuar në punë të lidhur me

infrastrukturën, por modelet e kostos mund të mos përshtaten me projekte të tilla janë vetëm fillestare ose eksperimentale në natyrë. Teknologjia e kontejnerëve duket e ngjashme me makinat virtuale, por kontejnerët janë më të lehtë dhe kërkojnë më pak burime nga makineria pritëse. Figura 3 ilustron ndryshimet midis dy strukturave.

Figura 6: Krahasimi ndermjet Makines Virtuale dhe Kontinjerit [15] Kontejnerët janë ambientet e tyre ekzekutuese me memorie të alokuar, CPU, I / O dhe lidhjet e rrjetit të ndara me makinerinë pritëse. Për të ekzekutuar aplikacione me kontejnerë, secili prej tyre nuk kërkon sistemin e vet operativ. Ato nuk duhet të instalohen askund për t'u përdorur, gjë që bën të mundur ekzekutimin e instancave të tyre në mënyrë të pavarur nga nikoqiri. Mund të ekzekutohen disa aplikacione ose raste të një aplikacioni të njëjtë paralele nëse është e nevojshme, duke i mbajtur të izoluar. Aplikimet në kontejnerë janë të paketuara si imazhe që përmbajnë pirjet e tyre të ekzekutimit, deklaratat e varësisë dhe konfigurimet. Imazhet janë të shtresuara, ku imazhi i platformës ka shërbimet e nevojshme për të ekzekutuar enë. Pjesë të tjera shtohen në krye të shtresave të mëparshme dhe bëhen modulare ndryshimet, për shembull, azhurnimi i një numri versioni në çdo shtresë është i mundur pa ndërtuar një imazh i ri nga e para çdo herë. [15]

Kontejnerët nuk janë parakusht i mikrosherbimeve ose anasjelltas, por ato plotësojnë njëri- tjetrin dhe kombinimi u bë i njohur nga praktikat e DevOps. Kontejnerët përfshijnë në thelb gjithçka që u nevojitet përveç aplikacionit për t'u ekzekutuar. Burimet janë kursehen kur secili kontejner nuk kërkon sistemin e vet operativ, por atë të hostit. Mjaftojnë OS dhe sistemi i ndërmjetëm i menaxhimit të kontejnerëve. Kontejnerët priren të filloni më shpejt sesa makinat virtuale për shkak të kësaj. Vendosja e burimeve të shumta shtesë duke përfshirë të gjithë mjedisin vetëm për të ekzekutuar aplikacionin e dëshiruar shmanget. Në nga ana tjetër, nëse shumë aplikacione patjetër që kanë nevojë për sisteme të ndryshme operative për të punuar, ato ende duhet të abstraktohen me makina të veçanta reale ose virtuale. Një tjetër tregti krahasuar me virtualizimin është mungesa e disa veçorive, siç është migrimi i drejtpërdrejtë. Për të lëvizur kontejnerët nga nyja pritëse në tjetrën, kontejnerët duhet të ndalen. [15] Rrënjët e kontejnerëve qëndrojnë në LXC, që qëndron për Linux Containers. Ishte e para teknikë e përdorur gjerësisht e kontejnerëve, e cila përdori hapësirat e emrave të bërthamave për të izoluar CPU-në, memorie, I / O dhe burime të tjera ndërmjet proceseve të vetme dhe grupeve CG (Kontrolli) Grupet) për të menaxhuar grupet e procesit. Bërthama e OS host është e ndarë në mënyrë që Sistemet e skedarëve të kontejnerit dhe proceset e ekzekutimit janë të menaxhueshme nga hosti. Me vone, palët e tjera kanë zhvilluar mjetet e tyre të kontejnerizimit të rafinuara për qëllime të ndryshme të tilla si thjesht për ruajtjen e të dhënave ose të orientuara për platforma të ndryshme, por ideja mbetet e njëjta. Për shembull, Microsoft ka krijuar Microsoft Containers për arsyen e qartë se kontejnerët me bazë LXC nuk përshtaten së bashku me sistemin operativ Windows. standardi de-facto në ditët e sotme duket të jetë Docker, por konkurrentë të tjerë të shquar përfshijnë rkt (shqiptohet "raketa") nga CoreOS dhe Solaris Containers. Kjo e fundit daton nga koha para Docker por mund të jetë një zgjidhje e mundshme për kompanitë që tashmë e kanë standardizuar veten në shërbimet e Oracle. [15] Dallimet në performancë ishin të vogla sipas studimit në [14 f. 48-50], pavarësisht nga të cilat u përdor teknologjia e kontejnerëve apo edhe një makinë vendase ose virtuale. E natyrisht, vetëm disa teknologji kontejnerësh u morën nga grupi i alternativave të ndryshme për të qenë pjesë e studimit. Rezultatet mund të shihen në Figurën 4.

Figura 7: Performanca ndermjet makinave per ekzekutimin e kontinjereve Makina virtuale (KVM) e bazuar në kernel ka mbetur prapa në krahasim me zgjidhjet e tjera, por vetëm minimalisht. Ndërsa përcjellësit e studimit u cituan në [14 f. 49], ata duhej ndryshoni shkallën kohore të figurës për të parë edhe ndonjë ndryshim. Nga faktorët e konsideruar, Standardet e rrjetit shkaktuan ndryshime më të dukshme sesa matjet e CPU-së. Ata gjithashtu vunë në dukje se opsione të ndryshme konfigurimi mund të ndikojnë në rezultate, për shembull, Docker mund të përdorë kartën e rrjetit fizik në host. Me atë përbërje, shërbimet e tjera arrihen sikur të ishin duke ekzekutuar në host, megjithëse kjo metodë zvogëlon numri i porteve në dispozicion. Në përgjithësi, kontejnerët nuk kishin të meta të konsiderueshme krahasuar me vendasit kur bëhet fjalë për performancën dhe rrjetëzimin. Aty ku shkëlqen kontejnerët është kur puna e konfigurimit të mjedisit duhet të automatizohet dhe replikohet lehtësisht për një numër të madh kompjuterash në mënyrë që softueri i kërkuar të mos bëjë duhet të instalohen në secilin prej tyre manualisht. Ata janë gjithashtu një zgjedhje e përshtatshme kur natyra e përdorimit të mjedisit të dëshiruar është e përkohshme.

Për shembull, tubacioni CI mund filloni një kontejner për të ekzekutuar testet e njësive të një angazhimi të ri dhe pastaj mbyllni atë pas testet kanë përfunduar. Kontejnerët janë të dobishëm për shkallëzimin automatik dhe ribalancimin e ngarkesa kur ndodhin dështimet e nyjeve. Vendosjet janë shumë më dinamike dhe të paqëndrueshme duke përdorur kontejnerë. Sidoqoftë, ashtu si vetë arkitektura e mikrosherbimit, koleksioni i shpërndarë i kontejnerëve krijon sfida në lidhje me monitorimin dhe modelimin e performancës. [3 f. 224-226, 14 f. 50] Monitorimi ofron pasqyrë në lidhje me performancën dhe matjet përkatëse të biznesit për zhvilluesit e softuerëve, arkitektët dhe analistët e biznesit, të tilla si sa kërkesa mund të shërbejë baza e të dhënave në sekondë. Përdoret për të zbuluar anomali, të tilla si pse është një shërbim përdorimi i burimeve në mënyrë të tepruar dhe dhënia e kohërave të gjata të përgjigjes. Mund të jetë e vështirë të përcaktohet se cila është e ashtuquajtura sjellje normale për shkak të ndryshimeve të shpeshta. Aplikacioni është përbërja nuk ka gjendje të qëndrueshme, e cila mund të çojë në alarme të rremë të rastit. Në arkitekturën e mikroservisit, monitorimi mund të zgjerohet për të ndjekur një kërkesë nga fundi në fund ose shëndetin e një shërbimi të caktuar. Sidoqoftë, të dhënat e mbledhura nga monitorimi mund të jenë shfrytëzuar për të shqyrtuar pika të ndryshme me interes të tilla si statusi dhe dështimet operacionale të shërbimeve. Mund të përdoret gjithashtu për të reflektuar në vetë zhvillimin duke redaktuar proceset për ciklet e zhvillimit në të ardhmen, edhe pasi softueri të vihet në prodhim. Për shembull, tubacioni mund të përshtatet me kërkesat shtesë dhe të përdoret për të vendosur cilat teste duhet të ekzekutohen dhe sa shpesh. [11]

6.1 ORKESTRIMI I KONTINJERËVE DHE DOCKER

Menaxhimi i kontejnerëve quhet orkestrim. Ajo përcakton funksionalitetin dhe bashkëpunimin e kontejnerëve të shërbimit. Kjo përfshin veprime nga procedurat themelore të tilla si fillimi dhe ndalimi i kontejnerëve, deri në krijimin e imazheve, monitorimi dhe konfigurime më të përparuara. Kontejnerët ofrojnë funksionalitet të përshtatshëm, për shembull, për të të mbulojë situatën e lartpërmendur ku bëhet rikuperimi i shërbimit ose balancimi i ngarkesës duke sjellë më shumë raste të shërbimit të tensionuar. Mjeti i

orkestrimit mund të krijojë automatikisht më shumë kopje të një ene të caktuar dhe t'i ridrejtojë kërkesat në raste të ndryshme. Shumë mjete për orkestrimin e kontejnerëve janë zhvilluar në përgjigje të nevojave të ndërmarrjeve të përmasave të ndryshme, në masën kur ato kanë formuar një treg konkurrues. Pak mjete të njohura janë Docker (me tufën e tij të integruar Docker Swarm), Kubernetes, Rancher, Red Hat OpenShift, Apache Mesos dhe Kontena. I fundit i përmendur, Kontena, është në fakt një zgjidhje e një kompanie finlandeze Digia që synon më të vogël, me shpirt fillestar ekipet e zhvillimit më shumë sesa ajo për të cilën synon Kubernetes. Për më tepër, disa shërbime cloud ofrojnë platforma të ngulitura për orkestrimin e kontejnerëve, të tilla si Amazon Web Service dhe Microsoft Azure. Mjetet e orkestrimit të kontejnerëve kanë disa funksione të zakonshme, por ato zakonisht janë e specializuar për qëllime të ndryshme. Për shembull, mjetet e menaxhimit të grupeve të tilla si Kubernetes mund të menaxhojnë automatikisht vendosjet në grupin e burimeve të disponueshme të makinës. Platformat cloud ofrojnë mundësi edhe më tej, siç është mënyra se si Amazon Lambda fsheh krejtësisht makineritë nga zhvilluesit. [3 f. 225-226] Docker u zgjodh për projektin për shkak të veçorive të tij që mbështesin një shkallë të gjerë aplikimi dhe një integrim Kubernetes jashtë kutisë. Docker u botua në 2013 dhe në atë kohë ishte një nga pionierët e parë në fushën e teknologjisë së kontejnerëve. Sot, njihet pothuajse si standardi i industrisë. Docker fillimisht lindi nga një kontejner projekti i hulumtimit të teknologjisë nga kompania franceze PaaS e quajtur dotCloud, prej nga është ishte veçuar në kompaninë e vet. Docker është ndërtuar kryesisht në LXC, por ekzekutimi i tij mjedisi u ndryshua në bibliotekën e vet të quajtur libcontainer. Docker ka më shumë karakteristika të bazuara në kernel dhe të orientuara drejt aplikimit për të menaxhuar proceset dhe izolimin brenda host se shumë implementime të mëparshme. Ajo ka një arkitekturë server-klient, ku një pjesë thelbësore është daemoni Docker i cili komunikon me kontejnerët. Për më tepër, Docker ofron veçori të tjera të njohura të tilla si Docker Hub, i cili është i hapur platformë për komunitetin për të shtuar imazhe të gatshme të kontejnerëve të shkarkueshëm. [9, 14 f. 48, 15] Kontejnerët nuk ishin vërtet shpikje e Docker. Ide të ngjashme të bazuara në kontejnerë, të tilla si Burgjet FreeBSD, Zonat Oracle, OpenVZ për Linux dhe LXC të përmendura më herët,

ishin shqyrtuar tashmë disa vjet më parë. Në ditët e sotme, programe të shumtë si sistemet operative dhe aplikacionet në internet po përdorin kontejnerë, edhe nëse përdoruesit përfundimtarë mund të mos e përdorin vëreni atë. Për shembull, motori i kërkimit i Google, email dhe shërbime të tjera në re janë duke përdorur teknologjia e tyre e kontejnerëve me burim të hapur të quajtur Më lejoni ta përmbajë atë për ju (LMCTFY). [16] Docker, megjithatë, ishte implementimi i parë komercial që mblodhi disa tipare të favorshme nga shumë prej mjeteve të mëparshme në një, platformë kontejnerësh të gatshme për përdorim. Docker bashkëpunoi me kompani të tjera që kishin hulumtuar dhe zhvilluar teknologjitë e kontejnerëve, e cila ishte një arsye që Docker të bëhet gati e standardizuar. Bashkëpunimi bëri të mundur që zhvilluesit të dilnin me të përkufizimet dhe udhëzimet e përbashkëta.

Docker përbëhet nga tri komponente bazë: • Daemon (proces që ekzekutohet në mbrapavijë), I cili funksionon si server dhe kontrollon orkestrimin e automatizuar të kontinjerëve. • REST API, përmes së cilës aplikacionet komunikojnë me të • CLI (Command Line Interface), i cili lejon ekzekutimin e komandeve në Docker dhe në të njejtën kohë mundëson kontroll manual mbi kontinjerët. Platforma përfshin shumë detyra në dispozicion për orkestrimin. Me CLI, Docker përdoruesi mund të sjellë ose mbyllë kontejnerët kur nuk nevojiten më, listoni të gjitha kontejnerët që funksionojnë, shpërndani ato në servera të ndryshëm ose makina virtuale dhe ndani ngarkesa e trafikut midis tyre për të përmendur disa shembuj. Në rast të përçarjes, kontejnerët mund të zhvendoset nga një vend në tjetrin, të rindizet ose kopjohet si instanca të reja pa shqetësime në ofrimin e shërbimit.

6.2 VIRTUALIZIMI

Koncepti i virtualizimit besohet të ketë origjinën në vitet 1960 dhe fillim të viteve 1970. Pionierët ishin International Business Machines Corporation, IBM, i cili shpenzoi mjaft përpjekje për të zhvilluar teknologji efikase të ndarjes së kohës për kornizat e tyre kryesore. Ndarja e kohës lejon që fuqia informatike e një linje kryesore të ndahet në aksione të cilat mund të shpërndahen në grupe të ndryshme të përdoruesve [17]. Duke kaluar përpara në fund të viteve 1990, kompania e teknologjisë VMware zhvilloi produktet e para të virtualizimit të cilat munden virtualizoni arkitekturën x86[18]. Me Virtualizimi x86 hardueri dhe sistemi operativ u ndanë në dysh nga një abstraksion avokat. Shtresa e abstraksionit lejon që sistemet operative dhe aplikacionet të funksionojnë në makina fizike për t'u bërë agnostikë e pajisjeve dhe me atë vjen shkathtësia në rritje dhe vazhdimësia e biznesit. Shërbimet nuk kanë më nevojë të hiqen për mirëmbajtjen e pajisjeve ose rezervë sepse aplikacionet lehtë mund të migrohen në hostë të tjerë fizikë ose kopjuar. Në një letër të bardhë nga viti 2007 VMware deklaroi se kishte klientë me prodhim servera të cilët kishin funksionuar për më shumë se tre vjet pa ndërprerje [18].

6.2.1 VIRTUALIZIMI I HARDUERIT

Virtualizimi i harduerit është një teknologji e cila krijon një shtresë abstraksioni midis hardueri dhe sistemi operativ. Bëhet nga softueri i quajtur hipervizorë. Hypervizorët vijnë në forma të ndryshme por ekzistojnë dy lloje kryesore; Hypervisors Type-1 dhe Type-2 hipervizorët. Hypervizorët e tipit 1 gjithashtu referohen si hipervizorë të metaleve të zhveshura sepse ato funksionojnë drejtpërdrejt në harduer. Shembuj të hipervizorëve të tipit 1 janë Microsoft HyperV, VMware ESXi dhe Citrix XenServer. Hypervizorët e tipit 2 funksionojnë në një sistem operativ host dhe për këtë arsye vjen me rritje të përgjithshme për makinat virtuale. Shembuj të Hipervizorët e tipit 2 janë VMware Workstation dhe Oracle VM VirtualBox [19]. Funksionaliteti kryesor i virtualizimit të harduerit është të bëjë sisteme të shumta operative dhe aplikacione të ekzekutueshme paralelisht në të njëjtin harduer duke krijuar raste virtuale të harduerit për secilën makinë virtuale dhe në këtë mënyrë të bëni kursime në kosto duke rritur përdorimin e harduerit [20]. Produkti më i hershëm nga ana e

serverit që arriti të bënte ky ishte VMware ESX. Përdorte një bërthamë të ndërtuar me porosi të quajtur VMkernel e cila ishte krijuar për të ekzekutuar dhe menaxhuar ngarkesat e punës së makinës virtuale. Vetë VMkernel drejton një Monitor Virtual Machine, VMM, për çdo makinë virtuale në sistem. VMM është përgjegjës për implementimin e harduerit virtual dhe ekzekutimin e makinës virtuale. Në mënyrë që të kemi makina të shumta virtuale drejtimin në të njëjtën host, ata duhet të jenë të izoluar nga njëri-tjetri dhe harduerin aktual aktual. Për të ilustruar pse është kjo e rëndësishme mund të imagjinohet që një makinë virtuale të dërgojë një udhëzim të privilegjuar fik veten. Në mënyrë që ky udhëzim të çaktivizojë vetëm makinën virtuale dhe jo i gjithë sistemi, thirrja duhet interpretohet në mënyrën e duhur. Për këtë qëllimi përdoret një teknikë e quajtur përkthim binar. Teknika bllokon të privilegjuarit udhëzime që vijnë nga makinat virtuale dhe i përkthen ato në atë që do të thotë udhëzimi në kontekstin e burimit që është një makinë virtuale. Figura 8 përshkruan si funksionon virtualizimi i plotë me përkthim binar në lidhje me unazat e ekzekutimit të udhëzimeve të arkitekturës x86 [18].

Figura 8: Virtualizimi duke perdorur perkthimin binary [18]

Një qasje tjetër e hershme për virtualizimin e pajisjeve është paravirtualizimi. Përdorimi i paravirtualizimit kërkon që sistemi operativ i vizitorëve të modifikohet me aplikacionet e menaxhimit të virtualizimit dhe drejtuesit e pajisjeve. Avantazhi i kësaj është heqja e nevojës për përkthim binar duke e bërë të ditur sistemin operativ mysafir se po virtualizohet. Me këtë vetëdije shtesë mysafiri sistemi operativ zëvendëson udhëzimet e privilegjuara jo të virtualizueshme me hiper thirrjet. Hypercalls janë udhëzime të veçanta të cilat i dërgohen 36

hipervizorit. Hypervisor pastaj përcjell udhëzimet e privilegjuara te hardueri. Paravirtualizimi supozohet të zvogëlojë vlerën e sipërme të virtualizimit duke hequr nevojën për të përkthim binar por pretendimet e VMware performancës ndryshojnë shumë në varësi të ngarkesës së serverit dhe shtyp fakti që paravirtualizimi shkakton më shumë kompleksiteti kur bëhet fjalë për menaxhim dhe mbështetje për shkak të nevojës për të modifikuar bërthamat e sistemit operativ mysafir. Figura 9 përshkruan se si paravirtualizimi punon në lidhje me unazat e ekzekutimit të udhëzimeve të arkitekturës x86 [18].

Figura 9: Virtualizimi duke perdorur paravirtualizimin [18]

Në dekadën e fundit një qasje e tretë është përdorur virtualizimi i harduerit që është virtualizimi i asistuar nga hardueri. Ajo u shfaq për herë të parë në 2006 kur Intel Corporation dhe Advanced Micro Devices lëshuan tiparet e tyre përkatëse të mbështetjes për virtualizimin e pajisjeve, Intel-VT dhe AMD-V Shtesat e reja shtuan një të re Karakteristika e mënyrës së ekzekutimit të CPU-së që do të thoshte VMM mund të ekzekutohet nën unazën 0, në një mënyrë e re e quajtur rrënjë (nganjëherë referohet si unaza -1). Thirrjet e privilegjuara të udhëzimeve bllokohen automatikisht në hypervisor dhe duke hequr kështu nevojën për përkthim binar dhe gjithashtu heq duhet të ekzekutojnë sisteme operative të modifikuara duke përdorur qasjen e paravirtualizimit. Figura 2.3 përshkruan se si ndihmohet nga hardueri

virtualizimi funksionon në lidhje me unazat e azhurnuara të ekzekutimit të udhëzimeve të arkitektura x86 [18].

Figure 10: Virtualizimi duke perdorur virtualizimin e harduerit [18] 6.3 KONTINJERIZIMI

Kontinjerizimi është një virtualizim i nivelit të sistemit operativ që përdoret për të siguruar izolimin dhe menaxhimin e resurseve, kryesisht në mjediset Linux. Emri i kontejnerizimit rrjedh nga mënyra e standardizimit të kontejnerëve të transportit dhe në kontekstin e aplikacioneve i referohet një mënyre të shkathët të paketimit të aplikacioneve në një mjedis të izoluar të ekzekutimit. Izolimi krijohet nga tre përbërës kryesorë; chroot, grupet dhe bërthama hapësira emrash. chroot është një komandë në Linux e cila lejon një proces të ndryshojë direktorinë rrënjë për të krijuar skedarë specifikë të kontejnerëve. cgroups është nënsistemi i bërthamës me të cilin proceseve mund tu caktohen kuotat e burimeve. Hapësira e emrave të kernelit mundëson që çdo kontejner të marrë konfigurimin e tij të rrjetit dhe komunikimin ndër-procesor, IPC, hapësirat e emrave [16]. Figura 11 tregon një përmbledhje të arkitekturës së kontejnerizimit.

Figure 11: Arkitektura e organizimit te kontinjereve Shembuj të sistemit operativ të konteinerëve siç shihet në figurën 11 janë CoreOS, Photon OS që janë krijuar posaçërisht për këtë qëllim, por shumica e shpërndarjeve kryesore Linux kanë mbështetje për të drejtoni një motor kontejner. Një Motor Kontejnerësh, për shembull Docker ose rkt, është softueri i cili drejton kontejnerët. Kontejnerizimi lejon krijimin e shumë shembujve të hapësirës së përdoruesit të cilët janë të izoluar njëri-tjetrin, dhe janë këto raste të segmentuara të cilat referohen si kontejnerë. Në Linux ku shpërndarjet e shumta Linux përdorin të njëjtën bërthamë që lejon secili kontejner të ketë një shpërndarje të veçantë nga OS host i kontejnerit. Aplikimet që ekzekutohen brenda ato mund të kenë bibliotekat e veta dhe kontejnerët mund të përshtaten për t'iu përshtatur këtij aplikacioni të veçantë. Pjesët e sistemit operativ të kontejnerit që ndahen nga kontejnerët janë vetëm për lexim për kontejnerët, ndërsa ata kanë pjesën e tyre në të cilën mund të shkruajnë. Ndarja e burimeve të kernelit i bën kontejnerët shumë më të lehtë se sa ato homologu i makinës virtuale. Brenda kontejnerëve është mjaft e mjaftueshme për të ekzekutuar çdo aplikacion, duke e mbajtur madhësinë e tij në minimum, drejtuesit mbahen brenda sistemit të përbashkët si pjesë e bërthama. Kontejnerët lejojnë që aplikacione të shumta të ekzekutohen të izoluara nga secila tjetri një OS i vetëm i përbashkët. Për të ekzekutuar shumë aplikacione të izoluara në të njëjtin host në virtualizimin tradicional të serverit, duhet të krijohet një makinë virtuale (VM) për secilën aplikacion [16].

6.4 CLOUD SERVICES

Termi Cloud computing në përgjithësi nënkupton ofrimin e qasjes në resurset procesuese përmes internetit. Avantazhi kryesor që ofron është se përdoruesi nuk ka nevojë për të të ndërtojë dhe mirëmbajë infrastrukturën e vet dhe mund të përqendrohet më shumë në zhvillimin e një aplikacioni. Cloud Computing ka filluar të lulëzojë një dekadë më parë. Lojtari i parë i madh ishte Amazon, me produkti i tij i quajtur Amazon Web Services, i cili u lansua në 2002. Në 2006 Amazon prezantoi Cloud Elastic Compute që u dha mundësinë përdoruesve të marrin me qira informatikë burimet në të cilat ata mund të ekzekutojnë aplikimet e tyre. Në vitin 2009 dy lojtarë të tjerë të mëdhenj hyri në treg: Google me Google App Engine dhe Microsoft me Windows Azure Ekzistojnë tre lloje të modeleve të shërbimit që dallohen tradicionalisht në cloud informatikë. Softueri si një Shërbim - një model në të cilin kompanitë ofrojnë qasje në softuerin e tyre që po punon në një infrastrukturë cloud [22]. Shembull tipik është Microsoft Office 365. Dikush mund të përdorë aplikacione të tilla si Word, Excel, PowerPoint në internet dhe të ketë qasje atyre përmes pajisjeve të ndryshme. Përfitimi i përdorimit të këtij lloji të shërbimit është ai që përdoruesi nuk ka nevojë të instaloni ndonjë softuer. Për më tepër rezervimi i të dhënave është përgjegjësi e cloud ofruesi. Platforma-si-një Shërbim - një model, në të cilin përdoruesi ka mundësinë të shfrytëzojë cloud infrastruktura me zinxhir mjetesh për të menaxhuar aplikacionet. Menaxhimi i fizike ose instancat llogaritëse virtuale, rrjetëzimi, hapësira ruajtëse kryhet nga ofruesi i resë kompjuterike. [21] Infrastruktura-si-një Shërbim - ndryshimi kryesor midis modelit PaaS është ai në IaaS përdoruesi merr qasje në infrastrukturën cloud. Ai siguron më shumë mundësi për të menaxhuar burimet, kontrollimin e rrjeteve, instalimin e programeve të ndryshëm. Në të njëjtën kohë shtresa fizike është ende përgjegjësi e ofruesit të resë kompjuterike. [21] Në ditët e sotme ka më shumë modele përveç atyre që u shpjeguan më parë. Për shembull Desktop si një DaaS Shërbimi i cili jep hapësirë pune të gatshme për të përdorur për klientin.

Sidoqoftë, ata nuk janë pjesë e këtij sondazhi. [21] Një temë tjetër që duhet të trajtohet në këtë pjesë janë llojet e reve. E para është Public cloud. Ky lloj cloud është në dispozicion për publikun e gjerë. Pengesa kryesore e tij është mungesa e sigurise. E dyta që duhet përmendur është Private Cloud. Në përgjithësi kjo re është përdoret vetëm brenda një organizate. E fundit por jo më pak e rëndësishmja është Reja Hibride. Kjo është kombinim i atyre publik dhe privat.

7 PËRSHKRIMI i EKSPERIMENTIT Instalimi i Docker në secilën nga distribucionet e Linux-it në ditët e sotme është një process shumë i lehtë, që do të thotë atë mund ta instalojmë nga menaxheri i paketeve të secilit nga distribucioneve. Ubuntu: duke supozuar qe është verzioni 14.04, komanda për instalim është sudo apt-get install docker-io ose në mënyrë alternative duke përdorur wget wget -qO- https://get.docker.com | sh CentOS, Fedora: në këto distribucione, yum është ajo që përdoret Sudo yum install docker-io Nganjëherë, paketa e përmendur është thjeshtë vetëm ‘docker’, sidoqoftë mund të ketë edhe konflikt në emërtimin e paketeve me aplikacionin e system tray (psh. Në CentOS 6.5), për atë është më e sigurtë të përdoret docker-io. Boot2Docker: është një distribucion i lehtë i Linux, i bazuar në Tiny Core Linux – i cili është një tjetër distribucion i vogël me vetëm 12MB. Ndër rastet ku përdoret më së shumti është mundësimi i Docker në Windows ose OS X. Për Windows dhe OS X një file ekzekutues ofrohet, i cili instalon Virtual Box dhe krijon një makinë virtuale me systemin e Boot2Docker dhe shton një aplikacion dhe komandet e shellit për menaxhimin e tij.

Figure 12: Instalimi I Boot2Docker

Windows: Edhe pse Docker kërkon kernelin e Linux-it, është e mundëshme të instalohet në Windows përmes Boot2Docker, të cilën do ta eksplorojmë më vonë. Sidoqoftë, është e mundshme të përdoret versioni vetëm për klient, i cili është lëshuar përmes versionit të Docker 1.6. Paketa për momentin është e disponueshme përmes menaxherit të paketeve të chocolatey. OS X: Me OS X, është një situatë pothuajse e ngjajshme me Windows, që do të thotë që mund të përdoret ose përmes Boot2Docker ose Kitematic. Kitematic funksionon ngjajshëm me Boot2Docker, i cili instalon VirtualBox për të krijuar një Makinë Virtuale me Docker, por ofron një GUI më të pasur për menaxhimin e Dockerëve. Si me çdo platformë tjetër, hap ii parë për të ekzekutuar një aplikacion është që menjëfar forme të marrim binaryët/skriptat dhe të dhenat. Për Docker, i tërë aplikacioni është i paketuar dhe ajo quhet imazh dhe këto imazhe ruhen në regjistra.Për momentin, ekziston një regjistër default, i cili mund të eksplorohet përmes shfletuesit ose në mënyrë alternative përmes komandës së dockerit për të parë të gjitha imazhet e disponueshme.

Figura 13: Kërkimi I imazheve në Docker Registry

Komanda search aktualisht kthen repozitoriumet, të cilat mund të përmbajnë disa verzione të imazheve, secila me version tag të ndryshem, por secila prej tyre kanë të disponueshme tagun “latest”. Një imazh dockeri gjithashtu është i identifikuar në mënyrë unike përmes një ID.

Është e rëndësishme të vërehet që vetëm ID e imazhit është në të vërtetë identifikuesi unik, pasi që dy imazhe mund të vijnë nga e njejta repositorium dhe të kenë të njejtin tag të versionit, por mund të jenë të ndryshme, psh. Në rastin e tagut “latest”. E gjithë esenca është normalisht gjatë përdorimit të Docker, virtualizimi që ajo sjellë, pra kur një imazh të ekzekutohet, Docker krijon një kontinjer dhe e vendos aplikacionin Brenda imazhit të tijë. Për të ekzekutuar një imazh, ne mund të specifikojmë ose ID e imazhit, emrin e repozitoriumit të bashkëngjitur me tag, ose vetëm emrin e repozitoriumit, ku në këtë rast default tag-u “latest” do të përdorët.

Figura 14: Ekzekutimi I kontinjerëve në docker engine Parametrat -t -i i tregojnë Docker-it të bashkëngjisë një pseudo TTY në kontinjer, ku pasi që të gjitha shtresat (layers) të shkarkohen, një output i konzolës nga kontinjeri mund të shihet

Figura 15: Output I ekzekutimit të kontinjerit në docker engine

Një numër i parametrave opcional mund të kalohet njëashtu, duke përfshirë opsionin për të emërtuar kontinjerin, specifikim e portit të mapuar nga kontinjeri në host, ose përdorimi i DNS serverëve të kustomizuar Brenda kontinjerit. Output konzola gjithashtu tregon që imazhi automatikisht është shkarkuar nga regjistrat para se të ekzekutohet lokalisht. Nëse do të dëshironim vetëm të shkarkonim imazhin, ne do të

kishim mundur të jepnim vetëm komandën “docker pull”. Një opsion tjetër që do të ishte i dëshiruar do të ishte vetëm krijimi in jë kontinjeri nga imazhi, por jo ekzekutimi i tij. Për këtë qëllim ekziston komanda docker create. Për kontinjerët në host, Docker ofron të gjitha mundësitë bazike, si psh. Listimi i të gjitha kontinjerëve, stopimi apo largimi i atyre kontinjerëve. Mundësitë më interesante janë ekzaminimi i log fileve (docker logs), shiqimi i proceseve Brenda kontinjerëve (docker top) ose konektimi Brenda kontinjerit të ekzekutuar (docker attach). Njëra nga opsionet më të rëndësishme është mundësia e ekzekutimit të kontinjerit në mbrapavij duke përdorur daemon mode me komandën -d. Gjatë startimit të kontinjerit, është e mundshme të impozohet restrikcioni i numrit të resurseve që mund të përdoret. Për të përdorur në maksimum limitin e memorjen për kontinjerin e dhënë, -m parametri përdoret, dhe -c parametri për ti dënë nivelin e prioritetit të CPU. Këto parametra aktualisht i kalohet modulit të cgroupeve, që janë përshkruar më lartë. Mapimi i porteve të kontinjerit në host portet mundëson aftësinë e të pasurit shumë kontinjerë, në të cilat proceset ekzekutohen në të njejtin port.

7.1 IMPLEMENTIMI I PROJEKTIT DHE TE GJETURAT

Në mënyrë që të elaborohet pjesa laboratorike e kësaj teze është krijuar një ambient i bazuar në makinë virtuale por zhvillimet janë bërë në atë mënyrë që të jenë fleksibile për migrim në ambiente të cloud dhe mundësinë që të mos vërehet rëndësia e hostimit. Makina Virtuale siç është përshkruar më lartë më së miri ekzekutohet kur për bazë ka një sistem operativ të bazuar në Linux, pasi Docker varret shumë nga kernel i Linux-it, për pjesën tonë laboratorike kemi përzgjedhur Linux CentOS 7 me 8GB Ram dhe 4vCPU. Makina është e instaluar në një particion /dev/sda me rreth 70GB të diskut të shpejtë (SSD) dhe është e konektuar me një VLAN ku është e çasshme hapësira për interkonektim në Internet.

Figura 16: Krijimi i VM në të cilin hostohet docker engine Është e rëndësishme gjatë pjesës së krijimit të environmentit të krijohet një environment kompatibil me të gjitha pjesët e zhvillimit, duhet pasur parasysh që qëllimi i kësaj teze është zhvillimi i mikroserviseve në kontinjerë ku atë mund ta bëjmë deploy si ne servera lokal, cloud apo orkestrues të pa-menaxhueshëm.

Figura 17: Alokimi i resurseve për instalimin e VM për docker Pasi që kemi krijuar makinën virtuale presupozojmë që kemi instaluar një distribucion siç e kemi përmendur më lartë duke u bazuar në sistemin operativ Linux.

Figura 18: Verifikimi i sistemit operativ dhe build number Pasi kemi verifikuar instalimin e sistemit operativ, duhet te bëjmë me domosdoshmëri azhurimin e skedarëve për të larguar ndonjë rrezik potencial të ndonjë dobësie të sigurisë në sistem. Është e rëndësishme të përmendet që të krijojmë një user lokal Brenda sistemit tonë operativ – dhe mos të përdorim llogarinë tonë e cila është inicializuar gjatë instalimit ‘root’. Pasi është bërë verifikimi i gjitha instancave të sistemit operativ, për të plotësuar nevojat e kësaj teme duhet bërë instalimi i paketeve për përdorimin e docker si dhe instalimi i serviseve të nevojshme. Duke presupozuar që është shtuar repozitoriumi i Docker paketeve, atëherë bëjmë inicializimin e paketeve përmes komandës: $ sudo yum install docker-ce docker-ce-cli containerd.io

Figura 19: Azhurimi i sistemit operativ Linux me paketet e fundita Pasi kemi instaluar paketet e nevojshme verifikojmë se servisi është instaluar me sukses dhe në restartimin potencial të makinës tonë, servisi do të startohet në mënyrë automatike.

Figura 20: Verifikimi i ngarkimit të servisit të docker

Docker na ndihmon në krijimin e një njësie për lansimin e aplikacionit tonë. Kjo njësi, që quhet kontinjer, ka gjithçka që i duhet një aplikacioni të funksionojë. Duke përfshirë kodin (ose binarët), runtime, veglat e sistemit dhe libraritë. Paketimi i të gjitha varrëshmërive në një njësi të vetme, siguron një ambient identic për aplikacionin, pa marrë parasyshë se ku bëhet deploy. Ajo gjithashtu ndihmon në mirëmbajtjen e ambienteve të zhvillimit dhe produksionit (live). Kjo gjithashtu, është edhe thelbi i temës tonë, ku do të zhvillojmë mikroservise në kontinjerë dhe nuk do të kemi nevojë për varrëshmeri të mbienteve, por atom und të i lansojmë në infrastrukturën tonë, cloud, apo edhe vegla orkestruese të kontinjerëve (Kubernetes, Openshift, Swarm, Digital Ocean). Kontinjerët gjithashtu eliminojnë një varësi të problemeve që shkaktohen nga skedarët që nuk janë në sinkronizim ose përshkak të dallimeve të ndryshme në ambientë të produksionit. Në këtë tezë do të ndjekim zhvillimin e një mikroservisi në gjuhën Go Lang. Shumica e Go aplikacioneve janë binarë të thjeshtë. Kjo gjitashtu ndjekë pyetjen se pse të zhvillojmë këtë mikroservis në Docker. Disa nga arsyet që janë parashtruar në identifikimin e problemit janë se: - Ueb aplikacionet tipikisht kanë shabllone dhe skedarë të konfigurimit. Docker ndihmon që këto skedarë janë në sinkronizim me binaryët. - Docker siguron për krijim identic të zhvillimit në ambientin zhvillues dhe produksion. Shumë shpesh, kemi ndëgjuar që aplikacionet funksionojnë në ambientin zhvillues por jo në produksion. - Makinat, Sistemet Operative, dhe softuerët e instaluar mund të ndryshojnë drastikisht ndërmjet ambienteve zhvilluese. Docker ofron një mekanizëm për të siguruar një ambient konçiz të ambientit zhvillues. Në këtë temë, do të përdorim një ueb aplikacion të shkruar në Go për demonstrimin e përdorimit të Docker. Këtë Aplikacion do ta quajmë DockerApp, dhe do të: • Ekspozojë rutat e operacioneve të ndryshme matematike, • Do të përdorë HTML shabllonet për views, • Do të përdorë një skedarë konfigurues për kustomizimin e aplikacionit, dhe • Do të përfshijë testimet për funksionet e selektuara. Pasi të përfundohet aplikacioni, struktura e direktoriumeve të DockerApp do të jetë:

DockerApp ├── Dockerfile ├── Dockerfile.deploy └── src ├── conf │ └── app.conf ├── go.mod ├── go.src ├── main.go ├── main_test.go ├── vendor └── views ├── invalid-route.html └── result.html Skedari kryesor i aplikacionit do të jetë main.go, i cili do të gjindet tek direktoriumi ‘src’. Ky skedar do të përmbajë të gjitha funksionalitetet e këtij aplikacioni. Disa nga funksionalitetet nga ‘main.go’ testohet nga skedari ‘main_test.go’. Folderi views përmbanë skedarët view ‘invalid-route.html’ dhe ‘result.html’. Skedari konfigurues ‘app.conf’ gjindet Brenda folderit ‘conf’. Frameworku Beego përdor këtë file për të kustomizuar aplikacionin. Për të komplementuar zhvillimin tonë do të krijojmë një repositorium në github, në të cilin do të vendosim të gjitha skedarët e nevojshëm për zhvillimin e këtij mikroservisi në docker.

Figura 21: Krijimi i repozitoriumit për aplikacionin në Github

Pasi kemi krijuar repozitorumin do ta incializojmë atë në mënyrë që skedarët që do të zhvillohen lokalisht të sinkronizohen në repositorium dhe të jënë të disponueshme Brenda repos tonë.

Figura 22: Klonimi i repozitoriumit në serverin lokal Pasi kemi inicializuar emrin e repozitoriumit për të përdorur projektin tanë, definojmë variablat për përdorimin e aplikacionit në GO si dhe e incializojmë aplikacionin tonë. $ export GOFLAGS=-mod=vendor $ export GO111MODULE=on $ go mod init github.com/agnesasaliaga/thesisapp

Pasi që kemi inicializuar aplikacionin fillojmë të vendosim kodin tonë brenda direktoriumeve të sipër përmendura. Skedari kryesor (main.go) përmban të gjithë logjikën e aplikacionit. Kontenti i atij skedari është paraqitur në figurën e mëposhtme:

Figura 23: skedari kryesor në të cilin gjindet kodi main.go

Ka raste kur programerët këto funksione mund të i vendosin në skedarë të ndryshëm, por duke pasur me rëndësi qëllimin e kësaj teme, në zhvillimin e mikroserviseve në kontinjerë nuk do të fokusohemi në operimin e kodit por në lansimin(deploy) të saj. Skedarët view janë HTML shabllone të cilat do të përdoren nga aplikacioni për të paraqitur përgjigjen nga kërkesat e ueb shfrytëzuesit. Kontenti i result.html është paraqitur në figurën e mëposhtme:

Figura 24: Skedari view në të cilin paraqitet output për klientin e uebshfletuesit Kontenti i invalid-route.html ku në rast se bëhet një kërkese në ueb aplikacion të cilin ne nuk e kemi trajtuar

Figura 25: Skedari view në të cilin paraqitet output në rast se nuk kemi përzgjedhur API Endpoint të duhur Skedari app.conf është një skedar i cili lexohet nga framework Beego për të bërë konfigurimin e aplikacionit. Përmbatja e tij është si më poshtë: appname = dockerapp runmode = "dev" httpport = 8010

ku në këtë rast, appname është emri i procesit ng ai cili aplikacioni do të lansohet, runmode specifikon se në çfarë ambienti aplikacioni do të bëhet deploy, httpport është porti në të cilin aplikacioni do të dëgjojë thirrjet. Pjesa e fundit për komplimentuar zhvillimin e aplikacionit është shkrimi i Docker file, i cili është një skedar që komplemeton një imazh të plotë, pa ndonjë varrëshmeri nga ndonjë source i jashtëm apo diçka që varët nga sistemi vetvetiu.

Figura 26: Skedari në të cilin gjendet Dockerfile Më poshtë do të spjegojmë në mënyrë të detajuar se secila komande çfarë vlere ka. FROM golang:1.14 as builder Na tregon që ky aplikacion është një multi-stage build; definon një imazh mesatar që ka vetëm një detyrë: të bëjë kompajllimin e Go binarëve.

RUN groupadd $APP_USER && useradd -m -g $APP_USER -l $APP_USER RUN mkdir -p $APP_HOME && chown -R $APP_USER:$APP_USER $APP_HOME

WORKDIR $APP_HOME USER $APP_USER COPY src/ .

Krijon direktoriumin e userit dhe aplikacionit për userin e aplikacionit. Shfrytëzuesit e aplikacionit janë opcional, por konsiderohen si një praktikë e mirë për tiu ikur ekzekutimit të proceseve sikur root. Pjesa finale vjen brenda kontinjerit, ku ne duhet të ekzekutojmë serviset. Ne nuk kemi nevojë për një instalim të plotë të Go-së për të ekzekutuar proceset, kështuqe mund të përdorim një imazh të vogël të Debian-it:

FROM debian:buster

Në përdorim komandën COPY për të kopjuar skedarët e kodit brenda imazhit. • chown: ndryshon pronarin dhe grupin e skedarëve dhe direktoriumeve. • from: kopjon të ekzekutueshmet nga imazhi i ndërmjetshëm që e bën procesin e build.

COPY src/conf/ conf/ COPY src/views/ views/ COPY --chown=0:0 --from=builder $APP_HOME/mathapp $APP_HOME

Pjesa vendimtare është ekspozimi i portit dhe startimi i binarëve të aplikacionit ku aplikacioni fillon të ndëgjojë në portin 8010 dhe është i çasshëm përmes ueb shfletuesit. Për të kompajlluar kodin dhe ta bëjmë build imazhin do të përdorim kodin

$ docker build -t dockerapp-deploy .

Figura 27: Procesi ku bëhet build imazhi i docker kontinjerit

Ndërsa për ta ekzektuar aplikacionin dhe që ta bëjmë aplikacionin run: $ docker run -it -p 8010:8010 dockerapp-deploy

Figura 28: Ekzekutimi i docker container me komandën run

Pasi që kemi ekzekutuar komandën e mësipërme vërejmë se aplikacioni është ekzektuar dhe është duke ndëgjuar në portin që e kemi specifikuar. E rëndësishme është të përmendet se pjesa e rrjetit se si është ekspozuar ky port është i bazuar në adapterin ‘bridge’ që do të thotë se I gjithë trafiku I rrjetit do të jetë I drejtuar në portin e hapur që është mbrenda hostit që është duke u hostuar ky mikroservis/kontinjer. Nëse hapim IP e serverit dhe portin që e kemi ekspozuar këtë mikroservis mbrenda një shfletuesi, do të na kthehet një përgjigje, por është e rëndësishme pasi ky mikroservis funksionon me API të theksohet edhe endpoint I API-të

se cfarë dëshirojmë të bëjmë request. Për më shumëse si duket paraqitja vizuale dhe mënyra e thirrjës së endpointeve do të diskutojmë në seksionin e mëposhtëm tek pjesa e Rezultateve.

7.2 SFIDAT

Gjatë implementimit të këtij projekti si në çdo projekt tjetër, kemi hasur në sfida të ndryshme. Ato sfida kanë të bëjnë me caktimin e cakut të mikroserviseve dh emirëmbajtjes së idesë së përgjithshme të operimeve të tyre. Natyrisht, në çdo implementim të caktuar do të ketë procese specifike dhe fusha të ndryshme, lloje të ndryshme të dokumenteve dhe terminologjive. Në raste të përgjithshme zhvilluesit pranojnë udhëzimet, kërkesat dhe definicionet nga nivelet më të larta gjatë marrjes së kërkesave por jo gjithmonë do të jenë efektive gjatë implementimit dhe nganjëherë duhet të përdoren framework apo operacione të cilat e bëjnë më të implementueshme projektin. Në fillim, termi minimum viable product (MVP) shpesh është përdorur sa i përket fushës së serviseve. Për secilën prej tyre, MVP idealisht ka kuptimin e ofrimit të minimum funksioneve të cilat janë të nevojshme për release të parë. Sidoqoftë pas një kohe është vërejtur që kuptimi i serviseve të cilat janë pjesë e MVP- së kanë dalluar ndërmjet antarëve të grupit të zhvilluesve, dhe serviset kanë pësuar një risk të zgjërimit më të madh se që është planifikuar apo duke shtuar features që nuk janë paraparë. Si rezultat, është vendosur të largohet termi MVP përveçse nëse definicionet janë të kjarta për secilën nga serviset e zhvilluara. Të gjitha mundësitë e reja të cilat dekorojnë features bazë janë të larguara nga verzioni i parë, dhe shtohen më vonë.

Vendimarrja rreth përgjegjsive të serviseve gjithashtu reflekton komunikimin ndërmjet serviseve dhe arkitekturës së plotë. Nuk do të ishte optimale nëse dy apo më shumë servise kryejnë të njejtën detyrë apo ruajnë të njejtin set të të dhënave, por më mirë do të ishte të kemi një servis që përmban funksionalitetet dhe mund të përdoret nga një numër i serviseve tjera. Sidoqoftë, mund të bëhet evidente që një kërkesë të kalojë ndërmjet shumë serviseve, dhe në këtë rast do të ishe sikur ato funksione të grupoheshin brenda një servisi të mënjanohej potencialisht ndonjë vonesë në rrjet. Ndoshta një situatë më reale do të ishtë kur një servis të dërgojë të njejtën kërkesa shumë herë brenda një dite ose ore kur gjithmonë do të pranonte të njejtën përgjigje. Për shembull, edhe pse projekti përmban një servis që merr kodet

shtetërore nga një provajder i jashtëm, duke kërkuar kodet që përshkruajnë dokumentin, ajo njofton kur një kod ndryshon me kohën, dhe që shkakton një numër të madh të kërkesave HTTP të panevojshme. Ruajtja jo-perzistente (cache) do të ishte një alternative, por kodet vetvetiu azhurohen një herë në një kohë që praktikisht bëhen të pandryshueshme. Trafiku i rëndë i rrjetit ose vonesat nuk do të ishin problem i madh nëse aplikacioni zhvillohet në cloud, por ajo jo gjithmonë është një opsion i disponueshëm. Edhe pse pjesa dërmuese e komponenteve të aplikacioneve janë lansuar në cloud, ka shumë raste kur disa kërkesa do të bëhen në servera lokal në infrastrukturën e brendshme, ku përsëri ekziston një risk i vonesave të rrjetit. Verzionimi më aktiv i API-ve na sjellë tek një sfidë tjetër: azhurimi i informatave të verzioneve të API-të tek serviset konsumuese të cilat shumë shpesh mund të mbesin të pabëra, nëse askush nuk ka punuar në diçka të re rreth serviseve ekzistuese. Ekzekutimi i azhurimit në masë kur një version i r ii API-të lansohet nuk është i mundshëm, por duhen të azhurohen manualisht në secalin servis. Në anën tjetër, kjo është pjesë e mirëmbajtjës së secilit aplikacion.

Në përgjithësi sfidat kanë qenë mjaft të parashikuara nga natyra dhe jemi munduar të adaptohemi në situata të reja duke ndjekur kërkimet dhe duke iu bazuar udhëzimeve të parashtruara në fillim të kësaj teze, në mënyrën se si proceset dhe metodat mund të ndërohen për të ofruar cikle më të mira të zhvillimit.

8 REZULTATET

Gjatë përpilimit të kësaj teze, kemi diskutuar disa përafrime në mënyrën se si mund të ndihmojmë në përshpejtimin e ciklit të zhvillimit të softuerit, në mënyrën e hostimit të aplikacionit në mënyrë më efektive, si dhe ofrimin e mundësive të ofrimit të environmenteve të ngjajshme, duke përjashtuar mundësinë e të pasur ndryshime ndërmjet environmenteve, qoftë ajo dev apo produksion. Në këtë tezë kemi marrë shembull krijimin e një mikroservisi, e cila aplikacioni është shkruajtur në gjuhën Go Lang dhe kemi larguar varrëshmëritë e paketeve dhe binarëve të gjuhëve programuese. Kështu ne kemi krijuar një aplikacion autonom të bazuar në mikroservise, pa pasur nevojë të kemi një mbështetje të plotë nga sistemi operativ, por duke qenë shumë fleksibil edhe në implementimin e atij aplikacioni në environmente si cloud, apo orkestrues të kontinjerëve. Duke u nisur nga pikënisjet e parashtruara në fillim të kësaj teze, ne kemi ndjekur një model në të cilin kemi vërtetuar për thjeshtësimin e environmenteve dhe kodi jonë ka qenë thjeshtësisht i struktuaruar edhe në deploy në cloud environment. Në këtë tezë s shembull kemi pasur zhvillimin e aplikacionit në infrastrukturë lokale, por pa pasur nevojë për modifikime të mëtutjeshme apo humbje të kohës në ndryshimin e kodit kemi arritur ta plasojmë atë kod në cloud (AWS). Nga shembulli që kemi ndjekur mbrenda kësaj teze kemi arritur në rezultatet e mëposhtme.

Aplikacioni në tërësi ka arritur madhësinë prej vetëm 132MB, ku në raste tradicionale ky aplikacion do të kishtë një madhësi shumë më të madhe duke konsideruar se do duhej instaluar Sistemi Operativ, paketet e azhurimeve, veglat për ekzekutim, dependencies për ekzekutimin e kodit, libraritë dhe binarët e gjuhës programuese. Të gjitha këto janë mënjanuar ku është enkapsuluar vetëm një imazh dhe ai mund të ekzekutohet edhe në servera lokal, apo edhe ata cloud.

Figura 29: Enkapsulimi i docker imazhit në të cilin hostohet kodi

Eshtë krijuar një network mbrenda hostit në të cilin do të rutohet I gjithë trafiku që tenton të bëjë thirrje në portin e ekspozuar. Ky network ndan të njejtin adapter të rrjetit me hostin dhe nuk ka ndonjë komunikim të izoluar në të cilin potencialisht do të humbaseshin pakete.

Figura 30: Paraqitja e rrjetit të docker kontinjerit në të cilin hostohet kodi

Si rezultat I kësaj aplikacioni ynë plotësisht I qasshëm nga ambienti ku është bërë deploy, në këtë rast ne kemi hapur shfletuesin dhe në API kemi thirrur endpointin për prodhimin ndërmjet dy numrave 3 dhe 4. Response I kësaj ka qenë rezultati I këtij prodhimi si dhe në të njejtën kohë ky response ruhet në të dhëna perzistente. Përgjigja e mikroservisit është e menjëhershme pa pasur nevojë që të shtohen filtrime apo rutime shtesë për të përshpejtuar kthimin e rekordeve.

Figura 31: Përgjigja e aplikacionit kur bëjmë request në endpointin për prodhim

Operacioni I cili është kthyer në shfletues ne të njejtën kohë në mbrapavijë na jep informata të më detajueshme, ku vërehet endpoint I API I thirrur dhe klientin se kush e ka bërë këtë

thirrje, në këtë rast ueb shfletuesi me IP adresën e mëposhtme ka marrë përgjigjen për operacionin e prodhimit ndërmjet numrit 3 dhe 4 brenda 1.40206ms.

Figura 32: Ruajtja perzistente e të dhënave nga thirrjet e bëra nga API endpointet

Përpos operacionit të prodhimit, është zhvilluar edhe një endpoint në të cilin bëhet operacioni i mbledhjës. Në rastin e mëposhtëm, në endpointin e API-t janë vendosur dy vlera të cilat janë bërë thirrje në ueb shfletuesin e klientit. Ajo përgjigje i është kthyer ueb shfletuesit në kohë rekorde me vlerën e saktë.

Figure 33: Përgjigja e aplikacionit kur bëjmë request në endpointin për shumë

Njësoj si në rastin e parë, endpoint I dytë ka realizuar thirrjen, dhe ajo është regjistruar mbrenda mikroservisit, në të cilën është ruajtuar shënimi si e dhënë perzistente. Vlen të përmendet që kërkesa, kalkulimi dhe kthimi I përgjigjes tek ueb shfletuesi është realizuar për një periudhë prej 843.362 μs.

Figure 34: Ruajtja perzistente e të dhënave nga thirrjet e bëra nga API endpointi për mbledhje Një nga komponentet kryesore të zgjidhjës për hapjen e komunikimit 'path-way' në sistemin 'legacy'(të vjetra) në formën e një mikroservisi të ndarë, është Classic Service. Sistemet e reja dhe ato të vjetra krijojnë një shembull që në jetën reale quhet pjesërisht mikro-servise- monolite hibride të lidhura nga ky Classic Service, të paktën për aq kohë sa sistemet e vjetra kanë nevojë të suportohen. Ky mikroservis dallon nga udhëzimet për arkitekturë të

mikroserviseve, duke pasur parasysh përgjegjësinë e të njohurit të sistemit legacy dhe thirrjen e të dhënave nga databaza e sajë. Kjo është përshkak se sistemet e vjetra nuk kanë një API për të thirrur dhe krijimi i një servisi të përkohshëm gjithmonë shihet si një ide më e mirë në zhvillimin e sistemeve të vjetra. Classic Service ekspozon një REST API të cilat mund të ripërdorën nga mikroservise të ndryshme.

9 PËRFUNDIMI

Nga kërkimi i bazuar në literaturë, artikuj, revista shkencore dhe diskutime të ndryshme, në mënyrën e çasjes së problemit të deklaruar në fillim, kam ardhur në përfundim të një zgjidhje duke emuluar mjedisin e përshtatshëm për zhvillimin e mikroserviseve në të cilat edhe zhvilluesit, por edhe shfrytëzuesit në anën tjetër kanë mjaft vështirësi si në zhvillimin e aplikacioneve, njëashtu edhe në operimin e tij në anën fundore tek shfrytëzuesit.

Me anë të kësaj teze ofroj një solucion analitik në mënyrën e perceptimit dhe zhvillimit të mikroserviseve duke përdorur një infrastrukturë të kontinjerizuar që shërben si çelës në hapjen e mundësive të integrimit dhe zhvillimit të pjesëve të integrueshme të aplikacioneve. Kjo temë ka prezentuar avantazhet dhe të metat e modeleve të arkitekturave të mikroserviseve dhe ato monolite, me shembujt të cilat kanë demonstruar se si mikroserviset mund të përdoren në një cikël zhvillimor Agjil.

Infrastruktura e kontinjerizuar e ka thjeshtësuar zhvillimin e këtyre mikroserviseve, të cilat kanë mundësuar thjeshtësimin e aplikacionit, duke mos krijuar një ngarkesë të madhe në procesim, por është kujdesur vetëm në hostimin e kodit, apo në këtë rast aplikacionin. Duke aplikuar këtë kemi pasur një reduktim të madh të fuqisë llogaritëse, duke konsideruar se pjesa e sistemit operativ është marrë nga vetë kernel i sistemit operativ, dhe aplikacioni yne ka qenë duke përdorur resurse minimale, vetëm aq sa i është nevojitur për ekzekutuar aplikacionin. Përpos pjesës së reduktimit të resurseve të tepruara, kemi krijuar një solucion i cili ka qenë thjeshtësisht i integrueshëm me sisteme tjera, dhe mbi të gjitha kemi ofruar mundësinë e ri-përdorimit të mikroserviseve. Thelbësisht jemi fokusuar edhe në aplikimin e trendeve të reja teknologjike, duke përsosur ciklin e zhvillimit të bazuar në metodologji Agjile, krijimin e një verzionimi të kodit, përdorimit të shërbimeve të cloud dhe mbi të gjitha duke automatizuar pjesën e aplikacionit duke e ofruar atë të gatshëm edhe për pjesën e implementimit në shërbime cloud apo edhe në orkestrues të kontinjerëve.

Kemi theksuar, se shërbimet e cloud janë duke luajtur një rol kyç në zhvillimin e industrisë së Teknologjisë Informative. Para disa viteve, është parë si e ardhmja e IT-së, tani mund të

themi se është pjesë e një realiteti që nuk mund ta neglizhojmë. Mund të potencojmë se njohja e aftësive në përdorimin e shërbimeve të cloud është një avantazh për gjithkënd që sot punon në industrinë e IT-së.

Synimi i kësaj teze ka qenë studimi i zhvillimit të mikroserviseve në infrastrukturë të kontinjerizuar, dhe se si e shohim atë në praktikë. Pjesa teorike ka përshkruar mikroserviset dhe shërbimet e cloudit. Ka qenë shumë e rëndësishme të kthehemi mbrapa në histori, dhe të shohim se si këto teknologji kanë evoluar, dhe çfarë probleme kanë zgjidhur. Avantazhet dhe të metat e tyre gjithashtu janë diskutuar në mënyrë të nxirren kuptimet për mënyrën më të mirë të implementimit të tyre në praktikë.

Ideja për pjesën praktike ka qenë për të krijuar një mikroservis të bazuar në API të hostuar në kontinjerë dhe më pas lansimi i tij në cloud. Sidoqoftë, për të arritur këtë, njohuria vetëm për shërbimet e cloud nuk kanë qenë të mjaftueshme. Vegla shtesë nevojiten për të krijuar këtë aplikacion dhe për ta bërë të migrueshëm edhe në cloud. Të gjitha këto janë diskutuar në kapitujt e mësipërm. Pjesa e implementimit është trajtuar hap pas hapi në mënyrën se si është arritur ajo, ku dhe në të njejtën kohë janë paraqitur edhe kodet si për zhvillimin e mikroservisit, një ashtu edhe për Dockerfile që e bën atë të konvertueshëm si kontinjerë dhe më pas të gatshëm për deploy në AWS.

Për zhvillimin e këtyre aplikacioneve duhet pasur parasysh mjedisi në të cilin përdoren ato, dhe mënyrën se si sillen me teknologjinë komunikuese të përdorur. Përmes këtij punimi, është munduar të bëhet një përafrim, për zgjidhjen e problemit të krijimit të infrastrukturës virtuale për testim, dhe gjetjen e një zgjidhje optimale për testimin e aplikacioneve para se të futen në produksion si në serverët lokal njëashtu dhe në cloud.

10 REFERENCAT

[1] Neil J. Gunther, (2007), ―A Review of "Guerilla Capacity Planning: A Tactical Approach to Planning for Highly Scalable Applications and Services, Performance Dynamics Company. [2] W. Felter, A. Ferreira, R. Rajamony, and J. Rubio, “An updated performance comparison of virtual machines and linux containers,” inPerformance Analysis of Sys- tems and Software (ISPASS), 2015 IEEE International Symposium On. IEEE, 2015,pp. 171–172 [3] Dua, A. Raja, and D. Kakadia, “Virtualization vs containerization to support paas,” in Cloud Engineering (IC2E), 2014 IEEE International Conference on, March2014, pp. 610–614. [4] [Online]. Available: https://docs.docker.com/get-started/overview/ [Accessed January 18th 2021]. [5] [Online]. Available: https://www.datadoghq.com/docker-adoption/ [Accessed December 20th 2020]. [6] Cerny T, Donahoo M and Pechanec J. Disambiguation and Comparison of SOA, Microservices and Self-Contained Systems. ACM. 2017; 228-235. [7] Lammervo T. Palvelukeskeisen arkkitehtuurin mallit: neljän mallin tarkastelu. Master of Science in Technology [thesis]. Turku: University of Turku; 2012. [8] Xiao Z, Wijegunaratne I and Qiang X. Reflections on SOA and Microservices. IEEE. 2016; 60-67. [9] Jaramillo D, Nguyen D and Smart R. Leveraging Microservices Architecture by Using Docker Technology. IEEE. 2016. [10] Daya S, Nguyen D, Eati K, Ferreira C, Glozic D, Gucer V, Gupta M, Joshi S, Lampkin V, Martins M, Narain S and Vennam R. Microservices from Theory to Practice: Creating Applications in IBM Bluemix Using the Microservices Ap- proach. IBM Redbooks; 2015. p. 1-56. [11] Heinrich R, van Hoorn A, Knoche H, Li F, Lwakatare L, Pahl C, Schulte S and Wettinger J. Performance Engineering for Microservices: Research Challenges and Directions. ACM. 2017; 223-226 [12] Bakshi K. Microservices-Based Software Architecture and Approaches. IEEE. 2017; 1-8. [13] [Online]. Available: Hernández J. Leadership Summaries. Jeff Bezos’ Mandate: Amazon and Web Services [Internet]. 2012 October 18 [cited 2018 March 27]. Available from: http://jesusgilhernandez.com/2012/10/18/jeff-bezos-mandate- amazon-and-web- services [Accessed January 10th 2021]. [14] [Online]. Available: Software Testing Fundamentals. Black Box Testing [Internet]. [cited 2018 March 28]. http://softwaretestingfundamentals.com/black-box-testing [Accessed January 10th 2021]. [15] Kovács Á. Comparison of Different Linux Containers. IEEE. 2017; 47-51

[16] [Online]. Available: https://blog.aq- uasec.com/a-brief-history-of-containers-from- 1970s-chroot-to-docker-2016 en. [Accessed January 5th 2021]. [17] [Online], Available: Oracle. 1.1.1. Brief History of Virtualization. [Online]. Available:https://docs.oracle.com/cd/E26996_01/E18549/html/VMUSG1010.html [Accessed December 25th 2020] [18] [Online]. Available: VMware, Inc. (2007, 09) Understanding Full Virtualization, Paravirtualizationand Hardware Assist. [Online]. Available:https://www.vmware.com/files/pdf/VMware_paravirtualization.pdf. [Accessed December 18th 2021]. [19] [Online]. Available: R. Vanover. (2009, 06) Type 1 and Type 2 Hypervisors Explained. https://virtualizationreview.com/blogs/everyday- virtualization/2009/06/type-1-and-type-2-hypervisors-explained.aspx [Accessed January 15th 2021]. [20] M. J. Scheepers, “Virtualization and containerization of application infrastructure:A comparison,”21st Twente Student Conference on IT, pp. 1–7, 2014. [21] [Online]. Available: Ben Kepes.Understanding the Cloud Computing Stack: Saas, PaaS, IaaS.https://support.rackspace.com/whitepapers/understanding- the-cloudcomputing-stack-saas-paas-iaas/. [Accessed January 5th 2021]. [22] [Online]. Available: http://technologyadvice.com/blog/information-technology/iaas- vs-paas/. [Online; accessed December 22nd 2020]. [23] Peter M. Mell and Timothy Grance. “SP 800-145. The NIST Definition of CloudComputing”. In: (2011).