„Dobrze zaprojektowana architektura” brzmi jak marketingowy frazes. AWS ma jednak na to konkretną, sprawdzalną definicję — Well-Architected Framework — i to właśnie ta wiedza stoi za certyfikatem AWS Certified Solutions Architect, który zdałem i z którego korzystam projektując architektury klientów, nie tylko na potrzeby egzaminu.
Pięć filarów
- Doskonałość operacyjna. Czy operacje (wdrożenia, monitoring, reakcja na incydenty) są zautomatyzowane i powtarzalne, czy zależą od pamięci jednej osoby.
- Bezpieczeństwo. Kto ma dostęp do czego, jak dane są szyfrowane, jak wygląda ochrona przed nieautoryzowanym dostępem.
- Niezawodność. Czy system przetrwa awarię pojedynczego komponentu i wraca do działania sam, bez telefonu do administratora.
- Wydajność. Czy zasoby są dobrane do realnego obciążenia, nie do przypuszczeń sprzed roku.
- Optymalizacja kosztów. Czy płacisz za to, czego faktycznie używasz, czy za margines bezpieczeństwa, który nigdy się nie przydał.
Framework nie mówi „zrób dokładnie tak”. Mówi „zadaj sobie te pytania, zanim coś pójdzie nie tak” — i to jest różnica między architekturą zaprojektowaną a architekturą, która się po prostu wydarzyła.
To nie lista do odhaczenia w całości
Nie każdy projekt potrzebuje maksimum w każdym filarze naraz. Aplikacja wewnętrzna dla dziesięciu pracowników nie wymaga tej samej niezawodności co system obsługujący płatności klientów. Framework to narzędzie do świadomego wyboru kompromisów, nie sztywny wymóg — ważne, żeby kompromis był świadomy, a nie przypadkowy.
Bezpieczeństwo w praktyce
Filar bezpieczeństwa to nie abstrakcja — to konkretne pytania: kto loguje się do konta AWS, jakimi uprawnieniami, czy jest włączone uwierzytelnianie dwuskładnikowe. Piszę o tym szerzej, razem z najczęstszymi błędami, w artykule o bezpieczeństwie konta AWS i zarządzaniu dostępem (IAM).
Zanim jednak przejdziemy do bezpieczeństwa, warto zrozumieć, ile to wszystko kosztuje w praktyce — piszę o tym w kolejnym artykule: ile kosztuje chmura AWS.