Definieer de infrastructuur voorbij het prototype

Begin bij het gegenereerde systeem

Neem een fictief prototypeplatform. Het maakt een webcontainer, een beheerde PostgreSQL-database en een publieke URL. De workflow werkt correct met voorbeeldrecords. Dat is een nuttig resultaat: mensen kunnen de functie beoordelen voordat een grotere implementatie wordt gefinancierd.

Nu wil het bedrijf vertrouwelijke contracten opslaan en zijn identiteitsprovider voor medewerkers gebruiken. Het vereiste systeem is veranderd. Een geslaagde containerdeployment toont geen autorisatie, goedgekeurde gegevensverwerking, herstelbaarheid of dienstverantwoordelijkheid aan.

Verschillende ontwikkelplatforms bieden verschillende mogelijkheden. Inspecteer de werkelijke dienst en configuratie. Neem niet aan dat elke prototypetool dezelfde beperkingen heeft of dat een bekende cloudnaam aan het bedrijfsbeleid voldoet.

Stel zeven productievragen

De antwoorden kunnen bestaande enterprisediensten gebruiken. U hoeft niet voor elke applicatie een nieuw identiteitssysteem of monitoringplatform te bouwen. Sluit aan op goedgekeurde mogelijkheden en documenteer resterende lacunes.

AWS Well-Architected beschouwt beheer, beveiliging, betrouwbaarheid, prestaties, kosten en duurzaamheid samen. Dat herinnert eraan dat een werkende deployment maar één deel van een architectuurbeoordeling is. Lees het framework.

Definieer grenzen tussen omgevingen

Identificeer ontwikkel-, test- en productieresources. Definieer welke identiteiten deze grenzen mogen oversteken. Kopieer geen productierecords naar een handige previewomgeving zonder goedgekeurd verwerkingsproces.

Inspecteer uitgaande verbindingen én inkomende toegang. Een private database kan via de applicatie toch een publieke logdienst voeden. Modelaanroepen van de code-agent zijn een andere stroom die apart moet worden beoordeeld.

Leg vast wie verantwoordelijk is voor cloudaccount, DNS, certificaat, encryptiesleutels en factureringsrelatie. Een project dat afhangt van het persoonlijke account van een vertrekkende medewerker heeft een eigenaarschapsprobleem, ook als de applicatiecode beschikbaar is.

Test de verantwoordelijkheidsverdeling

Een provider van een beheerde database kan de onderliggende dienst beheren, terwijl uw organisatie gebruikers, gegevenstoegang, schemawijzigingen en bewaartermijnen bepaalt. De exacte verdeling hangt af van dienst en contract. Vraag die expliciet op.

Voer voor de contractapplicatie een fictieve hersteloefening uit. Meet de werkelijke hersteltijd en identificeer mogelijk gegevensverlies. Vergelijk het resultaat met de bedrijfseis. Een vinkje ‘back-ups ingeschakeld’ is niet hetzelfde bewijs.

Test ook uitdiensttreding. Verwijder een fictieve medewerker uit de identiteitsbron en verifieer de bedoelde toegangsverandering. Neem actieve sessies, beheerdersrollen en automatiseringsidentiteiten mee in het ontwerp.

Koppel infrastructuur aan het leveringssysteem

Infrastructuurdefinities, omgevingsconfiguratie, pipelines en applicatiecode vragen gecoördineerde wijzigingen. Een agent moet plannen tegen de werkelijke doelomgeving. Anders kan een deployment ontstaan die botst met eisen voor netwerk, identiteit of verantwoordelijkheid.

Hier komen platform engineering en een softwarefabriek samen. Het platform biedt ondersteunde mogelijkheden en grenzen. Het leveringssysteem moet die gebruiken, bewijs opleveren en een duidelijke operationele overdracht behouden. Ga verder met platform engineering.