Udostępnij przez

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

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, możesz wyodrębnić 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 rozmiarów zasobów (na przykład małe, średnie i duże rozmiary koszulki)

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. Istnieją 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 przypadku zespoły ds. operacji lub 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 (na przykład interfejs API klastra, crossplane, operator usługi platformy Azure w wersji 2). Poza wykrywaniem dryfu narzędzi IaC dostępne są 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: monitorowanie zmian poza kodem infrastruktury oraz przeglądanie zmienionych predefiniowanych konfiguracji. Aby uniknąć zbyt dużej sztywności, można wdrażać tolerancje we wdrożeniach, korzystając z wstępnie zdefiniowanych limitów. 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.

Samozarządzanie czy zarządzanie przez kogoś innego?

W chmurach publicznych możesz korzystać z oprogramowania jako usługi (Saas), platformy jako usługi (PaaS) lub infrastruktury jako usługi (IaaS). Aby dowiedzieć się więcej na temat rozwiązań SaaS, PaaS i IaaS, zobacz moduł szkoleniowy Opis typów usług w chmurze. Usługi PaaS oferują usprawnione środowiska programistyczne, ale ich modele aplikacji są bardziej restrykcyjne. 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 pomocą usługi Azure Container Apps , zależy od wymagań 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 Azure App Service. Usługa Container Apps, Functions i App Service zmniejsza złożoność, a usługa AKS zapewnia większą elastyczność i kontrolę. Bardziej eksperymentalne modele aplikacji, takie jak projekt inkubacji radius OSS , 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 i 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żdy zasób udostępniony ma własny zestaw zagadnień. Na przykład są to zagadnienia dotyczące udostępniania klastrów Kubernetes, 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 organizacyjnego, 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 zasobów każdej aplikacji i wolną pojemnością, a także dokonaj szacowania, aby określić, czy udostępnianie jest możliwe. 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 incydentów na stronie działającej na żywo, gdy kończy się pojemność. 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ące zbyt wiele zasobów.
  • Optymalizowanie konfiguracji udostępnionych: Zasoby udostępnione, takie jak udostępnione klastry, wymagają dodatkowej uwagi i konfiguracji. Te zagadnienia obejmują przenoszenie kosztów, alokację zasobów, zarządzanie uprawnieniami, własność obciążenia, udostępnianie danych, koordynację aktualizacji, umieszczanie obciążeń, ustanawianie, zarządzanie oraz 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

Zarządzanie jest kluczowym elementem umożliwiającym samoobsługę z zasadami zabezpieczającymi, ale stosowanie reguł zgodności w sposób, który nie wpływa na czas dostarczenia wartości biznesowej aplikacji, jest częstym wyzwaniem. Istnieją dwie części ładu:

  • Początkowa zgodność wdrożenia (początek po prawej): Można to osiągnąć za pomocą standardowych szablonów IaC, które są udostępniane za pośrednictwem katalogów, z zarządzaniem uprawnieniami i zasadami w celu zapewnienia, że można wdrażać tylko dozwolone zasoby i konfiguracje.
  • Utrzymywanie zgodności (pozostań zgodny): Narzędzia oparte na zasadach mogą zapobiegać zmianom zasobów lub powiadamiać o ich wystąpieniu. Poza podstawową infrastrukturą warto rozważyć narzędzia, które wspomagają zgodność zasobów, takich jak Kubernetes, oraz systemu operacyjnego używanego 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, takich jak platforma 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ć wdrożenie praktyki polityki jako kodu (PaC) podczas pracy na dużą skalę. Jako kluczowy element twojej strategii startu i utrzymania właściwego kierunku, PaC zapewnia:

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

PaC może pomóc zminimalizować zakres potencjalnie szkodliwej polityki dzięki możliwościom takim 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 korygowanie istniejących zasobów oparte na pierścieniu pomaga zminimalizować zakres oddziaływania potencjalnie złej polityki
  • Zadanie korygowania ma wbudowane zabezpieczenia z mechanizmami kontroli, takimi jak zatrzymanie 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.

Zrzut ekranu pulpitu nawigacyjnego Grafana pokazujący obserwowalność i rejestrowanie.

