Najnowsze wiadomości

Porównanie AWS Lambda vs ECS wraca w niemal każdym projekcie chmurowym, który prowadzimy. Marketing serverless obiecuje płacenie wyłącznie za faktyczne wykonanie kodu, jednak w praktyce ten model nie zawsze jest najtańszy. Przy dużej skali funkcje Lambda potrafią kosztować więcej niż odpowiednio skonfigurowany klaster, a kontenery przy niskim ruchu generują opłaty za bezczynne zasoby. W tym artykule pokazujemy, jak porównać oba modele i na jakiej podstawie podjąć decyzję o wyborze architektury AWS.

Jedno VPC wystarcza na start, ale wraz z rozwojem firmy środowisk przybywa: osobne dla produkcji, testów i developmentu, kolejne dla nowych zespołów lub klientów, często w oddzielnych kontach AWS. W pewnym momencie te sieci muszą się ze sobą komunikować – i właśnie wtedy zapada jedna z ważniejszych decyzji w projektowaniu sieci AWS. Do wyboru masz dwa mechanizmy: VPC Peering i AWS Transit Gateway. Wyjaśniamy, czym się różnią, ile kosztują i kiedy każdy z nich ma sens.

Pierwszy gwałtowny wzrost ruchu szybko weryfikuje skalowalność MVP. Gdy kampania zaczyna działać, liczba rejestracji rośnie, a pojedynczy serwer przestaje radzić sobie z obciążeniem, sukces marketingowy szybko zamienia się w problem z dostępnością aplikacji. W takich sytuacjach sprawdzi się architektura oparta na automatycznym skalowaniu. AWS Lambda domyślnie obsługuje do 1 000 równoczesnych wykonań w regionie, a Amazon ECS może zwiększać liczbę kontenerów wraz ze wzrostem obciążenia.

Jeżeli planujesz połączyć maszyny produkcyjne z chmurą, pytanie o wybór protokołu IIoT pojawi się na jednym z pierwszych spotkań projektowych. MQTT i OPC UA to dwa najczęściej stosowane protokoły IoT przemysłowego, jednak powstały z myślą o innych zadaniach i mają odmienne mocne strony. Wyjaśniamy, czym się różnią, kiedy sprawdza się każdy z nich i dlaczego w projektach Przemysłu 4.0 często najlepiej działa połączenie tych protokołów.

Autoskalowanie to jeden z głównych powodów, dla których firmy przechodzą na Kubernetesa lub w ogóle chcą korzystać z chmury. Mimo to w wielu klastrach, które audytujemy, Horizontal Pod Autoscaler albo w ogóle nie jest używany, albo jest skonfigurowany w sposób, który aktywnie szkodzi aplikacji. Liczba replik jest ustalana raz, na sztywno wpisana w manifest, a klaster płaci za szczytową pojemność 24/7. To dokładne przeciwieństwo tego, jak powinno wyglądać środowisko cloud native.

Konteneryzacja i Kubernetes rozwiązały problem uruchamiania aplikacji w sposób powtarzalny i w dużej skali, ale stworzyły nowy: jak w kontrolowany sposób zarządzać dziesiątkami manifestów, w kilku środowiskach, w wielu zespołach naraz? Ręczne kubectl apply, pipeline z dostępami do środowiska produkcyjnego i konfiguracja, której nikt nie potrafi odtworzyć — to codzienność wielu zespołów. Odpowiedzią na ten chaos jest GitOps, a jednym z przodujących narzędzi, które go realizują — Argo CD.