W części 2 tej serii , zastosowaliśmy koncepcje wprowadzone po raz pierwszy w części 1 i zaprojektowaliśmy fikcyjny start-up oprogramowania randkowego o nazwie eTumble. Stworzyliśmy „żywe dokumenty” dla naszej strategii, projektu i architektury. Celem tego postu jest zebranie wszystkiego razem i zaplanowanie infrastruktury wymaganej do realizacji naszego pomysłu i zaspokojenia naszych przyszłych potrzeb skalowania.

Warunki wstępne dla postępu

• Przeczytałeś pierwszą część serii
• Zapoznałeś się z frameworkami/metodologiami, które badamy poniżej, przynajmniej oglądając linki wideo udostępnione w części 1
• Przeczytałeś drugą część serii

Bez pisania ani jednej linijki kodu ani wydawania pieniędzy nasze ćwiczenia „żywych dokumentów” opracowane w części 2 ujawniły wymagania systemowe, które określają nasze przyszłe potrzeby w zakresie infrastruktury hostingowej:

Nie musimy natychmiast zaspokajać wszystkich „poza” potrzeb, ale świadomość ich podczas projektowania i budowania naszego MVP może pomóc zminimalizować liczbę przeróbek. Sprawdźmy, jak to zrobić!

Początkowy zakres MVP oparty na mapie fabularnej i OGSM

eTumble przygotowuje się, by stać się kolejną wielką rzeczą w randkowaniu online. Nasz zespół mądrze poświęcił czas na analizę SWOT, udokumentował nasz 3-5-letni plan strategiczny za pomocą OGSM Framework, zwizualizował i ustalił priorytety naszego MVP za pomocą Story Mapping oraz zaprojektował i udokumentował naszą architekturę przy użyciu części metodologii C4 Model.

Nasz plan OGSM określił początkowy cel 25 000 użytkowników w pierwszym roku oraz taktykę osiągnięcia naszego celu, taką jak program rekomendacji i demonstracje kampusu uniwersyteckiego. Po wielu iteracjach mapowania historii zdecydowaliśmy się na nasz zakres MVP — i zapisaliśmy go .

Jeśli pominęliśmy planowanie strategiczne w celu określenia znaczenia awansów, być może nie wykonaliśmy wystarczającej iteracji na mapie fabularnej, aby ustalić MVP, co pomaga ustalić priorytety, co tworzymy jako pierwsze. Jeszcze bardziej przerażające, być może nazwaliśmy to „Mike's Match Maker” (powyżej) zamiast naszej fajniejszej nazwy, eTumble. ;-)

Szybkie przekazanie naszego MVP w ręce docelowych użytkowników pozwoli nam lepiej zrozumieć problematyczną domenę, a co za tym idzie wpłynie na decyzje na poziomie strategicznym i pomysłowym. Dlatego nasze plany są określane jako „żywe dokumenty” i powinny być powtarzane w miarę upływu czasu.

Wybór naszej platformy hostingowej w chmurze

Wybór dostawcy hostingu w chmurze może stać się politycznym lub religijnym ćwiczeniem w dowolnej organizacji lub zespole. Wolę stosować podejście oparte na danych w przypadku tych decyzji i opisałem, jak to zrobiliśmy w poprzedniej firmie w tym wywiadzie BrightTALK w 2020 roku.

We wcześniejszych częściach tej serii umknąłem faktowi, że będziemy używać Google Cloud Platform (GCP), więc pokrótce wyjaśnię moje typowe podejście.

Organizowałem ten proces w poprzednich organizacjach, a jedna miała linię produktów ze strategią mobilną, więc moje powody wyboru GCP wynikają z wcześniejszego doświadczenia i wspierania tysięcy firm w DoiT. AWS Amplify jest konkurencyjnym rozwiązaniem, ale nie wypada w porównaniu z GCP Firebase pod względem wielu powyższych kryteriów, zwłaszcza łatwości użytkowania.

