Automatyzacja jednym z kluczy do wsparcia programistów

Ireneusz Wiśniewski, dyrektor zarządzający w F5 Poland, mówi o tym, jak wzmocnić pozycję programistów, jednocześnie chroniąc przed skomplikowaniem, wysokimi kosztami i zagrożeniami bezpieczeństwa. Jego zdaniem, jednym z kluczowych działań jest automatyzacja, którą wdraża już 65% przedsiębiorstw zbadanych przez F5.

Transformacja polegająca na powielaniu istniejącej funkcjonalności, dziś już nie wystarczy. Utrzymanie uwagi i przychylności klientów korzystających z rozwiązań IT, wymaga generowania rozwiązań cyfrowych, które są po prostu atrakcyjne i konkurencyjne. 

Wszystkie organizacje i branże powinny umożliwić programistom tworzenie kolejnych, przydatnych usług cyfrowych, aplikacji mobilnych, czy cyfrowych doświadczeń. W naszym rozumieniu oznacza to zaufanie, autonomię i świadome podejmowanie decyzji. Programiści powinni mieć możliwość wyboru narzędzi, dokonywać kluczowych wyborów projektowych i usługowych dla tworzonych przez siebie cyfrowych rozwiązań. – mówi Ireneusz Wiśniewski.

Innowacje wiążą się z kosztami

Wzmocnienie pozycji programistów jest kluczem do stymulowania innowacji, jednak dla bezpieczeństwa wymaga pewnych ram i dyscypliny. Programiści bardzo cenią narzędzia (często open source), jednak nieograniczone możliwości ich wykorzystywania prowadzą do niekontrolowanego rozrostu portfela, w którym kilka technologii może dublować wykonywanie tego samego zadania. Architektury stają się przez to znacznie bardziej złożone, z czym wiążą się także wyższe koszty zarządzania wraz z ryzykiem operacyjnym i kwestiami bezpieczeństwa. Jak pokazują analizy F5, złożoność – nawet przy bezpłatnych narzędziach open source – zwiększa koszty.

Im więcej narzędzi, tym więcej czasu zespoły odpowiadające za infrastrukturę i platformy muszą poświęcić na ich utrzymanie. Wdrażanie do pracy nowych programistów jest w takim przypadku również bardziej skomplikowane i czasochłonne, ponieważ muszą zapoznać się z interfejsem użytkownika każdego narzędzia, w tym z jego unikalnymi cechami.

Złożoność prowadzi również do potencjalnych przestojów: więcej aktywnych elementów z własnymi modelami operacyjnymi i łańcuchami narzędzi zwiększa szanse przeciążenia, utraty kontroli. Gdy dojdzie już do awarii aplikacji ryzyko utraty reputacji, klientów i finansowe rosną. Użytkownicy mogą stracić cierpliwość zanim organizacja rozwiąże problem. 

Złoty środek na budowanie wsparcia

Wsparcie budowane na czterech poniższych elementach wzmocni siły programistów, jednocześnie chroniąc organizację przed złożonością, kosztami i zagrożeniami bezpieczeństwa.

Przesunięcie w lewo

Programiści chcą kodować, żeby zbudować nowe funkcjonalności. Poświęcanie czasu i energii na kwestie bezpieczeństwa nie jest już w ścisłym obszarze ich zainteresowań. Wprowadzenie zabezpieczeń na wcześniejszym etapie cyklu życia oprogramowania sprawi, że programiści będą mieli ułatwione zadanie i zechcą uczynić je częścią swojego workflow.

Dotąd mniej niż 40% organizacji zmieniło praktyki bezpieczeństwa w sposób zgodny z zasadami DevSecOps .

Przesunięcie w lewo jest więc wdrażaniem zabezpieczeń podczas pisania kodu - niezależnie od tego, czy chodzi o oceny modeli zagrożeń, audyty kodu czy stosowanie zasad bezpieczeństwa za pomocą mechanizmów kontroli, takich jak zapora aplikacji internetowej (WAF). Ma też ułatwić wykonywanie tych zadań w ramach istniejących przepływów pracy.  

Nowoczesny open source

Programiści sięgają po open source w pierwszej kolejności. Wsparcie zadziała, gdy dostaną narzędzia pasujące do tego etosu i preferencji technologicznych. W końcu większość firm korzysta z oprogramowania open source — z Linuksem, Dockerem, Kubernetesem i tysiącami innych narzędzi na czele. 

Według raportu Red Hat The State of Enterprise Open Source na rok 2021, 90% liderów IT korzysta z korporacyjnego open source. Oferta jest ogromna. Dlatego trzeba zapobiegać nadmiernemu rozrastaniu narzędzi poprzez standaryzację na wyselekcjonowanym zestawie narzędzi open source, odpowiednich dla preferencji deweloperów w organizacji.  

Infrastruktura jako kod

