Ewolucja architektury oprogramowania i DevOps: Krótki przegląd historyczny

Rozwój technologii jest nierozerwalnie związany z rosnącym zapotrzebowaniem na bardziej niezawodne i łatwe w utrzymaniu rozwiązania z zaawansowanymi funkcjami bezpieczeństwa, co jest szczególnie istotne we współczesnym świecie. Ponadto firmy starają się skrócić czas wprowadzania produktów na rynek, co jest dziś kolejnym ważnym czynnikiem.

Rozpoczęliśmy serię artykułów poświęconych ewolucji architektury oprogramowania i DevOps. Przyjrzymy się kontekstowi historycznemu, głównym etapom rozwoju architektury oraz trendom kształtującym przyszłość świata technologii. W tym artykule szczegółowo omówimy kluczowe etapy ewolucji architektury oprogramowania i jej rolę w DevOps. 

Przegląd historyczny

Pierwsze zastosowania architektury monolitycznej pojawiły się w latach 50. XX wieku i były szeroko rozpowszechnione aż do lat 90. XX wieku. Podejście monolityczne cieszyło się popularnością ze względu na ograniczenia sprzętowe, ograniczenia metod rozwoju i modeli wdrażania. Mimo że umieszczenie wszystkich komponentów w pojedynczej bazie kodu stanowiło wyzwanie, monolityczna architektura była prosta i pozwalała na scentralizowaną kontrolę nad rozwiązaniem. 

Następnym etapem była architektura klient-serwer (lata 80. XX w. – lata 2000.). Wraz z upowszechnieniem się komputerów osobistych (PC) i lokalnych sieci komputerowych (LAN) wdrożenie tego podejścia stało się nieuniknione. Aplikacje zaczęto dzielić na część kliencką i serwerową: klienci zarządzali zatem interfejsami użytkownika, a serwery danymi i logiką biznesową.

W latach 90. XX wieku architektura trójwarstwowa zyskała popularność i jest nadal szeroko stosowana. Wymaga dodatkowej warstwy pośredniej między klientami i serwerami, zwanej serwerem aplikacji lub oprogramowaniem pośredniczącym. Aplikacje dzielą się na warstwę prezentacji, aplikacji i danych, co zapewnia ich modułowość i skalowalność.

W latach 2000. pojawiła się architektura zorientowana na usługi (SOA), która nadal jest aktualna. Polega ona na tworzeniu luźno powiązanych, wielokrotnego użytku usług, które współdziałają ze sobą za pośrednictwem standardowych protokołów, takich jak SOAP i REST. SOA promuje interoperacyjność, elastyczność i ponowne wykorzystanie, ale wymaga ostrożnego zarządzania cyklem życia usługi.

Nowoczesne podejścia do architektury oprogramowania reprezentowane są przez architekturę mikrousług i architekturę bezserwerową. Oba podejścia pojawiły się w latach 2010. i nadal należą do najpopularniejszych.

Architektura mikrousług umożliwia podzielenie aplikacji na małe, niezależne usługi, które komunikują się ze sobą za pośrednictwem protokołów HTTP i kolejek komunikatów. Każda usługa odpowiada za określoną funkcję i może być rozwijana, wdrażana i skalowana niezależnie od pozostałych.

Przykładem udanego przejścia na mikrousługi jest rozwiązanie dla naszego klienta. Platforma została zbudowana na monolitycznej podstawie i podjęto decyzję o przejściu na architekturę mikrousług. Pozwoliło nam to na szybkie dostosowywanie się do zmian technologicznych, prawnych itp., a także na zaoszczędzenie czasu i pieniędzy, które moglibyśmy przeznaczyć na przyszły rozwój i wsparcie.

Przejście na mikrousługi pozwoliło na szybką integrację systemu rozliczeniowego dla dystrybutorów klienta: utworzone zamówienia były automatycznie synchronizowane w obu systemach, co uprościło zarządzanie dokumentacją i generowanie sprawozdań finansowych.

Architekturę bezserwerową często nazywa się funkcją jako usługą (FaaS), ponieważ pozwala deweloperom skupić się na pisaniu kodu jako funkcji, zamiast zarządzać infrastrukturą. Funkcje są wykonywane w kontenerach w odpowiedzi na określone zdarzenia, a dostawca chmury automatycznie zarządza infrastrukturą. Głównymi zaletami podejścia bezserwerowego są minimalizacja kosztów konserwacji, płacenie wyłącznie za wykorzystane zasoby i szybkie skalowanie. Jednocześnie może ograniczyć wybór dostawcy usług i wpłynąć na wydajność kodu.

W ramach jednego z naszych projektów planowaliśmy wykorzystać architekturę bezserwerową. Jednak w trakcie pracy zetknęliśmy się z innymi rzeczywistościami.

Główną zaletą przetwarzania bezserwerowego jest jego skalowalność. Jednak w przypadku klienta wolumen żądań wiązał się z milionami wykonań funkcji każdego miesiąca. Chociaż rozwiązania bezserwerowe skalują się automatycznie, koszty związane z tak dużą liczbą operacji stały się poważnym problemem. 

Ponadto zarządzanie dużą siecią indywidualnych funkcji w środowisku bezserwerowym może być trudnym zadaniem. Debugowanie, monitorowanie wydajności i utrzymywanie pojedynczych wersji kodu wymagają znacznych zasobów.

Co dalej?

Jeśli chodzi o przyszłość architektury oprogramowania, eksperci są zgodni, że kluczową rolę odegrają sztuczna inteligencja (AI), uczenie maszynowe (ML), obliczenia kwantowe i przetwarzanie brzegowe. Będziemy omawiać te trendy bardziej szczegółowo w przyszłych artykułach, dlatego bądź na bieżąco z naszym blogiem, aby dowiedzieć się więcej.