Planifikimi i arkitekturës informatike: më pak varësi, vendime më të qarta

Arkitektura përshkruan përgjegjësi, përveç sistemeve

Arkitektura përcakton ku qëndrojnë të dhënat, si komunikojnë aplikacionet dhe çfarë ndodh kur diçka dështon. Këto zgjedhje përcaktojnë nëse një funksion i ri është i thjeshtë apo kërkon fillimisht koordinim midis pesë furnizuesve dhe tri grupeve të të dhënave. Një diagram plot produkte të modës nuk u përgjigjet këtyre pyetjeve.

E thjeshtë nuk do të thotë një server ose sa më pak teknologji me çdo kusht. Një kopje rezervë shtesë ose një server i dytë aplikacioni mund të jetë i justifikuar. Kompleksiteti bëhet problematik kur përfitimi i tij është i paqartë, askush nuk e mirëmban ose varësitë dalin në pah vetëm gjatë një incidenti.

Nisni me tri rrjedha konkrete biznesi

Hartëzoni procese si trajtimi i një kërkese, përmbushja e një porosie dhe lëshimi i një fature përmes aplikacioneve, identitetit, ruajtjes dhe ndërfaqeve të jashtme. Përfshini bashkëngjitjet e emailit, tabelat llogaritëse dhe transferimet manuale; vetëm një inventar serverësh i lë jashtë këto burime vonese.

Bëjini kërkesat konkrete. A mund të presë një kërkesë dhjetë minuta gjatë mirëmbajtjes? A duhet personeli të punojë gjatë një ndërprerjeje interneti? Sa përdorues të njëkohshëm priten dhe cili informacion mund të mbërrijë më vonë? Këto përgjigje drejtojnë hostimin, sinkronizimin dhe redundancën në mënyrë më të dobishme sesa një rregull i përgjithshëm vetëm-cloud ose vetëm-zyrë.

Kur një përbërës shtesë e justifikon koston e funksionimit

Çdo përbërës ka nevojë për një kusht të matshëm që e justifikon dhe një përgjegjës operacional. Një cache që kursen vetëm disa milisekonda ndërsa hyrjet e vjetruara shkaktojnë vazhdimisht punë mbështetjeje meriton rishqyrtim. Ndarja e një importi që bllokon gjithë aplikacionin gjatë orarit të zyrës mund të ketë përfitim të qartë.

• Cache: justifikohet nga vonesa të matura në lexime të përsëritura; përcaktoni vlefshmërinë, rifreskimin dhe sjelljen në dështim.
• Radhë: e pengon punën e ngadaltë në sfond të bllokojë kërkesat; trajtoni riprovimet, rendin dhe proceset e dështuara.
• Shërbim i veçantë: mbështet publikime të pavarura ose kapacitet thelbësisht të ndryshëm; caktoni përgjegjësi për ndërfaqen, të dhënat dhe monitorimin e tij.
• Vendndodhje e dytë: mbështet kërkesën e biznesit për të përballuar humbjen e një vendndodhjeje; testoni rregullisht replikimin, kalimin rezervë dhe kthimin.

Monolitet dhe mikroshërbimet nuk janë nivele cilësie

Një aplikacion modular mund të ketë kufij të mirë biznesi dhe të dorëzohet si një vendosje e vetme. Një sistem i shpërndarë mund të mbetet i lidhur ngushtë. Mikroshërbimet lejojnë zhvillim dhe shkallëzim të pavarur, por sjellin kërkesa komunikimi, konsistence dhe funksionimi, siç shpjegon krahasimi arkitekturor i Microsoft.

Një ekip i vogël që publikon së bashku mund të përfitojë nga një monolit modular me ndërfaqe të qarta midis klientëve, porosive dhe faturimit. Një shërbim i veçantë përpunimi imazhesh mund të vijë më pas kur ngarkesa e tij rritet në mënyrë të pavarur. Kontejnerët mund të paketojnë cilindo projektim; përdorimi i kontejnerëve nuk kërkon ndarjen e aplikacionit në mikroshërbime.

Shembull: portali i klientëve, sistemi i inventarit dhe kontabiliteti

Dhënia e qasjes së drejtpërdrejtë për shkrim në bazat e inventarit dhe kontabilitetit një portali të ri krijon një rrugë të shkurtër, por i lidh publikimet e tij me dy skema të jashtme. Një përditësim në cilindo produkt mund ta ndërpresë papritur rrjedhën e klientit.

