Udostępnij za pośrednictwem

Uściślij platformę aplikacji, aby usprawnić tworzenie aplikacji i zarządzanie infrastrukturą

  • Artykuł

Dużą częścią ulepszania praktyk inżynieryjnych w organizacji jest ocena platformy aplikacji. Platforma aplikacji obejmuje wszystkie narzędzia i usługi używane do obsługi tworzenia, wdrażania i zarządzania aplikacjami w organizacji.

Uproszczenie i standaryzacja

Narzędzia infrastruktury jako kodu (IaC) i automatyzacji można łączyć z szablonami w celu standaryzacji infrastruktury i wdrażania aplikacji. Aby zmniejszyć obciążenie specyficzne dla platformy dla użytkownika końcowego, abstrakcyjne szczegóły platformy, dzieląc opcje na powiązane konwencje nazewnictwa, na przykład:

  • Kategorie typów zasobów (wysokie zasoby obliczeniowe, wysoka ilość pamięci)
  • Kategorie rozmiaru zasobów (rozmiar koszulki, mały średni i duży)

Szablony powinny reprezentować ogólne wymagania, które zostały przetestowane przy użyciu wstępnie ustawionych konfiguracji, więc zespoły deweloperów mogą natychmiast rozpocząć dostarczanie minimalnych parametrów i bez konieczności przeglądania opcji. Będą jednak sytuacje, w których zespoły muszą zmienić więcej opcji opublikowanych szablonów niż są dostępne lub pożądane. Na przykład zatwierdzony projekt może wymagać określonej konfiguracji spoza obsługiwanych ustawień domyślnych szablonu. W tym wystąpieniu operacje lub zespoły inżynierów platformy mogą utworzyć jednorazową konfigurację, a następnie zdecydować, czy szablon musi uwzględniać te zmiany jako domyślne.

Zmiany można śledzić za pomocą narzędzi IaC z funkcjami wykrywania dryfu, które mogą automatycznie korygować dryf (GitOps). Przykładami tych narzędzi są narzędzia Terraform i natywne dla chmury narzędzia IaC (przykłady, interfejs API klastra, crossplane, operator usługi platformy Azure w wersji 2). Poza narzędziem IaC wykryto, że istnieją narzędzia do konfiguracji chmury, które mogą wykonywać zapytania dotyczące konfiguracji zasobów, takich jak usługa Azure Resource Graph. Mogą one służyć jako dwie korzyści; monitorujesz zmiany poza kodem infrastruktury i przeglądasz zmienione konfiguracje ustawień wstępnych. Aby uniknąć zbyt sztywnego, można zaimplementować tolerancje we wdrożeniach również ze wstępnie zdefiniowanymi limitami. Możesz na przykład użyć usługi Azure Policy , aby ograniczyć liczbę węzłów Kubernetes, które może mieć wdrożenie.

Zarządzana samodzielnie lub zarządzana?

W chmurach publicznych możesz korzystać z rozwiązań SaaS, PaaS lub IaaS. Aby dowiedzieć się więcej na temat rozwiązań SaaS, PaaS i IaaS, zobacz moduł szkoleniowy Opis pojęć dotyczących chmury. Usługi PaaS oferują usprawnione środowiska programistyczne, ale są bardziej nakazowe dzięki swoim modelom aplikacji. Ostatecznie istnieje kompromis między łatwością użycia i kontrolą, którą należy ocenić.

Podczas projektowania platformy oceniaj i ustalaj priorytety potrzeb organizacji w zakresie obsługi. Na przykład niezależnie od tego, czy tworzysz aplikacje bezpośrednio w usłudze Azure Kubernetes Service (AKS), czy za pośrednictwem usługi Azure Container Apps (ACA), zależy od wymagań dotyczących usługi oraz od pojemności i zestawu umiejętności w firmie. Dotyczy to również usług w stylu funkcji, takich jak Azure Functions lub aplikacja systemu Azure Service. Usługa ACA, Azure Functions i App Service zmniejszają złożoność, a usługa AKS zapewnia większą elastyczność i kontrolę. Bardziej eksperymentalne modele aplikacji, takie jak projekt inkubacji radius systemu operacyjnego, starają się zapewnić równowagę między nimi, ale są ogólnie we wcześniejszych etapach dojrzałości niż usługi w chmurze z pełną obsługą i obecnością w ustalonych formatach IaC.

