Bezpieczne przyśpieszenie wdrażania aplikacji z NGINX

Wdrożenie nowej aplikacji przed pandemią zajmowało średnio od pół roku do roku. Obecnie jest to ok. sześciu tygodni. Jak twierdzą nasi klienci: tak zadziałał kryzys. Wszystkie procesy i politykę odsunięto na bok, a firmy zwiększyły deweloperom oprogramowania tempo prac z marszowego na sprint. Planowanie, prototypowanie i wypuszczanie kodu do produkcji zaczęło zajmować ułamek tego, co było dotychczasowym standardem czasu ich pracy. Szybkie tempo wdrożenia nowego kodu może jednak zaburzyć pracę lub potencjalnie usunąć aplikacje o krytycznym znaczeniu dla firmy, wpływając na reputację, przychody czy nawet narażając dane klientów.

Bezpieczne są tu firmy natywne dla chmury – nieobciążone pozostałościami po zastanych architekturach. Zostały one zaprojektowane żeby wprowadzać wiele zmian dziennie.

Tymczasem pandemiczne przyśpieszenie prowadzi do tarcia między deweloperami a zespołami odpowiedzialnymi za infrastrukturę, których zadaniem jest poprawa niezawodności i czasu pracy oraz upewnienie się, że nie dojdzie do naruszeń. Obecnie te procesy nie wytrzymują presji czasu dyktowanej przez COVID-19, a manualne sposoby zarządzania nie są wystarczające aby utrzymać odpowiednie tempo. Szczęśliwie zespoły, narzędzia i wiedza potrzebne w tym zakresie są dostępne. DevOps już teraz pomagają automatyzować proces dostarczania, a narzędzia CI/CD i orkiestracji są do tego wystarczające. Również technologie ewoluujące w kontenery, Kubernety i architektury natywne dla chmury są gotowe do produkcji. Wystarczy złożyć to wszystko w całość.  

W epicentrum zmiany znajduje się koncepcja mikrousług – dzielenia aplikacji na małe, oddzielne funkcje wielokrotnego użytku zoptymalizowane dla zespołów, narzędzi i technologii opisanych powyżej. Jeśli deweloper popełni błąd, to mikrousługa zaburzy wyłącznie mały wycinek całej struktury, a zdecydowana większość aplikacji – a tym samym biznes, który się na nich opiera – będą działały bez zakłóceń. Przedsiębiorcy wdrażają więc środowiska mikrousług w swoim portfolio aplikacji tworząc architekturę hybrydową. Dla klientów F5 oznacza to umieszczenie technologii NGINX bliżej aplikacji w roli mechanizmu dostarczania mikrousług działającego jako komplementarna, oddzielna warstwa nad BIG-IP dostarczającym ich aplikacje dla starszego środowiska.

Wydzielenie ich z architektury umożliwia deweloperom samoobsługę w obszarze potrzebnym do testowania i wdrażania nowych funkcji wymagających zmian w zasadach ruchu. Dzięki temu mogą przeprowadzać bezpieczne testowanie (canary testing), ograniczyć przestoje (blue-green) czy porównywanie wersji (A/B testing) bez konieczności ustaleń z innymi zespołami czy otwierania zgłoszenia IT i oczekiwania na okienko czasowe do wprowadzenia zmian. NGINX, jak mikrousługi, dzieli te możliwości na małe składowe infrastruktury dostarczania, dając każdemu zespołowi jego własną, oddzielną część i ograniczając tylko do niej możliwość zmian w aplikacji. Zapewnia to stabilność warstwie infrastruktury BIG-IP ponieważ takie małe zmiany nie są w stanie zachwiać potencjałem wielu aplikacji wspieranych przez infrastrukturę jako całość.

Niemniej takie rozwiązanie sprawdza się połowicznie. Pozostaje wyzwanie widoczności i łączenia środowisk pracy tak, aby wszyscy w organizacji mieli ten sam obraz. Dla wielu firm ze złożonymi środowiskami prawie nie ma znaczenia, jak szybko deweloperzy mogą wprowadzać zmiany – i tak kończą one w poczekalni na audyt kodu czy zmianę zasad firewall wprowadzanych przez specjalistów od ochrony. Z naszego doświadczenia wynika, że nawet 50 odrębnych zespołów aplikacyjnych na raz – każdy pracujący ze swoimi mikrousługami – potrzebuje skoordynować zmiany z zespołem ochrony na zasadach centrum rozliczeniowego, co powoduje nowe wąskie gardła w procesie.

Inwestowanie w oddzielną warstwę usadowioną ponad infrastrukturą dostarczania aplikacji rozwiązuje kłopot integracji sieci z oprogramowaniem. Niemniej, jeśli te warstwy nie komunikują się ze sobą, tworzy się po prostu kolejny silos. Problem z warstwy hardware przenosi się jedynie do warstwy software – jedna połowa równania może przebiegać szybko, ale druga już nie[1]. Pełne rozwiązanie kwestii „manualnych opóźnień” wymaga dostarczenia widoczności, orkiestracji i automatyzacji eliminujących punkty przekazywania i tarcia we wszystkich zespołach programistów, DevOpsów, infrastruktury i operacji oraz ochrony – tak jak robią to firmy natywne dla chmury.

Integracja wertykalna vs horyzontalna

Dotychczas, rozwiązaniem było tworzenie platform zintegrowanych wertykalnie (Paas i SaaS), które wykonają za nas te czynności. Ich minusem pozostaje jednak ścisłe łączenie usług aplikacyjnych z infrastrukturą bazową. Początkowo pozwala to przyśpieszać, ale później może się okazać, że możliwości adaptacji zostały ograniczone. Jeśli dojdzie do dużej zmiany jak np. akwizycja firmy, nie będziemy mogli szybko połączyć systemów, zadokować się do nowej chmury czy dokonać repatriacji aplikacji.

Integrowanie poziome – poprzez czynnik ludzki – okazuje się bardziej wartościowe niż pionowe, ponieważ jest sposobem gwarantującym widoczność, przepływy pracy i API we wszystkich stadiach cyklu życiowego aplikacji.  

Szczęśliwie technologie zapewniające powyższe możliwości otwartego i luźno powiązanego modelu są dostępne. Tak więc dla firm ze spuścizną infrastruktury hybrydowej możliwości przyśpieszenia i konkurowania z firmami natywnymi dla chmury są w zasięgu ręki. Co więcej, nie wymagają zatrudnienia tysiąca deweloperów oprogramowania, aby było to możliwe.

Zastosowanie odrębnej, horyzontalnej dla organizacji warstwy, która automatyzuje i utrzymuje dostarczanie aplikacji oraz ochrony aplikacyjnej, pozwoli deweloperom działać szybciej.

 Rob Whiteley, vice president of marketing for NGINX, F5 Networks 

[1] Dla przykładu: dobrze jest skrócić czas reakcji aplikacji ze 100 ms do 10 ms, ale jeśli zespół ochrony potrzebuje 2 m-cy na akceptację kodu i wdrożenie nowych polityk – pozostajemy z 5 bln ms opóźnienia powodowanego przez czynnik ludzki. Wprowadzenie nawet 90% redukcji w opóźnieniu aplikacyjnym niweluje więc tylko maleńką cześć kłopotu.