Azure Well-Architected Framework a Cloud Adoption Framework: jaka jest różnica?
By Mirko Peters ·
Gubisz się w usługach WAF i CAF firmy Microsoft? Poznaj kluczowe różnice między Cloud Adoption Framework a Well-Architected Framework, które pomogą osiągnąć sukces w chmurze.
Automatically translated with AI from the original post. Read the English original

Projektując i eksploatując rozwiązania w Microsoft Azure, architekci chmurowi często spotykają się z dwoma głównymi modelami wytycznych: Cloud Adoption Framework (CAF) i Well-Architected Framework (WAF). Chociaż oba pochodzą od firmy Microsoft i mają wspólny cel, jakim jest sukces chmury na poziomie przedsiębiorstwa, obejmują zupełnie inne warstwy architektury, zakres organizacyjny i odpowiedzialność operacyjną.
Najważniejsze wnioski
- Cloud Adoption Framework (CAF) buduje wspólne fundamenty przedsiębiorstwa, zasady zarządzania i strefy docelowe (landing zones) obejmujące subskrypcje Azure.
- Well-Architected Framework (WAF) koncentruje się wąsko na optymalizacji jednego konkretnego obciążenia lub aplikacji biznesowej na raz.
- Używając analogii do lotniska: CAF przygotowuje pas startowy, wieżę kontroli lotów i przepisy ruchu lotniczego, a WAF dba o to, by pojedynczy samolot bezpiecznie zrealizował swój lot.
- Oba podejścia się uzupełniają i są niezbędne w strategii chmury przedsiębiorstwa, ponieważ dotyczą różnych warstw architektury.
- WAF opiera się głównie na pięciu filarach – Niezawodność, Zabezpieczenia, Optymalizacja kosztów, Doskonałość operacyjna i Wydajność – stosowanych osobno dla każdego obciążenia.
Zrozumienie CAF: fundament przedsiębiorstwa
Zanim jakakolwiek pojedyncza aplikacja będzie mogła istnieć w chmurze, organizacja musi określić, w jaki sposób zamierza zarządzać swoimi zasobami chmurowymi, zabezpieczać je i administrować nimi. To jest domena Microsoft Cloud Adoption Framework (CAF). CAF został zaprojektowany, aby pomóc liderom IT i administratorom chmury odpowiadać na szerokie, strategiczne pytania dotyczące zgodności z celami organizacji, strategii chmury, zarządzania portfelem i podstawowego zarządzania.
Gdy przedsiębiorstwo przyjmuje CAF, konfiguruje subskrypcje, tworzy grupy zarządzania, ustawia zabezpieczenia kontroli dostępu opartej na rolach (RBAC), projektuje topologie sieci przedsiębiorstwa i udostępnia strefy docelowe Azure. Strefa docelowa to zasadniczo wstępnie skonfigurowane środowisko, które spełnia podstawowe wymagania dotyczące zabezpieczeń, zgodności i zarządzania. Można to porównać do budowy nowoczesnego biurowego parku handlowego: CAF wyznacza drogi dojazdowe, sieci elektryczne, wspólne ogrodzenia zabezpieczające, instalacje wodociągowe i przepisy zagospodarowania przestrzennego dla wszystkich przyszłych najemców.
Bez CAF organizacja naraża się na chaotyczne rozrastanie się chmury, gdy programiści bezplanowo tworzą zasoby, koszty nie dają się śledzić według centrów kosztów, a podstawowe wymagania bezpieczeństwa są niespójne. CAF dostarcza strukturalnych zasad współpracy dla całej firmy.
Zrozumienie WAF: perspektywa obciążenia
Gdy fundament przedsiębiorstwa zostanie ustanowiony za pomocą CAF, zespoły zaczynają wdrażać aplikacje, bazy danych i portale klientów. Wtedy do głosu dochodzi Azure Well-Architected Framework (WAF). WAF nie interesuje się całą subskrypcją firmy ani topologią sieci przedsiębiorstwa; zamiast tego skupia się na pojedynczym obciążeniu.
W tym kontekście obciążenie roboczе to znacznie więcej niż maszyna wirtualna czy fragment kodu aplikacji. Obejmuje wszystko, co jest potrzebne do osiągnięcia konkretnego rezultatu biznesowego. W przypadku portalu e-commerce dla klientów obciążenie robocze obejmuje kod aplikacji webowej, bazy danych, tożsamości klientów, integracje API, sygnały monitoringu, potoki wdrożeniowe, a nawet zespół wsparcia, który to wszystko obsługuje.
WAF ocenia to pojedyncze obciążenie roboczе w pięciu odrębnych filarach:
- Niezawodność: Czy obciążenie robocze dotrzymuje obietnicy biznesowej i potrafi sprawnie odzyskać sprawność po awariach?
- Zabezpieczenia: Czy tożsamości są chronione zgodnie z zasadami Zero Trust i czy wrażliwe dane są szyfrowane?
- Optymalizacja kosztów: Czy obciążenie robocze wydaje budżet celowo, bez zbędnego marnotrawstwa?
- Doskonałość operacyjna: Czy zespół potrafi niezawodnie uruchamiać, monitorować i aktualizować obciążenie robocze, korzystając z automatyzacji i infrastruktury jako kodu?
- Efektywność wydajnościowa: Czy aplikacja pozostaje responsywna, gdy pojawia się szczytowe zapotrzebowanie użytkowników?
Analogia lotniska: CAF kontra WAF w praktyce
Aby w pełni zrozumieć, jak te dwa frameworki współdziałają, warto posłużyć się analogią międzynarodowego lotniska. Cloud Adoption Framework to projekt rozbudowy i zarządzania lotniskiem. Obejmuje budowę pasów startowych, instalację wież kontroli lotów, ustanowienie procedur kontroli bezpieczeństwa, budowę terminali oraz określenie zasad funkcjonowania lotniska tak, aby obsługiwało ono wiele różnych typów statków powietrznych.
Well-Architected Framework z kolei to zadanie załogi lotniczej, która prowadzi konkretny samolot pasażerski. Załoga musi dbać o swój plan lotu, obliczenia paliwa, obciążenie pasażerami, zmiany trasy ze względu na pogodę, przeglądy techniczne oraz procedury awaryjnego lądowania. Samolot w pełni zależy od tego, czy lotnisko (CAF) działa sprawnie i jest dobrze zarządzane, lecz piloci muszą podejmować świadome, operacyjne decyzje dotyczące swojej konkretnej maszyny (WAF), aby bezpiecznie dotrzeć do celu.
Jak CAF i WAF współpracują ze sobą
Organizacje często popełniają błąd, wybierając jeden framework zamiast drugiego lub traktując je jak konkurencyjne metodyki. W rzeczywistości udane przyjęcie chmury wymaga, aby oba frameworki działały razem.
Podczas migracji aplikacji do Azure Twoi architekci chmury używają CAF do projektowania bezpiecznych stref docelowych (landing zones), zgodnych z korporacyjnym ładem. Gdy obciążenia robocze zostaną wdrożone w tych strefach, właściciele aplikacji i deweloperzy wykorzystują przeglądy WAF do ciągłego audytowania, doskonalenia i poprawy kondycji architektonicznej poszczególnych aplikacji. CAF zapewnia środowisko, a WAF dba o to, by aplikacja w nim prosperowała.
Podsumowanie i kolejne kroki
Poruszanie się w wytycznych architektonicznych Microsoftu nie musi być przytłaczające, gdy zrozumiesz granice między fundamentem przedsiębiorstwa a projektowaniem obciążeń roboczych. Wykorzystując Cloud Adoption Framework do budowy fundamentu w skali całej organizacji oraz stosując Well-Architected Framework do pojedynczych, krytycznych dla biznesu obciążeń roboczych, Twoje zespoły mogą zrównoważyć innowacje ze stabilnością, bezpieczeństwem i kontrolą finansową.
Aby głębiej poznać, jak te frameworki sprawdzają się w rzeczywistych scenariuszach chmurowych, koniecznie zapoznaj się z całą dyskusją. Posłuchaj pełnego odcinka, aby poznać eksperckie spostrzeżenia, praktyczne przykłady i strategiczne porady dotyczące optymalizacji Twojego środowiska Azure.
Często zadawane pytania
Czy mogę korzystać z Azure Well-Architected Framework bez Cloud Adoption Framework?
Tak, ale jest to znacznie trudniejsze. WAF zakłada, że masz już wdrożoną bazową strefę docelową i model ładu (które zapewnia CAF). Bez CAF poszczególne obciążenia robocze mogą nie mieć podstawowych rozwiązań sieciowych, zarządzania tożsamościami i zasad subskrypcji.
Który framework organizacja powinna wdrożyć najpierw: CAF czy WAF?
Organizacje zazwyczaj zaczynają od Cloud Adoption Framework, aby ustalić gotowość przedsiębiorstwa, ład i subskrypcje. Gdy strefy docelowe są przygotowane, zespoły stosują Well-Architected Framework podczas wdrażania konkretnych obciążeń roboczych w tych środowiskach.
Czy Cloud Adoption Framework ocenia wydajność aplikacji?
Nie. CAF koncentruje się na strategii, planowaniu, przygotowaniu środowiska chmurowego, ładzie i zarządzaniu na poziomie organizacji. Optymalizację wydajności i niezawodności poszczególnych aplikacji w całości obsługuje Well-Architected Framework.
Czy WAF obejmuje całą subskrypcję Azure, czy tylko jedną aplikację?
WAF dotyczy pojedynczego obciążenia. Obciążenie obejmuje wszystko, co jest potrzebne do osiągnięcia konkretnego rezultatu biznesowego – na przykład kod aplikacji, bazy danych, tożsamości, narzędzia do monitorowania oraz zespół, który ją obsługuje – i może stanowić tylko część subskrypcji Azure.