Aplikacje w chmurze AWS
Projektujemy i budujemy aplikacje w chmurze AWS. Model uruchomienia dobieramy do obciążenia: funkcje AWS Lambda, kontenery w ECS Fargate albo App Runner. Infrastrukturę opisujemy w AWS CDK lub Terraform, więc każde środowisko da się odtworzyć z repozytorium.
Kiedy aplikacja dobrze sprawdzi się w AWS
-
Ruch zmienia się w ciągu dnia albo sezonu
Funkcje Lambda i kontenery Fargate dodają moc, gdy rośnie liczba użytkowników, i oddają ją po szczycie. Płacisz za faktyczne użycie, a nie za serwer gotowy na największy ruch.
-
Proces składa się z wielu kroków
Zamówienie, płatność, dokument, powiadomienie: takie procesy rozpisujemy w AWS Step Functions. Każdy krok ma własną obsługę błędów i można go ponowić bez powtarzania całości.
-
Aplikacja przetwarza pliki
Przesłany plik trafia do Amazon S3 i od razu uruchamia funkcję, która go odczyta, przekonwertuje albo zapisze wynik w bazie. Nikt nie musi tego robić ręcznie.
-
Masz konto AWS bez porządku w kosztach
Przeglądamy usługi aplikacji, opisujemy je w kodzie, oznaczamy zasoby i ustawiamy budżety z alertami. Widzisz, ile kosztuje każde środowisko.
Kiedy wybrać AWS, a kiedy coś innego
AWS polecamy, gdy aplikacja ma nierówny ruch, przetwarza pliki albo składa się z wielu kroków uruchamianych zdarzeniami. Wybór usług serverless jest tu najszerszy, a Lambda, Step Functions i DynamoDB dobrze ze sobą współpracują. AWS ma sens także wtedy, gdy Twoja firma prowadzi już w nim inne systemy.
Inną chmurę rozważamy w trzech sytuacjach. Gdy firma ma subskrypcję Microsoft Azure i aplikację w .NET, wygodniej zostać w Azure (zobacz aplikacje w Microsoft Azure). Gdy dane muszą fizycznie pozostać w Polsce, wybieramy Azure albo Google Cloud, bo mają regiony w Warszawie, a AWS w Polsce regionu nie ma. Przy małej aplikacji ze stałym, przewidywalnym ruchem tańszy od usług chmurowych może być pojedynczy serwer, o czym mówimy przy wycenie.
Przykładowa architektura aplikacji w AWS
Typowa aplikacja webowa, którą budujemy w AWS, składa się z kilku warstw:
- Statyczne pliki interfejsu trafiają do Amazon S3 i są dostarczane przez CloudFront z certyfikatem HTTPS.
- Żądania użytkowników przyjmuje Amazon API Gateway i przekazuje je do funkcji Lambda albo do kontenera w ECS Fargate.
- Dane zapisujemy w DynamoDB, a gdy aplikacja potrzebuje relacji i raportów, w Amazon RDS for PostgreSQL.
- Pliki użytkowników trafiają do osobnego zasobnika S3, a każdy nowy plik uruchamia funkcję, która go przetwarza.
- Dłuższe procesy prowadzi AWS Step Functions, a zdarzenia między częściami aplikacji przekazuje EventBridge.
- Logi i alarmy zbiera CloudWatch, a budżety kosztów informują o przekroczeniu założonej kwoty.
Tak zbudowaną aplikację możemy po wdrożeniu utrzymywać i rozwijać w ramach utrzymania i rozwoju aplikacji. Jeśli planujesz własny produkt z subskrypcjami, zobacz, jak budujemy platformy SaaS i MVP. Automatyzację wdrożeń i pracę z kontenerami opisujemy szerzej na stronie DevOps dla aplikacji, a przykład użycia Amazon Bedrock na stronie integracja AI w aplikacji firmowej.
Co robimy
- Projektujemy architekturę aplikacji w AWS i szacujemy jej miesięczny koszt w AWS Pricing Calculator
- Budujemy backend serverless na AWS Lambda i Amazon API Gateway
- Uruchamiamy aplikacje Next.js, .NET i Node.js w kontenerach na Amazon ECS Fargate lub AWS App Runner
- Dobieramy bazę danych do sposobu korzystania z danych, Amazon DynamoDB albo Amazon RDS for PostgreSQL
- Rozpisujemy procesy wieloetapowe w AWS Step Functions, a zdarzenia przekazujemy przez Amazon EventBridge i SQS
- Udostępniamy pliki i interfejs przez Amazon S3 i CloudFront
- Dodajemy do aplikacji modele AI w Amazon Bedrock, z danymi przetwarzanymi w regionie UE
- Opisujemy infrastrukturę w AWS CDK, AWS SAM lub Terraform i automatyzujemy wdrożenia
- Ustawiamy uprawnienia IAM, logi i alarmy w Amazon CloudWatch oraz budżety kosztów
Dla kogo
- Budujesz nową aplikację, której ruch trudno przewidzieć
- Twoja firma ma już konto AWS i chce na nim uruchomić aplikację
- Aplikacja działa na jednym serwerze i chcesz przenieść ją do kontenerów w chmurze
- Proces w aplikacji obejmuje wiele kroków, plików albo integracji
Serverless: Lambda, API Gateway i DynamoDB
W architekturze serverless nie utrzymujemy żadnego serwera. Żądanie z aplikacji trafia do Amazon API Gateway, który uruchamia funkcję Lambda. Funkcja wykonuje logikę i zapisuje dane w DynamoDB. AWS sam zapewnia moc obliczeniową, aktualizacje systemu i dostępność w kilku strefach regionu. Ten model wybieramy dla aplikacji z nierównym ruchem i dla zadań uruchamianych zdarzeniami.
- Brak opłat za czas, w którym nikt nie korzysta z aplikacji
- Dostępność w kilku strefach regionu bez dodatkowej konfiguracji
- Każda funkcja wdrażana i skalowana osobno
Kontenery w ECS Fargate i App Runner
Aplikacje Next.js i .NET z naszych realizacji działają w kontenerach Docker. W AWS uruchamiamy je na Amazon ECS Fargate, który sam dobiera moc do obciążenia. Mniejsze aplikacje wdrażamy w AWS App Runner, który dodaje adres HTTPS i automatyczne skalowanie bez konfiguracji sieci. Nowa wersja wchodzi bez przerwy w działaniu, a w razie błędu wracamy do poprzedniej.
- Ten sam obraz Docker na komputerze programisty i w produkcji
- Wdrożenia nowych wersji bez przerwy w działaniu
- Szybki powrót do poprzedniej wersji
Infrastruktura w AWS CDK i Terraform
Każdą usługę AWS, uprawnienie i alarm opisujemy w kodzie. Własne narzędzia wdrażamy w AWS CDK i SAM, a infrastrukturę nowych stron Conetso Group opisaliśmy w Terraform. Środowisko testowe i produkcyjne powstają z tych samych plików, a każda zmiana przechodzi przegląd przed wdrożeniem.
- Środowiska odtwarzane z repozytorium
- Uprawnienia IAM ograniczone do tego, czego potrzebuje usługa
- Budżety i alerty kosztów dla każdego środowiska
Jak pracujemy
-
Przegląd wymagań
Ustalamy przewidywany ruch, rodzaj danych i region. Jeśli masz konto AWS, sprawdzamy, co już na nim działa.
-
Architektura i koszt
Rozpisujemy usługi AWS, które obsłużą aplikację, i podajemy szacunkowy miesięczny koszt dla przewidywanego ruchu.
-
Budowa w środowisku testowym
Infrastrukturę tworzymy z kodu, a aplikację wdrażamy automatycznie przy każdej zmianie. Wersję testową udostępniamy Ci do sprawdzenia.
-
Wdrożenie produkcyjne
Z tych samych plików tworzymy środowisko produkcyjne, ustawiamy alarmy, budżety i kopie danych, a potem przełączamy domenę.
Doświadczenie
- Nasz produkt Savanna One, system dla firm produkcyjnych, udostępniamy klientom jako usługę w chmurze AWS.
- Dla klienta zbudowaliśmy w Amazon Bedrock we Frankfurcie automatyczną weryfikację umów. Przy około 20 umowach miesięcznie oszczędza około 10 godzin pracy.
- Nowe strony Conetso Group działają na Amazon S3 i CloudFront, formularze obsługuje funkcja AWS Lambda, a całą infrastrukturę opisaliśmy w Terraform.
- Nasze narzędzia wewnętrzne działają na AWS Lambda, ECS Fargate, App Runner, DynamoDB i Step Functions i są wdrażane z AWS CDK i SAM.
Realizacje
-
Savanna One
Savanna One to nasz własny produkt: system dla zakładów produkcyjnych, który łączy magazyn, produkcję i dokumentację. Pracują na nim producenci żywności.
Najczęstsze pytania
W jakim regionie AWS będą nasze dane?
Aplikacje dla firm z Polski uruchamiamy w regionach AWS w Unii Europejskiej, najczęściej we Frankfurcie. Region wybieramy razem z Tobą przed startem projektu i w nim przechowujemy także kopie danych.
Czyje będzie konto AWS?
Konto może należeć do Twojej firmy, a my dostajemy do niego uprawnienia potrzebne do budowy i utrzymania aplikacji. Wtedy faktury za chmurę wystawia AWS bezpośrednio Tobie. Inny układ możemy ustalić w umowie.
Ile kosztuje utrzymanie aplikacji w AWS?
Koszt zależy od ruchu, ilości danych i wybranych usług. Przed rozpoczęciem prac liczymy go w AWS Pricing Calculator dla przewidywanego obciążenia, a po wdrożeniu ustawiamy budżety i alerty, które informują o przekroczeniu kwoty.
Czy przeniesiecie istniejącą aplikację do AWS?
Tak. Zaczynamy od przeglądu kodu i sposobu wdrożenia. Najczęściej najpierw umieszczamy aplikację w kontenerze i uruchamiamy ją w ECS Fargate, a dopiero później przenosimy wybrane funkcje do Lambda, jeśli przyniesie to oszczędności.
Zobacz także
-
Platformy SaaS i MVP dla startupów
Budujemy pierwszą wersję produktu (MVP) i platformy SaaS z kontami użytkowników, subskrypcjami, płatnościami, licencjami i API.
-
Utrzymanie i rozwój aplikacji webowych
W abonamencie dodajemy nowe funkcje, instalujemy poprawki bezpieczeństwa i dbamy o serwer. Czas reakcji określa umowa SLA.