Wymagania różnią się w zależności od roli. Na przykład zespoły inżynieryjne i operacyjne platformy wymagają 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 problemów, które mogą wystąpić w jednej 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: Zastosuj standardy rejestrowania, aby ułatwić tworzenie i ponowne używanie ustandaryzowanych dashboardów, oraz uproszczenie przetwarzania wprowadzania danych poprzez coś takiego jak framework do obserwacji OpenTelemetry.
  • Uprawnienia: Udostępnianie pulpitów nawigacyjnych na poziomie zespołu lub aplikacji przy użyciu czegoś takiego jak Grafana, aby zapewnić zagregowane dane dla wszystkich zainteresowanych, oraz możliwość zaufanym członkom zespołów aplikacji na bezpieczny dostęp do dzienników w razie potrzeby.
  • Przechowywania: 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 ds. operacji 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 czymś takim jak Grafana i rozszerzać zasoby współdzielone, gdy automatyczne skalowanie nie jest możliwe lub nie zostało włączone. Na przykład monitoruj liczbę węzłów klastra Kubernetes pod kątem pojemności, gdy aplikacje są dołączane i modyfikowane wraz z upływem czasu. 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 zgłaszanie alertów o systemach operacyjnych i udostępnionych zasobach (na przykład procesora CPU, pamięci i magazynu) na potrzeby głodu przy użyciu kolekcji metryk, takich jak monitorowanie rozwiązania Prometheus lub Kubernetes w usłudze Azure Monitor. 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ń.
  • Ujednolicaj zarządzanie bezpieczeństwem w DevOps w wielu liniach procesowych.
  • 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 w usłudze Microsoft Defender for Cloud). 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 tworzą, konserwują i zarządzają informacjami tożsamościowymi. Plan powinien obejmować usługi uwierzytelniania dla aplikacji i usług, a usługa ta powinna być zintegrowana z systemami autoryzacji 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 Azure Kubernetes Service aplikacje natywne w chmurze 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 wymiany tajnych danych 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, który przypisuje właścicieli do określonego zestawu 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 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 osieroconych zasobów.

Poza śledzeniem, może być konieczne przypisanie kosztów do poszczególnych zespołów aplikacji w związku z wykorzystaniem zasobów, używając tych samych metadanych z systemami zarządzania kosztami, takimi jak Microsoft Cost Management. Ta metoda śledzi zasoby udostępniane przez zespoły aplikacyjne, ale nie obejmuje kosztów współdzielonych zasobów, takich jak dostawca tożsamości, logowanie, magazynowanie metryk oraz zużycie przepustowości sieci. W przypadku zasobów udostępnionych można równomiernie podzielić koszty operacyjne między poszczególne zespoły lub udostępnić dedykowane systemy (na przykład pamięć do przechowywania dzienników), w przypadku których zużycie jest nierównomierne. Niektóre współużytkowane typy zasobów 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ć:

Question 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 od nowa, warto pomyśleć o tym, jak dostosować się do zmian z czasem. Natychmiastowe zmiany rzadko działają. Platformy aplikacji są stale zmieniającym się celem. Twój idealny system zmienia się w miarę upływu czasu. Należy uwzględnić to myślenie i wszelkie powiązane plany migracji w przyszłym projekcie.
Jeśli chcesz zmienić to, co robisz dzisiaj, z jakich produktów, usług lub inwestycji jesteś zadowolony? Jak mówi przysłowie, "jeśli coś nie jest zepsute, nie naprawiaj tego." Nie zmieniaj rzeczy bez powodu. 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 wewnętrzni klienci nie są zadowoleni i które raczej nie zmienią się często, są doskonałymi miejscami do rozpoczęcia. Mają one największy zwrot z inwestycji w dłuższej perspektywie. To również może pomóc ci dopracować, jak ułatwić migrację 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 tym, aby rozpocząć nowe projekty i aplikacje, podczas potwierdzania, że zmiana kierunku przynosi oczekiwane korzyści.
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ż, w które obszary dostawcy najprawdopodobniej zainwestują, i skup się z niestandardowym myśleniem na innych aspektach. Zacznij myśleć o sobie jako o integratorze, a nie dostawcy niestandardowej infrastruktury aplikacji ani modelu aplikacji. Wszystko, co budujesz, wymaga utrzymania, co w dłuższej perspektywie czasowej znacznie przewyższa koszty początkowe. Jeśli odczuwasz pilną potrzebę stworzenia niestandardowego rozwiązania w obszarze, który podejrzewasz, że w dłuższej perspektywie będzie objęty przez dostawców, zaplanuj jego wygaszenie lub długoterminowe wsparcie. Twoi wewnętrzni klienci zazwyczaj będą tak samo zadowoleni (jeśli nie bardziej) z produktu gotowego, jak z niestandardowego.

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ć pilotaż przed każdym rodzajem wdrożenia. Należy włączyć tę zmianę poprzez 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 prowizjonowania, śledzenia i wdrażania, zamiast zakładać jedną sztywną ścieżkę, aby lepiej zarządzać zmianami w czasie.

Treści powiązane

  • Last updated on