Przesunięcie zabezpieczeń w lewo i przyjęcie open source opiera się na innej, najlepszej praktyce: traktowaniu infrastruktury jako kodu. Oznacza to wdrażanie kodu jako oprogramowania lub usług, które mogą być programowane przez interfejsy API.

Według raportu F5 State of Application Strategy in 2021, 52% organizacji przyjęło praktyki Infrastructure as Code (IaC). IaC oznacza, że infrastruktura może być skalowana w górę i w dół. Traktowanie całej nowoczesnej infrastruktury aplikacji jako kodu, przesuwa odpowiedzialność za konfigurowanie infrastruktury najbliżej tych, którzy najlepiej znają aplikację: programistów i zespołów DevOps. Pojawienie się kontenerów zrewolucjonizowało sposób wdrażania infrastruktury i umożliwiło deweloperom i zespołom DevOps łatwe projektowanie i wywoływanie infrastruktury najlepiej dostosowanej do ich wdrożeń aplikacji.

Architektura samoobsługowa

Przesunięcie zabezpieczeń w lewo, przyjęcie open source i wdrożenie infrastruktury jako kodu, przy jednoczesnym umożliwieniu programistom swobody w działaniu bez barier ochronnych, niesie ze sobą ryzyko operacyjne. Dlatego potrzebna jest infrastruktura samoobsługowa. Ułatwi to programistom wdrażanie potrzebnej infrastruktury i usług oraz zmniejszy złożoność przy jednoczesnej kontroli kosztów.

Raport F5 State of Application Strategy 2021 ujawnił, że 65% organizacji przyjęło automatyzację i orkiestrację. Z kolei 68% stosuje automatyzację sieci i bezpieczeństwa. Dzięki temu zespoły DevOps, NetOps, SecOps i Platform Ops mogą ułatwić deweloperom dostarczanie infrastruktury za pośrednictwem katalogów samoobsługowych, dzięki kontenerom, które ograniczają zatwierdzone wdrożenia do sprawdzonych pod względem bezpieczeństwa i skutecznych w środowisku produkcyjnym. 

To dlatego chmura publiczna stała się tak popularna. Działa jako portal samoobsługowy dla katalogu technologii przyjaznych dla programistów, umożliwiając nawet małym zespołom tworzenie i skalowanie aplikacji. Wiemy, że dostawcy usług w chmurze nie zawsze zapewniają najbezpieczniejsze konfiguracje domyślne. Dlatego tak ważne jest, aby zarządzać własnymi sprawdzonymi modelami i konfigurować je tak, aby chroniły własną infrastrukturę.

Innowacje dla produktywności i postępu

W ciągu ostatnich dwóch lat zaobserwowaliśmy, że organizacje, które szybko zaufały programistom w obszarze budowania innowacji, czerpią z tego korzyści. 

Wiele z nich stworzyło nowe kanały sprzedaży lub umożliwiło całkowitą zmianę architektury aplikacji i infrastruktury na potrzeby przyszłych rozproszonych struktur wdrożeniowych opartych na chmurze i usługach. Te organizacje są dziś w lepszej sytuacji i mogą myśleć perspektywicznie.

Przesunięcie w lewo, włączenie open source, skalowanie infrastruktury jako kodu, tworzenie architektury samoobsługowej oraz tworzenie aplikacji adaptacyjnych w oparciu o najnowocześniejsze i najbardziej odporne technologie, takie jak Kubernetes, napędzają innowacje cyfrowe. 

„Deweloper też człowiek”

Chmura nauczyła nas, że jeśli bezpieczeństwo i infrastruktura są wystarczająco łatwe w obsłudze, programiści będę mieli możliwość wprowadzania innowacji.

Opisana wyżej ochrona jest niezbędna do zapewnienia nowoczesnego, natywnego dla chmury doświadczenia, ale w bezpieczny i niezależny od chmury sposób. Programiści to ludzie, którym trzeba ułatwiać pracę, żeby możliwie szybko zyskać na bezpiecznych innowacjach na dużą skalę. 

Informacje o F5

F5 (NASDAQ: FFIV) to firma zajmująca się bezpieczeństwem i dostarczaniem aplikacji w środowiskach wielochmurowych oraz umożliwia klientom – w tym największym na świecie przedsiębiorstwom, instytucjom finansowym, dostawcom usług i rządom – wprowadzanie w życie niezwykłych doświadczeń cyfrowych. Po więcej informacji przejdź do strony f5.com. Śledź @F5 na Twitterze lub odwiedź nasz profil LinkedIn I Facebook, aby uzyskać więcej informacji na temat F5, jej partnerów i technologii.

F5 i BIG-IP są znakami towarowymi, znakami usługowymi lub nazwami handlowymi firmy F5, Inc. w Stanach Zjednoczonych i innych krajach. Wszystkie inne nazwy produktów i firm w niniejszym dokumencie mogą być znakami towarowymi ich odpowiednich właścicieli.