Kilka lat temu mieliśmy ciekawy problem. Jesteśmy w pełni zdalną firmą z całym naszym oprogramowaniem w chmurze. Mieliśmy też zestaw aplikacji Spring Boot działających na kontenerach z Infrastructure as Code. Potrzebowaliśmy jednak elastyczności biznesowej. Globalny rynek pracy porusza się szybko i zawsze istnieje zapotrzebowanie na nowe produkty. Musieliśmy znaleźć sposób na utrzymanie pozycji lidera w branży.
Jesteśmy firmą technologiczną z odważną strategią
W 2022 stworzyliśmy ADR (Architecture Decision Record), który mówił: "serverless-first and containers-as-needed." I wywołał debatę w prawie 40 zespołach inżynieryjnych.
Wyjaśnijmy najpierw trochę terminologii
Serverless-first to nie tylko funkcje jako usługa. To także grupa usług zarządzanych od dostawców usług w chmurze, które:
- Niższe koszty operacyjne dzięki rezygnacji z zarządzania infrastrukturą
- Skalowanie według potrzeb, w tym skalowanie do zera, aby były w pełni elastyczne.
- Elastyczne ceny (płacą Państwo tylko za to, czego używają)
W G-P, serverless-first odnosi się do naszego wykorzystania AWS Lambda, EventBridge, Step Functions, Fargate, SQS, SNS, interfejs programowania aplikacji Gateway, S3, DynamoDB i innych.
Serverless-first oznacza, że kiedy wybieramy rozwiązanie Compute, Storage, Messaging lub podobne, chcielibyśmy, aby zespoły zaczynały od opcji bezserwerowej. Ważna uwaga: jeśli usługa bezserwerowa nie spełnia potrzeb, zespoły powinny wrócić do cięższej usługi - takiej, która wymaga większych inwestycji operacyjnych.
„Containers-as-needed” wyjaśnia, że „servless-first” nie oznacza „wyłącznie bezserwerowo”. Czasem potrzebujemy kontenerów (np. w celu zainstalowania oprogramowania COTS) — i to jest w porządku.
Strategia technologiczna, której priorytetem są klienci
Działamy w szybkim tempie, aby sprostać potrzebom naszych klientów i użytkowników. Usługi takie jak Lambda, S3 i DynamoBD są niezwykle odporne i szybkie. Odciążając niezróżnicowane, ciężkie zadania, możemy poświęcić więcej czasu na tworzenie funkcji dla użytkowników, zamiast pracować nad ogólną konfiguracją infrastruktury.
Kluczową zasadą w G-P jest: "Państwo budujecie, Państwo uruchamiacie." Nasze zespoły są właścicielami swojego oprogramowania. Nie przerzucamy więc oprogramowania przez ścianę do zespołu DevOps.
Korzyści płynące z "serverless-first"
Serverless jest z natury sterowany zdarzeniami.
Nasza architektura jest w pełni sterowana zdarzeniami. Korzystając z EDA (Event-Driven Architecture), możemy skalować zarówno naszą organizację, jak i nasze oprogramowanie. Serverless zmusza nas do utrzymywania małego promienia rażenia i komunikowania się w pełni natywny dla chmury sposób poprzez WYDARZENIA.
Ograniczenia umożliwiające
Jako platforma Globalna zatrudniania traktujemy zgodność z przepisami poważnie. Nasza infrastruktura chmurowa jest dobrze zaprojektowana, a my korzystamy ze strategii wielokontowej, która rozdziela obciążenia i automatyzuje zgodność z wymaganiami chmury. Rozwiązania bezserwerowe pomagają nam egzekwować wysokie standardy poprzez kontrolowanie sposobu udostępniania zasobów chmury.
Odciążenie od pracy
Nasz dostawca usług w chmurze zarządza naszymi usługami bezserwerowymi. Pojedynczy zestaw bloków konstrukcyjnych - zintegrowanych, zabezpieczonych, dostrojonych, włączonych i utrzymywanych przez AWS - pozwala nam skupić się na wyższym poziomie łańcucha wartości dla klientów.
Dobrze zaprojektowane obciążenia
Każde tworzone przez nas obciążenie jest weryfikowane za pomocą AWS Well-Architected Framework. Koncentrujemy się na skali, bezpieczeństwie, niezawodności i optymalizacji kosztów, aby zapewnić, że nie tylko spełniamy, ale także przekraczamy nasze umowy SLA (Service Level Agreement). Umożliwia to naszym zespołom inżynieryjnym dalszą ewolucję środowisk chmurowych.
O naszych zespołach
Nasza strategia technologiczna jest ambitna, co czyni ją wymagającą. Wielu inżynierów nie pracowało w architekturze bezserwerowej (lub rozproszonej). Przejście na architekturę bezserwerową nie jest łatwe, a my szukamy inżynierów, którzy czują się komfortowo ucząc się, myśląc na dużą skalę i poruszając się w szybkim tempie.
Niektórzy inżynierowie nie są pewni co do terminu serverless (tak, wiemy, że istnieją serwery), ponieważ podejście to jest czymś więcej niż tylko pisaniem kodu w funkcjach. Nasza strategia wymaga holistycznego podejścia do klasycznych zasad natywnych dla chmury.
Wynik
W ciągu dwóch lat poczyniliśmy niezwykłe postępy. Modernizacja niesie ze sobą wiele korzyści (zobacz nasz artykuł o coroczny dodatek do wynagrodzenia / znanej wartości biznesowej modernizacji chmury). Dokładniej rzecz biorąc, zaobserwowaliśmy następujące rzeczy:
1. Szybkość: Sposób, w jaki podzieliliśmy nasz system, pozwala zespołom i produktom na niezależną innowacyjność i ewolucję. Ma to ogromny wpływ na elastyczność biznesu.
2. Zgodność: Używamy coroczny dodatek do wynagrodzenia Well-Architected Framework do przeglądu wszystkich obciążeń. Ponieważ korzystamy z wielu coroczny dodatek do wynagrodzenia Managed Services, możemy polegać na ich doskonałości operacyjnej i zaczynać od wysokiej jakości.
3. Myślenie systemowe: Musieliśmy ujednolicić wiele naszych procesów, abyśmy mogli wnioskować o systemie, niezawodności i wartości biznesowej. Nie marnujemy czasu na pracę nad podzespołami o niskiej wartości.
4. Innowacja: Serwerless oznacza, że wszystko jest interfejs programowania aplikacji. To wymuszone ograniczenie wymaga podejścia interfejs programowania aplikacji-first. Kiedy myślimy o sobie jako o platformie, możemy osiągnąć nowy poziom innowacji, łatwo łącząc systemy za pomocą API, na przykład podłączając G-P Gia™ do nowej bazy wiedzy.
5. Własność: coroczny dodatek do wynagrodzenia jest właścicielem naszej infrastruktury, ale my jesteśmy właścicielami naszej domeny biznesowej. Koncepcja „servless first” i projektowanie zorientowane na domenę zmusiły nas do skupienia się na problemie biznesowym. To utrzymuje własność możliwości czystą.
Serverless-first nie zawsze jest szybsze, ale jest bardziej korzystne. Wolimy optymalizować pod kątem szybkości systemu niż szybkości poszczególnych deweloperów. Serverless-first polega mniej na korzystaniu z funkcji, a bardziej na myśleniu: "Kod to odpowiedzialność. System jest atutem." Im mniej kodu musimy napisać, tym więcej możemy rozważyć i kształtować system biznesowy, który budujemy.
W miarę jak będziemy dzielić się naszą historią, stanie się oczywiste, z jaką prędkością pracujemy, co jest bezpośrednim rezultatem serverless-first. Proszę być na bieżąco.
