praktycznych przykładów jak dobrze poruszać się w chmurze
Cloud
Casebook
A
10
Dane wrażliwe w chmurze.
Jak to się robi w globalnych bankach? 5
Chmura na naszych warunkach.
Jak uniknąć uzależniania od dostawcy chmury? 7
Skalowalność chmury:
większa wydajność i oszczędności 9
Skalowalność chmury:
szersze horyzonty biznesowe 11
Bezpieczniejsza ekspansja globalna Inwestycja w odważne rozwiązania dzięki infrastrukturze chmurowej
Multicloud, hybrid cloud i on-premise 14
Wdrożenie Azure Arc Google Anthos dla giełdy
Od pustego konta AWS
do wirtualnego banku w 18 miesięcy 16
Data Lake w banku wirtualnym Tokenizacja w banku wirtualnym
Landing Zone.
Jak miękko wylądować w chmurze? 20
Spis treści
PIOTR GWIAZDA
Senior Solution Architect, GFT Poland
JAROSŁAW
SZCZEPANKIEWICZ
Senior Solution Architect, GFT Poland
ANDRZEJ SZELEMETKO
Senior Solution Architect, GFT Poland
PRZEMYSŁAW JUSZKIEWICZ
Delivery Manager APAC,
GFT Poland
KAMIL OWCZAREK
Head of Big Data, GFT Poland
ADAM ULACHA
DevOps Engineer, GFT Poland
PAWEŁ BOLONEK
Solution Architect, GFT Poland
WOJCIECH PASIERBSKI
Technical Lead, GFT Poland
PIOTR KOSMOWSKI
Cloud Solution Architect, GFT Poland
JAKUB KASPRZAK
Principal Consultant, GFT Poland
Autorzy
D la jednego z największych banków inwestycyjnych raportowanie związane z płynnością finansową, wymagane przez regulatora, było operacją czasochłonną i wymagającą dużej mocy obliczeniowej.
Jednocześnie dane wymagane do zbudowania tego typu raportów są poufne. Zdecydowano się na przeniesienie tego procesu do chmury. Aby obniżyć poziom poufności danych zastosowano pseudoanonimizację (lub tokenizację), polegającą na zastąpieniu danych wrażliwych „tokenami”, których znaczenie pozostawało znane dzięki systemom banku.
W najprostszych słowach – prawdziwe znaczenie wrażliwych danych pozostało w systemach bankowych on-prem, co jest świetnym
rozwiązaniem na przykład w momencie, kiedy do „gry” wkracza regulator. Sama tokenizacja jest procesem bardzo prostym, jednak trzeba wiedzieć, kiedy i jak ją zastosować, żeby przyniosła spodziewany efekt.
Ten przykład jest tylko jednym z wielu, które obrazują jak dobrze korzystać z właściwości chmury, jednocześnie zamykając dyskusję na temat obaw. Same zalety chmury, stan jej
wykorzystania na rynku polskim, przygotowanie do migracji – to tematy znane i szeroko opisywane w wielu dostępnych na rynku raportach. Jako GFT chcieliśmy jednak podzielić się kilkoma wyselekcjonowanymi, praktycznymi przykładami, jak sprytnie i przy pomocy odpowiednich narzędzi zmigrować pewne rodzaje systemów do chmury nie robiąc przy tym rewolucji już na wstępie. Albo – robiąc, jeśli się ma fantazję i środki!
Piotr Gwiazda,
Senior Solution Architect, GFT Poland
Słowo wstępne
Piotr Gwiazda, Senior Solution Architect GFT Poland
Wdrożone rozwiązanie musi spełniać rygorystyczne wymagania związane z bezpieczeństwem wysoce wrażliwych danych (Highly Restricted Data). Jednym z wymagań polityki bezpieczeństwa jest brak dostępu do maszyn wirtualnych za pośrednictwem protokołu SSH, co podnosi stopień skomplikowania procesu utrzymania.
Jest to pierwsze wdrożenie platformy analizującej komunikację z wykorzystaniem środowiska chmurowego, a zarazem największe na platformę Google Cloud w dotychczasowej historii banku.
Zauważamy dwa podejścia do chmury. Niektóre organizacje starają się zbudować kompletny i szczegółowy plan migracji do chmury, często inwestując w to znaczące środki. Na jego podstawie chcą ocenić opłacalność migracji i tym samym ograniczyć ryzyko. Inne organizacje skupiają się na zbudowaniu wiedzy wewnątrz swoich zespołów i przejściu przez pierwsze scenariusze biznesowe w chmurze z dostawcą, pozostawiając szeroki plan migracji w zarysie.
Nasz zespół zrealizował dwa zasadnicze cele:
Przygotowanie infrastruktury podporządkowanej rygorystycznym wymogom bezpieczeństwa wrażliwych danych
Środowisko aplikacji składa się z dziesiątek maszyn wirtualnych opartych na
platformie Google Compute Engine. Jednym z ograniczeń narzuconych przez politykę bezpieczeństwa banku jest brak dostępu do maszyn wirtualnych za pośrednictwem protokołu SSH. Uniemożliwia to wprowadzanie poprawek lub modyfikację konfiguracji zainstalowanych systemów operacyjnych. W związku z tym ustalony został proces, wedle którego każda maszyna wirtualna funkcjonuje przez ograniczoną liczbę dni, a następnie jest instalowana na nowo. Jedynym sposobem instalacji nowej wersji oprogramowania lub wdrożenia poprawek jest utworzenie danej maszyny ponownie.
#dane wrażliwe #uprawnienia #wirtualizacja #bankowość inwestycyjna #GCP
Klient z branży bankowości inwestycyjnej (międzynarodowy bank Tier 1) wdrożył globalne narzędzie do wykrywania nieprawidłowości w komunikacji wewnętrznej pracowników banku opartej o kanały e-mail oraz instant messaging. Zespół GFT opracował wysoce dostępne i skalowalne rozwiązanie, bazujące na publicznej
chmurze Google Cloud Platform. Rozwiązanie wykorzystuje sztuczną inteligencję oraz zapewnia wydajność niezbędną do analizy ponad 2.5 terabajta danych dziennie.
Dane wrażliwe w chmurze.
Jak to się robi
w globalnych bankach?
A
Sebastian Grabski, Customer Engineer, Google Cloud
W ramach prac nad rozwiązaniem, zespół GFT Poland opracował aplikację, która umożliwia dokonywanie tzw. „health checks”, tj. testów zgodności i stabilności poszczególnych maszyn oraz uruchamianie środowisk zgodnie z polityką okresowej rotacji maszyn. Bezpieczeństwo danych zapewnione jest przez stosowanie sprzętowych kluczy szyfrowania i zachowanie wysokiej granularności uprawnień w ramach polityki Identity and Access Management, oferowanej przez Google Cloud Platform. Ponadto, każda maszyna wirtualna obecna w chmurze Google Cloud domyślnie pozostaje w izolacji względem pozostałych maszyn, chyba że właściciel systemu nada jej dostęp chroniony przez firewall.
Dzięki tym rozwiązaniom, bank zyskuje pewność bezpieczeństwa danych wysoce wrażliwych i utrzymuje nad nimi pełną kontrolę. Infrastruktura uniemożliwia modyfikację oprogramowania na danej maszynie wirtualnej i tym samym eliminuje ryzyko jakiejkolwiek niepożądanej ingerencji.
Zastosowane podejście jest fantastycznym przykładem przewagi rozwiązania chmurowego nad klasyczną infrastrukturą, nawet tą zwirtualizowaną. Chmura to Wirtualizacja 3.0, która wyróżnia się tym, iż należy traktować infrastrukturę nie jako trwający byt, ale jako kawałek kodu powoływany na określony czas.
Otwiera to zupełnie nowe możliwości, ale też stwarza nowe wyzwania operacyjne, które pomagają adresować specjaliści naszych partnerów takich jak GFT.
Umożliwienie łatwej integracji funkcji biznesowych klienta na platformie GCP dzięki Google Compute Engine
Polityka klienta nie pozwala na stosowanie wszystkich managed services dostawcy chmurowego i wymaga stosowania własnych rozwiązań banku. Wynika to zarówno z troski o bezpieczeństwo i geolokalizację danych, jak i z obawy, że funkcjonujące od dawna systemy banku należałoby poddać kosztownej i długotrwałej transformacji lub nawet kompletnemu przebudowaniu w środowisku chmurowym. Zastosowanie bezpiecznych maszyn wirtualnych w ramach Google Compute Engine chronionych przez procesy rotacji pozwala jednak na przeniesienie zastanych funkcji w niezmienionej formie – jest to de facto lustrzane odbicie dotychczasowych funkcjonalności. Dzięki temu bank nie jest zmuszony do inwestycji w kosztowną transformację podstawowych systemów, a migracja na rozwiązanie chmurowe jest relatywnie łatwa. Tak też było w przypadku projektu realizowanego przez zespół GFT: aplikacja do analizy komunikacji autorstwa zewnętrznego dostawcy została skutecznie wdrożona w ekosystemie chmurowym klienta, bez konieczności kosztownej przebudowy narzędzia.
Dzięki opracowaniu skutecznej infrastruktury maszyn wirtualnych, bank był w stanie dokonać pierwszej tego rodzaju migracji danych wysoce wrażliwych do chmury, zachowując pełną kontrolę nad danymi oraz dotychczasowy, wysoki poziom bezpieczeństwa. Dzięki korzyściom w skalowalności i automatyzacji procesów oferowanym przez chmurę, koszt procesowania danych został redukowany dziesięciokrotnie.
Przygotowanie pełnego planu migracji do chmury dla wielkich organizacji jest zadaniem bardzo trudnym i będzie obarczone sporym ryzykiem błędu z uwagi na ciągłą ewolucję usług chmurowych i zmieniające się wymagania biznesu. Dla wielu firm tej skali, migracja do chmury to przedsięwzięcie planowane na lata. Dlatego też organizacje stosują często znacznie lżejsze podejście, obejmujące zbudowanie katalogu systemów rozważanych do migracji i wykonaniu dla nich kategoryzacji 6R:
Rehosting – przeniesienie bez zmian na infrastrukturę chmurową
Replatforming – przeniesienie na zarządzane platformy chmurowe
Refactoring – przeniesienie z poprawą struktury rozwiązania i technologii
Rearchitecting – całkowita zmiana systemu na nowe rozwiązania cloud-native
Retain – rezygnacja z przeniesienia systemu
Replace – zastąpienie systemu innym, najczęściej gotowym systemem
Pełna infrastruktura w kodzie
Zastosowanie platformy Kubernetes do opracowania kompletnej infrastruktury umożliwia dostarczenie wszystkich funkcji w pełnej niezależności od wybranego dostawcy chmurowego lub rodzaju architektury, także on-premise. W myśl podejścia Everything as Code, wszystkie aspekty rozwiązań – infrastruktura, bezpieczeństwo, zgodność, testowanie itd. – podlegają spójnej metodyce dostarczania. Jednocześnie możemy z łatwością przenosić całość rozwiązania, nie uzależniając się od komponentów dostawcy chmury. Jeśli lokalne uwarunkowania regulacyjne (np. dotyczące lokalizacji geograficznej data center) lub względy bezpieczeństwa wymuszą zmianę dostawcy chmurowego, przeniesienie funkcjonalności nie będzie wymagało kosztownej transformacji oprogramowania. Pozwala to na otwarcie znacznie szerszych perspektyw ekspansji, np. na nowe rynki, w których obowiązują zróżnicowane wymagania odnośnie przechowywania i bezpieczeństwa danych.
Kubernetes to open source’owa platforma do zarządzania, automatyzacji i skalowania aplikacji kontenerowych. Jego pierwotna wersja została stworzona w 2014 roku przez Google, a obecnie rozwijany jest przez Cloud Native Computing Foundation. Jest wspierany przez większość chmur publicznych i dostarczany w usłudze Platform as a Service oraz Infrastructure as a Service .
#Everything as Code #Vendor lock-in #Kubernetes #Azure
Klient dostarcza narzędzia zapewniające dostęp i zarządzanie cyfrowymi aktywami (digital assets) przez pełen cykl życia – przechowywanie, możliwość wymiany oraz obsługę podatkową i legislacyjną. Zespół ekspertów GFT
zaproponował i wdrożył infrastrukturę dla systemów opartą o platformę
Kubernetes, która odpowiadała wysokim wymaganiom odnośnie bezpieczeństwa i poufności danych, a także zredukowała ryzyko związane z uzależnieniem od dostawcy platformy chmurowej, czyli tzw. vendor lock-in – jedną z częstych przeszkód w migracji między środowiskami chmurowymi.
Chmura na naszych warunkach.
Jak uniknąć uzależniania od dostawcy chmury?
A
Największą siłą Kubernetesa jest niezależność technologiczna jaką pozwala osiągnąć. Doskonale współpracuje ze środowiskami wszystkich dostawców chmury, ale możemy używać go także na własnych, w pełni kontrolowanych maszynach, zarówno w infrastrukturze cloud, hybrid cloud, multi-cloud jak i tradycyjnej on-prem. Co więcej, ponieważ jest to rozwiązanie open-source, od lat rozwijane jest przez tysiące programistów na całym świecie - po systemie Linux, jest zresztą najszybciej rozwijanym narzędziem open source! Rozwój Kubernetesa wspierają giganci pokroju Red Hat, IBM, Oracle czy Google. To wszystko
sprawia, że Kubernetes daje ogromny wachlarz możliwości specyficznych dla różnorodnych platform. Słowem: chmura, ale na naszych warunkach.
Jak zadbać o bezpieczeństwo poza naszą kontrolą?
Infrastruktura opracowana przez GFT oferuje podwójny poziom bezpieczeństwa: działają w niej zarówno mechanizmy wbudowane w platformę dostawcy usług (w tym wypadku:
Microsoft Azure), jak i własne rozwiązania zawarte w oprogramowaniu.
System klienta składa się z narzędzi zewnętrznych dostawców funkcjonujących poza środowiskiem Kubernetes opracowanym przez GFT. Naturalnie rodzi to pytanie o zachowanie bezpieczeństwa w sytuacji, gdy dane wychodzą poza perymetr bezpieczeństwa naszego rozwiązania. W takim przypadku z pomocą przychodzą mechanizmy szyfrowania dostępne w zastosowanym przez nas brokerze informacji Apache Kafka. Mechanizm szyfrowania wiadomości wychodzących i przychodzących blokuje ryzyko przedostania się zmodyfikowanej komunikacji. Co więcej, zastosowano zabezpieczenia na poziomie infrastruktury chmurowej Microsoft Azure – wszystkie połączenia systemu są szyfrowane.
Podczas gdy bazowe usługi IaaS i PaaS dostawców chmurowych oferują zbliżone możliwości, rywalizacja przeniosła się na rynek usług specjalistycznych, głównie z obszaru bezpieczeństwa, regulacji, analityki danych czy sztucznej inteligencji.
Wykorzystanie unikatowych usług różnych dostawców, starannie dopasowanych do danego scenariusza biznesowego, może znacznie przyspieszyć wdrożenie.
Oznacza to, że ograniczenie się wyłącznie do usług, które da się łatwo przenieść do innego dostawcy spowoduje znaczne ograniczenie zysków z wykorzystania chmury, a przygotowanie rozwiązań w pełni przenaszalnych dodatkowo znacznie wydłuży czas wdrożenia. Kluczowe jest zatem rozumienie skomplikowania migracji, unikatowej wartości danego rozwiązania i ryzyka z tym związanego.
Adam Ulacha, DevOps Engineer, GFT Poland
Piotr Gwiazda, Senior Solution Architect GFT Poland
#skalowalność #big data #machine learning
Klient GFT chciał dokonać radykalnych ulepszeń w zakresie wydajności i opłacalności narzędzia do reakcji na zapytania głosowe opartego na algorytmach przetwarzania języka naturalnego. Narzędzie miało rozpoznawać temat rozmowy i przekierowywać interesanta do odpowiedniego działu, redukując w znacznym stopniu zakres pracy potrzebny do obsługi infolinii.
Skalowalność chmury:
większa wydajność i oszczędności
A
GFT zastosowało technikę klastrów efemerycznych przy wykorzystaniu platformy Microsoft Azure HDInsight, gdzie tanie i trwałe przechowywanie danych w Microsoft Azure Data Lake Storage zostało wsparte efemerycznym klastrem Apache Spark, aktywowanym do wykonania obliczeń i usuwanym natychmiast po ich zakończeniu przez Azure Cloud Power Shell. Pozwoliło to na ponoszenie kosztów części obliczeniowej rozwiązania tylko w czasie trwania faktycznych obliczeń, przy minimalnych kosztach składowania nawet masywnych danych wynikowych.
– Klastry efemeryczne to nowa technika wspomagająca oszczędność środków przy przetwarzaniu batchowym ogromnych danych, pojawiająca się na horyzoncie w związku z coraz częstszym budowaniem data center w chmurze. Polega ona na szybkim zestawianiu klastrów obliczeniowych jedynie na czas wykonywania faktycznych obliczeń. Nie jest to możliwe w środowisku „on premise” ze względu na zbyt długi czas konfiguracji klastra i konieczność ponoszenia opłat na utrzymanie maszyn i sieci również, kiedy jest on nieaktywny.
Dynamiczna i w pełni zautomatyzowana kontrola zużycia zasobów chmurowych pozwoliła na rekordowe wyniki: wzrost rzędu 2000% w zakresie zdolności przetwarzania dużych danych przy jednoczesnym zapewnieniu 8-krotnej redukcji kosztów przetwarzania.
Kamil Owczarek, Head of Big Data Practice GFT Poland
Azure HDInsight to usługa chmury Microsoft Azure umożliwiająca wykorzystanie wiodących technologii z obszaru przetwarzania dużych danych, takich jak Apache Hadoop, Kafka, Spark, Storm i innych. Wykorzystanie potencjału narzędzi Big Data w środowisku chmurowym otwiera szerokie możliwości analityczne dzięki dynamicznemu skalowaniu zasobów, najwyższemu stopniowi dostępności i mechanizmom bezpieczeństwa oferowanym przez Microsoft Azure. Co ważne, każdą usługę działającą w HDInsight można skalować osobno, co pozwala na daleko idącą optymalizację kosztów.
Apache Spark jest technologią stosowaną głównie w przetwarzaniu wsadowym pozwalającym wydajnie przetwarzać masywne dane na klastrach obliczeniowych.
Chociaż Apache Spark zyskał początkowo popularność jako technologia „on premise”, obecnie jest szeroko dostępny w chmurze obliczeniowej, na przykład w usługach Azure HDInsight, Amazon EMR, Google Cloud DataProc oraz na platformie Databricks Unified Analytics, co czyni go de facto technologią „cloud agnostic”.
W czerwcu 2020 r. opublikowano nową wersję technologii – Spark 3, która według benchmarku TPC-DS przeprowadzonego przez koncern Alibaba, uzyskuje do 17-krotnie lepszą wydajność w porównaniu do Sparka 2 i rozszerza jego możliwości w obszarach takich, jak wykorzystanie klastrów GPU do przetwarzania wektorowego. Zdaniem inżynierów GFT, szybka adopcja nowej wersji oznacza poważne usprawnienia w realizacji projektów.
Bezpieczniejsza ekspansja globalna
Firma oferująca produkty oszczędnościowe dla klientów detalicznych postanowiła rozszerzyć działalność na rynki zagraniczne, wykorzystując swoją wiedzę biznesową oraz nową chmurową platformę sprzedażowo-rozliczeniową. Negocjacje biznesowe odbywały się równolegle na rynku europejskim, brytyjskim i amerykańskim.
W każdym regionie firma planuje dostarczać dostęp do swojej usługi za pośrednictwem API dostosowanego do potrzeb partnerów w danym kraju. Domena biznesowa pozostaje niezmienna, jednak warstwa integracji różni się w zależności od regionu oraz wymagań prawnych danego kraju.
Dzięki automatyzacji wdrażania infrastruktury (Infrastructure as Code) dokonanej przez zespół GFT, rozwiązanie zostało przygotowane i przetestowane dla każdego regionu i obejmowało zarówno odseparowany Landing Zone w każdym regionie, jak i infrastrukturę systemów. System został uruchomiony w pierwszym strategicznym regionie, a celem ograniczenia kosztów, został usunięty z pozostałych w oczekiwaniu na decyzje biznesowe.
Azure API Management to usługa pozwalająca błyskawicznie udostępniać API typu REST klientom lub partnerom na całym świecie. Odpowiada za warstwę bezpieczeństwa, szyfrowania, kontroli dostępu, zgodności definicji API oraz monitorowania. Pozwala przyznawać partnerom dostęp do wycinków API lub nawet tworzyć plany cenowe obejmujące różne zestawy danych oraz limity wykorzystania API.
Przypadek ten ilustruje ogromną korzyść w zakresie skalowalności biznesu jaką oferuje globalna chmura – nie jest to jedynie możliwość łatwego i przewidywalnego rozszerzenia infrastruktury, ale także błyskawicznego jej ograniczenia w sytuacji, gdy zajdzie taka potrzeba - co pozwala na redukcję ryzyka i tym samym większe pole do testowania rozwiązań biznesowych.
Dzięki pracy zespołu GFT, klient jest w stanie uruchomić środowiska testowe i w pełni zabezpieczone środowiska produkcyjne w nowym regionie świata w przeciągu maksymalnie dwóch dni. Dzięki stuprocentowej realizacji podejścia Infrastructure as Code, tempo wprowadzania zmian jest rekordowe: dostarczenie nowej aplikacji do kilku regionów świata to kwestia kilku minut.
#skalowalność #infrastructure as code #Azure
Skalowalność rozwiązań chmurowych to nie tylko zwiększenie potencjału obliczeniowego bądź optymalizacja kosztów. Zdolność do dynamicznego przekształcenia infrastruktury otwiera szersze możliwości rozwoju biznesu.
W przypadku decyzji o redukcji skali oprogramowania, nasi klienci nie ponoszą strat wynikających z inwestycji w infrastrukturę, która ostatecznie może nie być użyta.
Dzięki temu zyskują więcej swobody w planowaniu rozwoju oprogramowania.
Skalowalność chmury:
szersze horyzonty biznesowe
A
#skalowalność #Terraform #Azure
Projekt dla klienta zajmującego się obrotem nieruchomości zrealizowany był początkowo w formie Minimum Viable Product: klient zdefiniował minimalny zestaw wymagań potrzebnych do przedstawienia wersji demo dla zarządu spółki, na bazie której miała być podjęta decyzja o dalszym finansowaniu projektu. Dzięki w pełni skalowalnej infrastrukturze chmurowej opartej na Azure Kubernetes,
możliwe było stworzenie funkcjonalnego narzędzia już na tak wczesnym etapie.
Skalowalność chmury:
inwestycja w odważne rozwiązania dzięki
infrastrukturze chmurowej
A
Zespół GFT opracował nowy system do agregacji i wyceny ogromnej liczby nieruchomości obecnych na rynkach całego świata. System składa się z dwóch zasadniczych komponentów:
Narzędzie wspomagające wycenę nieruchomości, pozwalające gromadzić rozległe i szczegółowe dane od zewnętrznych brokerów, na bazie których określana jest szacunkowa wartość rynkowa nieruchomości. Dzięki tym informacjom, inwestorzy decydują o zakupie obiektu.
Panel wglądu w globalny inwentarz nieruchomości, z efektywnym silnikiem wyszukiwania i widokiem mapy.
Architektura aplikacji oparta jest o mikroserwisy w infrastrukturze Azure Kubernetes Service. Klient posiadał już podstawowe elementy infrastruktury Microsoft Azure zarządzane przez wewnętrzny departament IT, ale nie używał ich do uruchamiania skomplikowanych rozwiązań. Zespół GFT przygotował kompleksową infrastrukturę chmurową przy użyciu Terraform.
Terraform firmy Hashicorp jest narzędziem z rodziny Infrastructure as Code służącym do efektywnego budowania, modyfikacji i wersjonowania infrastruktury. Zamiast polegać na powtarzalnej i tworzonej ręcznie konfiguracji infrastruktury, zyskujemy dzięki niemu zdolność do automatyzacji i skutecznego śledzenia zmian tak, jak ma to miejsce w przypadku kodu źródłowego oprogramowania. Terraform jest kompatybilny z rozwiązaniami wiodących dostawców chmury publicznej takich jak Amazon Web Services, Microsoft Azure czy Google Cloud Platform, a także chmur prywatnych, np. VMWare, OpenStack lub CloudStack.
Zespół GFT przygotował kod infrastruktury w Terraform, w myśl metodyki ciągłej integracji i ciągłego dostarczania (CI/CD) na bazie Azure DevOps. Aplikacje są wdrażane automatycznie i niezależnie od siebie.
Aplikacja panelu wglądu wykorzystuje funkcje GIS (PostGIS) do przeszukiwania map i nieruchomości, a także Google Maps API do określania geolokalizacji na podstawie adresu i wyświetlania zdjęć nieruchomości za pomocą Street View.
Efektywne i wydajne wyszukiwanie i przeglądanie ok. 100 000 nieruchomości jest możliwe dzięki sprawnej konfiguracji bazy danych po stronie serwera
Podczas transformacji z wersji MVP do produkcyjnej wykorzystano autorską listę kontrolną gotowości produkcyjnej w chmurze opracowaną przez architektów GFT:
Cloud P15N. Dzięki niej, proces opracowania mechanizmów bezpieczeństwa, kontroli wersji, niezawodności, tworzenia kopii zapasowych oraz obsługi dostępu do sieci zewnętrznej trwał jedynie 8 tygodni przy zaangażowaniu niewielkiego zespołu:
architekta rozwiązania i 2 inżynierów Azure DevOps.
W efekcie klient zdecydował się na przejście z fazy MVP do produkcyjnej i otrzymał narzędzie pozwalające na przyspieszenie decyzji o inwestycji w nieruchomości.
Platforma opracowana przez GFT jest łatwa w obsłudze dla podwykonawców klienta, a zarazem dostarcza dokładniejszych i bardziej kompletnych danych. Tak kompleksowe rozwiązanie wymaga znacznych zasobów obliczeniowych – zdolność skalowania infrastruktury chmurowej opracowanej przez GFT umożliwiła podjęcie ryzyka związanego z inwestycją w zaawansowane oprogramowanie.
Multicloud nie jest domyślną strategią dla każdego. Na takie rozwiązanie decydują się zwykle bardzo duże organizacje, które przewidują to w swoim modelu biznesowym i są świadome kosztów, jakie to za sobą niesie. Nie ma też jednej gotowej recepty na skuteczne rozwiązanie multicloud pasujące do każdej organizacji.
Obserwujemy organizacje, które w wyniku zawarcia strategicznych partnerstw i kontaktów zmieniają swojego głównego dostawcę usług, podejmując się projektów na ogromną skalę. Dlatego też często widzimy, że decyzja
o zastosowaniu chmury ciągnie za sobą podpisanie umów ramowych z więcej niż jednym dostawcą. Decyzje o wykorzystaniu konkretnej chmury podejmowane są później, dla każdego scenariusza biznesowego osobno w zależności od wymagań technicznych, funkcjonalnych lub prawnych. Pozostawia to organizacji potrzebną elastyczność i kontrolowanie ryzyka związanego z przywiązaniem do danego dostawcy.
Wdrożenie Azure Arc
Zespół GFT zaprojektował platformę w oparciu o architekturę mikroserwisów, wdrażaną na dwóch klastrach Kubernetes. Wykorzystano platformę multicloud autorstwa Microsoftu: Azure Arc posłużył do utrzymania klastrów wdrożonych zarówno w Azure, jak i Google Cloud Platform. Dzięki Azure Arc możliwe jest rozszerzenie jej o dowolny inny skonfigurowany klaster Kubernetes, znajdujący się u dowolnego dostawcy usług cloud, w dowolnym regionie, a także w infrastrukturze on-prem.
Obciążenia aplikacyjne wdrażane są w obu klastrach i zarządzane oddzielnie przez poszczególne Kubernetes Control Planes. Główny punkt wejścia do aplikacji korzysta obecnie z Front Door, ale może to być dowolna brama, która jest w stanie skierować ruch do Kubernetes Ingress. Obciążenie jest zrównoważone pomiędzy klastrami w oparciu o zastosowane strategie wysokiej dostępności.
#hybryda #środowiska wielochmurowe
Nasi klienci są świadomi korzyści, jakie oferują rozwiązania w chmurze, takich jak skalowalność, elastyczność kosztowa, bezpieczeństwo, automatyczne aktualizacje itp. Mogą jednak obawiać się uzależnienia od dostawcy (vendor lock-in), czy też zagrożeń wynikających z przetwarzania wrażliwych danych ograniczonych przez lokalne przepisy. Firmy mogą też być niechętne wdrożeniu rozwiązań chmurowych jeśli zainwestowały już w infrastrukturę on-prem. Odpowiedzią na tego rodzaju ograniczenia są podejścia hybrydowe i wielochmurowe.
Multicloud, hybrid cloud i on-premise
A
Piotr Gwiazda, Senior Solution Architect GFT Poland
Waldemar Skrzypiec, Cloud Solution Architect, Microsoft
Andrzej Szelemetko, Senior Cloud Architect
& Head of Google Cloud Partnership
Zarządzanie heterogenicznym środowiskiem w swoim własnym, multicloudowym czy też hybrydowym centrum przetwarzania danych nie musi być koszmarem. Azure Arc pozwala na reprezentację zasobów w Azure i traktowanie ich jak natywnych serwisów. Dzięki temu można zarządzać nimi w ten sam, jeden i wystandaryzowany sposób. Platforma pozwala zarządzać klastrami Kubernetes na wielu chmurach i w środowiskach on-prem bezpośrednio z poziomu portalu Azure i jednocześnie wdrażać spójne polityki bezpieczeństwa i konfiguracji pomiędzy tymi klastrami w myśl podejścia GitOps. Wykorzystuje otwarte i sprawdzone w branży standardy, takie jak Flux i Open Policy Agent.
Nasze rozwiązanie wykorzystuje usługę Azure Policy, która pomaga zdefiniować rzeczone standardy jako zbiór programowalnych polityk. Polityka Azure Arc wykorzystuje Open Policy Agent jako silnik polityki oraz Gatekeeper Agent zainstalowany na klastrze Kubernetes. Oznacza to, że wszystkie polityki można przenosić między dostawcami, a rozwiązanie pozostaje odporne na problem vendor lock-in.
Google Anthos dla giełdy
Globalna giełda papierów wartościowych zwróciła się do GFT z potrzebą przebudowania konwencjonalnej infrastruktury danych na nowoczesne środowisko hybrid & multicloud.
Ograniczenia klasycznego data center hamowały rozwój biznesu klienta. Podjęto decyzję o przeniesieniu wszystkich aplikacji korporacyjnych do chmury działającej na platformach kontenerowych, co wymagało rozłożenia przetwarzania na różne platformy chmurowe (Google Cloud Platform i Amazon Web Services) oraz systemy on-premise oparte o rozwiązania VMware. Co ważne, migracja wszystkich aplikacji z dotychczasowego centrum danych musiała odbyć się bez jakichkolwiek przestojów w funkcjonowaniu.
Platforma Anthos firmy Google umożliwiła rozdzielenie zadań obliczeniowych poprzez umieszczenie ich w niezależnych fizycznie i geograficznie klastrach Kubernetes zarządzanych z tego samego interfejsu. Utworzenie spójnej platformy do rozwijania aplikacji i zautomatyzowanego egzekwowania polityki na przestrzeni całego, różnorodnego środowiska wielochmurowego, ułatwia wdrażanie oprogramowania stworzonego przez programistów po stronie klienta.
Tworzenie nowej aplikacji opartej o mikroserwisy czy też modernizacja istniejących rozwiązań często zaczyna się od przygotowania odpowiednich środowisk oraz narzędzi, które ułatwią i przyspieszą wdrażanie zmian. Platformy deweloperskie tego rodzaju wkraczają dynamicznie do świata oprogramowania. Google Anthos stanowi w dużej mierze gotową odpowiedź na tego rodzaju wyzwania: to zestaw dobrych praktyk i narzędzi „z pudełka”, których budowanie od podstaw wymagało dotychczas wielu tygodni pracy. Anthos oferuje wiele funkcjonalności: przykładowo, Anthos Service Mesh zapewnia bezpieczeństwo sieci oraz konfigurowalną komunikację między serwisami. Anthos Config Manager pozwala na konfigurację klastrów i polityk oraz wydawanie aplikacji w modelu GitOps. Co więcej, Anthosa można uruchomić w różnych środowiskach chmurowych, we własnym data center, a nawet w urządzeniach brzegowych - lub też podpiąć do niego istniejące klastry. Myślę, że z uwagi na tak wysoki stopień elastyczności, w najbliższym czasie będziemy obserwować wiele wdrożeń tego narzędzia, także w polskich przedsiębiorstwach.
Pracując ściśle z klientem, zespoły GFT przygotowały w pełni zautomatyzowaną platformę opartą o Anthos Google Kuberntes Engine dla ponad 30 aplikacji
korporacyjnych klienta. Ważnym kryterium sukcesu było zapewnienie maksymalnego stopnia bezpieczeństwa kontenerów w całej organizacji. Nowa platforma została skonfigurowana tak, by zapewnić jak najwyższą efektywność kosztową, maksymalną wydajność w środowisku on-premise oraz skuteczny mechanizm przenoszenia obliczeń do chmury jedynie wtedy, gdy jest to absolutnie konieczne.
Hong Kong Monetary Authority, czyli rodzaj centralnego banku w Hong Kongu, zauważył potrzebę innowacji w tym sektorze i zadecydował o przyznaniu licencji bankowych dla ośmiu podmiotów, które chciały zainwestować w banki bez fizycznych placówek. Z tej licencji, w porozumieniu z partnerami - regionalnym dostawcą usług telekomunikacyjnych oraz biurem podroży online - skorzystał Standard Chartered. Bank wykonał niesamowity zwrot w kierunku nowego klienta i stworzył zupełnie nową organizację, która korzysta z jego doświadczeń bankowych. Wychodzi jednocześnie naprzeciw oczekiwaniom konkretnej grupy użytkowników. Zapewnia natychmiastowy dostęp do pieniędzy niezależnie od miejsca i czasu, pozwalając na przykład na wydanie decyzji kredytowej w ciągu 30 sekund od złożenia wniosku
Elastyczny system core’owy
W budowie banku uczestniczyła niespełna setka inżynierów GFT w znakomitej większości pochodzących z Polski, którzy pracowali w kilku odrębnych zespołach.
Sercem banku został nowoczesny, gotowy system corebankingowy Vault firmy Thought Machine. Vault pozwala na tworzenie produktów finansowych „as code” za pomocą systemu smart kontraktów. Inteligentny kontrakt wykorzystuje kod jednego z dwóch najbardziej popularnych języków programowania na świecie – Pythona. Dzięki temu jest zrozumiały dla niemal każdego dewelopera. To wszystko sprawia, że Vault ma bardzo ważną przewagę konkurencyjną: mamy nad nim pełną kontrolę, a jego producent nie jest niezbędny przy absolutnie każdym kroku związanym z aktualizacjami, dostosowywaniem jego funkcjonalności czy wdrażaniem nowych produktów. Inteligentne kontrakty umożliwiają nowemu bankowi i GFT bezpośredni nadzór nad nimi, pozwalając na wprowadzanie zmian bez konieczności oczekiwania na interwencję dostawcy.
#virtualbanking #innowacja #AWS
Jednym z najciekawszych współczesnych trendów w bankowości jest powstawanie banków wirtualnych. Zaletą takiego banku jest przede wszystkich całkowite oderwanie od fizycznych placówek, dzięki czemu jego usługi mogą być dostępne 24/7 w każdym miejscu na Ziemi.
Jeden z pierwszych wirtualnych banków na świecie powstał w ostatnich miesiącach w Hong Kongu, a jego zbudowanie zainspirowane zostało przez brytyjskiego giganta bankowości, który chciał stworzyć produkt idealny dla pokolenia „digital natives”, nie ograniczony przez
“czynnik ludzki”, czyli godziny pracy obsługującego go zespołu.
Od pustego konta AWS
do wirtualnego banku w 18 miesięcy
A
Przemysław Juszkiewicz, Delivery Manager Asia Pacific, zarządza zespołem odpowiedzialnym za budowę i rozwijanie banku
Jarosław Szczepankiewicz, Senior Cloud Solution
Architect, GFT Poland
Jarosław Szczepankiewicz, Senior Cloud Solution
Architect, GFT Poland
Taki system w pełni wykorzystuje zalety chmury publicznej. Dodatkowo, jego zastosowanie pozwala ominąć długotrwałe procesy dostosowania istniejących systemów do nowych wymagań. Zmiana w drugim przypadku wymaga długotrwałego kontraktu z dostawcą, drobiazgowej analizy, kompatybilności wstecznej oraz przede wszystkim dużej akumulacji kapitału i długiego czasu oczekiwania na zwrot z inwestycji. Nowoczesne systemy corebankingowe z kolei udostępniają bardzo granularne API do dyspozycji integratora. System nie wymusza konkretnej wersji języka, bibliotek itp. Istnieje możliwość utrzymywania każdej warstwy w swoim własnym cyklu życia.
Cała infrastruktura banku spoczywa na chmurze AWS. Vault wykorzystuje skalowalnosc Kubernetesa i moc obliczeniową Amazon EC2, a do zarządzania krytycznymi danymi transakcyjnymi używa Amazon RDS PostgreSQL. W przyszłości będzie również korzystał z Amazon EKS dla Kubernetesa i Amazon MSK dla Kafki żeby jeszcze lepiej dostosować działanie do wymagań rynku.
Sprawny od pierwszego klienta
Tradycyjne banki, które korzystają z technologii opartej na własnych centrach danych, muszą opierać się na starannych prognozach dotyczących rozwoju rynku, żeby odpowiednio zaplanować wymagające inwestycje i wprowadzanie nowych produktów.
Ten problem nie dotyczy banku wirtualnego, który może sobie pozwolić na pewną dozę eksperymentowania. Taki bank może wprowadzać usługi dla bardzo małego wolumenu klientów przy stosunkowo niskich kosztach i przy zastosowaniu skalowalnej technologii. Optymalizację wydajności i zasobów czerpanych z chmury wspiera sam silnik Vault, dzięki czemu możliwe jest budowanie wachlarza usług bez zakładania z góry wyników banku.
Płacenie tylko za zużyte zasoby i moc obliczeniową to luksus, który nigdy nie był w zasięgu tradycyjnych systemów bankowych. Dzięki możliwościom, jakie daje nam chmura, nie musimy dostosowywać istniejącej infrastruktury do przewidywanych wzrostów. Jest to bezpieczne rozwiązanie również w przypadku nagłej zmiany koniunktury na rynku.
Dziś nowy klient banku wirtualnego może zostać onboardowany w mniej niż trzy minuty. Od momentu jego zaplanowania do wejścia z bogatym wachlarzem usług na rynek minęło 18 miesięcy, a po zaledwie miesiącu funkcjonowania, ma już 35 000 zarejestrowanych użytkowników. Bank może operować na takim poziomie usług poprzez wykorzystanie architektury event-driven w chmurze do ustalania priorytetów działań oraz inteligentnych kontraktów w Vault do szybkiej aktualizacji aplikacji. GFT z kolei, pracując w oparciu o zwinne zespoły DevOps, może w błyskawicznym tempie przystąpić do wprowadzania nowych produktów i usług.
Data Lake w banku wirtualnym
Nowoczesnym podejściem do przechowywania danych, które zapewnia znacznie większą elastyczność i skalowalność, jest Data Lake. W jego myśl struktura danych nie jest definiowana a priori, co oznacza, że możliwe jest przechowywanie dowolnego rodzaju danych bez konieczności czasochłonnego projektowania ich struktury lub modyfikowania jej na wypadek pojawienia się rekordów nowego rodzaju. Co więcej, wszystkie dane trafiają do takiego zbioru w postaci surowej, mamy więc dostęp do ich pierwotnego obrazu. Przetwarzamy z kolei tylko te, które chcemy w danej chwili wykorzystać.
Daje to znacznie większe możliwości w obszarze analizy: dane przechowywane w ramach Data Lake są pozbawione ciężaru strukturyzacji i dzięki temu można je łatwiej analizować i porównywać za pomocą technik z obszaru Data Science. Utrzymanie efektywnego Data Lake wymaga zdefiniowania standardów przetwarzania i katalogowania danych – w przeciwnym razie ryzykujemy powstaniem tak zwanego „Data Swamp”, czyli repozytorium o wysokim stopniu nieuporządkowania, z którego nie sposób uzyskać wartościowe z punktu widzenia procesów biznesowych informacje. Sprawna polityka data governance pozwala uniknąć tego rodzaju degradacji jakości oraz określić, czy Data Lake to w ogóle odpowiedni dla nas format.
Bank wirtualny potrzebował nowoczesnej platformy danych opartej na chmurze, która zapewni wysoki stopień skalowalności oraz wydajności kosztowej, jak też gotowość przyjmowania nieustrukturyzowanych danych pochodzących z mikroserwisów, systemów wewnętrznych klienta i systemów zewnętrznych. Co więcej, konieczne było sprostanie wymaganiom regulatora w zakresie raportowania. Zespół inżynierów danych (w tym programiści Python i Cloud) przy wsparciu inżynierów DevOps wdrożył rozwiązanie Data Lake oparte m.in. na object store w chmurze AWS (S3), Apache Spark i Confluent Kafka. Zastosowanie koncepcji Data Lake w połączeniu z dostępnością i skalowalnością chmury AWS umożliwiło utworzenie samodzielnego katalogu danych dla całej organizacji.
Główne benefity tego rozwiązania to możliwość przetwarzania wszelkich danych pojawiających się w banku (również w kontekście przyszłych, nieznanych jeszcze potrzeb), śledzenia pełnej ścieżki podróży i transformacji danych (data lineage) oraz zdecentralizowana platforma do przetwarzania i konsumpcji danych.
Apache Kafka jest systemem messagingowym typu open source, który charakteryzuje się bardzo niskimi opóźnieniami (na poziomie pojedynczych milisekund) w przekazywaniu wiadomości oraz wyjątkowo dobrą skalowalnością.
Z tego powodu Kafka stała się niezwykle popularną technologią przy budowaniu systemów analitycznych czasu rzeczywistego i jest dostępna „out of the box” na platformach Microsoft Azure oraz AWS. Kafka jest sercem systemu messagingowego i głównym źródłem informacji przetwarzanych w banku.
Systemy do przetwarzania danych potrzebują odpowiednich mechanizmów do planowania zadań (ETL), ich synchronizacji oraz budowania zależności pomiędzy nimi. Dzięki wykorzystaniu rozwiązania open source – Apache Airflow i podejściu opartemu na konteneryzacji, udało się osiągnąć wysoką skalowalność i niezależność procesów. System przetwarzania zadań został zdecentralizowany zgodnie z najlepszymi praktykami wywodzącymi się z Domain Driven Design (subdomeny – Bounded Contexts). Uzyskany w ten sposób poziom bezpieczeństwa i izolacji pomiędzy domenami, pozwolił na stworzenie systemu spełniającego wysokie wymagania regulatorów.
Tokenizacja w banku wirtualnym
Pracując nad budową data lake’ów dla wirtualnych banków, tak jak rozwiązań hybrydowych łączących w sobie elementy chmury prywatnej i chmury publicznej, wielokrotnie zetknęliśmy się z sytuacją, w której określone podzbiory danych nie mogą być zgodnie z prawem wykorzystane w pewnych obszarach systemu, który budujemy.
Przykładowo, w Polsce i Unii Europejskiej regulacje związane z RODO / GDPR, często praktycznie uniemożliwiają przechowywanie danych osobowych klientów (PII) fizycznie w chmurze publicznej, podczas gdy w wielu z pozostałych krajów, podobne zarządzenia wydają lokalni regulatorzy np. sektora finansowego.
W związku z tym znajdujemy się w sytuacji, w której elementy jednego systemu nie mogą bezpośrednio wymieniać się wymaganymi danymi bez złamania prawa. Ta sytuacja może być poważną przeszkodzą w budowaniu systemów opartych o chmurę hybrydową lub składowaniu danych pochodzących z systemów „on premise” w chmurze publicznej celem redukcji kosztów budowy data lake’ów.
Istnieje wiele potencjalnych technicznych rozwiązań tego problemu, przekonaliśmy się jednak, że jednym z najbardziej uniwersalnych i tanich jest zastosowanie tokenizacji. Jest to proces, w ramach którego newralgiczne dane przed przekazaniem do części systemu, w której nie mogą zostać użyte, zostają zastąpione tokenem - syntetyczną referencją do tych danych. Następnie, przy przenoszeniu danych z powrotem do „strefy bezpiecznej”, może zostać wykonany proces odwrotny, nazywany detokenizacją.
Im bezpieczniejsza tokenizacja, tym więcej zasobów jest potrzebnych na jej wykonanie.
W naszych projektach zastosowaliśmy jednak cache’owanie tokenów, co pozwoliło nam zniwelować ograniczenia narzucane na architekturę systemów przez unikanie wielokrotnej tokenizacji i detokenizacji. Dzięki temu mogliśmy zbudować systemy lepiej dostosowane do zadań, do których zostały przeznaczone.
W omawianym przypadku, tokenizacja pozwoliła nam połączyć system core banking wirtualnego banku z zewnętrznym data lake. Dane typu PII nie wydostawały się poza
„landing zone” dake lake’a, zgodnie z wymaganiami nałożonymi przez lokalnych regulatorów tego banku. Zachowaliśmy przy tym swobodę operacyjną w ramach data lake, potrzebną to tworzenia wokół niego rozbudowanych aplikacji analitycznych mających na celu usprawnienie funkcjonowania banku.
CHMURA PUBLICZNA
CHMURA PRYWATNA lub ON PREM
TOKENIZER/DETOKENIZER USŁUGA 2
USŁUGA 1 USŁUGA 4 USŁUGA 5
USŁUGA 3 USŁUGA 6
TOKEN
RAW DATA RAW DATA RAW DATA
RAW DATA
TOKEN TOKEN TOKEN
DANE PII NIEDOZWOLONE
Przygotowanie do lądowania
Często stosowaną praktyką jest zbudowanie minimalnej wersji Landing Zone dla pierwszego projektu chmurowego i przygotowanie się na rozbudowę w przyszłości.
Jednak dla dużych organizacji finansowych jest to jeden z najważniejszych kroków i poświęca mu się dużo uwagi szczególnie, gdy strategia obejmuje więcej niż jedną chmurę. Podstawowe zadania Landing Zone to:
Rozliczenie kosztów wykorzystania chmury
Kontrola dostępu dla użytkowników
Integracja sieci wirtualnych z sieciami organizacji
Przechowywanie historii zmian na chmurze
Podstawowe, automatycznie weryfikowane polityki bezpieczeństwa
Procesy wdrażania na chmurę
Segregacja środowisk na produkcyjne i testowe
Planowanie infrastruktury zapasowej
Monitoring usług chmurowych
#migracja #infrastruktura #automatyzacja
Landing zone jest pierwszym krokiem do wejścia w chmurę. Kiedy rejestrujemy się u dostawcy chmury, nowe konto można porównać do pustego magazynu z tylko jednym gniazdem zasilania. Aby stworzyć swoje centrum danych, należy zbudować wszystko od podstaw.
Obejmuje to szafy, regały, przełączniki sieciowe, Meet Me Rooms, Load Balancery, firewalle, serwery, pamięć masową, kopie zapasowe, DR i całe odpowiednie okablowanie. Budowanie tej początkowej konfiguracji infrastruktury w chmurze to właśnie Landing Zone.
Landing Zone.
Jak miękko wylądować w chmurze?
A
Tranquility Base – „miękkie” pierwsze lądowanie
Ciekawym rozwiązaniem na rynku jest open source’owe Tranquility Base, „Datacenter as code” opracowane przez GFT. Zbudowane przy użyciu współpracującego ze wszystkimi platformami chmurowymi języka Terraform, jest infrastrukturą (IaC) umożliwiającą deployment aplikacji u różnych dostawców chmury. Pod jednym interfejsem znajdują się referencyjne architektury GCP i AWS. Cloud-agnostic landing zone, działające zgodnie z metodyką DevOps, znacznie redukuje czasochłonny proces przygotowania do migracji.
Współpracując z doświadczonym zespołem DevOps można więc zacząć korzystać z możliwości chmury w ciągu zaledwie kilku dni, nie kilku miesięcy.
Landing zone dla klienta GFT
Globalny dostawca z branży spożywczej przeprowadził analizę swojej strategii technologicznej i doszedł do wniosku, że migracja do chmury pozwoli na wyciągnięcie lepszej wartości biznesowej z dużych zbiorów danych, przechowywanych lokalnie w kilku niezależnych systemach SAP oraz Salesforce i Workday. Zadecydowano o wprowadzeniu pilotażowego programu migracji celem zastosowania rozwiązań Machine Learning dla danych przeniesionych do chmury. Klient zdefiniował docelowy model infrastruktury Big Data, do której należało zmigrować zasoby.
Ograniczone ramy czasowe na postawienie gotowego środowiska AI i ML oznaczały, że landing zone musi powstać szybko, żeby można było poświęcić więcej czasu na konfigurację serwisów związanych z przetwarzaniem danych, które dostarczały rzeczywistej wartości biznesowej. Tranquility Base było dobrym wyborem, ponieważ posiada wbudowane, predefiniowane wzorce z najlepszymi praktykami, dzięki czemu można było szybko przejść do projektowania infrastruktury danych.
Cała infrastruktura implementowana za pośrednictwem Tranquility Base bazuje na cloud agnostic Terraform Infrastracture-as-Code, z prekompilowanymi modułami „aktywatorów”
dla specyficznych komponentów, włączając w to usługi AI i ML. „Aktywator” to w Tranquility Base rodzaj architektury referencyjnej dla danego typu aplikacji, zapewniający ujednolicone środowisko niezależnie od chmury, dzięki czemu aplikacja jest łatwo przenaszalna. Użycie istniejącego katalogu oraz odpowiednio skompilowanych
„aktywatorów” pozwoliło na przyspieszenie fazy testów.
W efekcie wspólnie z klientem wypracowaliśmy stabilną, skalowalną i wystandaryzowaną architekturę na Google Cloud Platform, którą
zaimplementowaliśmy w ciągu kilku dni przy użyciu Tranquility Base. Zawierały się w niej takie elementy jak środowisko do testowania rozwiązań ML i bezpieczna infrastruktura danych zoptymalizowana do analizy danych.
Copyright © 2020 GFT Poland Sp. z o. o.
O GFT
GFT to międzynarodowa firma specjalizująca się w tworzeniu rozwiązań technologicznych dla biznesu, wspierających rozwój sektora finansowego, ubezpieczeń i przemysłu. Zespół światowej klasy specjalistów GFT łączy umiejętność pracy w regulowanych środowiskach z kompetencjami w obszarze chmury, sztucznej inteligencji czy Internetu Rzeczy. Wysokie kwalifikacje ekspertów firmy potwierdzają liczne certyfikaty czołowych operatorów chmurowych: Google, AWS i Azure.
Dzięki wiedzy zgromadzonej podczas wieloletniej współpracy z globalnymi klientami oraz silnym parterstwom, GFT bezpiecznie przeprowadza klientów przez proces biznesowej zmiany i zapewnia optymalizację kosztów. Odpowiednia skala pozwala firmie angażować się w projekty zgodnie z zasadą „Big enough to deliver, small enough to care”. Firma powstała w 1987 roku Niemczech. Obecnie jest zlokalizowana w 15 krajach i zatrudnia ponad 6000 osób, z czego ponad 900 w Polsce - w Łodzi, Poznaniu, Warszawie i Krakowie. Spółka GFT Technologies SE jest notowana w segmencie Prime Standard Giełdy Papierów Wartościowych we Frankfurcie (ticker: GFT-XE).
REDAKCJA: MARTA PIOTROWSKA, MACIEJ SOPEK
