Tworzenie aplikacji chmurowych na AWS
Budujemy aplikacje cloud-native działające na AWS, w całości tworzone przez Terraform. Dzięki temu środowisko odtwarza się z kodu, a nie ze zgłoszenia do supportu, a każdy nowy region czy konto startuje z tego samego, przetestowanego fundamentu.
Tworzenie aplikacji cloud-native, za każdym razem tak samo
Co naprawdę zbudowaliśmy na AWS
Prawdziwa produkcyjna praca na AWS, od początku do końca.
Każdy z poniższych projektów działa na AWS i jest tworzony przez Terraform, więc to, co przekazujemy, da się odtworzyć i audytować.
-
Platforma energetyczna Zeronest działa na AWS
Platforma Zeronest do zarządzania fotowoltaiką i magazynami energii powstaje na AWS od stycznia 2024 r., a na produkcji działa od czerwca 2024 r. Kontenery działają na ECS, a dane za nimi trzymają RDS i S3. Zadania sterowane zdarzeniami obsługuje Lambda, a Cognito zarządza tożsamością użytkowników, uwierzytelnianiem i resetem haseł, więc nikt w zespole nie trzyma arkusza z danymi logowania. Komunikacja między usługami idzie przez SNS, a każda zmiana w tym stacku wdraża się przez GitHub Actions. Pod spodem Python i Django REST Framework obsługują API, a Celery zajmuje się zadaniami cyklicznymi i w tle. Całość tworzy Terraform, więc konfigurację można w każdej chwili audytować i odtworzyć z kodu. Platforma obsługuje dziś kilka tysięcy użytkowników przez trzy połączone aplikacje i 16 zintegrowanych marek falowników. Działa za AWS IoT Core, a ruch z urządzeń jest szyfrowany przez MQTT i TLS 1.2.
-
Jeden powtarzalny wzorzec na każdym kolejnym koncie
Centrum Komunikacji (komunikacja w sektorze publicznym), Ticket Club (e-commerce z biletami) i trzecia platforma, zbudowana dla klienta z przemysłowego IoT objętego NDA, działają na tym samym zestawie Terraform plus AWS: trzy różne branże, jeden powtarzalny wzorzec. Każde środowisko jest zdefiniowane w kodzie, więc recenzent może przeczytać zmianę, zanim trafi na produkcję. Każda zmiana w infrastrukturze ma autora i znacznik czasu, a jej powód jest zapisany w tym samym commicie. Stan Terraform jest przechowywany i blokowany centralnie, więc gdy dwóch inżynierów zmienia to samo środowisko naraz, dostają konflikt scalania, a nie dwa konta AWS, które po cichu się rozjeżdżają. Ta dyscyplina obowiązuje niezależnie od tego, na czyim koncie działa: ten sam krok review, ta sama blokada stanu, ten sam ślad audytowy. Żaden element tej konfiguracji nie istnieje wyłącznie w głowie jednego inżyniera - każdy w zespole może otworzyć pliki Terraform i zobaczyć dokładnie, co działa.
-
W drodze do walidacji AWS Partner
Pracujemy nad poziomem Validated w AWS Partner Central. Formalizuje on praktykę AWS, którą prowadzimy na co dzień: ten sam wzorzec Terraform i AWS, który już działa na produkcji u wymienionych wyżej klientów, oceniany według własnych standardów AWS pod kątem bezpieczeństwa, zarządzania kosztami i praktyk operacyjnych. Ta ocena dotyczy trzech rzeczy, które ta strona już opisuje: infrastruktury zdefiniowanej w Terraform, środowisk, które można odtworzyć z kodu, oraz zespołu, który prowadził ten wzorzec na czterech produkcyjnych kontach AWS, zaczynając od pierwszego środowiska Zeronest w styczniu 2024 r. Walidacja jest w toku.
Dlaczego warto zbudować z nami aplikację chmurową
Dwie rzeczy, które nie zmieniają się w żadnym naszym projekcie AWS.
-
Infrastruktura jako kod zamiast klikania w konsoli
Każde środowisko, które stawiamy, powstaje z Terraform, aż po grupy bezpieczeństwa i role IAM, więc staging odpowiada produkcji, bo oba buduje ten sam kod. Nowe środowisko odtwarza się z jednego commita w git, a zmiana w jednym środowisku jest widoczna w pull requeście, zanim trafi do pozostałych. Dzięki tej samej historii commitów możemy po miesiącach pokazać, dlaczego dokładnie zmieniło się ustawienie i kto to zatwierdził. Na koncie AWS Zeronest ta dyscyplina obowiązuje od stycznia 2024 r., we wszystkich dodanych od tego czasu środowiskach.
-
Jedna chmura, głęboka wiedza
AWS to nasza główna chmura dla systemów produkcyjnych - w ponad 50 projektach w całej firmie. Cztery opisane wyżej platformy tworzone przez Terraform (Zeronest, Centrum Komunikacji, Ticket Club i jeszcze jedna platforma objęta NDA) to nasze flagowe przykłady, a nie pełna liczba. Poza tymi czterema nazwane projekty AWS obejmują też platformę energetyczną Enerace i cyfrowego bliźniaka magazynu energii cieplnej dla KYOTO - to osobne projekty, oba opisane w publicznych case studies. Klienci dostają inżynierów, którzy rozwiązywali już problemy AWS tej samej klasy.
-
Zespoły, które zostają przy projekcie
Inżynierowie, którzy w styczniu 2024 r. postawili infrastrukturę AWS Zeronest, prowadzą ją do dziś, ponad dwa lata później. Długoterminowa odpowiedzialność chroni przed dryfem, który pojawia się, gdy infrastruktura co kilka miesięcy przechodzi z zespołu do zespołu, a każdy kolejny musi od nowa poznać to, co wiedział poprzedni, zanim cokolwiek naprawi. Oznacza to też, że osoba, która o 2 w nocy debuguje problem na produkcji, sama napisała dany moduł Terraform.
Powiązane artykuły
Masz pytania?
Tworzenie aplikacji chmurowych na AWS - odpowiedzi
-
Nasze praktyczne, wielokrotnie sprawdzone doświadczenie produkcyjne dotyczy AWS: Zeronest, Centrum Komunikacji, Ticket Club i jeszcze jedna platforma objęta NDA działają tam dziś. Możemy zaprojektować architekturę niezależną od chmury, gdy ograniczenia klienta wymagają innego dostawcy, ale nie twierdzimy, że mamy równie głębokie doświadczenie produkcyjne w innych chmurach - i powiemy to na wstępie.
-
Tak, i zaczynamy od audytu, a nie od przepisywania, tak jak w naszych pracach przy modernizacji systemów legacy. Mapujemy to, co istnieje, stabilizujemy to, co kruche, a potem proponujemy zmiany - w tej kolejności. Tak samo działaliśmy, gdy przejęliśmy bieżące prace AWS przy istniejącej platformie z sektora energetycznego.
-
Pracujemy nad poziomem Validated w AWS Partner Central. To status, o który się staramy, a nie taki, który już mamy - i wolimy powiedzieć to wprost, niż zaokrąglać w górę.
-
Autoskalowanie dostrojone do faktycznego obciążenia zamiast stałego rozmiaru instancji oraz alerty, które sygnalizują skok kosztów, póki jest jeszcze mały. Tę samą parę zmian dodaliśmy do konfiguracji RDS w Zeronest: najpierw autoskalowanie, potem alerty, które wyłapują to, czego samo autoskalowanie by nie złapało.
Sprawdźmy, czego naprawdę potrzebuje Twoja platforma AWS
Dziękujemy za wiadomość.
Każdą wiadomość czytamy sami i odpowiadamy w ciągu 48 godzin w dni robocze.
Coś pilnego? hello@ordergroup.co