Ten artykuł zawiera dalsze szczegóły dotyczące porównania dwóch popularnych frameworków mobilnych, GCP Firebase i AWS Amplify , ale jest to za zaporą Medium. Konsensus był taki, że Firebase jest bardziej wszechstronna, łatwiejsza w użyciu i może być bardziej opłacalna.

Bez względu na to, którą platformę wybierzesz, zidentyfikowaliśmy zarówno krótko-, jak i długoterminowe wymagania naszego systemu. Załóżmy, że przeszliśmy przez powyższy proces oceny, wybraliśmy GCP z różnych powodów, a teraz musimy zaprojektować naszą infrastrukturę hostingu w chmurze.

Automatyzacja naszych wdrożeń kodu źródłowego

Oprócz ludzi, rdzeniem każdego startupu programistycznego jest jego kod źródłowy — ustrukturyzowany tekst, który jest konwertowany na instrukcje, które komputer może zrozumieć i przetworzyć. Aby nasze programy dotarły do ​​zamierzonej grupy odbiorców (zakładając, że na tym etapie nie ma „Smokescreen MVP”), muszą zostać wdrożone w wybranych przez nas środowiskach hostingowych.

Jedną z naszych strategii dla eTumble jest wprowadzanie innowacji szybciej niż inni. Chociaż może to opisywać wiele aspektów uruchamiania oprogramowania, skupimy się na szybkości programistów i szybkości, z jaką użytkownicy końcowi mogą realizować nowe funkcje (historie użytkowników). Istnieją badania, które dowodzą, że jest to przewaga konkurencyjna, jednak w tym artykule nie będziemy omawiać wszystkich szczegółów DevOps i DevSecOps oraz potoków CI/CD.

Sposób, w jaki to się dzieje, może zależeć od osobistych preferencji zespołu programistów. Wielu dostawców hostingu kodu źródłowego (np. — Github.com, Gitlab.com lub Bitbucket.com) ma teraz własne narzędzia. Wiele z nich oferuje również webhooki, gdy wystąpią zdarzenia, które uruchamiają rozwiązania innych firm. Każdy dostawca hostingu w chmurze ma również własne usługi, takie jak Microsoft Azure Dev Ops lub Cloud Build i Cloud Deploy firmy GCP.

Zwykle zalecam większości organizacji rozważenie rozwiązania dostawcy usług w chmurze, minimalnie na etapie „wdrażania” potoków kompilacji, ponieważ eliminuje to potrzebę udostępniania długotrwałych kluczy konta usługi (które mogą być zagrożone) zewnętrznemu podmiotowi system. GCP oferuje Workload Identity Federation , która umożliwia przypisywanie ról IAM do rozwiązania innej firmy bez udostępniania kluczy, co również jest opcją.

Zagadnienia dotyczące skalowania w chmurze

Monolit czy nie

Spójrzmy prawdzie w oczy, większość odnoszących obecnie globalne sukcesy startupów programistycznych zaczynała jako 3-warstwowa aplikacja monolityczna. Nie ma nic złego w monolitach na wczesnym etapie. Sprzężenie minimalizuje wiele złożoności technicznych i, jak sugeruje „Topologie zespołu”, decyzje te często dotyczą obciążenia poznawczego zespołu . Z celem 25 000 użytkowników w naszym pierwszym roku i skupieniem się na kampusie uniwersyteckim, jest to całkowicie akceptowalny projekt dla zakresu naszego MVP.

Problem często pojawia się, gdy zaczynasz skalować. Nie obawiaj się jednak, ponieważ możemy zaprojektować nasze „szybkie i brudne” rozwiązanie, aby łatwo uwzględnić naszą przyszłą architekturę mikrousług.

W naszych diagramach architektury modelu C4 zidentyfikowaliśmy „Kontrolery” w widoku komponentu dla aplikacji „Backend API”. Na przykład wiersze wskazujące publikowanie wiadomości w Pub/Sub mogą początkowo zawierać logikę mikrousługi w aplikacji API w warstwie „Model” architektury Model-View-Controller (MVC). Trasy API pozostają takie same.

