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 serverless-first nie oznacza wyłącznie serverless. Są chwile, kiedy potrzebujemy kontenerów (np. instalując oprogramowanie 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 globalna platforma zatrudnienia poważnie traktujemy zgodność z przepisami. Nasza infrastruktura chmurowa jest dobrze zaprojektowana i korzystamy ze strategii wielu kont, która oddziela obciążenia i automatyzuje zgodność z przepisami dotyczącymi chmury. Serverless pomaga nam egzekwować wysokie standardy poprzez kontrolowanie sposobu udostępniania zasobów w chmurze.

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 przynosi wiele korzyści (proszę zapoznać się z naszym artykułem na temat AWS / znanej wartości biznesowej modernizacji chmury). W szczególności zaobserwowaliśmy, co następuje:

1. Szybkość: Sposób, w jaki podzieliliśmy nasz system, pozwala zespołom i produktom wprowadzać innowacje i rozwijać się niezależnie. Ma to ogromny wpływ na elastyczność biznesową.

2. Zgodność z przepisami: Używamy AWS Well-Architected Framework do przeglądu wszystkich obciążeń. Ponieważ korzystamy z wielu usług AWS Managed Services, możemy polegać na ich doskonałości operacyjnej i zacząć od wysokiej jakości.

3. Myślenie systemowe: Musieliśmy ustandaryzować wiele naszych procesów, abyśmy mogli myśleć o systemie, niezawodności i wartości biznesowej. Nie poświęcamy czasu na pracę nad komponentami o niskiej wartości.

4. Innowacja: Serverless oznacza, że wszystko jest API. To wymuszone ograniczenie wymaga podejścia opartego na interfejsie programowania aplikacji. Kiedy myślimy o sobie jako o platformie, możemy osiągnąć nowy poziom innowacji poprzez łatwe łączenie systemów za pośrednictwem interfejsów programowania aplikacji, takich jak podłączenie G-P Gia™ do nowej bazy wiedzy.

5. Własność: AWS jest właścicielem naszej infrastruktury, ale to my jesteśmy właścicielem naszej domeny biznesowej. Serverless-first z projektowaniem opartym na domenie zmusiło nas do skupienia się na problemie biznesowym. Dzięki temu własność możliwości jest jasna.

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.