Nu mai este mult până în 12 iunie când va avea loc conferința The Developers. Am profitat de lansarea revistei din această lună pentru a le lua un scurt interviu la trei dintre keynote speakerii de anul acesta.
Spune-ne câteva lucruri despre tine, legat de educație, tehnologii preferate și hobby-uri.
Sunt căsătorit și am doi copii. Vin din Scoția, dar locuiesc în Marea Britanie (deocamdată). Am obținut licența în Psihologie de la St. Andrew University cu o teză finală pe rețele neuronale (spații semantice multi-dimensionale). Acestea se află momentan la baza RAG, iar pentru a le înțelege am învățat C. Am ajuns să lucrez în cele din urmă pentru Sun Microsystems, pe măsură ce bula dot.com creștea din ce în ce mai mult (1999). Așteptam să văd când va exploda. Apoi am devenit consultant, lucru pe care îl fac de douăzeci de ani, întâi la Capgemini, iar în ultimii cinci-șase ani la ThoughtWorks unde sunt senior tehnic.
Am crescut cu Java și îmi place să lucrez cu instrumentele tipice pentru procesele de build. M-am familiarizat cu arhitectura prin intermediul DDD care îmi place la nebunie. (Am și un curs introductiv de DDD pe O'Reilly). Momentan, scriu o carte despre Facilitating Software Architecture pentru O'Reilly, carte ce va fi disponibilă la finalul acestui an. Sper că va putea explica cum putem avea mai multă arhitectură fără a angaja mai mulți arhitecți.
Îmi petrec timpul liber cu familia. Când nu petrec timp cu familia, citesc (cărți sau benzi desenate) sau încerc să învăț japoneză pe Duolingo.
Din perspectiva ta de arhitect software, care sunt tendințele din domeniul DevOps și al paradigmelor utilizate?
Cea mai importantă tendință pe care o observ este că paradigmele sunt în criză. Modul lor vechi de a aborda problemele nu mai merge. În același timp, tendința de a folosi lucruri precum microservicii, arhitectură evoluționară, livrare continuă și echipe de produs aliniate arată că avem nevoie nu de mai puțină arhitectură, ci de mai multă. Sper ca prin cartea mea să ajut în această privință, așa cum o fac și alte cărți publicate pe această temă. Este important să răspândim bunele practici în ceea ce privește arhitectura software și să înțelegem cu adevărat cum funcționează aceasta azi.
3. Spune-ne mai multe despre prezentarea ta de la conferința The Developers?
Prezentarea mea acoperă o temă pe care am abordat-o și în cartea mea. Voi vorbi despre forțele din societate care ne afectează codul, dar pe care încercăm să le ignorăm. Am realizat că tiparele de comunicare la nivel organizațional au un impact major, motiv pentru care au devenit atât de populare Team Topologies. Totuși, tema este mai vastă. Structurile de putere la nivel de societate, precum patriarhia și alte ierarhii, ne afectează codul. Reprezintă cauza codului scris prost. Voi explica de ce și cum acest lucru ne afectează negativ, dar și cum putem opri acest fenomen.
Spune-ne câteva lucruri despre tine: educație, tehnologii preferate și hobby-uri
Așa a început totul!
Cele mai timpurii amintiri pe care le am sunt cele legate de Microsoft Flight Simulator 1.0 de pe calculatorul tatălui meu, la începutul anilor 90. Mă jucam într-un hambar. Nu am înțeles de ce nu era voie să ținem acel calculator în casă! Am devenit și mai pasionat în adolescență când am început să mă joc serios. Petreceam în jur de 1000 de ore jucându-mă Unreal Tournament 2004, ceea ce a dus la o obsesie pentru hardware și ore suplimentare. Printre proiectele mele personale, cred că am construit peste 100 de calculatoare pentru prieteni.
Educație și carieră
Am studiat IT la Trinity College Dublin. Acolo am devenit un mare fan software datorită câtorva profesori pasionați care au stârnit în mine un real interes pentru scrierea de cod. Fără ei, nu aș fi apreciat frumusețea software atât de mult precum apreciam hardware-ul la momentul respectiv. Ca să fiu complet sincer, nu mi-a fost ușor, deoarece multe cursuri erau extrem de academice și poate mi-ar fi plăcut ca studiile să includă mai multă informație despre cum putem deservi industria propriu-zisă. Multe universități oferă programe în urma cărora se dobândește experiență de muncă.
Prima mea slujbă după ce am absolvit a fost cea de Systems Administrator. Parcă aș fi intrat în industrie "pe ușa din spate". În timp ce mulți colegi au intrat în organizații mari, lucrând ca ingineri software, eu mă târam pe sub birouri ca să schimb calculatoare!
Cu toate acestea, sunt încântat de parcursul meu, deoarece a trebuit să asimilez foarte multă informație foarte repede, de multe ori asamblând sisteme din hardware de duzină cu un buget foarte mic. Am învățat foarte multe despre ceea ce NU e bine să faci, ceea ce mi-a influențat deciziile de design și întreaga abordare ulterioară în carieră.
De multe ori, am fost în poziții unde funcționam precum "un om bun la toate", poate pentru că eram singurul DevOps sau Systems Engineer din organizație, ceea ce probabil explică de ce am devenit pasionat de terraform și infrastructure as code. Aceste tehnologii au avut un impact major asupra carierei mele. Am reușit să scriu software pentru a orchestra infrastructura. Am reușit ca, într-o după masă, să obțin ceva ce mi-ar fi luat mai multe weekenduri cu mult mai mult hardware.
Hobby
Deși sunt extrem de pasionat de tehnologie, recent mă ocup și de activități analogice. Am o chitară acustică, iau lecții de canto și fac parte dintr-un cor, toate ca să ies din zona de confort.
Care sunt tendințele actual în securitate, DevOps, infrastructură cloud?
În 2017, Werner Vogels, CTO Amazon, a declarat: "Pe viitor, singurul cod pe care va trebuie să îl scrieți este logica de business". În calitate de individ preocupat mai mult de Ops și Infrastructură, cred că mai avem nevoie de ceva timp ca să se împlinească această profeție. Chiar și în cadrul paradigmei serverless, e nevoie de o foarte bună cunoaștere a domeniului de lucru pentru a putea realmente beneficia de tehnologie. Paradigma "infrastructura drept cod" (infrastructure as code) este interesantă și are din ce în ce mai mulți adepți, aceasta enunțând că infrastructura se creează automat când formulați logica de business. Totuși, opinia mea sinceră și umilă este că aceste instrumente de lucru le permit echipelor să se îndrepte exact ca niște somnambuli în probleme operaționale majore, ceea ce va duce la acumulare rapidă de debite tehnice. Multe instrumente pur și simplu generează foarte mult cod, pun în funcțiune multe constructe și servicii care sunt dificil de analizat și fixat când nu avem scenarii standard de lucru. Citatul de mai sus nu va deveni o realitate până când nu vor apărea limbaje de programare cloud native ce pot orchestra un runtime gestionat complet. Servicii precum AWS Step Functions care este complet gestionat sau mașinile de stare low code sunt un pas în această direcție.
Securitate
Consider că Cloud Misconfiguration reprezintă cea mai nouă și mai periculoasă problemă de securitate pe măsură ce tot mai multe companii adoptă public cloud.
Spune-ne câteva cuvinte despre prezentarea ta la conferința The Developers
Turning Your Servers Inside Out: From Pets to Cattle (Cum întoarcem serverele cu susul în jos - de la animale de companie la turme)
Serverless este grozav pentru proiectele ce nu au multe restricții (greenfield projects), dar poate deveni problematic dacă aveți deja o platformă serverful de prestigiu care aduce bani în firmă. Această prezentare este despre cum trecem de la animale de companie (servere pe care le cunoașteți pe nume și la care țineți) la turme. Conor va exemplifica câteva abordări utile în procesul de descompunere a acestor sisteme, ceea ce vă va permite să analizați beneficiile operaționale ale tehnologiei serverless fără a vă descotorosi de lucrurile care contează. La finalul prezentării, veți fi familiarizați cu strategii ce vă vor permite să vă ocupați de serverele legacy, dar și să aveți o bază solidă pentru gestionare ML și AI.
Spune-ne câteva lucruri despre tine: educație, tehnologii preferate, hobby.
Am obținut licența în domeniul Ingineriei Telecomunicațiilor de la Universitatea Málaga, apoi m-am specializat în programare. De fapt, am creat un sistem de mesagerie prin Bluetooth folosind tehnologii de ultima oră, precum JSP și J2ME pentru teza finală. Acum, toate aceste lucruri sunt antice. De atunci, am fost fascinat de simplitatea și puterea limbajului Java cu toate librăriile sale și instrumentele ce permit programatorilor să construiască aplicații diverse (servere web, aplicații mobile, aplicații enterprise etc.). Este fascinant să observ cum a evoluat Java pe parcursul anilor, încet și sigur, cu adoptări masive ale unor paradigme precum Programarea Funcțională sau Programarea Reactivă.
Când scriu cod, folosesc paradigme precum Spring Boot, deoarece îmi place mai mult să mă axez pe rezolvarea problemelor decât să mă pierd în partea tehnică, în "balast". Totuși, înțeleg nevoia de a ști cum funcționează instrumentele de lucru și de a nu ne baza doar pe abstracțiile obscure. Este important ca noi, programatorii, să alocăm timp pentru a înțelege aceste paradigme. În ceea ce mă privește, am scris o carte pentru a mă încuraja să învăț "magia" din spatele acestora.
La un nivel mai mare de abstractizare, folosesc mult Systems Thinking, dar și soluții specifice precum Domain-Driven Design și Event-Driven Architecture, deoarece acestea permit organizațiilor să scaleze mai ușor.
În timpul meu liber, îmi place să fac drumeții și să călătoresc. Devine din ce în ce mai complicat să fac asta cu un copil de trei ani lângă mine, dar am găsit soluții - rucsacul special pentru copil este cea mai bună investiție din ultimii ani, deși spatele meu, probabil, m-ar contrazice!
Din perspectiva ta de arhitect software, care sunt tendințele din acest domeniu și a framework-urilor folosite?
Arhitecturile modulare, cu precădere microserviciile, devin un standard, deci nu mai este o abordare folosită excepțional, așa cum era acum 10 sau 15 ani. Mai mult, serviciile cloud sunt acum mature și oferă grade de abstractizare ce facilitează adoptarea arhitecturilor moderne - baze de date cu disponibilitate permanentă, message brokers, orchestrarea containerelor gestionate etc. Totuși, arhitecturile moderne și serviciile cloud avansate, contrar aparențelor, aduc multă complexitate (și costuri suplimentare) unor nivele de lucru ce nu au valoare de business în mod direct. Valoarea reală a acestor tipare se regăsește în cerințele non-funcționale: scalare organizațională, disponibilitate, performanță, mentenanță etc. Observ o tendință îngrijorătoare în cadrul noilor proiecte software atunci când aceste arhitecturi standardizate, moderne, dar complicate sunt adoptate prea devreme, înainte de a avea clarificate cerințele non-funcționale, ceea ce distrage oamenii cu mult setup tehnic, consumându-se timp în defavoarea validării scenariilor de business. Totul trebuie făcut la momentul potrivit: începeți simplu, validați, obișnuiți-vă cu schimbarea, astfel încât să puteți îmbunătăți arhitectura atunci când e nevoie.
Pe de altă parte, în dezvoltarea software, mai observ tendința de a adopta paradigme și instrumente de lucru care ne scutesc de muncă repetitivă sau de sarcini de lucru bogate tehnic, astfel încât să ne putem ocupa de rezolvarea de probleme. Sunt populare paradigme precum Spring Boot, dar și alte funcționalități precum asistență în scrierea de cod prin intermediul IDE-urilor, AI Copilots etc., care sunt aici pentru totdeauna ceea ce este o veste bună pentru ecosistemul software.
Spune-ne mai multe despre prezentarea ta de la conferința The Developers?
Voi discuta despre modul în care am implementat ultimul proiect la care lucrez momentan, Sympower. În cadrul acestui proiect, am ajutat la tranziția de la o arhitectură monolitică la una bazată pe microservicii. Cred că este grozav să vorbim despre aceste experiențe din viața reală, deoarece ne permite să înțelegem că avem de învățat atât din greșeli, cât și din succese. Voi aborda și detaliile tehnice, discutând despre motivațiile programatice din spatele lor, dar și despre scalabilitate, aceștia fiind factorii care au determinat alegerea paradigmei Spring Boot 3.