Määra prototüübist kaugemale ulatuv taristu

Alusta genereeritud süsteemist

Vaata väljamõeldud prototüübiplatvormi. See loob veebikonteineri, hallatud PostgreSQL-i andmebaasi ja avaliku URL-i. Töövoog toimib näidiskirjetega õigesti. See on kasulik tulemus: inimesed saavad funktsiooni hinnata enne suurema teostuse rahastamist.

Nüüd soovib ettevõte salvestada konfidentsiaalseid lepinguid ja kasutada töötajate identiteedipakkujat. Nõutav süsteem on muutunud. Edukas konteinerijuurutus ei tõenda autoriseerimist, heaks kiidetud andmetöötlust, taastatavust ega teenuse vastutust.

Erinevad arendusplatvormid pakuvad erinevaid võimekusi. Uuri tegelikku teenust ja seadistust. Ära eelda, et igal prototüübitööriistal on samad piirangud või et tuttav pilvenimi täidab ettevõtte reeglid.

Küsi seitse tootmisküsimust

Vastused võivad kasutada ettevõtte olemasolevaid teenuseid. Sa ei pea iga rakenduse jaoks uut identiteedisüsteemi ega monitooringuplatvormi ehitama. Ühendu heaks kiidetud võimekustega ja pane allesjäänud lüngad kirja.

AWS Well-Architected vaatleb koos käitust, turvalisust, töökindlust, jõudlust, kulu ja kestlikkust. See tuletab kasulikult meelde, et toimiv juurutus on ainult üks osa arhitektuuri hindamisest. Loe raamistikku.

Määra keskkondadevahelised piirid

Tuvasta arendus-, test- ja tootmisressursid. Määra, millised identiteedid võivad neid piire ületada. Ära kopeeri tootmiskirjeid mugavasse eelvaatekeskkonda ilma heaks kiidetud töötlusprotsessita.

Uuri lisaks sissetulevale juurdepääsule ka väljuvaid ühendusi. Privaatne andmebaas võib rakenduse kaudu siiski andmeid avalikku logiteenusesse saata. Koodiagendi mudelipäringud on veel üks eraldi hinnatav voog.

Pane kirja, kes vastutab pilvekonto, DNS-i, sertifikaadi, krüpteerimisvõtmete ja arveldussuhte eest. Lahkuva töötaja isiklikust kontost sõltuval projektil on vastutusprobleem ka siis, kui rakenduse kood on olemas.

Katseta vastutuste jaotust

Hallatud andmebaasi pakkuja võib käitada alusteenust, samal ajal kui sinu organisatsioon kontrollib kasutajaid, andmejuurdepääsu, skeemimuudatusi ja säilitusseadeid. Täpne jaotus sõltub teenusest ja lepingust. Küsi seda selgesõnaliselt.

Tee lepingurakendusega väljamõeldud taastamisharjutus. Mõõda tegelikku taastamisaega ja tuvasta võimalik andmekadu. Võrdle tulemust ärinõudega. Märkeruut „varundamine sisse lülitatud“ ei ole sama tõend.

Katseta ka juurdepääsu lõpetamist. Eemalda väljamõeldud töötaja identiteediallikast ja kontrolli kavandatud juurdepääsumuutust. Kaasa kavandisse aktiivsed seansid, administraatorirollid ja automatiseerimisidentiteedid.

Seo taristu tarnesüsteemiga

Taristumääratlused, keskkonnaseadistus, pipeline’id ja rakenduse kood vajavad koordineeritud muudatusi. Agent peab kavandama tegeliku sihtkeskkonna järgi. Vastasel korral võib ta genereerida juurutuse, mis on võrgu-, identiteedi- või vastutusnõuetega vastuolus.

Siin kohtuvad platform engineering ja tarkvaratehas. Platvorm annab toetatud võimekused ja piirid. Tarnesüsteem peab neid kasutama, tootma tõendeid ja säilitama selge üleandmise käitusele. Jätka platform engineering’u õppetunniga.