Określ infrastrukturę potrzebną poza prototypem

Zacznij od wygenerowanego systemu

Rozważ fikcyjną platformę prototypową. Tworzy kontener webowy, zarządzaną bazę PostgreSQL i publiczny URL. Proces działa poprawnie z przykładowymi rekordami. To przydatny wynik: ludzie mogą ocenić funkcję przed sfinansowaniem większej implementacji.

Teraz firma chce przechowywać poufne umowy i używać swojego dostawcy tożsamości pracowników. Wymagany system się zmienił. Udane wdrożenie kontenera nie potwierdza autoryzacji, zatwierdzonego przetwarzania danych, możliwości odtworzenia ani właściciela usługi.

Różne platformy wytwarzania zapewniają różne możliwości. Sprawdź rzeczywistą usługę i konfigurację. Nie zakładaj, że każde narzędzie prototypowe ma te same ograniczenia albo że znana nazwa chmury spełnia politykę firmy.

Zadaj siedem pytań produkcyjnych

Odpowiedzi mogą wykorzystywać istniejące usługi firmowe. Nie musisz budować osobnego systemu tożsamości ani monitoringu dla każdej aplikacji. Podłącz zatwierdzone możliwości i zapisz pozostałe luki.

AWS Well-Architected łącznie rozpatruje eksploatację, bezpieczeństwo, niezawodność, wydajność, koszt i zrównoważony rozwój. Przypomina to, że działające wdrożenie jest tylko częścią oceny architektury. Przeczytaj framework.

Określ granice środowisk

Wskaż zasoby developerskie, testowe i produkcyjne. Określ tożsamości, które mogą przekraczać te granice. Nie kopiuj rekordów produkcyjnych do wygodnego środowiska podglądowego bez zatwierdzonego procesu przetwarzania.

Sprawdź połączenia wychodzące oraz dostęp przychodzący. Prywatna baza może przez aplikację nadal wysyłać dane do publicznej usługi logowania. Wywołania modelu przez agenta programistycznego stanowią kolejny przepływ do osobnej oceny.

Zapisz, kto jest właścicielem konta chmurowego, DNS, certyfikatu, kluczy szyfrowania i umowy rozliczeniowej. Projekt zależny od osobistego konta odchodzącego pracownika ma problem z odpowiedzialnością, nawet gdy kod aplikacji jest dostępny.

Sprawdź podział odpowiedzialności

Dostawca zarządzanej bazy może obsługiwać usługę bazową, podczas gdy organizacja kontroluje użytkowników, dostęp do danych, zmiany schematu i przechowywanie. Dokładny podział zależy od usługi i umowy. Poproś o jego jasne określenie.

Dla aplikacji umów przeprowadź ćwiczenie odtwarzania na fikcyjnych danych. Zmierz rzeczywisty czas przywrócenia i możliwą utratę danych. Porównaj wynik z wymaganiem biznesowym. Zaznaczenie „kopie zapasowe włączone” nie stanowi tego samego dowodu.

Przetestuj też odebranie dostępu po odejściu. Usuń fikcyjnego pracownika ze źródła tożsamości i sprawdź oczekiwaną zmianę dostępu. Uwzględnij w projekcie aktywne sesje, role administratorów i tożsamości automatyzacji.

Połącz infrastrukturę z systemem dostarczania

Definicje infrastruktury, konfiguracja środowisk, pipeline’y i kod aplikacji wymagają skoordynowanych zmian. Agent powinien planować dla rzeczywistego środowiska docelowego. Inaczej może wygenerować wdrożenie sprzeczne z wymaganiami sieci, tożsamości lub odpowiedzialności.

W tym miejscu platform engineering spotyka się z fabryką oprogramowania. Platforma zapewnia wspierane możliwości i granice. System dostarczania musi ich używać, wytwarzać dowody i zachować jasne przekazanie do eksploatacji. Przejdź do platform engineering.