Budowa nowoczesnej architektury SOA przy wykorzystaniu szyny usług
Założenia stojące za architekturą SOA (architekturą zorientowaną na usługi) były i są jak najbardziej słuszne i solidne. Niestety, to sposób ich implementacji często zawodzi, powodując porażkę projektów i frustrację u menadżerów – szczególnie tych odpowiedzialnych za budżet. Natomiast idea architektury usługowej może z powodzeniem być fundamentem filozofii stojącej za integracją systemów i aplikacji, a nowoczesna szyna usług – o ile będzie to rozwiązanie zapewniające zwinność i elastyczność – wielokrotnie udowodniła swoją skuteczność.
Wprowadzenie – kilka słów o architekturze usługowej
Architektura usługowa (Service Oriented Architecture – SOA) została uznana zarówno za nowoczesne i elastyczne podejście do budowy połączeń aplikacji w przedsiębiorstwach, jak i bardzo kosztowne i czasochłonne we wdrażaniu. Niespełnione oczekiwania przy realizacji licznych projektów mających na celu budowę architektury SOA, spowodowały wiele frustracji i rozczarowań. Niejedna firma odrzuciła szynę usług jako rozwiązanie integracyjne po takiej próbie lub nawet kilku próbach.
Rozwiązanie, jakie Unity Group proponuje swoim klientom wyrażającym potrzeby integracji systemów, to odmienny sposób myślenia o SOA i szynie usług. Zamiast postrzegać ESB jako kosztowne „pudełka”, które przedsiębiorstwo kupuje, warto zacząć rozważać wybór rozwiązania przez pryzmat pryncypiów i wzorców prawidłowej integracji, szczególnie z perspektywy architektury IT. Innymi słowy, rozważając integrację systemów IT i wybór stosownych rozwiązań i partnerów, należy pamiętać o SOA, gdyż jest to istotny kamień milowy w budowie architektury i realizacji wzorców integracyjnych.
Założenia SOA są wciąż słuszne
Kluczowym założeniem architektury SOA było i jest projektowanie oraz budowanie architektury IT przedsiębiorstwa w oparciu o usługi, a nie o całe aplikacje. W takiej architekturze kluczowe jest budowanie komponentów (usług), czyli niewielkich, separatywnych części oprogramowania, realizujących konkretną funkcję i, co bardzo istotne, które są reużywalne dla innych aplikacji i systemów. W takim modelu zorientowanym na usługi rolą dewelopera jest głównie tworzenie nowych aplikacji poprzez łączenie zestawów usług, a nie budowanie całych aplikacji od zera. W założeniu i praktyce eliminuje to powtarzalność funkcjonalności w aplikacjach w architekturze, a tym samym zmniejsza czas niezbędny do realizacji. Jako przykład można podać aplikację bankową (zrealizowaną w architekturze SOA) uczestniczącą w procesie udzielania kredytów. Składałyby się ona m.in. z usług sprawdzania statusu kredytowego, usług kalkulujących odsetki i usług związanych z danymi klientów.
Zgodnie z teorią, SOA powinna rozbijać masywne „silosy” logiki biznesowej i danych, które najczęściej gromadzone są w osobnych aplikacjach. Te zestawy logiki i danych mogą istnieć w oprogramowaniu lokalnym lub w chmurze, w aplikacjach SaaS, itp. W modelowej formie, SOA powinna umożliwiać interoperacyjność pomiędzy wszystkimi elementami logiki biznesowej i źródłami danych poprzez integrację, co z kolei skutkuje przyspieszeniem i ułatwieniem automatyzacji procesów biznesowych.
To zorientowane na usługi podejście do architektury ma wiele zalet:
- Dzięki większej elastyczności zbudowanych w ten sposób systemów informatycznych i oprogramowania procesów biznesowych, przedsiębiorstwa mogą reagować na zmiany znacznie szybciej i wydajniej.
- Łatwiejsze staje się np. wprowadzanie innowacji do nowych produktów, tak aby zachować konkurencyjność i budować przewagę rynkową.
- Dzięki wdrożeniu architektury SOA przedsiębiorstwa mogą zredukować nadmiarowość i złożoność często występujące w starszych systemach (legacy), zoptymalizować koszty IT związane z utrzymaniem i aktualizacjami oraz zwiększyć produktywność zespołów IT, czyniąc projektowanie oprogramowania bardziej intuicyjnym.
Można z przekonaniem rzec, iż idee SOA nie są złe. Po prostu liczne próby wdrożeń nie spełniły tej obietnicy.
Proponowane podejście do SOA – szyna usług
Możliwym powodem wielu niepowodzeń wdrożeń architektury SOA było to, że zostały zainicjowane w sposób „odgórny”. Uruchamiano je jako pojedynczą, zmasowaną inicjatywę, obejmującą swym zasięgiem całą organizację. Podejście to, często było związane ze specyfiką dostawców oraz producentów rozwiązań (wielkie marki) i wymagały drogich, wieloletnich, wieloetapowych wdrożeń. Niejednokrotnie z udziałem rzeszy kosztownych konsultantów. Były niezwykle pracochłonne i czasochłonne, a zespół projektowy klienta często musiał się uczyć i wykorzystywać wdrażany produkt do ponownego zaprojektowania wszystkich istniejących systemów, a także zaprojektować nowe aplikacje zgodnie z zasadami SOA. Deweloperzy niekiedy musieli zastąpić swoje znane narzędzia, procesy, a także umiejętności i przekwalifikować się, aby dostosować no nowej rzeczywistości. Miało to negatywny wpływ na możliwość szybkiego wprowadzania innowacji i nadążania za tempem zmian.
Innym sposobem podejścia do problemów, które adresuje SOA, jest lekka, open source’owa szyna usług (ESB), np. Mule ESB lub WSO2. Taka szyna może wspierać tworzenie i orkiestrację usług bez konieczności stosowania rozbudowanych pakietów oprogramowania integracyjnego (często z bardzo drogą licencją) lub np. komponentu infrastruktury, eliminując wysokie koszty początkowe implementacji SOA. Zamiast przeciągniętego w czasie okresu analizy i implementacji, ESB można wdrożyć i zacząć używać w bardzo krótkim czasie. Dzięki temu programiści mogą tworzyć używalne interfejsy z interfejsami API, stopniowo budując i rozwijając nową architekturę w oparciu o pryncypia SOA. Przykładem takiej architektury jest model API-Led Connectivity.
Szyna usług umożliwia firmom sukcesywną adopcję SOA, bez konieczności rewolucji w architekturze. Ponieważ rekomendowane przez Unity Group rozwiązania są budowane zgodnie z otwartymi standardami (open source), dają one klientom dużą elastyczność w zakresie integracji szerokiej gamy systemów, usług chmurowych i aplikacji. W przeciwieństwie do wczesnych inicjatyw z obszaru implementacji SOA, ESB pokroju Mule czy WSO2, nie wprowadzają tzw. vendor locka, czy też nie narzucają ściśle określonego (często wygodnego dla producenta) wzorca integracji i docelowej architektury. Pod wieloma względami szyna usług realizuje to, co obiecują założenia SOA.
Korzyści wynikające z zastosowania szyny usług
Szyna usług doskonale nadaje się do projektów integracyjnych i może sprawić, że łączenie systemów będzie efektywne i szybkie. Istnieje jednak wiele innych komponentów składających się na nowoczesną architekturę dla dzisiejszych organizacji. Na przykład firmy, które chcą oprzeć integracje o API, będą potrzebowały sposobu na ich projektowanie, budowanie, zarządzanie i zabezpieczanie. Potrzebne są także mechanizmy, które pozwolą na realizację ciągłej integracji / ciągłego wdrażania (CI/CD).
Zarówno Mule ESB, jak i WSO2 ESB oferują nie tylko niezawodną łączność między systemami, ale również pełne zarządzanie cyklem życia API na jednej platformie. Platformy te zostały zbudowane na potrzeby DevOps i zwinnego rozwoju z myślą o wykorzystaniu popularnych i uznanych narzędzi, używanych do ciągłej integracji i ciągłego wdrażania (CI / CD), tj. SCM, Maven, JUnit, Jenkins. W utrzymaniu szyny usług, a więc zapewnieniu ciągłości biznesowej, krytyczne są także aspekty monitorowania. Tu z pomocą przychodzą narzędzia wbudowane i dostarczone wraz z szyną usług przez producentów. Istnieje jednak możliwość (często rekomendowana przez Unity Group) wykorzystania dodatkowych rozwiązań zewnętrznych, takich jak ELK, które nierzadko są już znane i stosowane przez naszych klientów.
Tak zunifikowana platforma integracyjna wykorzystująca zasady SOA i funkcjonalność szyny usług – wdrażana przez zaufanego i kompetentnego partnera – pozwala stworzyć zorientowaną na usługi architekturę IT. Zapewnia ona elastyczność i niezawodność po to, aby pozostać konkurencyjnymi w dzisiejszym otoczeniu.
Jeżeli chcesz dowiedzieć się więcej o architekturze SOA, koncepcji API-led oraz narzędziach do zarządzania cyklem życia API, zapraszamy do zapoznania się z naszą ofertą oraz kontaktu!
