Definujte infrastrukturu nad rámec prototypu

Začněte vygenerovaným systémem

Představte si fiktivní platformu pro prototypy. Vytvoří webový kontejner, spravovanou databázi PostgreSQL a veřejnou URL. Pracovní postup se vzorovými záznamy funguje správně. To je užitečný výsledek: lidé mohou funkci posoudit před financováním větší implementace.

Firma nyní chce ukládat důvěrné smlouvy a používat svého poskytovatele identity zaměstnanců. Požadovaný systém se změnil. Úspěšné nasazení kontejneru neprokazuje autorizaci, schválené nakládání s daty, obnovitelnost ani odpovědnost za službu.

Různé vývojové platformy poskytují různé schopnosti. Prozkoumejte skutečnou službu a konfiguraci. Nepředpokládejte, že každý prototypovací nástroj má stejná omezení nebo že známý název cloudu splňuje firemní pravidla.

Položte sedm produkčních otázek

Odpovědi mohou využít existující podnikové služby. Pro každou aplikaci nemusíte vytvářet nový systém identity ani monitorovací platformu. Napojte se na schválené schopnosti a zaznamenejte zbývající mezery.

AWS Well-Architected posuzuje společně provoz, bezpečnost, spolehlivost, výkon, náklady a udržitelnost. Připomíná tím, že fungující nasazení je pouze jedna část hodnocení architektury. Přečtěte si rámec.

Definujte hranice prostředí

Určete vývojové, testovací a produkční prostředky. Definujte, které identity smějí tyto hranice překračovat. Nekopírujte produkční záznamy do pohodlného náhledového prostředí bez schváleného postupu nakládání s daty.

Vedle příchozího přístupu prozkoumejte i odchozí spojení. Soukromá databáze může přes aplikaci stále dodávat data veřejné logovací službě. Volání modelu programovacím agentem jsou dalším tokem k samostatnému posouzení.

Zaznamenejte, kdo vlastní cloudový účet, DNS, certifikát, šifrovací klíče a fakturační vztah. Projekt závislý na osobním účtu odcházejícího zaměstnance má problém s odpovědností, i když je aplikační kód dostupný.

Otestujte rozdělení odpovědností

Poskytovatel spravované databáze může provozovat základní službu, zatímco vaše organizace řídí uživatele, přístup k datům, změny schématu a nastavení uchování. Přesné rozdělení závisí na službě a smlouvě. Výslovně si je vyžádejte.

Pro smluvní aplikaci proveďte fiktivní cvičení obnovy. Změřte skutečnou dobu obnovy a určete možnou ztrátu dat. Porovnejte výsledek s obchodním požadavkem. Zaškrtávací políčko „zálohy zapnuty“ není stejný důkaz.

Otestujte také odchod zaměstnance. Odeberte fiktivního zaměstnance ze zdroje identity a ověřte zamýšlenou změnu přístupu. V návrhu zohledněte aktivní relace, administrátorské role a identity automatizace.

Propojte infrastrukturu se systémem dodávky

Definice infrastruktury, konfigurace prostředí, pipeline a aplikační kód potřebují koordinované změny. Agent má plánovat pro skutečné cílové prostředí. Jinak může vygenerovat nasazení v rozporu s požadavky na síť, identitu nebo odpovědnosti.

Zde se potkává platform engineering se softwarovou továrnou. Platforma poskytuje podporované schopnosti a hranice. Systém dodávky je musí používat, vytvářet důkazy a zachovat jasné předání do provozu. Pokračujte lekcí o platform engineeringu.