- Platvormitehnika loob arendajate kognitiivse koormuse vähendamiseks abstraktsioonikihte, kasutades IDP-sid.
- See põhineb tootepõhisel lähenemisviisil, kus infrastruktuuri pakutakse standardiseeritud iseteenindusena.
- Selle eesmärk on optimeerida tarkvara tarnetsüklit optimeeritud marsruutide või kuldsete radade abil.
Oled ilmselt märganud, et terminit „platvormtehnika“ on viimasel ajal tehnoloogiasektoris kõikjal esile kerkinud . See pole juhus; näeme ettevõtteid, kes püüavad lahendada kaost, mida mõnikord põhjustab pilve- ja mikroteenuste kontrollimatu kasv, otsides viisi, kuidas arendajad ei peaks olema absoluutselt kõiges eksperdid, et lihtsalt tootmiskeskkonnas muudatusi teha.
Põhimõtteliselt räägime sotsiaal-tehnilisest distsipliinist, mis keskendub sisemiste tarkvaraplatvormide kujundamisele ja hooldamisele . Idee on lihtne, kuid võimas: luua keskkond, kus arendusmeeskonnal on kõik vajalik koheselt saadaval, töötades autonoomselt, ilma et nad peaksid avama pileteid ja ootama päevi, et keegi operatsioonidest neile serveri või S3-ämbri looks.
Mida platvormitehnika täpselt hõlmab?
Erinevalt teistest lähenemisviisidest keskendub see distsipliin sisemise arendusplatvormi (IDP) loomisele . Mõelge sellest kui omamoodi infrastruktuuri "müügiautomaadist". Lõputute konfiguratsioonifailidega maadlemise asemel pääseb arendaja juurde portaalile, kus ta saab oma teenuseid eelnevalt kinnitatud standardite järgi juurutada.
See mudel ei tekkinud tühjalt kohalt; see on DevOpsi loomulik areng . Kui DevOps andis meile koostöö ja automatiseerimise filosoofia, siis Platform Engineering tõlgib need kontseptsioonid konkreetseteks tööriistadeks. Selle peamine eesmärk on võidelda kognitiivse koormusega – selle ülekoormava tundega, mis tekib siis, kui programmeerija peab samaaegselt haldama koodi, turvalisust, jälgitavust ja infrastruktuuri.
Selle lähenemisviisi toetavad sambad
- Toote mõtteviis: Siin on võti. Platvorm ei ole kindla lõppkuupäevaga projekt, vaid elav toode. Arendajad on kliendid ja platvormi meeskond peab kuulama nende kaebusi ja pidevalt täiustama.
- Iseteenindus: Eesmärk on kurikuulsa "TicketOpsi" likvideerimine. Arendusmeeskonna eesmärk on olla isemajandav, pääsedes ressurssidele juurde API-de või veebiportaalide kaudu ilma vahendajatest sõltumata.
- Kuldsed teed: Need on eelnevalt määratletud ja optimeeritud juurutamisteed. Kui arendaja järgib kuldstandardit, teab ta, et tema rakendus vastab vaikimisi turvalisuse ja regulatiivsetele nõuetele, kuigi väga erandjuhtudel on lubatud sellest kõrvale kalduda.
Miks see tänapäeval nii vajalik on?
Praegune ökosüsteem on tööriistade džungel. Kubernetesi, Terraformi, hübriidpilvede ja turvaregulatsioonide vahel on lihtne teelt ära eksida. Platvormitehnika aitab seda keerukust hallata , abstrakteerides kõige tihedamalt esinevaid tehnilisi detaile, et meeskond saaks keskenduda sellele, mis on tõeliselt oluline: äriväärtuse loomine.
Lisaks on rangelt reguleeritud sektorites vastavuse ja turvalisuse tagamine suur peavalu. Nende reeglite otse platvormi integreerimisega on vastavus automaatne. Arendajad ei pea lugema 100-leheküljelist turvakäsiraamatut; platvorm lihtsalt takistab neil haavatavate objektide juurutamist .
Tegelik mõju organisatsioonile
Kui me seda õigesti rakendame, on kasu tunda kõigil tasanditel. Ettevõtte tasandil vähenevad tegevuskulud ja protsessid standardiseeritakse , mis takistab igal meeskonnal jalgratast leiutamast. Meeskondade jaoks tähendab see vähem hõõrdumist ja palju sujuvamat koordineerimist eri valdkondade vahel.
Arendaja jaoks on see kogemus murranguline. Nad tunnevad end võimsamana, kuna ei pea teisi ootama, ja saavad palju kiiremini mõjukaid tulemusi saavutada . Vähem aega Kubernetes YAML-iga maadlemisele tähendab rohkem aega äriloogika kirjutamisele ja väiksemat ohtu kardetud läbipõlemiseks liigse operatiivse keerukuse tõttu.
Peamised erinevused SRE ja DevOpsi vahel
Neid mõisteid aetakse sageli segi, kuid neil on erinevad eesmärgid. DevOps on üldine filosoofia, mis lõhub arenduse ja tegevuse vahelised piirid. Teisest küljest keskendub saidi töökindluse projekteerimine (SRE) süsteemi stabiilsusele, hallates kättesaadavust ja jõudlust standardsete koormuspiirangute (SLO) ja veaeelarvete abil.
Platvormitehnika seevastu vastutab tööriista (IDP) loomise eest, mis võimaldab kõike eelnevat tõhusalt toimida. Kui SRE keskendub tootmissüsteemi tervisele, siis platvormitehnika spetsialist keskendub arendajakogemusele (DevEx) , et tagada programmeerija sülearvuti ja pilve võimalikult lühike ja turvaline teekond.
Kuidas platvormi insenerimeeskonda kokku panna
Massilise üleöö juurutamise proovimine pole soovitatav. Ideaalis peaksite alustama kõige õhema elujõulisema platvormiga (Thinnest Viable Platform) – minimaalse elujõulise versiooniga, mis vastab meeskonna kõige pakilisemale vajadusele. Saate ära kasutada SRE või CloudOps meeskondade sisemist talenti, kuid on oluline, et nad omaks tootekeskse mõtteviisi.
Meeskonnas paistavad tavaliselt silma kindlad rollid. Platvormi tootejuht filtreerib kasutajate vajadused ja seab tegevuskava tähtsuse järjekorda. DevEx-insenerid keskenduvad liidese ja töövoogude intuitiivseks muutmisele, samas kui infrastruktuuriinsenerid ehitavad sisemise mootori, tagades platvormi skaleeritavuse ja töökindluse.
Levinud tööriistad ja tehnoloogiad
Selle ökosüsteemi loomine hõlmab tavaliselt mitme komponendi kombineerimist. Taristu kui kood (IaC) on keskkonna loomise automatiseerimiseks ülioluline. Mängu tulevad ka konteinerorkestraatorid nagu Kubernetes ja CI/CD tööriistad, mis võimaldavad sujuvaid ja pidevaid edastusvooge.
Visuaalne tuum on tavaliselt sisemine arendajaportaal (IDP) , mis toimib visualiseerimis- ja autentimiskihina. Need tööriistad võimaldavad läbipaistvat juhtimist ja tagavad, et ettevõtte standardeid rakendatakse igas juurutuses nähtamatult, kuid tõhusalt.
Selle lähenemisviisi omaksvõtmine kujutab endast paradigma muutust, kus infrastruktuur lakkab olemast takistus ja saab kiirendajaks. Keskendudes tehnilise hõõrdumise vähendamisele ja autonoomia edendamisele iseteeninduse kaudu, ei paranda ettevõtted mitte ainult tarnekiirust, vaid loovad ka palju atraktiivsema ja tervislikuma töökeskkonna tehnilistele talentidele, tagades, et tehnoloogia on alati vahend ärieesmärkide saavutamiseks, mitte eesmärk omaette.