Przyszłość API w obszarze operacyjnym
W ostatnich latach interfejs oprogramowania aplikacji API ewoluował od ściśle powiązanej specyfikacji imperatywnej – nakazowej do luźno powiązanego modelu deklaratywnego. Najpopularniejsze obecnie interfejsy API są RESTful i służą do integracji. Niezależnie od implementacji oraz trybu wywoływania są zwykle związane z tworzeniem i rozwijaniem aplikacji. Ciągle jednak rozwija się inna gałąź API, która łączy się z procesami operacyjnymi – tutaj „A” oznacza automatyzację.
Interfejsy API w obszarze operacyjnym dają możliwość zautomatyzowania procesu wdrażania, konfiguracji i obsługi infrastruktury oraz usług aplikacyjnych. Dlatego API potrzebne do obsługi działań operacyjnych muszą koncentrować się na upraszczaniu automatyzacji.
Takie podejście jest istotne dla wchodzących w drugą fazę transformacji cyfrowej organizacji, w których następuje ekspansja automatyzacji procesów dostarczania i wdrażania. Skalowanie automatyzacji wymaga zdolności do opracowania spójnych, powtarzalnych i przewidywalnych procesów, które odzwierciedlają pipeline wdrażania aplikacji.
Raport Kentika na temat stanu automatyzacji w 2019 r. wskazał, że ponad połowa organizacji (53%) już używa automatyzacji do konfiguracji sieci, a kolejne 40% korzysta ze zautomatyzowanego zarządzania zasadami (policy). Badania F5 Networks pokazują, że odsetek ten może być znacznie wyższy - aż 86% respondentów automatyzuje sieć. Te same badania (State of Application Services) wykazały również rosnącą spójność automatyzacji w całym procesie wdrażania.
Zmieniają się narzędzia używane przez organizacje. Chociaż Python jest nadal jednym z najpopularniejszych, w obszarze IT obserwujemy rosnące znaczenie DevOps i aplikacji natywnych dla chmury. Pipeline wdrażania jest coraz częściej napędzany przez narzędzia takie jak Jenkins i Ansible oraz uruchamiany przez repozytoria takie jak GitHub i GitLab Enterprise. Wybiegając w przyszłość: infrastruktura i usługi aplikacji będą oparte na praktycznych wnioskach uzyskanych dzięki zaawansowanej analizie.
To systemy, a nie ludzie, będą odwoływać się do API w całym procesie wdrażania. Dlatego trzeba zaprojektować API specjalnie z myślą o automatyzacji. Oznacza to potrzebę rozważenia następujących czynników:
1. System
Konieczne może okazać się rozważenie systemu, z którego można wywołać operacyjny interfejs API. Dane dostępne z Jenkins lub repozytorium będą bez wątpienia znacznie różnić się od danych pochodzących z tradycyjnych narzędzi i usług automatyzacji sieci. Może to oznaczać pozyskiwanie danych z innych źródeł lub, w miarę możliwości, stosowanie standardowych wartości.
2. Użytkownik
Większość naszych systemów uwierzytelniania zakłada dziś, że użytkuje je człowiek. Dlatego trzeba uwzględnić potrzeby wywołania interfejsów API przez „poświadczoną maszynę”, niezależnie od wywołania „poświadczonego użytkownika”. Klucze API mogą być dobrym rozwiązaniem, niemniej będą wymagać wiedzy (po stronie operacyjnej IT) aby wdrożyć, obsługiwać i zarządzać systemem zaprojektowanym do uzyskiwania poświadczeń tylko przez maszyny. Jest to krytyczne dla trzeciej i ostatniej fazy transformacji cyfrowej, w której usługi aplikacyjne oraz operacje wspomagane AI będą brały na siebie większą część obciążeń operacyjnych.
Cieszy fakt, że możemy używać narzędzi do tworzenia skryptów, dzięki którym można zautomatyzować procesy operacyjne. Pamiętajmy jednak, że w przyszłości będziemy myśleć o „A” w API jako o automatyzacji (przynajmniej jeśli chodzi o zakres operacyjny) ze względu na to, w jaki sposób wpłynie na interakcje i wywołania między maszynami, a nie ludźmi.
Lori MacVittie, Principal Technical Evangelist, Office of the CTO at F5 Networks
