Përcaktoni infrastrukturën përtej prototipit

Filloni nga sistemi i gjeneruar

Merrni një platformë imagjinare prototipimi. Ajo krijon një container web, një bazë të menaxhuar të dhënash PostgreSQL dhe një URL publike. Rrjedha e punës funksionon saktë me regjistrime shembull. Ky është rezultat i dobishëm: njerëzit mund ta vlerësojnë funksionalitetin para se të financojnë një zbatim më të madh.

Tani kompania dëshiron të ruajë kontrata konfidenciale dhe të përdorë ofruesin e vet të identitetit të punonjësve. Sistemi i kërkuar ka ndryshuar. Vendosja e suksesshme e një container-i nuk vërteton autorizimin, trajtimin e miratuar të të dhënave, aftësinë e rikuperimit ose përgjegjësinë për shërbimin.

Platforma të ndryshme zhvillimi ofrojnë aftësi të ndryshme. Shqyrtoni shërbimin dhe konfigurimin real. Mos supozoni se çdo mjet prototipimi ka të njëjtët kufij ose se një emër i njohur cloud plotëson politikën e kompanisë.

Bëni shtatë pyetje për prodhimin

Përgjigjet mund të përdorin shërbimet ekzistuese të ndërmarrjes. Nuk ju duhet të ndërtoni një sistem të ri identiteti ose platformë monitorimi për çdo aplikacion. Lidhuni me aftësitë e miratuara dhe regjistroni mangësitë që mbeten.

AWS Well-Architected shqyrton bashkë funksionimin, sigurinë, besueshmërinë, performancën, koston dhe qëndrueshmërinë mjedisore. Kjo kujton se një vendosje që funksionon është vetëm një pjesë e vlerësimit të arkitekturës. Lexoni kuadrin.

Përcaktoni kufijtë ndërmjet mjediseve

Identifikoni burimet e zhvillimit, testimit dhe prodhimit. Përcaktoni cilat identitete mund t’i kalojnë këta kufij. Mos kopjoni regjistrime prodhimi në një mjedis të volitshëm parapamjeje pa një proces të miratuar trajtimi.

Shqyrtoni lidhjet dalëse, si dhe aksesin hyrës. Një bazë private të dhënash mund t’i dërgojë sërish të dhëna një shërbimi publik regjistrimi përmes aplikacionit. Thirrjet e modelit nga agjenti i kodimit janë një rrjedhë tjetër që duhet vlerësuar veçmas.

Regjistroni kush është përgjegjës për llogarinë cloud, DNS, certifikatën, çelësat e enkriptimit dhe marrëdhënien e faturimit. Një projekt që varet nga llogaria personale e një punonjësi që largohet ka problem përgjegjësie edhe kur kodi i aplikacionit është i disponueshëm.

Testoni ndarjen e përgjegjësive

Një ofrues i bazës së menaxhuar të të dhënave mund të mbajë në funksionim shërbimin bazë, ndërsa organizata juaj kontrollon përdoruesit, aksesin te të dhënat, ndryshimet e skemës dhe cilësimet e ruajtjes. Ndarja e saktë varet nga shërbimi dhe kontrata. Kërkojeni shprehimisht.

Për aplikacionin e kontratave, kryeni një ushtrim imagjinar restaurimi. Matni kohën reale të rikuperimit dhe identifikoni humbjen e mundshme të të dhënave. Krahasoni rezultatin me kërkesën e biznesit. Një kuti e shënuar «kopjet rezervë janë aktivizuar» nuk është e njëjta evidencë.

Testoni edhe heqjen e aksesit. Hiqni një punonjës imagjinar nga burimi i identitetit dhe verifikoni ndryshimin e synuar të aksesit. Përfshini në projektim seancat aktive, rolet e administratorëve dhe identitetet e automatizimit.

Lidheni infrastrukturën me sistemin e dorëzimit

Përkufizimet e infrastrukturës, konfigurimi i mjedisit, pipeline-et dhe kodi i aplikacionit kërkojnë ndryshime të koordinuara. Një agjent duhet të planifikojë sipas mjedisit real të synuar. Përndryshe, mund të gjenerojë një vendosje që bie ndesh me kërkesat e rrjetit, identitetit ose përgjegjësisë.

Këtu takohen inxhinieria e platformave dhe fabrika e softuerit. Platforma jep aftësi dhe kufij të mbështetur. Sistemi i dorëzimit duhet t’i përdorë, të prodhojë evidencë dhe të ruajë një kalim të qartë të përgjegjësive për funksionimin. Vazhdoni me inxhinierinë e platformave.