Problemy zidentyfikowane podczas planowania powinny pomóc w ocenie, który koniec tej skali jest odpowiedni dla Ciebie. Pamiętaj, aby uwzględnić swój własny zestaw umiejętności wewnętrznych podczas podejmowania decyzji.

Udostępnione a dedykowane zasoby

W organizacji istnieją zasoby, które mogą być współużytkowane przez wiele aplikacji w celu zwiększenia wykorzystania i efektywności kosztowej. Każda udostępniona zasoby ma własny zestaw zagadnień. Na przykład są to zagadnienia dotyczące udostępniania klastrów K8s, ale niektóre dotyczą innych typów zasobów:

  • Organizacja: Udostępnianie zasobów, takich jak klastry, a nie poza granicami organizacji, może poprawić ich dopasowanie do kierunku organizacji, wymagań i priorytetu.
  • Dzierżawa aplikacji: aplikacje mogą mieć różne wymagania dotyczące izolacji dzierżawy. Należy przejrzeć poszczególne zabezpieczenia aplikacji i zgodność z przepisami, jeśli może współistnieć z innymi aplikacjami. Na przykład w rozwiązaniu Kubernetes aplikacje mogą używać izolacji przestrzeni nazw. Należy jednak również rozważyć dzierżawę aplikacji dla różnych typów środowisk. Na przykład często najlepiej jest unikać mieszania aplikacji testowych z aplikacjami produkcyjnymi w tych samych klastrach, aby uniknąć nieoczekiwanych skutków spowodowanych błędami konfiguracji lub problemami z zabezpieczeniami. Możesz też zdecydować się na najpierw przetestowanie i dostosowanie dedykowanych klastrów Kubernetes w celu śledzenia tych problemów przed wdrożeniem w klastrze udostępnionym. Niezależnie od tego, spójność w podejściu jest kluczem do uniknięcia pomyłek i błędów.
  • Użycie zasobów: zapoznaj się z użyciem poszczególnych zasobów aplikacji, oszczędzialną pojemnością i wykonaj projekcję, aby oszacować, czy udostępnianie jest opłacalne. Należy również pamiętać o limitach wykorzystanych zasobów (limity pojemności centrum danych lub subskrypcji). Celem jest uniknięcie przenoszenia aplikacji i zależności z powodu ograniczeń zasobów w środowisku udostępnionym lub wystąpienia zdarzeń witryny na żywo po zakończeniu pojemności. Użyj limitów zasobów, testowania reprezentatywnego, monitorowania alertów i raportowania, aby zidentyfikować zużycie zasobów i chronić przed aplikacjami zużywających zbyt wiele zasobów.
  • Optymalizowanie konfiguracji udostępnionych: zasoby udostępnione, takie jak udostępnione klastry, wymagają dodatkowej uwagi i konfiguracji. Te zagadnienia obejmują opłaty krzyżowe, alokację zasobów, zarządzanie uprawnieniami, własność obciążenia, udostępnianie danych, koordynację uaktualniania, umieszczanie obciążeń, ustanawianie, iterowanie i iterowanie konfiguracji punktu odniesienia, zarządzanie pojemnością i umieszczanie obciążeń. Zasoby udostępnione mają korzyści, ale jeśli konfiguracje standardowe są zbyt restrykcyjne i nie ewoluują, stają się przestarzałe.

Implementowanie strategii zapewniania ładu