Uwzględniając mikroserwisy, możemy przenieść funkcjonalność „Modelu” z aplikacji API do osobnych usług i komunikować się za pośrednictwem protokołu HTTP/RPC lub przesyłania komunikatów asynchronicznych. Jeśli planujesz z wyprzedzeniem, możesz zaprojektować warstwę opakowującą dla wywołań funkcji lub metod, które początkowo wchodzą w interakcję z warstwą danych, a następnie przejść do wywołań zdalnych w przyszłości przy minimalnych zmianach w kodzie.

Jeśli jednak zaprojektowałeś wystarczającą liczbę systemów rozproszonych, możesz zamiast tego wybrać architekturę sterowaną zdarzeniami, jak pokazano na naszym diagramie kontenera.

Przejście „bezserwerowe” lub używanie kontenerów

Na początku tej 3-częściowej serii stwierdziłem, że dzisiejsze startupy programistyczne mają przewagę nad tymi sprzed pięciu do dziesięciu lat, po części dzięki dostawcom chmury hiperskalowej. Doskonałym przykładem są produkty bezserwerowe, takie jak AWS Lambda, Google Cloud Functions, czy nawet Azure Functions. Deweloperzy mogą przesyłać swój kod do tych „środowisk wykonawczych” i korzystać z braku konserwacji infrastruktury oraz automatycznego skalowania.

Chociaż wydaje się to oczywistym podejściem do uruchomienia MVP, pamiętaj o technicznym polu minowym, które założysz po drodze. Niektóre z tych usług oferują emulator, dzięki czemu można budować i testować lokalnie, co pomaga zmniejszyć zależność i koszty innego środowiska.

Wolę wykorzystywać rozwiązania bezserwerowe do małych zadań asynchronicznych o jednym celu, które są wyzwalane przez zdarzenia w systemie, takie jak „przesłanie lub zmiana pliku” lub „opublikowanie wiadomości”.

W celu zbudowania interfejsu API, który będzie kierował żądania do różnych elementów zaplecza, rozsądniejszym wyborem może być aplikacja kontenerowa. Ponieważ wszystkie zależności są spakowane w obrazie, kontenery upraszczają lokalne programowanie i testowanie. Większość dostawców hostingu w chmurze oferuje „bezserwerowe” rozwiązania kontenerowe, takie jak ECS na AWS i Cloud Run lub App Engine Flexible na GCP.

Wolę przenośność kontenerów w przypadku bardziej złożonych aplikacji, a jeśli przestrzegasz zasad metodologii aplikacji 12-czynnikowej , zmniejsza to również ryzyko przeniesienia konfiguracji do różnych środowisk w potoku CI/CD.

Priyanka Vergadia w Google udostępnia zbiór „notatek ze szkicami”, a ten poniżej ilustrujący „ Gdzie powinienem uruchomić swoje rzeczy ” jest przydatnym przewodnikiem.

Wykorzystanie grup e-mail do skalowania od jednego do wielu zespołów

Załóżmy, że zaczynaliśmy od kilku osób, ale nasz plan ostatecznie wymaga obsługi dziesiątek milionów użytkowników w wielu krajach. Bez wątpienia rozszerzymy naszą organizację tak, aby obejmowała wiele zespołów i specjalistów (oś y i oś z kostki AKF Scale Cube dotyczy również naszej organizacji).

Najlepszą praktyką podczas konfigurowania zarządzania tożsamością i dostępem (IAM) z platformami chmurowymi jest przypisywanie ról grupom zamiast poszczególnym użytkownikom. W artykule, który napisałem kilka lat temu o strukturyzacji przedsiębiorstw w chmurze , wyjaśniam zalecane grupy początkowe i wiele więcej.

grupy, które zakładamy na wczesnym etapie, mogą skalować się wraz z organizacją (tylko członkowie zmieniają się z czasem)

Nawet jeśli nasz startup zaczyna się od trzech osób, nic nie stoi na przeszkodzie, aby na start zdefiniować grupy i dodać osoby do kilku z nich . W miarę zatrudniania kolejnych osób możemy stopniowo oddawać grupy specjalistom.

