Дефинишите инфраструктуру која превазилази прототип

Почните од генерисаног система

Размотримо измишљену платформу за прототипове. Она прави веб-контејнер, управљану PostgreSQL базу и јавни URL. Ток рада исправно ради са примерима записа. То је користан резултат: људи могу да процене функцију пре финансирања веће имплементације.

Сада компанија жели да чува поверљиве уговоре и користи свог добављача идентитета запослених. Захтевани систем се променио. Успешно постављен контејнер не доказује ауторизацију, одобрено поступање са подацима, могућност опоравка или одговорност за сервис.

Различите развојне платформе пружају различите могућности. Испитајте стварни сервис и конфигурацију. Не претпостављајте да сви алати за прототипове имају иста ограничења или да познат cloud бренд испуњава политику компаније.

Поставите седам питања о продукцији

Одговори могу да се ослоне на постојеће сервисе организације. Не морате да градите нов систем идентитета или платформу за праћење за сваку апликацију. Повежите се са одобреним могућностима и забележите преостале недостатке.

AWS Well-Architected заједно разматра оперативни рад, безбедност, поузданост, перформансе, трошкове и одрживост. То подсећа да је постављен систем који ради само један део процене архитектуре. Прочитајте оквир.

Дефинишите границе између окружења

Утврдите развојне, тестне и продукционе ресурсе. Дефинишите који идентитети могу да прелазе те границе. Не копирајте продукционе записе у погодно preview окружење без одобреног поступка обраде.

Испитајте излазне везе као и улазни приступ. Приватна база и даље може да шаље податке јавном сервису за евидентирање преко апликације. Позиви модела које агент за програмирање врши још су један ток који треба засебно проценити.

Забележите ко контролише cloud налог, DNS, сертификат, кључеве за шифровање и однос наплате са добављачем. Пројекат који зависи од личног налога запосленог који одлази има проблем одговорности чак и када је код апликације доступан.

Тестирајте поделу одговорности

Добављач управљане базе може да одржава основни сервис, док ваша организација контролише кориснике, приступ подацима, промене шеме и подешавања задржавања. Тачна подела зависи од сервиса и уговора. Изричито је затражите.

За апликацију са уговорима спроведите измишљену вежбу враћања. Измерите стварно време опоравка и утврдите могући губитак података. Упоредите резултат са пословним захтевом. Поље означено као „резервне копије укључене” није исти доказ.

Тестирајте и укидање приступа при одласку. Уклоните измишљеног запосленог из извора идентитета и проверите намеравану промену приступа. Укључите активне сесије, администраторске улоге и идентитете аутоматизације у дизајн.

Повежите инфраструктуру са системом испоруке

Дефиниције инфраструктуре, конфигурација окружења, pipeline поступци и код апликације захтевају усклађене промене. Агент треба да планира за стварно циљно окружење. У супротном може да генерише постављање које је супротно захтевима мреже, идентитета или одговорности.

Овде се сусрећу platform engineering и фабрика софтвера. Платформа обезбеђује подржане могућности и границе. Систем испоруке мора да их користи, ствара доказе и обезбеди јасну предају оперативних одговорности. Наставите са platform engineering приступом.