Ład jest kluczową częścią włączania samoobsługi z barierami zabezpieczającymi, ale stosowanie reguł zgodności w sposób, który nie ma wpływu na czas na wartość biznesową aplikacji, jest częstym wyzwaniem. Istnieją dwie części ładu:

  • Początkowa zgodność wdrożenia (po prawej stronie): można to osiągnąć za pomocą standardowych szablonów IaC udostępnianych za pośrednictwem katalogów z zarządzaniem uprawnieniami i zasadami w celu zapewnienia, że można wdrożyć tylko dozwolone zasoby i konfiguracje.
  • Utrzymywanie zgodności (zachowaj rację): narzędzia oparte na zasadach mogą uniemożliwiać lub otrzymywać alerty w przypadku zmian zasobów. Poza podstawową infrastrukturą należy rozważyć, że narzędzia obsługują również zgodność wewnątrz zasobów, takich jak K8s, wraz z systemami operacyjnymi używanymi w kontenerach lub maszynach wirtualnych. Na przykład możesz wymusić zablokowaną konfigurację systemu operacyjnego lub zainstalować narzędzia do zabezpieczeń, takie jak zasady grupy systemu Windows, SELinux, AppArmor, Azure Policy lub Kyverno. Jeśli deweloperzy mają dostęp tylko do repozytoriów IaC, możesz dodać przepływy pracy zatwierdzania, aby przejrzeć proponowane zmiany i uniemożliwić bezpośredni dostęp do płaszczyzn kontroli zasobów (na przykład platformy Azure).

Utrzymywanie zgodności wymaga narzędzi do uzyskiwania dostępu, raportowania i reagowania na problemy. Na przykład usługa Azure Policy może być używana z wieloma usługami platformy Azure na potrzeby inspekcji, raportowania i korygowania. Ma również różne tryby, takie jak Audit, Deny i DeployIfNotExists w zależności od potrzeb.

Zasady mogą wymuszać zgodność, ale mogą również nieoczekiwanie przerywać aplikacje. W związku z tym należy rozważyć zmianę zasad jako praktyki kodu (PaC) podczas działania na dużą skalę. Jako kluczowy element twojego startu i zachowaj właściwe podejście, paC zapewnia:

  • Centralnie zarządzane standardy
  • Kontrola wersji zasad
  • Testowanie automatyczne i walidacja
  • Skrócenie czasu wdrażania
  • Ciągłe wdrażanie

PaC może pomóc zminimalizować promień wybuchu potencjalnie złej zasady z możliwościami, takimi jak:

  • Definicje zasad przechowywane jako kod w repozytorium, które jest przeglądane i zatwierdzane.
  • Automatyzacja w celu zapewnienia testowania i walidacji.
  • Stopniowe wdrażanie zasad i korygowania na podstawie pierścienia w istniejących zasobach pomaga zminimalizować promień wybuchu potencjalnie złej polityki.
  • Zadanie korygowania ma wbudowane zabezpieczenia z mechanizmami kontroli, takimi jak zatrzymywanie zadania korygowania, jeśli ponad 90 procent wdrożeń zakończy się niepowodzeniem.

Implementowanie możliwości obserwowania i rejestrowania specyficznego dla roli

Aby obsługiwać aplikacje i infrastrukturę, potrzebujesz możliwości obserwowania i rejestrowania w całym stosie.

Ilustracja pulpitu nawigacyjnego narzędzia Grafana przedstawiająca możliwość obserwowania i rejestrowania.

Wymagania różnią się w zależności od roli. Na przykład zespół inżynierów i operacji platformy wymaga pulpitów nawigacyjnych, aby przejrzeć kondycję i pojemność infrastruktury z odpowiednimi alertami. Deweloperzy wymagają metryk aplikacji, dzienników i śladów w celu rozwiązywania problemów i dostosowanych pulpitów nawigacyjnych, które pokazują kondycję aplikacji i infrastruktury. Jednym z tych ról może być napotkanie jednego z tych ról, jest przeciążenie poznawcze z powodu zbyt dużej ilości informacji lub luk w wiedzy z powodu braku przydatnych informacji.