Një projektim më i qartë e përcakton sistemin e inventarit si përgjegjës për regjistrimet operative të klientëve, kontabilitetin për dokumentet e regjistruara dhe portalin për të dhënat e hyrjes dhe preferencat e shfaqjes. Ndërfaqet e dakordësuara transferojnë informacionin e kërkuar. Shfaqni kohën e përditësimit kur nevojitet, në vend që të premtoni të dhëna në kohë reale që nuk garantohen.

Edhe kjo ndarje kërkon punë: versiononi ndërfaqet, bëjini të dukshme dështimet e transferimit dhe trajtoni pa paqartësi riprovimet. Për një mjet të vogël të brendshëm, një ndërfaqe leximi më e thjeshtë dhe e dokumentuar mund të mjaftojë. Vendosni sipas kërkesave për ndryshim, pasojave të dështimit dhe kapacitetit të ekipit.

Regjistroni vendimet dhe krahasoni koston e plotë të funksionimit

Një regjistër vendimi arkitekturor (ADR) dokumenton një vendim, kontekstin e tij, alternativat dhe pasojat. Duhet të jetë e mundur që ai të zëvendësohet shprehimisht nga një vendim i ri. Procesi ADR i AWS përshkruan këtë cikël jete; ruajtja e arsyetimit ka më shumë rëndësi se gjatësia e dokumentit.

Një regjistër për portalin mund të shënojë se informacioni i klientëve mbetet në sistemin e inventarit sepse personeli i tij mirëmban regjistrimin autoritativ, ndërsa portali shfaq një pamje leximi të sinkronizuar me vonesë të dakordësuar. Rishqyrtojeni këtë zgjedhje kur klientët duhet të kryejnë vetë ndryshime detyruese.

Krahasoni zbatimin, infrastrukturën, licencat, mbështetjen, përfshirjen fillestare dhe daljen për të njëjtën periudhë dhe kërkesa. Hostimi i lirë mund të bëhet i kushtueshëm nëse çdo përshtatje kërkon ekspertizë të rrallë. Platformat e menaxhuara mund ta pakësojnë punën, por sjellin varësi kontraktore dhe eksporti.

Përdorni prova konkrete në një shqyrtim arkitekture

Nisni me tri pamje: rrugëtimin e përdoruesit nëpër sisteme, përgjegjësinë për të dhënat e rëndësishme dhe vendosjen nëpër vendndodhje ose ofrues. Etiketoni qëllimin dhe drejtimin e çdo lidhjeje. Shënoni kalimet e panjohura si pyetje, në vend që të fshihni mungesën e njohurive pas një diagrami në dukje të plotë.

Shtoni ndryshimet dhe incidentet e fundit përkatëse. Cila varësi e befasoi ekipin? Ku u desh të vepronin së bashku disa ekipe? Çfarë shkaktoi punë manuale të përsëritur? Nxirrni disa ndryshime të arsyetuara, në vend që të zëvendësoni gjithë mjedisin sipas preferencave personale teknologjike.

Tri demonstrime e bëjnë projektin e synuar të testueshëm

Për ndryshueshmërinë, ndiqni një ndryshim tipik biznesi përmes përbërësve, njerëzve, hapave manualë dhe kohës së miratimit. Për rikuperimin, testoni alternativën e pritshme ose rikthimin e një rrjedhe të rëndësishme në një mjedis të përshtatshëm. Për dorëzimin, kërkojini një personi të dytë të kryejë një detyrë rutinë vetëm me dokumentacionin.

Bini dakord fillimisht për kriteret e suksesit: një kohë përgjigjeje, interval rikuperimi ose publikim i përfunduar pa pyetur zhvilluesin origjinal. Vlerat duhet t'i përshtaten biznesit. Objektivi është përparimi kundrejt pengesave të vëzhguara, jo një rezultat universal arkitekture.

Ndërtoni një udhërrëfyes me kushte nxitëse

Jo çdo zgjerim i mundshëm duhet ndërtuar menjëherë. Nisni me funksionim të qëndrueshëm dhe lidheni investimin e mëvonshëm me një kusht të matur. Ndani një detyrë në sfond kur ajo shkel vazhdimisht objektivin e kohës së përgjigjes; shtoni një vendndodhje të dytë kur procesi kërkon tolerancë ndaj humbjes së vendndodhjes, edhe nëse trafiku është i ulët.

Caktoni për çdo vendim një përgjegjës dhe një kusht rishqyrtimi: orar i ndryshuar, shumë më tepër përdorues, kategori e re të dhënash, kontratë që skadon ose incidente të përsëritura. Këto kushte justifikojnë investimin dhe ruajnë mundësitë në mënyrë më të dobishme sesa një riprojektim i plotë arbitrar çdo disa vjet.