W skali przedsiębiorstwa można w końcu podzielić zespoły dalej, zgodnie z potrzebami i wymaganiami obciążenia poznawczego. Bez względu na to, od czego zaczynasz, najlepszą praktyką jest przydzielanie ról IAM w chmurze grupom zamiast poszczególnym użytkownikom, aby ułatwić ich konserwację i zminimalizować przeróbki — zwróć uwagę na ten wzorzec.

Projektowanie hierarchii zasobów w chmurze dla wielu dzierżawców

Ta lista kontrolna Bezpiecznego GCP , której jestem autorem kilka lat temu, zawiera ilustracyjny przykład zalecanego projektu najlepszych praktyk. Ponieważ projektujemy naszą architekturę chmurową dla naszego MVP, na wczesnym etapie może być trochę „wyrzucenia”, ale nadal zalecam podobną strukturę podczas konfigurowania dowolnej hierarchii zasobów w chmurze.

Wraz ze skalowaniem organizacji i postępem w kierunku nowszych wersji produktu zilustrowanych na naszej mapie historyjek użytkownika, możemy przejść do scentralizowanej administracji sieciowej, zarządzania klastrami Kubernetes i wielodostępnej struktury zespołu. To często powoduje problemy ze start-upami oprogramowania, gdy osiągają punkty przegięcia opisane w części 1 tej serii.

na wczesnym etapie mogą wystąpić pewne „wyrzucanie” pracy

GCP ma świetne odniesienie, które opisuje, jak ustanowić wielodostępność przedsiębiorstwa z większą ilością szczegółów. Poniżej znajduje się ilustracja tego, jak może wyglądać infrastruktura chmurowa eTumble w przyszłości, kiedy osiągniemy nasze cele na rok 2 i 3 (pomijając widok zasobów ze względu na zwięzłość artykułu).

Kluczowym wnioskiem jest tutaj zauważenie, że początkowe projekty folderów usług wspólnych nigdy się nie zmieniają, a grupy , które utworzyliśmy na wczesnym etapie, mogą skalować się wraz z organizacją (tylko członkowie zmieniają się z czasem). Każda dzierżawa (zespół) utrzymuje swoje określone zasoby, takie jak bazy danych i wpisy tajne w swoich projektach, i odwołuje się do nich z kontenerowych aplikacji wdrożonych w klastrach w odpowiednich przestrzeniach nazw.

Systemy zewnętrzne (uwierzytelnianie, płatności, poczta e-mail itp.)

Nasz plan i projekty ilustrowały zapotrzebowanie na systemy zewnętrzne, takie jak transakcyjna poczta e-mail, płatności online oraz ewentualnie tożsamość i uwierzytelnianie. Wybierając zewnętrznych dostawców rozwiązań, weź pod uwagę następujące kwestie:

• wiele środowisk do testowania i produkcji z oddzielną autoryzacją
• utrzymywanie i obracanie poświadczeń w zaszyfrowanym tajnym magazynie
• zachęty handlowe dostępne do zakupu za pośrednictwem platformy handlowej

Gratulacje za zajście tak daleko! Ta trzyczęściowa seria zabierze Cię w podróż od przydatnych metodologii i frameworków, do projektowania start-upu oprogramowania od podstaw, aż po wykorzystanie „żywych dokumentów” do planowania infrastruktury chmurowej zarówno na wczesnym, jak i późniejszym etapie.

• Część 1: tło i wprowadzenie do metodologii
• Część 2: wdrażanie metodologii z fikcyjnym startupem
• Część 3: projektowanie i skalowanie infrastruktury chmurowej

Nie mogę się doczekać, aż zastosujesz te zasady i dokończysz tam, gdzie skończyliśmy, aby pomóc rozwiązać problem samotności na skalę planetarną . ;-)

Jeśli uważasz, że ta seria będzie pomocna dla innych, nie trzymaj tego w tajemnicy. Daj każdej części trochę „miłości” i klaszcz, i podziel się z innymi. Dziękuje za przeczytanie!