Aby rozwiązać te problemy, rozważ następujące kwestie:

  • Standardy: Stosowanie standardów rejestrowania w celu ułatwienia tworzenia i ponownego używania ustandaryzowanych pulpitów nawigacyjnych oraz upraszczania przetwarzania pozyskiwania za pomocą struktury obserwacji OpenTelemetry.
  • Uprawnienia: Udostępnianie pulpitów nawigacyjnych na poziomie zespołu lub aplikacji przy użyciu czegoś takiego jak Grafana w celu udostępnienia danych zbiorczych dla osób zainteresowanych, a także obiektu dla zaufanych członków zespołów aplikacji w celu bezpiecznego uzyskiwania dostępu do dzienników w razie potrzeby.
  • Przechowywanie: przechowywanie dzienników i metryk może być kosztowne i może powodować niezamierzone zagrożenia lub naruszenia zgodności. Ustanów domyślne ustawienia przechowywania i opublikuj je w ramach wskazówek dotyczących prawidłowego rozpoczęcia.
  • Monitorowanie limitów zasobów: zespoły operacyjne powinny mieć możliwość identyfikowania i śledzenia wszelkich ograniczeń dla danego typu zasobu. Te ograniczenia powinny być uwzględniane w szablonach IaC lub zasadach przy użyciu narzędzi takich jak Usługa Azure Policy. Następnie operacje powinny aktywnie monitorować przy użyciu pulpitów nawigacyjnych w rozwiązaniu Grafana i rozszerzać udostępnione zasoby, w których automatyczne skalowanie nie jest możliwe lub włączone. Na przykład monitoruj liczbę węzłów klastra K8s pod kątem pojemności, gdy aplikacje są dołączane i modyfikowane w czasie. Alerty są potrzebne, a te definicje powinny być przechowywane jako kod, aby można je było programowo dodać do zasobów.
  • Identyfikowanie kluczowych metryk pojemności i kondycji: monitorowanie i alerty systemu operacyjnego i zasobów udostępnionych (na przykład procesor CPU, pamięć, magazyn) na potrzeby zbierania metryk za pomocą kolekcji metryk, takich jak Prometheus lub Azure Container Insights. Można monitorować używane gniazda/porty, zużycie przepustowości sieci w aplikacjach czatty oraz liczbę aplikacji stanowych hostowanych w klastrze.

Tworzenie zabezpieczeń przy użyciu zasady najniższych uprawnień, ujednoliconego zarządzania zabezpieczeniami i wykrywania zagrożeń

Zabezpieczenia są wymagane w każdej warstwie, z kodu, kontenera, klastra i chmury/infrastruktury. Są to minimalne zalecane kroki zabezpieczeń:

  • Przestrzegaj zasady najniższych uprawnień.
  • Ujednolicenie zarządzania zabezpieczeniami metodyki DevOps w wielu potokach.
  • Upewnij się, że kontekstowe szczegółowe informacje w celu zidentyfikowania i skorygowania najbardziej krytycznego ryzyka są widoczne.
  • Włącz wykrywanie i reagowanie na nowoczesne zagrożenia w obciążeniach w chmurze w czasie wykonywania.

Aby ułatwić rozwiązywanie problemów w tym obszarze, potrzebne są narzędzia do oceny narzędzi, które działają w systemach inżynieryjnych i aplikacjach, zasobach i usługach w chmurach i hybrydowych (na przykład Microsoft Defender dla Chmury). Poza zabezpieczeniami aplikacji oceń:

Wymagania dotyczące uprawnień mogą się różnić w zależności od środowiska. Na przykład w niektórych organizacjach poszczególne zespoły nie mogą uzyskiwać dostępu do zasobów produkcyjnych, a nowe aplikacje nie mogą automatycznie wdrażać, dopóki przeglądy nie zostaną ukończone. Jednak automatyczne wdrażanie zasobów i aplikacji oraz dostęp do klastrów na potrzeby rozwiązywania problemów mogą być dozwolone w środowiskach deweloperskich i testowych.

