Solution Architect @iQuest
Acum șase ani, am început să lucrez la primul proiect legat de microservicii. Era vorba de migrarea de la o soluție monolitică la ceva diferit, la containere și microservicii. Acum în 2020, în TOATE proiectele la care lucrez, avem containere, dar mai avem și altceva – componenta serverless.
Azure Cosmos DB are cinci nivele diferite de consistență (Strong / Bounded Stateless / Session / Consistent Prefix / Eventual). Fiecare nivel de consistență poate afecta, la nivel de stocare, latența operațiunilor pe care le efectuăm. Vom încerca să răspundem la următoarea întrebare: Care este impactul diferitelor nivele de consistență asupra latenței?
Cloudul a devenit un bun de consum, iar numărul furnizorilor de cloud este mare- aici fiind incluși și furnizorii privați. Majoritatea furnizorilor au un număr mare de servicii ce pot fi folosite direct de pe piața lor de desfacere: de la mașini virtuale clasice la comunicare pe bază de mesaje sau data warehouse. Odată ce ați început să lucrați cu mai mulți furnizori de cloud, nivelul de maturitate al furnizorilor este crucial. Nivelul de maturitate este important când vreți să optimizați costurile și să îmbunătățiți calitatea soluțiilor IT pe care le realizați sau pe care le gestionați.
Azure Kubernetes Services (AKS) este locul perfect unde puteți implementa soluția de microservicii pe care o aveți, peste Kubernetes. AKS ne oferă posibilitatea să ne concentrăm asupra aplicației și asupra modului de rezolvare a problemelor de business, iar Microsoft va gestiona infrastructura de care Kubernetes are nevoie pentru a rula. Odată ce ajungeți live iar numărul de utilizatori crește, va fi nevoie să scalați aplicația în funcție de diferiți factori, precum numărul utilizator, numărul de vizualizări sau alte metrici specifice businessului vostru. Vă propun să descoperim împreună ceea ce ne oferă Azure din acest punct de vedere și cum ne poate ajuta să scalăm aplicația automat, pe baza unor metrici ale sistemului.
În urmă cu câteva săptămâni, Microsoft a anunțat un nou serviciu *cloud* disponibil pentru toți utilizatorii - Azure DevOps. Scopul principal al acestei articol este de a identifica trăsăturile principale ale acestui serviciu nou și care sunt diferențele dintre Visual Studio Team Services și Azure DevOps.
În acest articol vom supune analizei modul cum putem grupa rapoartele și dashboardurile în categorii diferite, în funcţie de viteza cu care putem aduce și actualiza datele din cadrul acestora. Timpul este un termen relativ mai ales atunci când are impact direct asupra businessului pe care îl avem. Din această cauză capacităţile de raportare ale sistemelor interne pot să aibă un impact direct asupra succesului nostru ca business. Sunt mai multe elemente care sunt importante când vorbim despre rapoarte și timp de răspuns scurt, dar două din ele sunt relevante în această discuție.
IoT este un mai mult decât un trend, a devenit o realitate care ne înconjoară. Acest lucru i-a determinat pe cei mai mari furnizori de cloud de pe piaţă (Amazon și Microsoft) să dezvolte platforme pentru IoT. Scopul acestui articol este de a compara soluţiile curente din perspectiva feature-urilor și a capabilităţilor. Cel mai interesant lucru din ultimii ani este modul în care au evoluat platformele IoT. La început, soluţiile erau orientate pe transport și comunicare, dar acum platformele IoT au evoluat și sunt integrate cu sisteme ce rulează în cloud, fiind interconectate cu alte sisteme.
Să analizăm Azure Functions din perspectiva programatorului. În acest articol vom scrie o funcţie Azure (Azure Function) care adaugă coordonatele GPS pentru o imagine sub formă de watermark.
În lumea dispozitivelor inteligente, acestea au devenit din ce în ce mai vorbăreţe. Să presupunem că avem un dispozitiv inteligent care trebuie să trimită, la fiecare 30 de secunde, un impuls de locaţie (Location Heartbeat) care conţine
Toţi facem greşeli. Uneori acestea sunt minore, fără a influența evoluția businessului, alteori sunt mari şi cu impact asupra acestuia. Acum câţiva ani am fost direct implicat într-un proiect unde o decizie greşită a dus nu doar la pierderea unei sume importante de bani, ci a avut și un efect negativ major asupra continuităţii businessului. Am decis să scriu acest articol ca o lecţie pentru a preveni astfel de greşeli, în special în aceste vremuri, când SaaS este opţiunea preferată, când cumpărarea licenţelor pentru soluţiile existente este mai bună decât a le dezvolta pe cele proprii - fără a analiza impactul şi paşii care trebuie urmaţi dacă doriţi să schimbaţi furnizorul.
Dorim să prezentăm funcţionalitatea şi feature-urile disponibile în momentul de faţă (Q3, 2016) în Azure CDN. Pe pagina web Azure, veţi găsi multe informaţii utile şi sunt sigur că deja aţi consultat-o. Comparativ cu ultimii ani, Microsoft face acum un mare pas, semnând contracte cu Akamai şi Verizon (furnizori majori de servicii CDN).
În acest articol vom discuta despre ceea ce se întâmplă cu datele transmise între regiunile Azure şi sistemele locale. Microsoft deschide din ce în ce mai multe centre în întreaga lume. Regiuni precum Japonia, UK (urmează să fie anunţată), Brazilia, Germania, Corea sunt deja instalate sau urmează să fie instalate. Aceste ţări au legi care precizează că datele dintr-o anume industrie nu au voie să părăsească ţara. În industria serviciilor de sănătate, este normal să existe restricţii pentru ca informaţiile personale ale pacienţilor să nu părăsească ţara în niciun moment. Există legi similare și pentru alte industrii precum domeniul bancar și protecţia datelor. Trebuie să ţinem cont de aceste legi, de soluţiile existente și de ceea ce se întâmplă cu conţinutul transmis între regiunile Azure și sistemele locale.
Anul trecut, Microsoft a lansat Microsoft Band 2. Este foarte puternic cu mulți senzori și o autonomie a bateriei care îmi oferă două zile de energie. Dar ceea ce mă impresionează este partea de software și ușurința cu care poți dezvolta un tile (o aplicație custom) pentru acesta. Nu trebuie să înveți C# pentru că poți crea ușor un tile
Logging-ul (înregistrarea) și auditul (verificarea) sunt obligatorii pentru toate aplicațiile. Fără aceste informații, echipa de monitorizare și suport nu ar putea să știe dacă sistemul funcționează corect și să aniticipe anumite stări de fapt. În plus, din perspectiva siguranței, trebuie verificate la diferite niveluri ale sistemului cine vă accesează sistemul, care este acțiunea și când se manifestă ea.
Am început să lucrăm la un proiect în care este necesar să oferim o soluție de încredere pentru partajarea ecranului la distanță - Remote Screen Sharing – RDP (Remote Desktop Protocol). Din fericire, toate dispozitivele funcționează pe sistem de operare Windows și noi putem folosi cu succes suportul de la Windows. Deoarece toate dispozitivele sunt împrăștiate în întreaga lume, avem nevoie de o soluție care să facă un liant între toate acestea. Întregul conținut care este trimis prin cablu trebuie să fie codat. În teorie, am avea nevoie de niște servere releu care să fie ”persoana de la mijloc” între dispozitive și persoanele care doresc să acceseze acea pute de legătură a dispozitivelor.
Timpurile recente stau sub semnul serviciilor _cloud_. Funcționalități noi ale furnizorilor de cloud se lansează în fiecare zi, aducând cu ele prețuri din ce în ce mai mici. În acest moment, cei mai cunoscuți furnizori de servicii cloud sunt Amazon, Google și Microsoft. Uitându-ne peste serviciile lor, vom vedea SLA-uri (Acorduri de nivel al serviciilor - Service Level Agreements) care ajung la o disponibilitate de 99,9%, 99,95% sau chiar 99,99%.
În teorie, trimiterea unui mesaj prin cablu înspre un alt dispozitiv este o sarcină simplă. Dar trimiterea unui mesaj într-un mod sigur și de încredere poate fi o sarcină dificilă. În epoca IoT, în care numărul dispozitivelor conectate la internet crește dramatic în fiecare zi, noi trebuie să găsim diferite mecanisme de comunicare. Deoarece nu putem controla când un dispozitiv este conectat la internet și pregătit să primească mesajul nostru, e important să detectăm diferite modalități de a comunica cu el.
În acest articol vom analiza cele mai importante servicii care ne ajută să creăm o reţea mai bună pe infrastructura Azure. Presupun că deja cunoaşteţi conceptele de bază din cloud. Cele trei servicii care intră în această categorie sunt:
În ultimele trei luni am încercat să scriu despre diferite subiecte prezentate în Clean Code. Chiar dacă acesta este al patrulea articol pe această temă, am sentimentul că mai există încă multe probleme despre care ar trebui să discutăm atunci când vorbim despre un cod curat şi bine scris. Am putea spune că această carte, „Clean Code” scrisă de Robert C. Martin, a stabilit standardele în industria noastră din această perspectivă. Este biblia dezvoltatorilor şi de multe ori este utilizată drept „legea” codului. Nu vreau să intru mai adânc în acest subiect, dar promit că într-o zi voi vorbi în detaliu despre motivele pentru care ar trebui să utilizăm sau nu această carte ca un reper important al dezvoltatorilor .
În ultimele două numere ale TSM am descoperit ce fel de denumiri ar trebui să utilizăm pentru metodele, câmpurile, clasele noastre și așa mai departe. În legătură cu aceasta, am văzut că ar trebui întotdeauna să utilizăm nume cu înțeles care au legătură cu problema pe care dorim să o rezolvăm. De asemenea, am văzut că un nume de metodă trebuie întotdeauna să exprime o acțiune - să înceapă cu un verb- iar un nume de clasă ar trebui să fie întotdeauna un substantiv. După aceasta, am vorbit despre funcții, când am aflat că o funcție ar trebui să fie scurtă, să facă numai un singur lucru, iar numărul parametrilor să fie limitat.
În ultimul articol din TSM, am descoperit împreună universul codului curat, prin ,,Clean Code” scrisă de Robert C. Martin. Am avut ocazia să aprofundăm subiectul denumirilor și să vedem cât de ușor pot lucrurile mici precum numele funcțiilor sau al variabilelor să îmbunătățească calitatea și lizibilitatea codului însuși.
Dacă eşti un programator cu experiență atunci ai auzit de cartea „Clean code” scrisă de Robert C. Martin. În multe companii, această carte a devenit parte din biblia dezvoltatorului. Combinată cu „Clean Coder” (Programatorul Curat), aş spune că aceste două cărţi sunt obligatorii pentru toţi dezvoltatorii. Voi realiza o serie dedicate acestui subiect. Dacă deja aţi citit cartea, atunci este o ocazie bună să vă o reactualizați. Pentru ceilalţi, acesta este momentul perfect pentru a descoperi cât de bine ar trebui să arate codul. Toate ideile principale sunt preluate din „Clean Code” (Cod Curat). Puteţi privi această serie de articole drept un rezumat al cărţii în sine.
În ultimele trei numere ale TSM, am descoperit lumea AOP folosind trei stack-uri diferite - .NET, Unity și PostSharp. Dacă ne uităm la aceste framework-uri cu un ochi critic, putem să observăm că PostSharp este un framework extrem de robust care face magia AOP-ului în momentul compilării. Pe când Unity sau .NET stack inserează toată această funcționalitate la runtime.
În ultimele săptămâni am descoperit împreună principiile de bază ale Programării Orientate pe Aspecte (AOP). Acum este timpul să vedem cum putem valorifica adevăratul potențial caracteristicile AOP utilizând PostSharp. Înainte de a intra în subiect, să facem o scurtă recapitulare. AOP este o paradigmă de programare care are drept scop principal creșterea modularității unei aplicații. AOP încearcă să atingă acest scop prin permiterea separării aspectelor secante(cross-cutting concerns) – utilizând interceptarea diferitelor comenzi sau cereri.
În ultimul număr al revistei Today Software Magazine, am discutat despre principiile de bază ale AOP și despre cum putem implementa conceptul de bază al AOP utilizând caracteristici ale .NET 4.5, fără a folosi alte cadre. În acest articol, vom vorbi despre Unity și vom vedea cum putem utiliza acest cadru pentru a implementa AOP.
În cele ce urmează vom discuta despre AOP și despre cum putem implementa propria noastră stivă (stack) AOP utilizând caracteristicile .NET Core. Acronimul vine de la Aspect Oriented Programming și este o altă paradigmă de programare cu scopul principal de a crește modularitatea unei aplicații. AOP încearcă să atingă acest țel permițând separarea aspectelor/relațiilor secante (cross-cutting concerns).
În articolul din numărul trecut am analizat modul cum putem să măsurăm metricele software folosind Sonar. Acesta este un tool care poate fi util liderului echipei cât și restului echipei. Orice membru din echipă poate extrem de ușor să verifice pe interfața web a Sonar-ului care este valoarea la diferite metrice.
În lumea IT, code metrics sunt cunoscute și apreciate ca fiind foarte importante. Articolul de față își propune să analizeze code metrics din perspectiva unui dezvoltator sau a unui project leader. Folosind code metrics, orice membru din echipă își poate da seama care este starea codului din punct de vedere a calități acestuia. Teoretic acesta poate să detecteze zonele de cod care ar putea să fie problematice și să le analizeze.
În acest articol vom descoperi punctele de extensie într-o aplicație enterprise. Bineînțeles că aceste puncte de extensie se aplică pentru orice fel de aplicație, indiferent de mărimea acestora. Cu cât o aplicație este mai mare, cu atât aceste puncte de extensie devin mai importante pentru a păstra calitatea codului ridicată, iar costul unei schimbări să fie cât mai redus. De foarte multe ori, adăugarea unui număr prea mare de puncte de extensie într-o aplicație simplă va duce doar la creșterea complexității codului, fără a aduce o valoare reală aplicației în sine. Despre over-engineering , vom completa cu mai multe detalii în rândurile următoare.
Peste tot în jurul nostru auzim că se discută despre inovare. Orice companie dorește să facă parte din grupul companiilor care fac ceva inovator. În mod evident, domeniul IT este cel mai marcat de această deviză a inovării.
Trăim într-o lume dinamică, o lume în care datele zboară extrem de rapid. În această lume, aplicațiile web au devenit din ce în ce mai complexe. Zilele când aveam doar pagini web statice au trecut de mult, la fel și perioada în care Ajax și jQuery erau la putere. Într-o lume în care aplicațiile real time fac parte din viața noastră, avem nevoie de noi mecanisme pentru a putea face apeluri server2client. Aplicațiile web pentru monitorizare, jocurile online, aplicațiile bursiere sau cele în care edităm documente au nevoie de sisteme de acest fel, care să fie robuste și scalabile.
De câte ori nu vi s-a întâmplat să aveți un o problemă în producție sau în mediul de testare pe care să nu o puteți reproduce pe mașina de dezvoltare? Când acest lucru se întâmplă, lucrurile ajung să o ia razna, iar noi încercăm diferite modalități de remote debug. Fără să știm, aceste tool-uri pot să fie chiar lângă noi, însă noi le ignorăm sau nu știm cum să le folosim.
Într-o lume perfectă m-aș aștepta să pot rula un load test sau un stres test folosind un furnizor de cloud fără să fiu obligat să modific o linie de cod din testele mele. În cadrul acestui articol vom descoperi cum putem să facem acest lucru folosind un nou serviciu de cloud. Cum o persoană care are cunoștințe zero despre cloud poate să ruleze un load test de 50.000 de useri timp de 24 de ore cu costuri minime, fără să fie obligat să achiziționeze și să configureze 10, 20 de noduri.
În numerele trecute am descoperit lumea pe care Hadoop o formează. O lume în care fișierele de 100GB sau 500GB sunt la ordinea zilei. Acesta ne permite să facem lucruri pe care nu le puteam face până acum. Când? Datele pe care firma noastră le colectează pot să devină o mină de aur. Putând prelucra cantități mari de date, avem posibilitatea să vizualizăm datele într-un mod pe care nu l-am putut face până acuma. Prima întrebare pe care trebuie să o punem când dorim să analizăm datele cu Hadoop este: Ce dorim să analizăm? Răspunsul la această întrebare este important, deoarece trebuie să identificăm ce vrem să facem cu datele, ce informație dorim să analizăm și care este valoarea acestor date.
În ultimul număr am descoperit lumea pe care Hadoop o formează și care este secretul prin care putem să stocăm zeci și chiar sute de TB fără nici un fel de probleme. Aceasta se bazează pe un sistem de tip master-slave extrem de simplu, dar care funcționează foarte bine.
Cu toții am auzit de trenduri. Avem trenduri în muzică, în modă și bineînțeles în IT. Pentru anul 2013, au fost anunțate mai multe trenduri, care la ora actuală fac deja parte din viața noastră. Câți din noi nu am auzit de cloud, machine to machine (M2M) sau NoSQL. Toate acestea sunt trenduri care au pătruns în viața noastră, făcând parte din cotidian. Big Data este un trend care s-a manifestat și anul trecut, menținându-se printre cele mai puternice trend-uri și în acest an.
NoSQL – este unul dintre trend-urile anului 2013. Dacă în urmă cu trei, patru ani auzeam destul de rar de câte un proiect care să folosească NoSQL, în ziua de azi proiectele care folosesc baze de date non-relaţionale sunt extrem de multe. În cadrul acestui articol vom vedea care sunt avantajele şi provocările pe care le putem avea când dorim să folosim NoSQL. În a doua parte a articolului vom analiza și vom sublinea mai multe soluţii non-relaţionale şi o să încercăm să vedem care sunt avantajele fiecăreia.
Așa cum știm cu toții, noțiunea de open-source a existat încă de la prima linie de cod care a fost scrisă vreodată. În cadrul acestui articol vom vedea ce a însemnat noțiunea de open-source pentru Microsoft, ce înseamnă ea în ziua de azi și care sunt noile direcții.Noțiunea de open-source într-o forma sau alta apare încă din anii 1950-1960, când cea mai mare parte din cod era scrisă de către universități în colaborare cu corporațiile.
Cloud – un alt buzz word pe care îl auzim aproape în fiecare zi. În momentul de faţă există mai mulţi provideri care oferă acest serviciu: Amazon, Microsoft (Windows Azure), Google, Rackspace. Când ne gândim la cloud ce ne vine în minte? Una, două sau mai multe instanţe pe care le ţinem într-un cloud, iar când avem nevoie de mai multe resurse putem să creştem foarte uşor numărul de instanţe.
Numărul de persoane care deţin tablete sau telefoane mobile din noua generaţie este din ce în ce mai mare. În ziua de azi aproape orice familie are cel putin un dispozitiv de acest fel. O mare parte din aplicaţiile desktop au fost sau urmează să fie portate pe acest gen de dispositive. În momentul de faţă putem să vedem de la Office la jocuri extreme de complexe pe tablete sau telefoane.
În cadrul acestui articol vom discuta două design patern-uri pe care le putem folosii când trebuie să rezolvăm anumite probleme într-o solutie enterprise. Cele doua soluţii care urmează să fie prezentate se bazează pe Windows Azure Service Bus. Acesta este un sistem de distribuire de mesaje oferit de către Microsoft. Pentru a îl putea folosi nu este necesar să instălam sau să configurăm nici un server.
Primul CTP de Windows Azure a fost anunţat în 2008, iar după doi ani a fost lansată şi versiunea comercială. De atunci şi până astăzi, fiecare nouă versiune de Windows Azure a adus noi funcţionalităţi. Dacă în 2010 web role-ul şi worker role-ul erau principalele puncte forte, astăzi Windows Azure este mult mai complex şi ne permite să facem lucruri pe care nici nu ni le puteam imagina.
Noul sistem de operare lansat de către cei de la Microsoft a adus destul de multe schimbări. Una dintre aceste schimbări este şi background tasks pentru aplicaţiile Metro. Înainte să putem vorbi despre background task-urile din Windows 8 este nevoie să întelegem de ce au fost introduse. Windows 8 a apărut din necesitatea unui sistem de operare de a rula pe mai multe tipuri de device-uri. Pe lângă cele cu care suntem obişnuiţi din ce în ce mai multe persoane au început să folosească tabletele. Chiar dacă din punctul de vedere a procesorului şi a memoriei acestea devin din ce în ce mai puternice, aşteptările pe care le avem de la o tableta sunt diferite. Durata bateriei este extrem de importantă pentru o tabletă.