Zarządzanie dostępem tożsamości do usług, aplikacji, infrastruktury na dużą skalę może być trudne. Dostawcy tożsamości do tworzenia i obsługi informacji o tożsamości oraz zarządzania nimi. Plan powinien obejmować usługi uwierzytelniania dla aplikacji i usług, które można zintegrować z systemami kontroli dostępu opartej na rolach (RBAC) na dużą skalę. Na przykład możesz użyć identyfikatora Entra firmy Microsoft do zapewnienia uwierzytelniania i autoryzacji na dużą skalę dla usług platformy Azure, takich jak Azure Kubernetes Service, bez konieczności konfigurowania uprawnień bezpośrednio w każdym klastrze.

Aplikacje mogą potrzebować dostępu do tożsamości w celu uzyskania dostępu do zasobów w chmurze, takich jak magazyn. Należy przejrzeć wymagania i ocenić, w jaki sposób dostawca tożsamości może to obsługiwać w najbezpieczniejszy możliwy sposób. Na przykład w usłudze AKS aplikacje natywne dla chmury mogą korzystać z tożsamości obciążenia, która sfederuje się z identyfikatorem Entra firmy Microsoft, aby umożliwić uwierzytelnianie konteneryzowanych obciążeń. Takie podejście umożliwia aplikacjom uzyskiwanie dostępu do zasobów w chmurze bez wpisów tajnych wymiany w kodzie aplikacji.

Obniżanie kosztów przez identyfikowanie właścicieli obciążeń i śledzenie zasobów

Zarządzanie kosztami to kolejna część inżynierii platformy. Aby prawidłowo zarządzać platformą aplikacji, potrzebujesz sposobu identyfikowania właścicieli obciążeń. Chcesz uzyskać spis zasobów mapujących właścicieli na określony zestaw metadanych. Na przykład na platformie Azure można używać etykiet usługi AKS, tagów usługi Azure Resource Manager wraz z pojęciami, takimi jak projekty w środowiskach wdrażania platformy Azure, aby grupować zasoby na różnych poziomach. Aby to zadziałało, wybrane metadane muszą zawierać obowiązkowe właściwości (przy użyciu czegoś takiego jak Usługa Azure Policy) podczas wdrażania obciążeń i zasobów. Ułatwia to alokację kosztów, mapowanie zasobów rozwiązania i właścicieli. Rozważ regularne raportowanie w celu śledzenia oddzielonych zasobów.

Poza śledzeniem może być konieczne przypisanie kosztów do poszczególnych zespołów aplikacji na potrzeby użycia zasobów przy użyciu tych samych metadanych z systemami zarządzania kosztami, takimi jak Microsoft Cost Management. Ta metoda śledzi zasoby aprowidowane przez zespoły aplikacji, ale nie obejmuje kosztów udostępnionych zasobów, takich jak dostawca tożsamości, rejestrowanie i magazyn metryki oraz zużycie przepustowości sieci. W przypadku zasobów udostępnionych można równomiernie podzielić koszty operacyjne przez poszczególne zespoły lub udostępnić dedykowane systemy (na przykład magazyn rejestrowania), w których występuje zużycie niezwiązane. Niektóre typy zasobów udostępnionych mogą być w stanie zapewnić szczegółowe informacje na temat zużycia zasobów, na przykład platforma Kubernetes ma narzędzia, takie jak OpenCost lub Kubecost i może pomóc.

Należy również wyszukać narzędzia do analizy kosztów, w których można przeglądać bieżące wydatki. Na przykład w witrynie Azure Portal istnieją alerty dotyczące kosztów i alerty dotyczące budżetów, które mogą śledzić zużycie zasobów w grupie i wysyłać powiadomienia po osiągnięciu wstępnie ustawionych progów.

Decydowanie o tym, kiedy i gdzie inwestować

Jeśli masz więcej niż jedną platformę aplikacji, może to być trudne, aby zdecydować, kiedy i gdzie inwestować w ulepszenia, które rozwiązują problemy, takie jak wysokie koszty lub słaba zauważalność. Jeśli zaczynasz od nowa, centrum architektury platformy Azure ma kilka potencjalnych wzorców do oceny. Ale poza tym, oto kilka pytań, które należy wziąć pod uwagę, gdy zaczniesz planować, co chcesz zrobić:

Pytanie Wskazówki
Czy chcesz dostosować istniejącą platformę aplikacji, zacząć od nowa lub użyć kombinacji tych podejść? Nawet jeśli jesteś zadowolony z tego, co masz teraz lub zaczynasz świeże, chcesz myśleć o tym, jak dostosować się do zmian w czasie. Natychmiastowe zmiany rzadko działają. Platformy aplikacji są obiektem docelowym przenoszenia. Idealny system zmienia się w miarę upływu czasu. Chcesz uwzględnić to myślenie i wszelkie powiązane plany migracji do projektu go-forward.
Jeśli chcesz zmienić to, co robisz dzisiaj, jakie produkty, usługi lub inwestycje jesteś zadowolony? Jak mówi, "jeśli nie jest uszkodzony, nie napraw go." Nie zmieniaj rzeczy bez powodu, aby to zrobić. Jeśli jednak masz jakiekolwiek rozwiązania domowe, zastanów się, czy nadszedł czas, aby przejść do istniejącego produktu, aby zaoszczędzić na długoterminowej konserwacji. Jeśli na przykład korzystasz z własnego rozwiązania do monitorowania, czy chcesz usunąć to obciążenie z zespołu ds. operacji i przeprowadzić migrację do nowego zarządzanego produktu?
Gdzie widzisz największą zmianę w czasie? Czy którekolwiek z tych obszarów są wspólne dla wszystkich (lub większości) typów aplikacji organizacji? Obszary, z których ty lub twoi klienci wewnętrzni nie są zadowoleni i często nie zmieniają się, są doskonałymi miejscami do rozpoczęcia. Mają one największy zwrot z inwestycji w dłuższej perspektywie. Może to również pomóc w sposobie ułatwienia migracji do nowego rozwiązania. Na przykład modele aplikacji są zwykle płynne, ale narzędzia do analizy dzienników mają dłuższy okres trwałości. Możesz również skupić się na nowych projektach/aplikacjach, aby rozpocząć, gdy potwierdzisz, że zmiana kierunku ma żądane zwroty.
Czy inwestujesz w rozwiązania niestandardowe w obszarach o najwyższej wartości? Czy zdecydowanie czujesz, że unikatowa funkcja platformy infrastruktury aplikacji jest częścią twojej przewagi konkurencyjnej? Jeśli zidentyfikowano luki, przed wykonaniem czegoś niestandardowego rozważ, które obszary dostawcy najprawdopodobniej zainwestują i skupią się na niestandardowym myśleniu gdzie indziej. Zacznij od samodzielnego myślenia jako integratora, a nie niestandardowej infrastruktury aplikacji lub dostawcy modelu aplikacji. Wszystko, co budujesz, trzeba zachować, które karłowate koszty z góry w dłuższej perspektywie. Jeśli uważasz, że pilna potrzeba niestandardowego utworzenia rozwiązania w obszarze podejrzewasz, że będą objęte przez dostawców długoterminowo, zaplanuj zamknięcie lub długoterminowe wsparcie. Twoi wewnętrzni klienci zazwyczaj będą tak szczęśliwi (jeśli nie więcej) z produktem gotowym jako niestandardowy.

Dostosowanie istniejących inwestycji na platformę aplikacji może być dobrym sposobem na rozpoczęcie pracy. Podczas wprowadzania aktualizacji rozważ rozpoczęcie od nowych aplikacji, aby uprościć wdrażanie pilotażowe przed każdym rodzajem wdrożenia. Należy uwzględnić tę zmianę w uwierzytelnianie IaC i tworzenie szablonów aplikacji. Zainwestuj w niestandardowe rozwiązania dla unikatowych potrzeb w obszarach o wysokim wpływie i wysokiej wartości. W przeciwnym razie spróbuj użyć gotowego rozwiązania. Podobnie jak w przypadku systemów inżynieryjnych, skoncentruj się na automatyzacji aprowizacji, śledzenia i wdrażania, a nie przy założeniu jednej sztywnej ścieżki, aby ułatwić zarządzanie zmianami w czasie.

Powiązana zawartość

Projektowanie podstaw samoobsługi dla deweloperów